Hur hanteras interrupt i högnivåspråk?

[Pjoms]

Ja, som rubriken säger: Hur hanteras interrupt i högnivåspråk?
Om jag har högnivåkommandot "Gör-Nå't-Coolt" så kompileras ju det till ett antal rader maskinkod. Om det nu triggas en interrupt "mitt i" detta kommando, vad händer då?
Avbryts kommandot "internt" för att ta hand om interrupten, eller görs det först när kommandot "Gör-Nå't-Coolt" har körts klart?
Jag har harvat en del i PicBasic Pro, men funderar på att kliva vidare, och frågan är vart.
Antar att det kan skilja mellan olika kompilatorer och språk, så det är därför jag undrar lite...

[bearing]

Det finns något enstaka multitaskande operativsystem, men det klarar inte vanlig C av. C har bara snäppet högre nivå än assembler så det finns sällan saker som sköts "av sig själv" s.a.s.

Ett interrupt avbryter huvudkoden - kör sin kod - och hoppar sedan tillbaka till huvudkoden. Visa processorer har olika prioritetsnivåer på interrupten.

[Pjoms]

Glömde bort en liten detalj här: Det är PIC uC jag i första hand avser...

[bearing]

16- och 18-serien har inte möjlighet till olika interruptnivåer vad jag vet.

Jag rekommenderar inte multitasking eftersom det "verkar segt" + man har inget direkt kolla på hur långt tid olika saker tar. Bättre att använda interrupts om flera saker ska hända "samtidigt".

Här är iaf ett operativsystem för picar.
http://www.bknd.com/leanslice/index.shtml

[sodjan]

Det är helt upp till kompilatorn hur den gör !
En del enablar bara interrupt mellan "kommandon", jag har sett det
i en del Basic varianter.

Det kan vara lite lurigt eftersom kompilatorn ibland kan få för sig
att den har något viktigt att göra som inte får bli avbrutet, och det
är inte alltid så enkelt att veta var och när. När det gäller C så kan
en rellevant fråga vara om ett interrupt kan avbryta en lib funktion
(itoa, fprint o.s.v) eller om funktionerna måste köra klart först.
Ingen aning...

C är dock lite mer maskinnära och man har i allmänhet mer kontroll
över saker och ting (än i t.ex Basic).

Men, det definitiva svaret måste komma från dokumentationen
till de verktyg du studerar.

[sodjan]

Vad har multitasking med det här att göra ???

> 18-serien har inte möjlighet till olika interruptnivåer...

Jo, två.

[bearing]

Det var detta som tog mig in på multitasking:
"Avbryts kommandot "internt" för att ta hand om interrupten, eller görs det först när kommandot "Gör-Nå't-Coolt" har körts klart?"

Ok, det visste jag inte.

Såhär programmerar man interrupts med knudsens kompilator. Om du sätter flaggan GIE (Global Interrupt Enable) hoppar kodpekaren hit om interrupt sker. Sen får man kolla med if-satser vilken interrupt som skedde. (gäller 16-serien)

Kod: Markera allt

interrupt int_server( void)
{
    int_save_registers    // W, STATUS (and PCLATH)

    if ( T0IF)  {
        /* TMR0 overflow interrupt */
        TMR0 = -45;
        if ( pin1 == 1)
            pin1 = 0;
        else
            pin1 = 1;
        T0IF = 0;  /* reset flag */
    }

    if ( INTF)  {
        /* INT interrupt */
        INTF = 0;  /* reset flag */
    }

    if ( RBIF)  {
        /* RB port change interrupt */
        W = PORTB; /* clear mismatch */
        RBIF = 0;  /* reset flag */
    }


   /*
     NOTE: GIE is AUTOMATICALLY cleared on interrupt entry and set
           to 1 on exit (by RETFIE). Setting GIE to 1 inside the
           interrupt service routine will cause nested interrupts
           if an interrupt is pending. Too deep nesting may crash
           the program !
   */

    int_restore_registers // W, STATUS (and PCLATH)
}

[henkebenke]

Om du kör C så är deklarationen av interrupts väldigt kompilatorspecifikt men själva exekveringen av dem har ingenting att göra med vilken kompilator du kör. Det fungerar precis som om du kör assembler. Det man behöver berätta för kompilatorn när man deklarerar en interruptrutin är vilken interruptvektor som ska köra rutinen.
Det kan kanske finnas library-rutiner som ändrar interruptflaggor men det är inget jag stött på, så även dessa kan bli avbrutna.

[sodjan]

Jo, det är klart. Processorn har ju inte en aning om vilket verktyg
som har genererat maskinkoden, så där finns ingen skillnad. Spelar
sedan ingen roll om det är C, Basic, Pascal, assembler eller något annat.

Frågar är mer vilken kod kompilatorn genererar. Jag kan tänka mig att
de flesta library-rutiner kan avbrytas, men det kan även finnas mer "internal"
rutiner som kompilatorn lägger dit (hantering av stack eller liknande) som
in bör bli avbrytna hur som helst.

Men det betyder också i så fall, att om t.ex en printf avbryts tidigt, och
ISR'en sedan strular runt med argumenten till printf, så kanske den inte ger
det resultat som var förväntat. Som vanligt gäller det väl att veta vad man gör,
oavsett vilket verkyyg man använder...

Man kan misstänka att det finns en anledning till att man inte kan göra
CALL från en ISR i MikroBasic (om jag inte minns fel !?). Antagligen för
att det finns risk för stack-corruption eller något liknande otrevligt...

[bearing]

I knudsens kompilator kan man anropa rutiner från interruptet, men inte samma rutiner som även anropas från main. Antar att det beror på att PICen inte har någon stack som argumenten sparas i utan argumenten får fasta minnesplatser.
Man får göra en kopia av rutinen om man vill använda den även från interrupts...

[$tiff]

>> bearing

Låter otympligt. Jag ser det som en självklarhet att kunna anropa vanliga rutiner från en ISR, så länge man har koll på vad rutinen behöver för resurser och hur mycket man därför t.ex. behöver lägga på stack. Bekvämligheten ska ju ligga i att kompilatorn har koll på detta åt en.

Detta skiljer naturligtvis avsevärt mellan arkitekturer och språk.
Är man van vid C/asm så kan man ha svårt att förstå varför man "optimerat bort" vissa möjligheter i andra språk.

Edit: Syfta

[Micke_s]

När det gäller att anropa funktioner från en ISR så rekomenderar jag starkt att undvika detta eftersom detta tar upp onödig tid.

När det gäller "Gör-Nå't-Coolt" så ska det krävas att ISR avaktiveras för inte de ska anropas, något som inte printf och andra funktioner ska hindra en eftersom var vi hoppade ifrån och statusregister sparas under, detta gäller i c i alla fall.
Däremot så kan vissa register vara dåligt att peta i samtidigt de används i "main", t.ex. att använda eeprom:et samtidigt, detta kan ge oönskade effekter.

[bearing]

Tiff:
Knudsen gör en C-kompilator, om inte det kom fram.

PIC 16-serien har ingen stack som är åtkomlig genom instruktioner. Bara en dåld där den sparar returadresser vid funktionsanrop.

Enda möjligheten att använda samma funktioner från interrupt borde då vara funktioner som inte tar eller endast tar ett argument som läggs i W och inte använder lokala variabler.

Kompilatorn kan ju inte veta när interrupten sker. Men den skulle iofs kunna göra en kopia själv om man har samma funktionsanrop från ett interrupt som i main.

[$tiff]

Så var det, det finnsingen stack på PIC16. Jag arbetar mest med AVR nuförtiden. Jämför man med en AVRTiny så har åtminstone de nyare en fullfjädrad stack.
Vi måste väl vara överens om att det inte är sama svar på ursprungsfrågan för olika arkitekturer (även om vi håller oss till 8-bits µC).

[sodjan]

Hm, det finns en stack (för retur-adresser), men man kommer inte åt den
från applikationsprogramvaran...

Dock, de flesta kompilatorer brukar implementera (ibland valbart) en
programvarustack, men eftersom den inte hanteras av hårdvaran så blir den
känslig för interrupt och liknande. Access till stacken måste synkas på något
sätt (mellan t.ex "main" och en ISR) för att den inte ska bli korrupt av
misstag...