Akkor egy 32 bites szám egyes Byte-jai így is kiszámolhatóak:

24 bites számokkal nem volt gondom, de 32 bitessel előjött valamiféle számítási hiba. Sajnos nem emlékszem már milyen.

Koszonom, szoval nincs direkt lehetoseg. Csak erdekes, hogy ha dw van...
Bell: "Ha egy kellene" alatt az 1db 32 bites szamot ertettem...

Ha nem előjeles, akkor lehetne egy makrót írni, ami tetszőleges sorrendben leteszi db/dw direktívákkal.

Mint lentebb, a 32 bites számot 4 darab 8 bitesre (b0,.. b3) alakíthatod, amit jól kezel az MPASM.

Sziasztok!
Újabb nonszenszbe futottam bele az adó-vevő kapcsán.
Ha a szinkronjel (500 usec) után mindössze egy byteot küldök, és ellenőrzöm, hogy az érkezett-e meg ami kell, több mint 20 méter a hatótáv, stabil kapcsolattal.
Ha három byteot küldök, 5 méter után, a távolság növekedésével egyre többször érkeznek hibás adatok.
Ha már öt byte az adat, a stabil kapcsolat távolsága 1 méter alá esik. Mi okozhatja ezt?

A konkrét program ismerete nélkül ezt senki sem fogja Neked megmondani.
Pl. primitív protokoll, zavarérzékeny gagyi RF modul, időzítési hibák tömkelege, stb..
Érdemes lenne menet közben az RF modul kimenetét hallhatóvá tenni, szkóppal rámérni.

Szia!
A vevő AGC fokozatát zavarja, hogy az adás egyenszintje nem állandó. Próbáld ki, hogy az adatot Manchester kóddá lalakítva küldöd át. Ebben a kódolásban a DC szint állandó lesz. Esetleg az is megoldása lehet, hogy az egyes adat byte -ok után a negáltjukat küldöd át. Ekkor a DC szint két byte -ra átlagolva lesz állandó.
Egy kis segítség.

Szia!
Amit a DC szintről írtál, azt értem.
De az adat negát átküldésétől csak az eredő szint lesz állandó. Adás közben végig változik.
A Manchester kódolással viszont az a problémám, hogy nem jöttem rá, hogyan tudnám dekódolni.

Legyen a távitat:
0x55, 0x55, 0x55 , 0xAA, adatbyte1, neg(adatbyte1), adatbyte2, neg(adatbyte2), adatbyte3, neg(adatbyte3), chksum, neg(chksum)
Ekkor minden páros sorszámon kezdődő egymás utáni két byte -os egységre a DC szinit azonos lesz. Az egymást követő 0x55, x055, 0xAA -ról felismerhető a távirat kezdete.
Manchester kódolásra és dekodolásra példa.

Sziasztok!
Segítsséget szeretnék kérni. Elakadtam egy egyszerű timer vezérelt megszakítással.
Egyszerűen nem történik meg a megszakítás.
Inicializálás ide vonatkozó része:

A CBLOCK:

A megszakítási indítása:

A megszakítási rutin:

Az ide vonatkozó programrészlet:

Hol hibáztam?

Milyen PIC? A megszakításnál ORG?

PIC18F14K22.
Magas prioritású megszakítás címe 0x0008
Alacsony prioritású megszakítás címe 0x0018

Hát a megszakítás része elég fura nekem. Én tanultam:


Ha mellékelnéd az egész asm-et, könnyebb lenne segíteni.

Eddig oké!
De a megszakítási rutin nem lóghat bele az alacsony prioritású megszakítás kezdőcímébe.
Ez most pont ideférne, de így szoktam meg.
Viszont amit csak most vettem észre, hogy az org-nál nagy x-et, írtam. Ez befolyásolhat valamit?
A program többi része nem befolyásolja ezt a részt. Itt kellene bekapcsolódnia a megszakításnak, és a rutin végén letiltásra kerül. Timer1 sincs máshol használva, ahogy PORTA,0 sem.
PORTA,0-ra szorgalmasan érkeznek a jelek, tehát csak azért ragadhat be itt a program, mert timer1 nem vált ki megszakítást. De nem értem, hogy miért?

Nem tudom, hogy befolyásol-e, de nem hinném. A fordító úgyis kiabál ha nem stimmel. Tedd fel az asm-et vagy küld el mélbe, mert így sötétbe tapogatózás csak.

Ez egy kisérlet 1 vezetékes adattovábbításra, kétsoros kijelző számára.
Előszőr kiír egy szöveget, ami a programmemóriában van eltárolva,
majd belép a Jelfigyelés rutinba, és addig ott van, míg nem kap újabb képernyőtartalmat.

Ez így le sem fordul.... Az itteni 166, 167 sorból hiányzik, hogy melyik bitet szeretnéd állítani.

A 166, 177 sornál nálam jelezne, hiányzik a 0.

Jogos!
Ez pár perce még így nézett ki:

CSak közben is próbálkozok mindennel.

Akkor is kelle a Timer1 megszakítás, ha a PORTA,0 még nem jött jel?

Én leszimuláltam és az INTCON, GIE piszkálása volt a baj kiszedtem akkor a szimulátor is generált megszakítást, amíg bent volt a BCF INTCON, GIE .. BSF INTCON, GIE addig nem.

Nekem az a fura, hogy a Timer1 már a program elején indítva van, de a megszakítás engedélyezése, csak jóval később, miután PORTA,0-nál már bejött egy jel. Addig csak megy magában, viszont ha azon túlmegy akkor egyből megszakításba megy mert a flag bit már rég 1-ben van.
Ha a 162,163 sorba ezt írom:

Egyből van Timer1 megszakítás.

Pont az a lényeg, hogy csak akkor legyen megszakítás, ha már az indítójel bejött. A flagbitet pedig még az előtt törlöm, hogy a megszakítást bekapcsolnám. Megpróbáltam már fordítva is, hogy a megszakítás folyamatosan legyen aktív, és timer1-et tiltom. De úgy sem működik. Miért?

Értem. Szimulátorban ez így pedig működik, viszont ha ez az elképzelés, akkor nem csak a TMR1L-et kellene feltölteni egy értékkel, mert az Isten tudja, hogy a TMR1H mennyi lesz, mire bejön az első jel.

Lehet, hogy rávezettél a hibára!
Én ugyanis timer 1-et 8 bites módban akartam üzemeltetni. Így aztán várhatom a megszakítást. Holnap lepróbálom timer2-vel. Majd megírom az eredményt.

Amikor a TMR1L-t feltöltöd, töltsd fel a TMR1H-t b'11111111'-val és akkor csak az alsónak kell elszámolnia 255-ig a megszakításhoz. De csinálhatod TIMER0-val is, az csak 8 bites alapból.
Ha pontos megszakításokat akarsz akkor ez jól jöhet: Bővebben: Link

Szia!
Timer2-vel hibátlan.
Ráadásul még egyszerűbb is, mert nem kell értékkel feltölteni, mivel PR2-vel meghatározható, hogy meddig számoljon.
Most így néz ki:



Ráadásul elég komoly szórást is elvisel.
PR2 értéke 191-202-ig állítható. Tehát 197-re állítva +-2,5%-os frekvenciaszórást elvisel.
Köszi mindenkinek a segítsséget!

Idézet:
„Nem segít a bádogtető lejtésének emelése, ha jó nagy lyuk van rajta.”

Ilyen szép, szemléletes műszaki hasonlatot nem hallottam az elmúlt félszáz évben... (Esetleg az "Eccerű, mint a faék" fogható hozzá.)

Sziasztok!

Kérlek, segítssetek!
Adott egy PIC18F46K22-es microcontroller.
Az a problémám vele, hogy a D port bemenetnek konfigurált lábai valamiért nem érzékelik a magas szintet. Az A, a B, és a D port egy része bemenet. Fizikailag ugyan úgy vannak felépítve. Közvetlen a PIC lábain mérve, ha egy bemenet sem aktív, a felhúzóellenállások által mérhető a tápfeszültség. Ha egy bemenet aktív, 0V van a lábon. Ehhez képest ha D port megfelelő lábait lekérdezem, mindegy mi van rajtuk, alacsony szintet mutatnak.
Ezek a beállítások:


Mi nem jó?