Per chi scrive codice già da un po’ di tempo, sicuramente i termini interrupt (o interruzione) e polling non sono affatto nuovi; si tratta di due tecniche che possono essere utilizzate per mettere in allerta la scheda di sistema, come ad esempio un microcontrollore, quando ci si trova in presenza di un input. Ma qual è la differenza tra i due metodi? Uno è meglio dell’altro, o la loro utilità varia a seconda delle situazioni? Sia l’interrupt che il polling presentano dei vantaggi e degli svantaggi, scopriamoli insieme!

Polling: verifica ciclica di tutte le operazioni di input/output

Quando si lavora, ad esempio, su una scheda chipKIT, uno dei primi progetti che si esegue è quello di realizzare un circuito molto semplice, che prevede l’accensione di un Led alla pressione di un tasto. Per sapere quando si preme il pulsante, il programma utilizza un sistema di lettura digitale dello stato della tensione del pin connesso al tasto e, successivamente, accende o spegne il Led. Tuttavia, con la lettura digitale il microcontrollore deve monitorare di continuo lo stato della tensione su quel pin, per valutare l’azione successiva da compiere (spegnere o accendere il Led).

Questo metodo di controllo e verifica continuo è conosciuto come polling.

Lo svantaggio, però, è che esso può sfruttare in maniera intensiva il processore, poiché il microcontrollore è in continua fase di checking riguardo il cambiamento di stato della tensione; d’altro canto, questa modalità operativa rappresenta un valido strumento per assicurarsi che, non appena si verifica il cambiamento, segue immediatamente l’effetto desiderato.

Interrupt: interruzione di un processo in determinate condizioni

Un interrupt, o interruzione, è, come il polling, un metodo per rilevare se è occorso un cambiamento all’interno del sistema, ma non ha bisogno di continui controlli per saperlo. Piuttosto, un interrupt presenta delle modifiche nell’hardware e provoca il verificarsi immediato di una ISR (Interrupt Service Routine), anche se la scheda chipKIT si trova nel pieno svolgimento di una qualsiasi operazione. Di solito, una ISR prevede l’assegnazione di un flag (variabile booleana) per avvisare la scheda di sistema che si è verificato un interrupt; poi sarà la scheda di sistema ad esaminarlo in maniera più completa dopo aver controllato specificatamente lo stato di quel flag.

Ma se un interrupt si verifica immediatamente, perché non fare in modo che tutto ciò che è associato con quella interruzione venga eseguito non appena essa si verifica? In teoria, tutto può essere gestito in una ISR, ma in realtà la maggior parte delle applicazioni sono sensibili al tempo, quindi potrebbe essere controproducente far girare un gran numero di codici in un interrupt che è progettato solo per verifiche veloci.
Inoltre, le funzioni che dipendono dal tempo, come la funzione delay (), non saranno attive all’interno di una ISR; allo stesso modo, un contatore per la funzione millis() non continuerà a lavorare all’interno di un interrupt.
A causa di questo, di solito è molto più semplice lanciare un polling occasionale all’interno di un circuito da controllare, per vedere se il flag dell’interrupt è cambiato, così da mantenere la scheda di sistema in funzione senza problemi, così come è stata progettata.

Polling Vs Interrupt: differenze

Per concludere, è quindi bene analizzare le differenze, o meglio la principale differenza tra il polling e l’interrupt. Per capirlo, è possibile prendere come esempio la ricezione di messaggi di testo sul proprio telefono cellulare; se controlliamo di continuo il telefono per vedere se qualcuno ci ha scritto, siamo di fronte ad un polling. Se invece siamo occupati nello svolgimento di qualsiasi attività, e sentiamo il tono di avviso di ricezione di un messaggio, si è verificato un interrupt, un’interruzione; in questo caso, sappiamo di aver ricevuto un messaggio (flag dell’interrupt), ma possiamo decidere se controllare subito il telefono o se aspettare un momento più opportuno.

E voi, che metodo usate più frequentemente?

Article by James Colvin courtsey of blog.digilentinc.com