Szia,
Megnéztem az adatlapban ezt a kódrészletet.
Bár nem próbáltam, de érdekes hogy nem működik. Lehet a szimulátor rosszul kezeli ezeket a regisztereket.
Illetve, nem hinném hogy ez a gond, de fontos megjegyzés, hogy a BRA utasítással nem éred el a teljes programmemóriát. A teljes programmemória ~65kB, de BRA-val csak 1kB "távolságra" tudsz ugrani, ugyanis a BRA mögé írt címből (ami egy label, de abból számolja ki a címet a fordító) csak az alsó 11 bit fér bele az utasításba (amiből még lejön az előjelbit).
Bár ha nagyobbat írsz lehet kiabál a fordító.
Mindenesetre én kerülném az összes ilyen utasítás használatát: BC, BN, BNC, BNN, BNOV, BNZ, BZ (ezekkel ráadásul jóval kisebb "távolságra" lehet ugrani, csak 127 byte!) és a BRA-t.
Hát vagy nagyon-nagyon körültekintően kell használni: ha biztosan tudja az ember, hogy a label, amire ugrik, tutira nincs 127 (illetve 1023) byte-nál nagyobb távolságra (és nem is lesz!).
Illetve BRA-hoz hasonló megkötése van még az RCALL-nak is, na azzal futottam bele ilyen hibába. Ezt is kerülöm.

A BRA működik, mert visszalép oda ahová kell. Ami nem működik az az INFSZ, mert amikor nullázódik az EEARDH regiszter, akkorsem ugorja át a BRA-t.

Szia !
Találtam egy fórum bejegyzést (#12), ahol ugyanebbe a problémába ütköztek.
Itt az írják , hogy a szimulátor a hibás , elméletileg ez a pic-ben jól hajtódik végre ( nem próbáltam )
Itt ajánlják a plusz egy "nullás értéket" tesztelő sort :
incf EEADRH
tstfsz EEADRH

Szia!
Köszönöm, ez működik!
Egyébként nem szimulátor hiba, mert az INCFSZ EEARDH utáni utasítások nem hajtódnak végre, tehát itt "elakadt" a program a valóságban is. De ezzel a kiegészítéssel tökéletesen működik.

Idézet a PIC16F887 adatlapjából (DS41291D-page 26):


Idézet a PIC18F6622 adatlapjából (DS39646B-page 77)

A kihasználatlan bitek a SFR regiszterekben a 18F2266 -nál nem garantáltan 0 értékűek.
Egy kis változás a dokumetáció írójának, hagy gond a programozónak.

Innetől az egyik verzión fog működni, de egy másikon már nem biztosan.

Csak az nem világos, hogy az INCFSZ-nél mi váltja ki az ugrást amikor eléri a nullát? Mert ha a regiszer teljes értéke nem nulla, akkor a TSTFSZ sem működne. Vagy rosszul gondolom?

Normál regiszternél FF-ből (túlcsordul) és 00-ba vált ,
de az EEADRH regiszternél lehet hogy 03-ból 04 lesz (lenne),
de valami törli a nem használt biteket ,
és lehet emiatt nem teljesül a incfsz utasítás.
De így kiderült , hogy néhány PIC leírásban hibás a program példa.

Az adatlap is lehet hibás, nem szentírás csak a fele Mondom én, hogy ilyen kérdéses állapotot nem szabad kihasználni, normálisan meg kell írni a programot, különben meg kijön egy új revision chip, és lehet csodálkozni mi változott, mitől más a progi futása.

Nem kérdéses az állapot. A regiszter értéke nulla a túlcsordulás után, ugyanúgy mintha 8 bites lenne, hiszen akkor a TSTFSZ sem működne ha bármelyik bit is nem nulla a regiszterben.

Akkor használd ki. Fél év mulva próbálsz módosítani a progin, aztán csodálkozol hogy pl mint írod a szimulátorban nem megy, de akkor már ki emlékszik rá... Igy pl máris kizárod magad a szimulátor használatából... Vagy ugye telerakod a programot feltételes fordítással attól függően hogy szimulátorra, vagy procira fordítasz. Te tudod...

Az "unknown" bármit jelenthet: egyes utasítások végrehajtásakor vagy más egyéb körülménytől függően más értéket adhat.
Pl a jó öreg Z80 input / output indirekt címzésű utasításai csak a 8 bites C regisztert említik, de a processzor a címbusra a BC regiszterpár értékét teszi ki. Milyen jó lehet, ha a INI vagy IND vagy azok INIR, INDR változatánál mivelezek az utasítások módosítják a B tartalmát.

Ezt értem. Ami nem világos, hogy az ugrás kiváltása szempontjából mi a különbség a INCFSZ és TSTFSZ között? A jelenlegi példában az egyik működik, a másik meg nem, pedig mindkettő akkor ugrik ha a regiszter értéke nulla, tehát nem akármennyi, mert akkor egyik utasítás sem működne. Ez miért lehet?

Hello! Esetleg zéró vizsgálat előtt maszkold ki a szükségtelen biteket. (AND) Akkor tudni fogod hogy az tényleg nulla és nem valami tetszőleges érték.

Nem az ugrás kiváltásával lesz itt a gond, hanem az incfsz egy RMW művelet, a tstfsz nem. Az eredmény valahol a kontroller belsejében keletkezik az incfsz esetében, míg a tstfsz -nél az operandus alapján dönti el, hogy ugrik vagy sem. Ebből már ki is jöhet egy kis eltérés.
Ilyen esetben az is kérdéses, hogy egyes silicon revision mellett működni fog, egy másokon már nem.
Jobb lenne a maszkolást beletenni - örök élet és egy nap / bármely megvalósításon működnie kell majd.

Még jobban végiggondolva:
EEADRH értéke legyen 0x3.
Az incfsz EEADRH,f végrehajtása az alábbi:
- beolvassa az EEADRH regiszter értékét oparandusként,
- az ALU növeli az értékét és beállítódnak a flag bitek is.
- kiírja az értéket az EEADRH regiszterbe.
Az utolsó lépésben 0x4 -et ír az EEADRH regiszterbe (hiszen más regiszterrel is végrehajthatjuk), de csak a két alsó bitje "marad meg" viszont az ALU a 0x04 alapján állítja be a STATUS regiszterben a Z bitet. Azaz az eredmény nem lett nulla. z=0

A tstfsz EEADRH az első lépést ugyan úgy végrehajtja, de 0-val komparál az ALU. Ez eredmény szerint beállítja a Z bitet. Itt már Z értéke 1 lesz.