PIC: PCLATH en RETLWs weirdness

Laatst kwam ik een link naar de Open Random Bit tegen. Da's een open source hardware Random Number Generator (eigenlijk Random Bit Generator), op basis van een PIC 12C671, met alleen een 100K weerstand als extern component.
Ik was juist bezig met een andere hardware RNG, maar die had meer componenten en 12V nodig, dus dit leek me een goede vervanging. Alleen is de 12C671 een OTP apparaat, en ook nog eens lastig te verkrijgen.
De 12F683 heeft evenveel geheugen, maar is een Flash-chip, en dus voor de hobby veel geschikter.

Ik ben bezig geweest om de firmware te porten naar de 12F683, maar ik krijg het niet goed aan de praat. Als ik de boel simuleer in MPLAB, dan zie ik allerlei zaken fout gaan met de program counter, en ontstaat er zelfs een underflow! Dit zie ik ook gebeuren in de originele gepubliceerde code -- zit er dan een fout in die code, of houdt MPSIM zo zijn eigen methoden er op na?

Uiteraard heb ik AN556 grondig doorgenomen, maar ik snap nog iets niet. Ik zie het volgende gebeuren:
- De PCLATH wordt gezet voor bank 3, waar een lookup-tabel in zit die 32 waardes bevat;
- Een call wordt gedaan naar de subroutine, waar de instructie 'addwf PCL,F' uitgevoerd wordt, zoals te doen gebruikelijk;
- De retlw keert terug naar de aanroepende routine, maar dan twee instructies verder dan waar de call gebeurt. De instructie die direct na de call volgt wordt dus niet uitgevoerd.
- Er worden nog wat berekeningen gedaan, en dat wordt met een goto terug gesprongen naar eerder in de loop. En doordat de PCLATH gezet wordt, komt dit midden in de lookup-tabel terecht die eerder werd aangeroepen, de retlw wordt uitgevoerd en we hebben een stack underflow!

Is dit nou code die nooit gewerkt kan hebben? Is MPSIM onbetrouwbaar in deze gevallen? En belangrijker -- hoe krijg ik het opgelost? Voor elke call en goto de PCLATH expliciet zetten?

Funny (onzichtbare) karakters in de source file hebben wel het eens het effect dat een source regel niet vertaald wordt. Dat kan je controleren in de output listing van de assembler.

Werkt het wel als je de originele source met de simulator test? Dan heb je toch een foutje gemaakt.

Op 30 september 2007 21:57:48 schreef JoWi:
Funny (onzichtbare) karakters in de source file hebben wel het eens het effect dat een source regel niet vertaald wordt. Dat kan je controleren in de output listing van de assembler.

Werkt het wel als je de originele source met de simulator test? Dan heb je toch een foutje gemaakt.

Ik zie geen gekke dingen in de assembler output -- dat zit allemaal netjes in elkaar. En nee, de originele source werkt ook niet correct volgens MPSIM, zoals ik al schreef.

CALL en GOTO gebruiken PCLATH helemaal niet, dus het lijkt erop dat MPSIM totaal de mist in gaat. Misschien zit er een bug in de MPSIM-implementatie van de 12F683 die je gebruikt, OF je hebt misschien niet de goede processor gedefinieerd.

Ik kan er naast zitten, maar het is bekend dat Microchip z'n spullen niet echt op orde heeft. Ik heb al vele jaren geleden MPSIM afgezworen, na een week of twee (!) te hebben zitten ploeteren op iets dat in werkelijkheid gewoon werkte.

>> hoe krijg ik het opgelost? Voor elke call en goto de PCLATH expliciet zetten?

Alleen voor calls die de program counter PCL manipuleren. Het terugzetten van PCLATH na return van een call moet alleen als het een call naar een andere page is...

>> CALL en GOTO gebruiken PCLATH helemaal niet

Computed calls en goto's gebruiken PCLATH wel
(Zie datasheet van de betreffende chip)

Calls en goto's naar een andere memory page gebruiken PCLATH zelfs altijd

[Bericht gewijzigd door Arco op (22%)]

Ik heb het even geprobeerd.

Volgens mij heb je te maken met een grapje van de simulator, hij stopt 1 telaat na de call naar unique_id. Maar als je de register inhoud kijkt doet hij het gewoon goed. Met F7 stapt ie wel netjes. Van underflows en zo heb ik geen last (maar ik heb geen stimuli file gemaakt voor de AD converter om alles af te lopen)

Als je port: zorg niet dat je posities verschuift in die code met de lookuptables

Op 30 september 2007 22:14:18 schreef Arco:
>>CALL en GOTO gebruiken PCLATH helemaal niet

Computed calls en goto's gebruiken PCLATH wel
(Zie datasheet van de betreffende chip)

Een computed GOTO is geen GOTO, maar een rekenkundige instructie op de Program Counter. Een computed CALL bestaat volgens mij niet.

Calls en goto's naar een andere memory page gebruiken PCLATH zelfs altijd

Niet van toepassing. De 12F processoren hebben maar 1 code memory page.

>> Een computed GOTO is geen GOTO, maar een rekenkundige instructie op de Program Counter.

Een computed GOTO is wel een GOTO instructie, alleen een waarvan het uiteindelijke sprongadres berekend wordt. (Microchip noemt het zelf ook een computed goto.)


GOTO MYTABLE
         ...
         ...

MYTABLE:
         ADDWF  PCL,F
         GOTO   LABEL1
         GOTO   LABEL2
         ...
         ...

Op 1 oktober 2007 05:02:04 schreef Arco: (Microchip noemt het zelf ook een computed goto.)

Hetgeen niet wil zeggen dat dit consequent taalgebruik van MC zelf is.
Een CALL is ook een GOTO instructie, alleen wordt daarbij het terugkeeradres op de stack gezet.
Een BTFSS is ook een computed goto instructie, alleen met een beperkt aantal sprongadressen (twee om precies te zijn).

Maar goed, on topic:

Het lijk erop dat de table read precies zo is geïmplementeerd, zoals het niet moet.
AN556e beschrijft hierin het e.e.a. en er staat ook een voorbeeld in van hoe het nu juist níet moet.
Deze foute manier is nu juist net zoals het is geïmplementeerd in die rbg |:-(

[edit]
Wazige pdf's van MC: de app note heet AN556, zonder e

AN556 beschrijft table gebruik in 12xx en 16xx cpu's wel goed... Wat zou er niet aan kloppen?

Gaarne mijn antwoord iets zorgvuldiger lezen.

Example 4 geeft een voorbeeld een table read zoals het níet moet.
Dat vermelden ze er zelf 'ter leering ende van de vermackelijcke' ook expliciet bij.
En deze manier is nu net de manier zoals het in die rbg is geïmplementeerd.

Allen dank voor jullie reacties. Inmiddels is mij ook gebleken dat MPSIM volledig de plank misslaat in dit geval, en dat de vreemde effecten die ik in mijn circuit zag, door andere zaken kwamen. Fuzzbass had dus helemaal gelijk.

Ik heb de code werkend, moet 'em alleen nog even wat opschonen.