Fórum témák
» Több friss téma |
A legegyszerűbb, ha az adatbájtokat számolod.
Úgy érted, hogy ha tudom, hogy az átküldendő adat mondjuk 100 bájt, akkor minden egyes bájt küldése után növelek egy változót és ha az eléri a 100-at akkor van vége?
Igen.
Én inkább az adatbájtok számát tölteném a változóba, és azt csökkenteném, ha nulla, akkor vége - azt könnyebb figyelni.
Ha még szükség van rá esetleg ez segíthet Bővebben: Link.
Idézet: „...az eddigiekben olyan rutint használtam ami az egyes beolvasott értékek után 0x00-val xor-t csináltam és a Z bitet figyeltem...” Sok helyet szabadíthatsz fel: A movf utasítás állítja a Z jelzőbitet.
Hát ezt még emésztenem kell, mert elsőre nem nagyon értem, hogy mit kell az INDF-be tölteni és miért.
Nem az INDF a lényeg, lehet ott bármelyik regiszter. Maga a movf utasítás álltja a Z bitet. ((Ezért nem használható a mewgszakítási rutin végén a W mentett értékének visszaállítására.))
Nem is kell w-be tölteni, használhatod f-el is, így önmagába tölti vissza, csak közben beállítja a Z bitet.
Ezt már értem, de az még nem világos, hogy egy táblázatból meghívott adatok végének jelzésére, hogyan kell ezt használni.
Az utóbbi hozzászólások arról az esetről szólnak, amikor 0x00 tartalmú bájt jelzi az adatok végét.
Értem, akkor ez nekem nem jó most, de egy szöveg kiírásénál jó lehet. A te általad javasolt bitszámolós megoldást tegnap kipróbáltam, az jól működik!
A retlw nem állítja a Z bitet. 18F -eken a movf TABLAT,w vagy movf TABLAT,f állítja.
A hozzászólás módosítva: Márc 18, 2015
Péter mester. Összeraktam a szintillesztődet. Üresjáratban működik mint a kisangyal. Nézd át az áramköröd, méricskélj, mert valamit nagyon elnéztél.
Egyenlőre csak 16F van nálam, de ezt nem nagyon értem. Van egy DT táblám mondjuk 200 byte-tal, mindenféle értékkel, hogy tudom a végét jelezni a Te módszereddel?
- Van olyan érték, ami nem fordul elő a táblázatban: erre az értékre való komparálás
(pl. ASCII karakterek esetén a 0x00 vagy olyan karakter, aminak a 7. bitje 1.) - Nincs ilyen érték: darabszám figyelése.
Értem! Akkor marad a második variáció, mert egy kép esetében minden előfordulhat.
Nem akar működni ez a DT -vel létrehozott tábla dolog. Egy címke alá betettem a DT táblát, CALL -lal hívom az adatokat belőle sorba és rutinnal feldolgozom. De mindig csak az elsőt olvassa be belőle. Mit csinálok rosszul?
A hozzászólás módosítva: Márc 19, 2015
Hol növeled meg a címet?
Az AN556 sokat segíthet.
Egy BRW hiányzik (vagy addwf PCL, F).
A hozzászólás módosítva: Márc 20, 2015
Így kéne?
Így sem megy, az első beolvasás után megakad a végrehajtás. A hozzászólás módosítva: Márc 20, 2015
Mivel a PCL-nek csak az alsó 8 bitet használhatod max. 255 elem lehet, de ez is csak akkor, ha a Picture 00-ás címnél kezdődik. Ezt úgy biztosíthatod, hogy elé raksz pl. egy org 0x2000-et, vagy valami kerek címet.
Szia!
Evvel a PCL-el én már feladtam a küzdelmet. Sosem működött normálisan. Használd inkább a TABLAT-ot!
Én meg annakidején a 8-bites PIC-ekkel adtam fel a küzdelmet, mert beleuntam a sok korlátozásba, meg nyomi megoldásba. A 16-bites PIC24 és dsPIC programozása egy álom hozzájuk képest. Még egy LED villogtatáshoz is inkább 16-bitest használok.
Szia!
Ahogy a többiek is írják, (feltéve, hogy 18F-ről van szó) használd a táblaolvasó műveleteket, sokkal jobb, és 18F-re már inkább ajánlott azokat használni. Főleg akkor tud nagy segítséget nyújtani, mikor ciklusban olvasol ki adatokat, mert van automatikus pointer növelés/csökkentés, külön utasítás nélkül! Ja, és nagyon egyszerű a használata.
18F se tetszett?
 Szerk.: asm vagy C? A hozzászólás módosítva: Márc 20, 2015
Én 16F-el kezdtem Basicben. Aztán egyre több assembly betétet kellett alkalmaznom az optimális működés érdekében, így idővel jobbnak láttam a teljes programot assemblyben írni. A regiszterek kevés száma, a címzésmódok hiánya, a szűkös bitszélesség és hiányos utasításkészlet aztán arra késztetett hogy váltsak valami korszerűbbre. Először az Atmel cuccaival szemeztem (mert 8-bites téren az AVR egyértelműen jobb mint a PIC.), de a PIC24-es család aztán megnyerte a tetszésemet minden téren. (A PIC18 család nem ad elegendő plusszt a PIC16-hoz képest. Ezért ez is kilőve.) Nálam elsőrendű dolog a könnyű és hatékony programozhatóság - assembly nyelven. Ebben a PIC24 ill. dsPIC - szerintem - verhetetlen.
|
Bejelentkezés
Hirdetés |
