Quando è Bene Disabilitare Gli Interrupt - PICmicro 18F2553

[Neway]

E' la prima volta che utilizzo gli interrupt in modo serio.

In pratica il programma principale gira di continuo e svolge calcoli matematici, legge i sensori tramite ADC e SPI e memorizza dati su una EEPROM esterna.

Al contempo il PIC genera un segnale PWM per un servocomando tramite interrupt (non si può usare il modulo PWM del PIC perchè troppo veloce).

Posso lasciare gli interrupt sempre attivi oppure è bene non interrompere il flusso del programma principale in certe operazioni?

Grazie

[Livio Orsini]

Scopo dell'interrupt è o gestire un evento ad alta priorità oppure gestire un evento casuale. Se l'evento casuale può attendere si può mascherare l'interrupt durante certe operazioni ad alta priorità; similmente quando più interrupts accadono 8quasi9 contemporaneamente il processore elabora quello a priorità maggiore, lasciando glia altri in coda.

Devi valutare tu le priorità di elaborazione ed i tempi necessari.

Comunque se gli altri programmi non hanno priorità maggiore dell'interrupt non vedo ragione per disabiltarlo.

Invece se hai un programma ad alta priorità, o che necessita di un tempo ben preciso come potrebbe essere un programma di regolazione, allora disabiliti tutti gli interrupts all'inizio di questa funzione per riabilitarli al termine.

[Neway]

Ok, intendevo dire se esistono delle particolari situazioni in cui un interrupt può mandare in crash il PIC o portare a errori. Se non ricordo male una di queste situazioni è la scrittura sulla EEPROM interna (che in questo caso non mi interessa).

Vorrei capire se è dannoso che un interrupt intervenga mentre si legge l'A/D o mentre si sta ricevendo dei dati tramite SPI

[Livio Orsini]

Questo avviene se la funzione di gestione dell'interupt è sbagliata o contiene errori, come qaulsiasi altra funzione.

Dovresti studiarti bene, sul manuale del PIC, come funzionano gli inerrupts (ma il funzionamento è simile a tutti i processoru). Un interrpt viene servito solo dopo che è terminata l'esecuzione dell'istruzione in corso!

[RealTime]

In GENERALE l'interrupt deve essere eseguito nel minor tempo possibile per lasciare tempo macchina ad altri POSSIBILI interrupt che possono essere richiesti da altre periferiche alla CPU.

Ovvio! Se hai una SOLA sorgente di interrupt non preoccuparti affatto di questo criterio ... è solo una regola generale che deve essere rispettata quando hai una intensa attività di interruzione da svariate periferiche ....

Molti chips dispongono di una struttura con interrupt annidati (NESTED INTERRUPT) che permettono ad un interrupt di priorita' piu' elevata di interrompere un interrupt con priorità più bassa. Con questo metodo vai pero' incontro ad altri problemi collegati con la profondita' dello stack che deve essere sufficientemente grande per assicurare una corretta gestione degli interrupt anche nei casi limite ....

RT

[alfa_e_omega]

Non e' raro nella programmazione di microcontrollori che all'interno di un'interrupt si svolgano molte operazioni o si agisca su variabili gestite anche all'esterno dell'interrupt, in questo caso non c'è solo un problema di priorità, ma lo stesso flusso dell'elaborazione potrebbe essere compromesso dal fatto che un interrupt entri mentre sto facendo una determinata operazione, in questi casi è fondamentale compiere alcune operazioni ad interrupt disabilitati. Provo a fare un esempio: ho un contatore a 16 bit su un micro a 8 bit , il contatore viene decrementato da un interrupt che entra ogni millisecondo e viene aggiornato nel main quando ricevo un certo segnale dall'esterno. L'aggiornamento del contatore avverrà con due caricamenti (parte alta e parte bassa), se entrasse l'interrupt che gestisce il contatore tra le due operazioni il contatore verrebbe decrementato e potrebbe assumere un valore inconsistente, se disabilito gli interrupt prima del caricamento per abilitarli subito dopo il problema non si pone. Rimanendo sul generale direi che operare ad interrupt disabilitati è utile quando durante una sequenza di operazioni non si vuole essere "disturbati" dall'interrupt, cioè non si vuole che l'interrupt modifichi qualche variabile o qualche registro su cui si sta lavorando e dal cui valore dipende la consistenza delle operazioni che si eseguono. Spesso molte operazioni di configurazione delle periferiche vengono fatte ad interrupt disabilitati come è buona norma disabilitare gli interrupt durante tutta la fase di inizializzazione delle variabili e dei registri di un determinato firmware...

[Livio Orsini]

Direi di più.

E' buona norma abilitare gli interrupts solo dopo aver completato la funzione di inizializzazione generale.

In genere la prima istruzione del programma dovrebbe essere una "DI" (Disable Interrupts). La conseguente eventuale "EI" seguirà solo dopo l'avvenuta inizializzazione.

[RealTime]

Sì, queste sono le medesime problematiche tipiche degli ambienti multitasking (Multiprogrammazione)

Due o più processi concorrenti che accedono ad un medesimo elemento devono essere opportunamente sincronizzati in modo da accedere "a mutua esclusione" agli elementi condivisi. Tipicamente gli ambienti operativi dispongono di primitive per questo tipo di processi: Semafori, Mutex, Spinlockers e via dicendo ....

La primitiva DISABLE-INTERRUPT in questo contesto può essere assimilato ad un oggetto di tipo MUTEX. In questo caso il processo principale ottiene l'accesso ESCLUSIVO della variabile impedendo l'accesso agli interrupt. Il processo di interrupt di per sè ha già ottenuto l'esclusivita' del processore a meno che esso non venga interrotto da processi a priorità più elevata

RT

[Neway]

Grazie, mi avete chiarito molto le idee

[alfa_e_omega]

Esatto nella programmazione concorrente esiste una vera e propria contemporaneità tra processi poiché un sistema operativo gestisce le risorse e i processi (altri software, periferiche, etc.) cercano di accedere alle risorse contemporaneamente, nel programmare un microcontrollore sebbene l'esecuzione sia sempre sequenziale spesso si ragiona come se si stesse programmando un mini sistema operativo. La differenza rispetto all'esecuzione sequenziale di un qualsiasi software sta proprio nella presenza delle periferiche e dei relativi interrupt che per definizione sono eventi asincroni e possono essere assimilati ai processi che in un sistema operativo cercano di accedere a risorse condivise. Non a caso in microcontrollori di grandi dimensioni si cominciano ad usare veri e propri sistemi operativi (RTOS:Real Time Operating System) spesso derivati da sistemi operativi come linux o simili. Scrivendo firmware quindi ci si deve preoccupare di come e quando le varie periferiche cercheranno di accedere a una risorsa (locazione di memoria, registro, bus di comunicazione) e implementare soluzioni tipo semaforo, ad esempio utilizzando delle "flag", oppure gestendo gli interrupt in maniera opportuna.

Ovviamente più la complessità del firmware aumenta più l'esigenza di meccanismi di controllo diventa stringente...

Spero che queste nostre considerazioni contribuiscano a chiarire le idee a Neway e non a confonderle uleriormente

Modificato: 26 agosto 2011 da alfa_e_omega