Interrupt: varie ed eventuali

[Paolino]

A seguito di un commento di Matteo1991 a questo articolo di ildani - Un paio di precisazioni. Per quanto la gestione degli interrupt, i PIC16F hanno solo un vettore di interrupt, ossia una sola locazione alla quale salta il program counter a seguito di un interrupt. I PIC18F hanno invece due vettori, locazioni alle quali si salta in funzione della priorità (bassa o alta) assegnata alla sorgente di interrupt. Per quanto riguarda i PIC a 16bit e quelli a 32 bit, la faccenda è un po' più complicata, ma non ne parliamo qui.

Nei PIC16F, quindi, qualunque sorgente di interrupt porta il program counter ad una unica routine. Ma come discriminare un interrupt da un altro? Come si fa a capire quale sia stata la causa scatenante l'interrupt? Si va ad interrogare i bit di interrupt flag relativi agli interrupt che sono stati abilitati nel codice sorgente: quando si trova un IF (interrupt flag) a valore logico alto, allora BINGO! Lo si resetta e si eseguono le operazioni che è necessario svolgere.

Quindi, per esempio, nel main() si abilitano alcuni interrupt:

Codice: Seleziona tutto

void main (void)
{
..............
..............
..............
T0IE = 1;
TMR1IE;
INTIE = 1;
..............
..............
..............
}


Poi, la routine di interrupt gestisce i vari casi:

Codice: Seleziona tutto

void interrupt InterruptServiceRoutines (void)
{
    if (T0IF)
    {
        T0IF = 0;
        ...
        ...
        ...
    }

    if (TMR1IF)
    {
        TMR1IF = 0;
        ...
        ...
        ...
    }

    if (TMR2IF)
    {
        TMR2IF = 0;
        ...
        ...
        ...
    }
}


Spero di aver aiutato a fugare qualche dubbio.

Ciao.

Paolo.

[Candy]

E Qui si impara a programmare ed ogttimizzare il codice... Tra registri da salvare e ripristinare oltre che molte if da controllare, si rischia che ad ogni uscita sia gia' ora di rientrare...

[ildani]

E Qui si impara a programmare ed ogttimizzare il codice... Tra registri da salvare e ripristinare oltre che molte if da controllare, si rischia che ad ogni uscita sia gia' ora di rientrare...

Non ci puoi mettere queste pulci nell'orecchio e poi lasciarci a bocca asciutta senza un esempio

[TardoFreak]

Beh, non è che ci sia molto da "esempiare". Si mettono i test dei bit delle interrupt a priorità più elevata (decise dallo sviluppatore) per prime, quelle a bassa priorità o più lente dopo.
E se sono troppe e troppo frequenti tali da ingolfare il micro vuol dire che ... bisogna cambiare micro

[ildani]

Beh, non è che ci sia molto da "esempiare". Si mettono i test dei bit delle interrupt a priorità più elevata (decise dallo sviluppatore) per prime, quelle a bassa priorità o più lente dopo.
E se sono troppe e troppo frequenti tali da ingolfare il micro vuol dire che ... bisogna cambiare micro

Sicuro che Candy intendesse solo questo?
Io mi immaginavo ragionamenti contorti e codice assembly per far girare la ISR più velocemente possibile

[simo85]

Le interrupt devono essere il più corte possibile. Se non è Assembly è C, e dipende dal compilatore come assembla o traduce il codice secondo quali istruzioni.

[Matteo1991]

Idee, progetti, esperimenti, prove.... Il mio cervello è in overflow!
Tornando a noi, cosa succede se accade un altro interrupt durante l'esecuzione della isr?

[TardoFreak]

Che viene richiamata di nuovo e sul PIC16 sono dolori.

[Matteo1991]

Mentre con le priorità come funziona? se viene chiamata un isr ad alta priorità il micro non considera un eventuale interrupt a bassa priorità?

[TardoFreak]

Le priorità nel PIC16 non esistono. Quello che intendevo dire è che, visto che per riconoscere quale interrupt ha generato l' evento devo andare a fare un po' di verifiche, verificherò prima le interrupt che IO SO che necessitano di essere servite per prime, magari perché più importanti o più frequenti.