Dicembre 6, 2019

Sempre più spesso si trovano descrizioni di progetti più o meno complessi che ruotano intorno ad una scheda programmata in ambiente Arduino. In generale è sconsigliabile iniziare la programmazione di sistemi embedded proprio da Arduino. Il motivo è semplice, si inizia nel modo sbagliato, si inizia “viziati”, “coccolati” da una marea di librerie che semplificano (troppo) tutto il lavoro. Lo studente di sistemi embedded che approccia per la prima volta questo mondo utilizzando ambienti di programmazione troppo semplificati, dovrebbe invece prima comprendere a fondo come è fatto l’hardware sul quale vuole lavorare, poi piano piano imparare a scrivere il codice nel modo più opportuno preparando da solo le funzioni che gli permettono di controllare una determinata funzionalità. Invece no, con Arduino c’è una sorta di astrazione dall’hardware, l’importante è scrivere codice. Poi se questo è fatto bene o male poco importa, per molti l’importante è che funzioni.

Nel nostro webinar gratuito di introduzione al video corso di elettronica, viene spiegato proprio perché il problema di molti non è Arduino ma il non conoscere l’elettronica. Prendiamo ad esempio l’utilizzo della funzione delay() e cerchiamo di capirne l’uso corretto.

Innanzi tutto cosa succede ogni volta che chiamiamo la funzione delay()? Come descritto sul sito ufficiale di Arduino, l’esecuzione del programma viene sospesa per la quantità di tempo specificata dall’argomento. L’argomento è quel numero che andiamo a mettere tra parentesi. Così scrivere delay(100) significa sospendere il programma per 100 ms. In realtà il programma non viene minimamente sospeso perché quando viene chiamata questa funzione il programma da svolgere è esattamente “non fare nulla”, attendere inutilmente, cioè la CPU non è ferma ma sta facendo solo cicli a vuoto, non produce risultati se non far passare il tempo. Una vera sospensione del programma prevede lo stop della CPU, ma qui entreremmo in bel altre discussioni. Quindi, tralasciando l’inutile spreco di energia che questa funzione arreca, è importante porre l’attenzione sull’aspetto semantico della questione.

Perché si dovrebbe utilizzare una funzione che non produce alcun effetto se non quello di perdere tempo (e sprecare energia)?

Molti, la stragrande maggioranza di quelli che utilizzano Arduino seguendo i tutorial che trovano in rete, la utilizzano per creare degli intervalli di tempo tra una funzione ed un’altra, per esempio per far lampeggiare un LED. Speriamo quindi di fare un regalo utile mostrando come si può fare lampeggiare un LED in modo sbagliato o in modo corretto. Partiamo dal modo sbagliato, dal modo “ufficiale”, quello descritto proprio sul sito di Arduino.

Poniamoci come obbiettivo di realizzare una porzione di codice tale che:

1. accenda un LED all’inizio di ognuno dei cicli composti dalle seguenti operazioni:
   1. acquisisca una tensione analogica
   2. legga il tempo ad ogni inizio della misura
   3. invii la misura e i tempi via porta seriale / USB
   4. indichi quanto tempo è trascorso al termine della misura
   5. spenga il LED
2. Ripeta questa serie di azioni esattamente una volta al secondo

Poniamo l’attenzione sull’avverbio esattamente perché è tutto ciò che fa realmente la differenza tra un lavoro ben fatto ed uno fatto male: ricordiamo che l’argomento centrale di questo articolo è l’impiego del tempo nei sistemi embedded.

Il nostro esercizio prevede quindi la scrittura di una serie di operazioni da eseguire con periodicità di 1 secondo. Partiamo dall’esempio riportato su https://www.arduino.cc/reference/en/language/functions/time/delay/ e mostrato nella seguente Figura 1.

Con poche modifiche possiamo ottenere il codice che assolve i compiti che ci siamo prefissati: è mostrato nella Figura 2.

Il codice è molto semplice. Nel setup() c’è l’inizializzazione del pin relativo al LED e l’abilitazione della comunicazione seriale a 9600 bps. Nel loop() troviamo invece tutta la sequenza di operazioni richieste: l’accensione e lo spegnimento del LED alle righe 12 e 20 rispettivamente, l’invio sulla seriale dei tempi e della misura. Infine la tanto desiderata funzione delay(1000) alla riga 21, un bel ciclo di attesa di 1000 ms. Dove è l’errore? Avviamo l’esecuzione e scopriamo cosa succede. Nel webinar ciò è illustrato con un video che mostra esattamente la ricezione dei dati inviati dalla scheda Arduino. Qui per ovvi motivi sono riportati solo un paio di screenshot. Dal primo dei due, Figura 3, si evince subito che il ciclo non dura 1 secondo ma 1 secondo e 7 millisecondi.

Come è ben evidente questo ritardo si accumula di ciclo in ciclo e porta, come mostrato in Figura 4, ad avere un errore di mezzo secondo dopo appena 63 cicli.

Il codice fa esattamente quello che è scritto, sintatticamente è corretto e viene eseguito dal microcontrollore senza problemi, ma è semanticamente sbagliato. Infatti, così facendo non otteniamo una periodicità di 1 secondo ma di 1 secondo e qualche millesimo. E se dopo 63 cicli abbiamo già perso mezzo secondo, immaginate a quanto si può arrivare dopo un intero giorno di lavoro.

Finché si tratta di far lampeggiare un LED tutto ciò può essere tollerabile, ma in tante altre applicazioni no. È quindi un modo di fare assolutamente sbagliato. Alcuni potrebbero obiettare che si potrebbe ridurre il delay da 1000 a 993 o 994. Bene, intanto abbiamo due possibili valori, se osservate la sequenza a volte il ritardo è di 6 ms e a volte di 7 ms: quale mettiamo? Inoltre, ed è qui la cosa grave, semanticamente parlando siamo di fronte ad un errore concettuale grave, il processore in quell’attesa non può fare altro, è bloccato lì e questo riduce molto le potenzialità del sistema. Inoltre, se aggiungessimo istruzioni, per esempio la lettura di un ingresso, dovremmo andare a cambiare ancora una volta il delay. Quindi no, non si fa, non si deve usare, non è una cosa su cui si può opinare.

La soluzione a questi problemi è quella di usare un timer: dall’inglese time = tempo e quindi timer = temporizzatore. In pratica si tratta di una o più periferiche del nostro processore appositamente realizzate per generare eventi periodici. In realtà possono essere impostate per fare anche tante altre cose, per esempio per contare eventi, ma limitiamoci all’uso classico di cui abbiamo bisogno. Dipendentemente dall’architettura impostarne uno può essere un compito più o meno complesso, ma in Arduino trovate librerie per quasi tutto e ovviamente ce ne è una anche per la gestione dei timer. La trovate a questo indirizzo: https://playground.arduino.cc/Code/Timer/

Vediamo come cambia il nostro programma attraverso la Figura 5.

Nel setup() oltre all’inizializzazione di pin di output per LED e porta seriale ora troviamo la dichiarazione di una variabile chiamata timerEvent a cui è associato un timer con periodicità 1000 ms. Sinteticamente, quando sarà trascorso un secondo il flusso dell’esecuzione del programma si sposterà alla funzione chiamata timerISR. ISR sta per Interrupt Service Routine, cioè una serie di istruzioni da eseguire quando si verifica un particolare evento, cioè un interrupt. Ovviamente questa funzione può avere un nome qualsiasi, non ci sono vincoli se non quello che nel dare i nomi sarebbe opportuno darne di significativi. Come si può vedere la timerISR() è piuttosto minimale ed avrebbe potuto esserlo ancora di più. Ciò che è stato volutamente inserito è l’accensione del LED e l’invio in seriale del momento della chiamata di questa funzione. Dopo queste prime istruzioni è presente la “event = 1”, cioè si assegna un valore diverso da zero alla variabile event. Tutte le funzioni eseguite ad interrupt dovrebbero essere quanto più brevi possibili rimandando alla parte sincrona del listato lo svolgimento di compiti non necessariamente urgenti. Tornando nel loop(), attraverso il controllo “if (event == 1)” si passa all’esecuzione delle restanti istruzioni. Per fare in modo che queste istruzioni vengano eseguite solo una volta al secondo, prima di uscire dalla “if” bisogna azzerare la variabile event con “event = 0”. La sintassi è quindi molto semplice e comporta poche modifiche rispetto al listato originale, però il risultato è di assoluto altro livello, la periodicità è garantita come mostrato dagli screenshot di Figura 6 e Figura 7.

Come appare subito evidente dai primi secondi di esecuzione di Figura 6, l’accensione del LED avviene sempre all’inizio di ogni secondo e non più, come in precedenza, con un ritardo via via crescente.

Altra cosa importante, ma che ovviamente non è immediatamente visibile, è che terminata l’esecuzione delle istruzioni la CPU non ha altri compiti da assolvere, è scarica, non deve fare altro, e potrebbe essere messa tranquillamente in stato inattivo, in “idle”, per risparmiare energia.

In questo esempio, invece, per mantenere le cose il più semplice possibile, non è stata inserita alcuna altra istruzione e la CPU continua a “ciclare” all’interno del loop fino all’arrivo dell’evento successivo. Se fosse necessario aggiungerne non ci sarebbero problemi in quanto tutto ciò che è sincrono (all’interno del loop) non impatta sull’esecuzione di ciò che è asincrono (eseguito ad evento).

Dalla Figura 7 si può notare che la periodicità è garantita, l’avvio è sempre puntuale e nemmeno dopo ore ed ore di funzionamento c’è evidenza di alcun ritardo: questo è il modo corretto di programmare anche in ambiente Arduino. Queste ed altre tecniche sono universali, si possono applicare a qualsiasi microcontrollore di qualsiasi produttore, basterà adattarsi al diverso ambiente di sviluppo. Si dimostra così che il problema di molti non è non conoscere Arduino ma l’elettronica di base e il funzionamento dei dispositivi elettronici.

Dopo avere visto tutto ciò probabilmente è lecito chiedersi quando si può usare la delay(), perché se è stata messa a disposizione evidentemente un motivo ci deve essere. Ed in effetti una certa utilità può averla, ma non se ne può fare l’uso sconsiderato che si è soliti vedere praticamente ovunque: nei forum online, in gruppi, in articoli vari su riviste più o meno specializzate.

La delay() va usata solo quando non se ne può fare a meno, ovviamente, o quando si deve eseguire un pezzo di codice una sola volta, ad esempio per inizializzare una periferica all’avvio del sistema (nel setup()). Può succedere infatti che il costruttore di un particolare dispositivo dichiari che si debbano rispettare dei tempi prima di impostare i vari registri. In questi casi si può inizializzare i primi registri, utilizzare il delay per attendere che le modifiche abbiano effetto, proseguire con il resto dell’inizializzazione. Una volta che il nostro microcontrollore è operativo è vivamente sconsigliato l’utilizzo della delay(), ci sono metodi migliori come è stato mostrato sopra.

Ovviamente la programmazione di sistemi embedded richiede anni di formazione, non si impara in una settimana. Un consiglio utile è quello di essere curiosi, di non accontentarsi della prima soluzione che si trova, bisogna sempre chiedersi quale è il rovescio della medaglia: se si fa così che succede? Cercare informazioni, documentarsi e studiare è fondamentale. In rete c’è di tutto e di più, ma è importante saperlo cercare e organizzare in una sequenza progressiva corretta e coerente. L’alternativa più efficace è affidarsi a qualcuno di provata esperienza, perciò dai un’occhiata al nostro corso Electronic Maker Hiker.

Chi avesse dubbi o domande può scriverci utilizzando il seguente form.