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.

Broken Breakpoint hibakereséskor

Sziasztok!

Miért nem aktív a töréspont?

Köszönöm.

Ha a State nevű változót nem használod máshol, akkor nagy valószínűséggel a teljes


sort eldobja az optimalizáló algoritmus, mert hát minek is pörögni a semmin. Ezzel a töréspont is elveszik. Lehet, hogy nulla szintű optimlizálásnál megmarad, de nem biztos, némi rendezgetést úgy is végrehajt.

Memória mentése

Sziasztok!

Van egy bemenetválasztó panelkám relékkel és ledekkel, gombokkal.
Hogyan kell megcsinálni, hogy kikapcsoláskor, jegyezze meg az utolsó állapotokat?
Van valami regiszter, ami figyeli a feszültséget, vagy annak csökkenését (BOR), vagy valami (és akkor gyorsan menteném az állapotot)? Vagy pedig, kell egy A/D-t használni, mint feszültségfigyelő. Aztán, ha valamennyi alá megy a tápfeszültség, akkor menti a pic eeprom-ját? 18F2620-at használok.
Azt mondta a barátom, hogy minden gombnyomás után kéne menteni, de akkor, szerintem túl sokat írkálnánk a belső eepromot. Így viszont csak egyszer kéne, kikapcsoláskor.
Ha tudnátok programozni, hogyan oldanátok meg (elvi síkon)?

Az adatlap az adat EEPROM-ra 1 millió törlési/írási ciklust ad meg átlagos élettartamnak. Nem tartom valószínűnek, hogy egy bemenetválasztó nyomógomb ennél nagyobb igénybevételnek lenne kitéve.

Köszi a választ.
Nem tudom. De akkor minden lenyomásnál írja/menti az eepromot? Nem pazarlás/túlzás?
Egyszer csinált nekem valaki ilyet, kb.20 éve.
Az egyik lábat használta valahogy, és azt figyelte, valami fesz.osztó lehetett.

Én így szoktam, lásd melléklet.

Ha olyan külső eszköz közvetlen csatlakozik a PIC-hez amelyiknek aktív H kimenete van (pl. UART TX vonal), akkor biztos ami biztos alapon azzal is sorbakötve egy 1 kΩ-os ellenállás, mert ott előbb jelenhet meg a feszültség, mint a PIC táplábain.

Bekapcsoláskor minden láb bemenet. Ez egészen addig így is marad és pörög magában a kontroller, amíg figyelő lábon minimum 4 V meg nem jelenik (5 V tápfeszültség esetén)*. Ha ez megvan, akkor a láb felügyeletét átveszi egy komparátor és indulhat a program lényegi része.

Tápfeszültség elvesztésekor a komparátor generál egy megszakítást, a megszakításban minden lábat bemenetre kapcsolok, mentem az adatokat és RESET(); A 4400 µF viszonylag sok, újraindításkor megeshet, hogy a kondenzátor még életben tartja a kontrollert, viszont a tápegység már nem szolgáltat energiát. Erre az esetre (is) jó a bekapcsoláskori figyelés.

* Én újabb kontrollereket használok, azok alacsonyabb feszültséggel is elindulnak, nálad nem lesz elég a 4 V-os küszöb.

Köszönöm neked is!
Hát, már kész a nyák és be van ültetve.
Mcp23016 portbővítők vannak rajta.

Sziasztok !
Egy speciális EERAM megoldás a microchip-től : 47C16
a tápfeszültség megszűnésekor elmenti EPROM-ba , majd a tápfeszültség visszatérésekor visszatölti a memóriába.

Nyilván meg lehet oldani, de az esetedben a panelon levő relék élettartama hamarabb fogja bekorlátozni a készülék élettartamát. Ha mindenképpen minimalizálni akarod az adat EEPROM "kopását", akkor kiegészítő hardver nélkül a legegyszerűbb megoldás, ha csak az utolsó gombnyomás után pár másodperccel mented az EEPROM-ba a beállítást. Ennek mondjuk megvan az a hátránya, hogy ha váltás után azonnal kikapcsolod a készüléket, elveszhet az utolsó beállítás. Másik lehetőség, ha nem mindig ugyanarra a helyre írod, hanem körbejársz a memóriába. Ezt kicsit bonyolultabb megoldani, mert az állapot mellett egy folyamatosan növelt számláló értéket is be kell írni, hogy tudd melyik volt az utolsó kiírt érték. A kikapcsoláskori verziókat meg mások már leírták.

Köszönöm. Később még jó lehet ez is.

Mekkora memoria teruletet kellene menteni? Ha nem tul nagy akkor alkalmazzal FRAM-ot. (gyors, kis energiaigenyu, szinte elnyuhetetlen 100 bill I/O muvelet)