Svenska ElektronikForumet

Ett steg i taget blir det, oftast framåt.
Mycket tack vare den hjälp och information som delas med sig av här.
Stort tack till var och en som bidrar.

Jag vet att jag tidigare inte tyckt det här med interupt verkar så himla bra. Och i den kontexten var det oxå så.

Frågan är dock nu om denna snutt kod ser ut som den ska.

Dels rent allmänt när det gäller GIE etc.
Dels vad gäller att använda CALL inom den.
Dvs är det bättre att använda GOTO än CALL i detta fall?

De olika rutinerna i sig är inte med, vilket torde fungera då de inte påverkar just ramverket för ISR.

En sak jag inte blir riktigt klok på är hur man skapar W_TEMP.
Som texten är skriven ska den definieras i både bank 0 och bank 1.
Hur går det till?

Ser det rätt ut?
Minns jag rätt gäller det PIC12F629.
Jo, jag hoppar mellan olika PIC, de gör olika saker, har olika roller.

*Alla* PIC12 och PIC16 har en del av minnet som "unbanked".
Det gäller dels vissa FSR register men även en mindre del (på
vissa med lite minne hela) GPR arean.

Anledningen till detta är att man *alltid* ska kunna nå vissa
register och vissa minnesadresser utan att behöva byta bank.
Detta är viktigt t.ex. i ISR'er.

Du nämner 12F629. Om du tittar i databladet så ligger dessa
FSR i båda bankerna: PCL, STATUS, FSR, PCLATH och INTCON.
När det gäller GPR så är alla 64 byte mappade i båda bankerna.
I större PIC modeller så är det normalt 16 byte som är gemensamma
för alla banker ("unbanked memory").

Så när det gäller t.ex. W_TEMP så spelar det ingen roll hur den definieras,
den är alltid tillgänglig oavsett hur bankbitarna står i STATUS registret.

Den kod du visar innehåller enbart själva ISR'en. W_TEMP definieras normalt
i början på huvudkoden, som du har klippt bort. Kolla hela koden så
ger det sig nog.

> Dels rent allmänt när det gäller GIE etc.

Vad är frågan !?

> Dels vad gäller att använda CALL inom den.

Inget problem.

> Dvs är det bättre att använda GOTO än CALL i detta fall?

Vilket "fall" ? Om det är en ISR eller inte spelar ingen roll.
Däremot får du ju vara lite försiktig med att göra CALL till
subrutiner som *också* anropas från huvudkoden...

Jag tittade inte så noga på koden i sig. Den har ett antal
fel som kommer att synas direkt då du bygger den. Rena
små/skit/slarv fel, så jag tar inte det här, du der det direkt.

Jo, en annan liten notering bara. Nyare PIC som 12F1xxx
modellerna har automatisk "context save and restore" så
det där SWAP'ander i början och slutet försvinner helt.

Bra, tack.

Förutom att INTCON resp PIR1 inte kom med så fungerar detta alltså.
Jag för skylla på att jag fortfarande tycker det är ... med flera nivåer adressering.
... sedan kommer ju inte TMR1IF att användas alls, så ingen PIR1, TMR1IF.

W_TEMP definieras givetvis tillsammans med övriga GFR i deras tilldelade block (0x20).
Kopplingen över FSR var informationen som vanns där.

Angående GIE var det bara en extra kollation om att GIE är huvudbrytaren vad gäller anmodan om interupt.
Samt att den slår av och sedan på sig själv vid interupt.

Himla bra att MC lagt in automatisk skötsel av det runt interupt på senare PIC.

Bra, allt klart. Tack.

> Samt att den slår av och sedan på sig själv vid interupt.

Ah, jo. Själva interruptet nollar den och RETFIE sätter den igen...

> W_TEMP definieras givetvis tillsammans med övriga GFR i deras tilldelade block (0x20).

Precis. Och hela de blocket är "speglat" över båda bankerna.

Perfekt, tack.

Det som kvarstår är att I/O IOC inte sätter individuella flaggor, vilket ju innebär att ISR måste vara kvick nog att hinna plocka vilken pinne som utlöste.
Givetvis kan detta minskas genom att spegla I/O det första man gör.
Men inte hindra att I/O som uppstår under tiden för ISR iofs loggas men hinner försvinna och följdaktligen inte finns vid den ISR som den utlöste.

Nej, det är ju "business as usual". Koden måste vara anpassad
till verkligheten, så att säga. Men måste veta inom vilka gränser
som koden ska förväntas arbeta. Du bör alltså redan nu veta vilken
högsta frekvens (eller kortaste intervall) som ändringarna kommer
med, och sedan se om koden klarar av det. Sen så kan ju två olika
pinnar som mer eller minmdra samtidigt skiftar värde, men det bör
ISR'en kunna se.

Om man läser av porten tidigt (då även IOC flaggan resetas) inom
ISR'en, så kan en ändring komma innan REFFIE och ISR'en kommer
att återanropas. Men det är alltid lite trixigt om man ligger på
marginalerna för vad processorn klarar av...

Där sa du något som...

Från början, igen.
Men ta sista stycket först...

GPIF sätts om någon GPIO ändrar läge.
Detta sker oavsett GIE, GPIE och IOC.
Korrekt?

Det enda kriteriet är att pinnen är digital I/O, med eller utan WPU respektive IOC och oavsett in- eller output.
Korrekt?

GPIF orsakar dock bara ISR om pinnen som slog om var IOC.
Korrekt?
Bör vara ej korrekt därför att...

...ISR måste göras oavsett om pinnen är IOC eller ej emedan varken IOC eller GPIF anger vilken (I/O) pinne som ändrats och därefter cleara GPIF automatiskt och det blir en väldig mängd ISR begärda, begärda från icke IOC satta digitala pinnar....

Interupt flag, "nnnIF", sätts ju oavsett allt annat.

Så ISR måste utföras, för att cleara GPIF så att relevant GPIF, dvs från IOC satt pinne, kan fångas.

Vad som alltså måste ingå i IOC är förmågan att cleara GPIF och låta bli ISR om ej IOC.
För annars blir det, enligt ovan, en väldig mängd ISR begärda - och begärda utförda dessutom.

Eller sätts GPIF endast av IOC satt pinne?
Något som texten inte leder mot och som skulle skilja ut hur GPIF sätts från exempelvis T0IF.
Dvs T0IF, och enligt texten GPIF likaså, sätts vid varje radikal förändring (rollover, statusbyte etc).

sodjan skrev:Om man läser av porten tidigt (då även IOC flaggan resetas) inom
ISR'en, så kan en ändring komma innan REFFIE och ISR'en kommer
att återanropas. Men det är alltid lite trixigt om man ligger på
marginalerna för vad processorn klarar av...

Jag hoppas att du här INTE menar att ISR kan anropas inifrån sig själv.
Utan att du menar att ISR kommer ske omedelbart efter innevarande RETFIE.

> Jag hoppas att du här INTE menar att ISR kan anropas inifrån sig själv.
> Utan att du menar att ISR kommer ske omedelbart efter innevarande RETFIE.

Ja, exakt. Det är helt normalt. Ibland låter man processorn göra så istället
för att köra alla interrupt som har hänt "samtidigt" på samma gång i en loop
inom ISR'en. ISR'en blir lite "renare" på så sätt och går något snabbare.

> GPIF sätts om någon GPIO ändrar läge.
> Detta sker oavsett GIE, GPIE och IOC.
> Korrekt?

Nej. Enbart om respektive IOC bit är satt.

> GPIF orsakar dock bara ISR om pinnen som slog om var IOC.
> Korrekt?

GPIF genererar *alltid* ett interuppt *on* GPIE och GIE är satta.
Se: "FIGURE 9-10: INTERRUPT LOGIC"

> Eller sätts GPIF endast av IOC satt pinne?

Ja. Se t.ex.: "FIGURE 3-1: BLOCK DIAGRAM OF GP0 AND GP1 PINS"

Resten av inlägget verkar bara vara missförstånd...

9.4 Interrupts
Note 1: Individual interrupt flag bits are set, regardless of the status of their corresponding mask bit or the GIE bit.

Därav frågeställningen.


Bra, tack.


Åsså två frågor om TnCON, TMRnON då.

A) Vad sker med innevarande timer-värde vid start/stopp?

B) Ingen risk att en två-register timer kan clearas med en samlingsinstruktion, eller?
Alltså typ CLRF TMR1, istället för CLRF TMR1L & CLRF TMR1H.
Inget som tyder på det, men hoppet sägs vara det sista som överger en...

> Därav frågeställningen.

Jo, men det var inte det du citerade som du frågade om...

A) Skitenkelt att testa i MPSIM...

B) Nej, det tror jag inte går...

Frågan gällde hur GPIF ställer sig gentemot status på GIE och IOC.
Och noten anger att GPIF sätts oavsett hur de står.
Därav svårigheten få klarlagt det hela.

Men svaret, vilket jag tackar för, är att denna not inte gäller i detta.

sodjan skrev:> Jag hoppas att du här INTE menar att ISR kan anropas inifrån sig själv.
> Utan att du menar att ISR kommer ske omedelbart efter innevarande RETFIE.

Ja, exakt. Det är helt normalt. Ibland låter man processorn göra så istället
för att köra alla interrupt som har hänt "samtidigt" på samma gång i en loop
inom ISR'en. ISR'en blir lite "renare" på så sätt och går något snabbare.

Vilket inte borde funka då GIE clearar alla nnnIF som var utlösta vid start av ISR vid RETFIE. Det är endast de nnnIF som utlöser under tiden ISR utförs som lagras till efter RETFIE.

Dvs det tillkommer inga nnnIF medan ISR utförs och alla utlösta nnnIF måste hanteras inom samma ISR då de clearas vid RETFIE (BSF INTCON,GIE).

Att de kan sparas annorstädes, i ett GFR, är något helt annat.

Det är så skeendet beskrivs iallafall.



OK, inget svar på vad som sker med värdet i en timer när den stoppas och startas.

> Frågan gällde hur GPIF ställer sig gentemot status på GIE och IOC.
> Och noten anger att GPIF sätts oavsett hur de står.

Nej, det står det INTE !!

Det står att xxIF flaggorna sätts oberoende av xxIE och GIE/PEIE.
Inget annat...

> Men svaret, vilket jag tackar för, är att denna not inte gäller i detta.

Jo, det gör den så klart. Men GPIF sätts inte om inte IOC är satt.
Det ligger "steget före" det som ditt citat (helt korrekt) talar om.

> ...då GIE clearar alla nnnIF som var utlösta vid start av ISR vid RETFIE.

Var i jösse namn har du fått *det* från !? Det är totalt fel hur som helst...