UART per il debug dei dispositivi embedded: best practice per dispositivi a basso consumo

USB la fa da padrone per la maggior parte delle periferiche ma UART è ancora vivo e vegeto nel mondo dei sistemi embedded, utilizzato per il debug di qualsiasi cosa, dai moduli GPS alle schede Raspberry Pi e Arduino.

Tuttavia, data la tendenza inarrestabile verso progetti che consumano sempre meno, gli sviluppatori spesso si domandano se UART non sia un killer silenzioso della batteria. La risposta è facile: No, non necessariamente. Come ogni buono strumento, tutto dipende da come lo si implementa. Vediamo come stanno le cose.

Tenere d'occhio la corrente di dispersione TX/RX

Un modo semplice per evitare un inutile assorbimento di potenza è quello di affrontare il problema delle correnti di dispersione dai canali TX e RX. Anche se non è molto comune che vi siano perdite elevate, è sempre meglio controllare e risolvere i potenziali problemi in anticipo per evitare in futuro un consumo energetico inaspettato.

Scrivere ed eseguire il codice pensando a bassi consumi energetici

Considerate UART come il vostro coltellino svizzero per il debug: è molto utile durante lo sviluppo, ma non lo portereste sempre aperto in tasca. Una mossa intelligente è quella di utilizzare un'istruzione #define nel codice per attivare UART per il debug e disattivarlo quando il dispositivo viene messo in produzione. È un trucco semplice, ma può salvarvi dagli incubi del mondo reale.

Immaginate questa situazione: voi e il vostro team siete super concentrati sulla riduzione al minimo del consumo energetico. State eseguendo misurazioni continue della corrente e notate ottimi progressi. Durante lo sviluppo, lasciate UART abilitato per il debug, accettando il temporaneo calo di energia. Ma poi qualcuno accidentalmente unisce quel codice nel ramo principale, con UART ancora abilitato, che viene così diffuso via etere su milioni di dispositivi. Improvvisamente, il vostro progetto, un tempo efficiente, assorbe l'energia delle batterie come una macchina da gioco e vi ritrovate con una miriade di clienti insoddisfatti.

Qual è la soluzione? Creare un sistema di integrazione continua con benchmark di consumo di corrente. Ciò consente di individuare problemi come questo prima che diventino errori costosi. Consideratela come una rete di sicurezza automatica che tiene sotto controllo gli ampere extra prima che il codice raggiunga la produzione.

Assicuratevi di spegnere tutto

L'abilitazione di UART può attivare diverse parti del software, tra cui vari blocchi MCU e clock. Spesso, per facilitare lo sviluppo gli MCU sono progettati con tutte le funzioni attivate per impostazione predefinita. Tuttavia, prima che l'MCU entri in modalità di sospensione è fondamentale disattivare i componenti che non servono. Se i clock UART rimangono abilitati, potrebbero impedire all'MCU di raggiungere lo stato di sospensione più profonda, con conseguente aumento del consumo energetico. Rivedete la vostra struttura di clock e assicuratevi che tutti i componenti collegati a UART siano spenti correttamente, quando non sono necessari.

Esperimento Otii in azione

Confrontiamo due versioni del firmware in esecuzione sullo stesso dispositivo, Seeed Studio XIAO nRF52840 di Seeed Technology. Abbiamo preparato uno script di esempio che inizializza il modulo, imposta la memoria flash, esegue una breve sequenza di lampeggiamento dei LED e mette poi il modulo in modalità di consumo energetico minimo. In una versione UART è abilitato, nell'altra no. Utilizzando Otii Ace Pro di Qoitech, abbiamo misurato il consumo di corrente per analizzarlo e confrontarlo in entrambe le versioni a diversi livelli di tensione.

Nella Figura 1 si vede il dispositivo che invia attivamente messaggi UART, mentre la Figura 2 mostra l'MCU in modalità di sospensione. La linea blu indica che UART è abilitato, mentre la linea arancione indica che è disabilitato. La differenza evidenzia l'impatto che UART può avere sul consumo energetico.

Figura 1: Dispositivo SeeedStudio XIAO nRF52840 attivo con comunicazione UART | Abilitato (grafico blu) | Disabilitato (grafico arancione). (Immagine per gentile concessione di Qoitech)

Figura 2: Dispositivo XIAO nRF52840 in modalità a consumo ridotto (parte selezionata del grafico) con comunicazione UART | Abilitato (grafico blu) | Disabilitato (grafico arancione). (Immagine per gentile concessione di Qoitech)

In modalità attiva, il consumo medio di corrente è passato da 460 μA a 1,34 mA (come mostrato nella Figura 1). In modalità di sospensione, il consumo di corrente passa da 2,27 μA a 2,19 μA (Figura 2). Sebbene tale differenza possa sembrare insignificante, lunghi periodi di sospensione tipici dei dispositivi IoT incidono sensibilmente sulla durata della batteria. Chiaramente, il firmware è ottimizzato per quando UART è disabilitato.

Stima della durata della batteria con Otii

Per illustrare l'impatto sulla durata della batteria, abbiamo utilizzato Battery Life Estimator di Otii Desktop App. Abbiamo ipotizzato un periodo attivo all'ora, in cui il dispositivo si riattiva, esegue la sequenza di lampeggio e poi va in sospensione per circa 3600 secondi.

Nella Figura 3, UART è disabilitato e nella Figura 4 è abilitato. La differenza della durata della batteria fra i due casi è notevole.

Figura 3: Stima della durata della batteria con comunicazione UART disabilitata. (Immagine per gentile concessione di Qoitech)

Figura 4: Stima della durata della batteria con comunicazione UART abilitata. (Immagine per gentile concessione di Qoitech)

La differenza è enorme! La durata stimata della batteria scende da 5,9 anni a soli 11,6 giorni quando UART viene lasciato abilitato.

L'insegnamento più importante che se ne trae è assicurarsi che tutto ciò che riguarda UART sia spento prima che l'MCU entri in modalità sospensione. L'inserimento di questo aspetto nel vostro processo di integrazione continua utilizzando Otii Product Suite vi aiuterà a prevenire rilasci di prodotti con UART accidentalmente abilitato, che potrebbe ridurre drasticamente la durata della batteria del vostro dispositivo.