PIC18F25K22 - Timer, Nested interrupts och annat

[Magnus_K]

Jo det är precis så jag menar. Det kommer finnas en interrupt som har högre prioritering än dom andra och vad jag läst mig till så ska det fungera som jag önskar, dvs att om en lågprio ISR körs när en högprio inträffar så pausar den låga medans den höga körs.
Om jag förstått det hela rätt vill säga.

Tänkte testa för en väldigt snabb ISR som inte "får ställas på kö".
Förklarar mer ikväll när det inte fungerar.

[sodjan]

OK, ja så länge du håller dig till de "high/low priority" interrupt som
har stöd i PIC18 hårdvaran så är det ju inga speciella konstigheter.

De är egentligen inte "nästlade" eftersom de har olika adresser och
kör två helt skilda ISR rutiner/koder. Det är även fullt dokumenterat
hur man använder det...

[lillahuset]

Jodå de är nästade interrupt om ett interrupt med högre prioritet avbryter ett med lägre prioritet.

[sodjan]

OK, semantik. Om det är high/low interrupten som stöds
direkt av hårdvaran så är det inget större problem.

[lillahuset]

Vi är helt överens. Jag tvekade lite innan jag skrev inlägget.

[Magnus_K]

Skönt att ni är överens.
Tänkte flika in en fråga nu när jag ändå sitter här. Har alltid undrat men glömt av att fråga.

Ta nedan kodsnutt som exempel. Hur vet jag vart jag ska sätta alla IF, {, } med mera för att det ska bli lättläst? Ibland när man ser liknande if-satser och annan kod så blir det mycket snyggare och mer lättläst om allt "sitter på rätt ställe". Förstår ni vad jag menar?
Trodde det var detta som kallades för "indentering" men när jag markerar detta stycke i IDE:t och trycker "Indent" så hoppar allt bara ett steg åt höger.
Finns det någon automatik för sånt här?

Kod: Markera allt

void interrupt(void)
 {
 if (PIR1.TMR1IF)
     {
      Button_Counter <<= 1;
      Button_Counter |= BUTTON_READ;
      
      if (Button_Counter == 0xff)
          {
           Button_Status = 1;
           }
           else if (Button_Counter == 0x00)
                {
                 Buttons_Status = 0;
                 }
      PIR1.TMR1IF = 0;
       }
}

[TomasL]

Det är en vanesak, många sätter { direkt efter IFen, och tabbar in ett steg för det som ligger i IFen, avslutar sedan med} i samma tabhöjd som IFen.
Personligen tyckert jag det blir lättare att läsa om man sätter { på raden under IFen vid samma tabläge, koden hamnar på nästföljande rader intabbade 1 steg.
Ett sätt att göra det på:

Kod: Markera allt

void interrupt (void) {
	if (nånting) {
	   nu hittar vi på en del saker;
	   ännu mer saker;
	   innan vi slutar;
	}// if (nånting)
}// void interrupt(void)

Så som jag föredrar:

Kod: Markera allt

void interrupt (void)
{
	if (nånting) 
	{
	   nu hittar vi på en del saker;
	   ännu mer saker;
	   innan vi slutar;
	}// if (nånting)
}// void interrupt(void)

Men som sagt en smaksak, personligen upplever jag det sista sättet som mer lättläst, då man på ett enkelt sätt ser exakt var saker och ting börjar resp slutar, framförallt om man har långa IF-satser, och IFar i flera nivåer.

Sedan är det också mer lättläst om man lägger en rad med stjärnor eller så mellan varje funktion, och naturligtvis en förklaring till vad funktionen gör och vad eventuella argument är för något mm.

[Magnus_K]

Ahaa, trodde att det fanns någon automagisk funktion som hjälpte till med detta.
Jag håller med om att av de två du redovisar så ser den nedre helt klart bäst ut. Lätt att se vilken { som tillhör vilken }. Ska söka runt lite på olika varianter.

Jo för övrigt med kommentering, definering etc etc har diskuterats mycket i en annan av mina trådar så det har jag god hjälp med.

[TomasL]

Ofta är det så (beroende på hur smart editorn är), att den sätter in en tab efter det att du skrivit { och ny rad, en del sätter in {}per automatik

[Magnus_K]

Provade lite olika stilar och tror jag testar denna för detta projekt. Det blir alltså liknande din föredragna metod men jag placerar { på samma rad som IF:en istället samt en tom rad för att markera ny if-sats/funktion.
Får se hur det känns. Märker också att editorn hjälper till en del med tabbningen.

Kod: Markera allt

void interrupt(void) {
     
     if (PIR1.TMR1IF) {
        Button_Counter <<= 1;
        Button_Counter |= BUTTON_READ;

        if (Button_Counter == 0xff) {
           Button_Status = 1;
        }
        
        else if (Button_Counter == 0x00) {
                Buttons_Status = 0;
        }
        
        PIR1.TMR1IF = 0;
      }
}

[Magnus_K]

Ok, tillbaka till allvaret.

Jag har en interrupt som ser ut som nedan men har två frågor:

1. Har jag tänkt rätt att om Pulse är deklarerad som en bit så kommer funktionen först skifta in portvärdet till bit:en, efter 3 st NOP:ar så AND:as portstatusen in igen, dvs om det redan är en 1:a så krävs det en 1:a igen för att Pulse ska innehålla värdet 1 vid interruptets slut?

2. När den kodsnutten kompileras (eller vad det kallas) så jag kan läsa ASM-koden så ser den ut som nedan. Kan jag helt enkelt gå igenom rad för rad och räkna ihop antal cykler med hjälp av tabell 25-2? Tabellen finnes på sidan 376 i detta datablad.

Kod: Markera allt

if (INTCON.TMR0IE) {
         Pulse = PORTC.B3;
         asm { nop }
         asm { nop }
         asm { nop }
         Pulse &= PORTC.B3;
         INTCON.TMR0IE = 0;
      }

Kod: Markera allt

;CoreMemory16bits.c,49 ::                 if (INTCON.TMR0IE) {
0x0044        0xAAF2              BTFSS       INTCON, 5 
0x0046        0xD010              BRA         L_interrupt4
;CoreMemory16bits.c,50 ::                 Pulse = PORTC.B3;
0x0048        0xB682              BTFSC       PORTC, 3 
0x004A        0xD002              BRA         L__interrupt10
0x004C        0x9019              BCF         _Pulse, BitPos(_Pulse+0) 
0x004E        0xD001              BRA         L__interrupt11
L__interrupt10:
0x0050        0x8019              BSF         _Pulse, BitPos(_Pulse+0) 
L__interrupt11:
;CoreMemory16bits.c,51 ::                 asm { nop }
0x0052        0x0000              NOP
;CoreMemory16bits.c,52 ::                 asm { nop }
0x0054        0x0000              NOP
;CoreMemory16bits.c,53 ::                 asm { nop }
0x0056        0x0000              NOP
;CoreMemory16bits.c,54 ::                 Pulse &= PORTC.B3;
0x0058        0xA019              BTFSS       _Pulse, BitPos(_Pulse+0) 
0x005A        0xD004              BRA         L__interrupt12
0x005C        0xA682              BTFSS       PORTC, 3 
0x005E        0xD002              BRA         L__interrupt12
0x0060        0x8019              BSF         _Pulse, BitPos(_Pulse+0) 
0x0062        0xD001              BRA         L__interrupt13
L__interrupt12:
0x0064        0x9019              BCF         _Pulse, BitPos(_Pulse+0) 
L__interrupt13:
;CoreMemory16bits.c,55 ::                 INTCON.TMR0IE = 0;
0x0066        0x9AF2              BCF         INTCON, 5 
;CoreMemory16bits.c,56 ::                 }

[TomasL]

Svar: Ja

[lillahuset]

TomasL har helt rätt men vi har olika uppfattning om vilken variant vi gillar bäst.

Det viktigaste är att man är konsekvent. Det finns verktyg, tex indent (har jag för mig att det heter), som kan formattera om källkod så att allt blir lika. Kan vara bra om man importerar någon annans källkod. Sedan brukar editorer kunna hjälpa till.

Sedan brukar man ha olika regler för hur saker namnges. Själv kör jag med enbart VERSALER för macron, inledande Versal för globala variabler och bara gemener för lokala variabler. Längre identifierare brular bli i camelCase, tex magnusVariabel. Andra vill skriva magnus_variabel istället.

Det brukar finnas en "standard" inom olika projekt så all kod ser likadan ut oavsett vem som skrivit den.

[Magnus_K]

@TomasL:
Åååå gudars vad glad jag blev av det svaret. Kanske verkade lite slött att jag frågade men det hade antagligen tagit 2 veckor för mig att verifiera det här istället för dom 2 minuter det tog att få ett svar här. Tackar

@lillahuset:
Ja det verkar vara det genomgående bästa förslaget, även om man läser lite på andra forum; att hålla samma stil genom hela programmet. Ska försöka tänka på det.

För övrigt stör jag mig något vidrigt på att jag inte kan hitta den länken/pdf:en som någon berättade om i någon annan tråd. Det var en slags programmeringsstandard men skriven på ett väldigt underhållande och lättläst sätt. Önskar jag hittar den snart igen.

[TomasL]

Dessutom är det en bra sak att inkludera typen i variabelnamnet, till exempel "testVariabel_uint8"

Beträffande det där med { så är det en personlig smaksak, vad man trivs bäst med, bägge sätten är lika korrekta.

För att ge dig lite matnyttig sänglitteratur så:
http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
Detta använder vi i våra projekt.