Il microcontrollore riveste un ruolo di fondamentale importanza per quanto concerne i consumi di un progetto: in un contesto come l’attuale dove l’efficienza energetica è un fattore sempre più determinante, gli utenti ripongono aspettative sempre maggiori su questo dispositivo. Le modalità di realizzazione e di funzionamento dei microcontrollori devono subire una decisa evoluzione nel momento in cui viene loro richiesto di fornire prestazioni sempre più elevate a fronte di risorse di batteria limitate. Partendo dalla considerazione che il costo di una batteria a bottone può essere più elevato rispetto a quello di una Mcu, il progetto di un sistema che risulti il più efficiente possibile dal punto di vista energetico appare vantaggioso. In primo luogo permette di ridurre costi e dimensioni della batteria. In secondo luogo consente di aumentare la durata della batteria stessa, e quindi di ridurre costi, frequenza e impatto ambientale legati all’intervento del servizio di manutenzione. Per i microcontrollori, così come per numerose altre tipologie di componenti elettronici, appare conveniente evidenziare le caratteristiche di bassissimi consumi, un elemento importante laddove giustificato dal range dinamico del dispositivo considerato: in ogni caso, poiché la quantità di carica disponibile da una cella della batteria è chiaramente definita, è necessario analizzare con attenzione le modalità secondo le quali un micro utilizza questa energia – ovvero il consumo in funzione del tempo. I progettisti devono minimizzare il prodotto tra la corrente e il tempo in tutte le fasi del funzionamento del micro, sia nei periodi di attività sia in quelli di “sleep”: quindi devono prendere in considerazione non solo ogni microampere, ma anche il numero di microsecondi impiegati per lo svolgimento di qualsiasi funzione. Appare logico domandarsi perché continuare a usare un micro a 8 o a 16 bit.
8, 16 e 32 bit a confronto
Se si considerano solo le caratteristiche legate al consumo di potenza in modalità “deep-sleep”, è facile comprendere perché si è tradizionalmente preferito ricorrere a micro a 8 e a 16 bit nelle applicazioni sensibili all’aspetto energetico, dove i duty cycle del microcontrollore possono essere molto ridotti. Dopotutto, un micro può rimanere in modalità “deep sleep” per il 99% del tempo. Nel caso invece si prendano in considerazione ogni microampere e ogni microsecondo richiesto da ciascuna funzione, l’utilizzo di una Mcu a 32 bit sarebbe un’opzione da tenere più spesso in considerazione anche nel caso di progetti molto semplici. Le maggiori prestazioni dei microprocessori a 32 bit consente un completamento di un processo in un tempo inferiore, permettendo in tal modo alla Cpu di trascorrere più tempo nelle modalità “deep sleep”, il che si traduce in una diminuzione del consumo di energia complessivo. Le Mcu a 32 bit, quindi, non sono necessariamente sovradimensionate rispetto a certe applicazioni. Molto più spesso di quanto si pensi, anche semplici operazioni su variabili a 8 o 16 bit potrebbero richiedere le risorse di un micro a 32 bit nel caso sia necessario conseguire alcuni obiettivi in termini di utilizzo dell’energia. Sfruttando al meglio le potenzialità delle attuali tecniche di progettazione a basso consumo, è possibile ad esempio ricorrere ai core Arm a 32 bit, caratterizzati dalla presenza di un gran numero di modalità a basso consumo che assicurano prestazioni uguali se non addirittura migliori rispetto a quelle di alternative a 8 bit. Un’altra convinzione errata è che il passaggio da una Mcu a 8 bit a una a 32 bit comporti un aumento delle dimensioni del codice, che influenza costi e consumi dei prodotti finali. Ciò nasce dalla convinzione che le Mcu a 8 bit utilizzano istruzioni a 8 bit e che Mcu a 32 bit utilizzano istruzioni a 32 bit. In realtà, molte istruzioni di Mcu a 8 bit hanno un lunghezza pari a 16 o 24 bit. I processori Cortex-M3 e Cortex-M0 di Arm sono basati sulla tecnologia Thumb-2 che garantisce un’elevata densità di codice. Le Mcu che adottano questa tecnologia hanno istruzioni sia a 16 sia a 32 bit: queste ultime sono un superset delle istruzioni a 16 bit. Il 90% delle istruzioni fornite in uscita da un compilatore C sono di tipo a 16 bit. La versione a 32 bit viene utilizzata solamente nei casi in cui un’operazione non possa essere effettuata con un’istruzione a 16 bit. Ne consegue che la maggior parte delle istruzioni di un programma per una Mcu Cortex di Arm sono a 16 bit. Si tratta quindi di istruzioni di lunghezza inferiore rispetto a quella di parecchie istruzioni di Mcu a 8 bit: di conseguenza, le dimensioni del codice compilato di una Mcu a 32 bit sono inferiori rispetto a quelle di Mcu a 8 e 16 bit.
L’importanza delle modalità “sleep”
Anche se l’impiego di un processore a 32 bit consente a una Mcu di rimanere in una modalità “deep sleep” per un periodo più lungo, esistono consumi di potenza di base che possono avere un impatto notevole sul bilancio energetico. Storicamente i processori a 32 bit non sono stati in grado di supportare modalità di standby con consumi inferiori al μA. Grazie all’introduzione di architetture a 32 bit particolarmente efficienti dal punto di vista energetico, le opzioni di standby vanno a integrarsi con la riduzione dei tempi attivi e di elaborazione. I consumi relativamente bassi di molte Cpu in modalità “deep sleep” fanno sì che le funzionalità che sono in grado di supportare quando si trovano in questo stato sono spesso limitate. Poiché molte applicazioni richiedono funzionalità sempre abilitate, molte Cpu non possono neppure entrare in modalità “deep sleep” poiché il supporto di tali funzionalità è disponibile solo in modalità attiva. Senza dimenticare che un gran numero di Cpu hanno limitate, se non nulle, capacità di mantenimento dello stato della memoria Sram o della Cpu nelle modalità di standby con consumi inferiori al μA. In parecchie delle soluzioni disponibili è necessario escludere o porre in duty cycle i rivelatori di brown-out e Por al fine di contenere i consumi. Allo scopo di garantire l’efficienza energetica, quindi, i microcontrollori devono mettere a disposizione dei progettisti una gamma di modalità di “sleep” che diano la possibilità di regolare le risorse base, e quindi i consumi, secondo livelli definiti o modalità energetiche.
Un risveglio rapido
È ovvio che ha poco senso offrire una Cpu con ridottissimi consumi in modalità “sleep” se il guadagno conseguito in termini di efficienza energetica viene vanificato a causa del tempo richiesto dalla Cpu per “svegliarsi” e iniziare a funzionare. Quando una Mcu passa da uno stato “deep sleep”, dove gli oscillatori sono disabilitati, a uno stato attivo, esiste sempre un periodo di risveglio durante il quale il processore deve aspettare la stabilizzazione degli oscillatori prima di iniziare l’esecuzione del codice. Poiché in questo periodo non può essere effettuata alcuna elaborazione, l’energia spesa in questo periodo è totalmente sprecata: di conseguenza è importante ridurre il periodo di wake-up per ottimizzare il consumo di energia. È anche importante tenere in considerazione che numerose applicazioni sono di tipo real-time, il che implica la minimizzazione del tempo di risveglio al fine di consentire all’Mcu di rispondere a un evento in un periodo di tempo prefissato. Poiché il tempo di latenza richiesto in parecchie applicazioni è inferiore al tempo di wake-up di molte Cpu, il dispositivo non può entrare in modalità “deep sleep”, il che non rappresenta la soluzione ideale nelle applicazioni dove il risparmio energetico rappresenta un fattore critico. Una possibile soluzione è ricorrere a un oscillatore RC molto veloce capace di “risvegliare” la Cpu in tempi brevissimi e trasferire, se necessario, la generazione del clock a un oscillatore a quarzo. In questo modo risulta possibile soddisfare le esigenze delle applicazioni real time oltre a favorire il duty-cycle delle modalità di “sleep” e attiva. Nonostante l’oscillatore RC non sia così preciso come un oscillatore a quarzo, rappresenta una soluzione adeguata come generatore di clock della Cpu durante l’avviamento del cristallo.
Uno sguardo al clock
Il ritorno a una modalità di “sleep” è un elemento critico per il risparmio energetico. Di conseguenza la Cpu dovrebbe operare a una frequenza di clock elevata per espletare il proprio compito in maniera più rapida ed efficiente. Il vantaggio è legato al fatto che il sistema è in grado di ritornare alle modalità a basso consumo in un tempo più breve. Le periferiche, dal canto loro, potrebbero non richiedere il funzionamento alla frequenza di clock della Cpu. Una possibile soluzione a questo dilemma è di regolare preventivamente il clock relativamente al core e alle periferiche in modo da minimizzare il consumo di potenza dinamico dei differenti componenti. Nel caso le periferiche possano operare senza la supervisione della Cpu, ci si potrà rendere conto che un sistema di temporizzazione flessibile è un requisito importanzte per avere Cpu efficienti dal punto di vista energetico.
Autonomia delle periferiche
Per minimizzare il consumo di energia da parte dei microcontrollori è necessario consentire alla Cpu di restare “addormentata” e quindi disporre di periferiche in grado di operare con un intervento minimo o nullo da parte della Cpu stessa. Nel momento in cui le periferiche sono occupate a svolgere le proprie funzioni, la Cpu può espletare compiti di livello più elevato oppure entrare in una modalità di “sleep”. Grazie a una più avanzata programmazione delle sequenze, le routine relative alle periferiche in funzione che in precedenza erano controllate dalla Cpu possono essere gestite dalle periferiche. L’utilizzo di un controllore Dma si propone come un approccio utile per garantire il funzionamento autonomo delle periferiche. Contribuendo al passaggio del carico di lavoro dalla Cpu alle periferiche, un controllore Dma può gestire in maniera efficace i trasferimenti dati tra la memoria e le interfacce di comunicazione o di elaborazione dati. Ovviamente non ha molto senso utilizzare periferiche autonome per alleggerire il carico di lavoro della Cpu se sono caratterizzate da consumi elevati. I produttori di Cpu devono monitorare attentamente il consumo di energia delle periferiche quali le interfacce di comunicazione seriali, gli engine di cifratura/decifrazione, i circuiti di pilotaggio per i display e le periferiche per comunicazione radio. Tutte le periferiche devono essere implementate in maniera efficiente per quel che concerne l’aspetto energetico al fine di soddisfare i requisiti dell’applicazione in termini di consumi.
Il debug dell’energia
Il fatto di poter disporre di un microcontrollore efficiente in termini energetici non dà agli utilizzatori la certezza che venga utilizzata la minore energia possibile. Siccome è necessario fare parecchie scelte nel corso della realizzazione di un sistema, tutte possono avere un impatto sui consumi. Mentre la Cpu può rivestire un ruolo di fondamentale importanza, la scelta dei componenti più idonei e la loro corretta integrazione sono elementi altrettanto critici. La capacità di individuare e rimuovere le perdite di energia negli stadi iniziali dello sviluppo di un prototipo può contribuire a ridurre il consumo di energia finale. Inoltre è utile considerare il processo di debug di sistemi embedded a basso consumo come un ciclo a tre fasi: debug hardware, debug delle funzionalità software e debug dell’energia. I tool di sviluppo per Mcu devono a loro volta subire un’evoluzione in modo da consentire ai progettisti di identificare i “bachi di energia” nel software nel corso del ciclo di sviluppo.
Microcontrollori ad alta efficienza energetica
Energy Micro ha realizzato una Mcu a 32 bit a elevata efficienza energetica caratterizzata da consumi pari a ¼ rispetto a quelli di analoghi prodotti a 8, 16 e 32 bit. Utilizzando la Mcu della serie EFM32 Gecko i progettisti di sistemi per i quali i consumi rappresentano un elemento critico possono disporre della capacità di elaborazione richiesta per lo sviluppo dei prodotti della prossima generazione ed essere in grado allo stesso tempo di allungare di almeno il 300% la durata di una tipica batteria a 3V. Utilizzando le più recenti tecniche di progettazione a basso consumo, Energy Micro ha realizzato questa Cpu sfruttando un core Arm Cortex-M3 a 32 bit. L’architettura del chip è stata realizzata a partire da zero in modo da privilegiare gli aspetti energetici. L’EFM32 prevede cinque diverse modalità energetiche per minimizzare i consumi. Le Mcu Gecko permettono la realizzazioni di numerosi sistemi con l’aggiunta di un numero ridotto di componenti esterni grazie alla presenza on-chip di una vasta gamma di funzioni periferiche low-power. Tra queste si possono annoverare un convertitore A/D a 12 bit a 8 canali caratterizzato da una velocità di conversione di 1MSample/s e un consumo di 200 μA alla massima risoluzione, un controllore per Lcd a 4x40 segmenti che utilizza una corrente di soli 550 nA e fornisce funzioni di boost (aumento di tensione), controllo di luminosità, contrasto, animazione e lampeggiamento oltre a un Uart a bassa energia con un clock a 32 kHz che consuma solo 100mA con una velocità di trasmissione dati di 9.600 baud. Per espletare compiti di cifratura/decifratura, l’integrazione di un acceleratore Aes dedicato consente alla Cpu di trasferire l’elaborazione dell’algoritmo di cifratura AES a un componente hardware dedicato, proseguire con altri tipi di elaborazione e recuperare i dati cifrati o decifrati in tempi di brevi, con conseguente risparmio dell’energia della batteria. EFM32 integra una struttura di interconnessione denominata Peripheral Reflex System che consente alle periferiche di colloquiare tra di loro senza richiedere l’intervento del core Arm, in modo da consentire al core stesso di restare nello stato di “sleep” e consumare meno energia. I kit di sviluppo di EFM32 integrano anche un sistema Aem (Advanced Energy Monitoring), una funzione che consente una misura continua della corrente consumata. Una misura di questo tipo consente di valutare accuratamente la potenza utilizzata in funzione del tempo, in modo da permettere l’ottimizzazione di casi reali e garantire quindi un funzionamento a basso consumo. Mediante il display LCD presente a bordo dei kit di sviluppo è possibile visualizzare in modo grafico il consumo di energia. Quando utilizzato con il tool software per il debug dell’energia energyAware Profiler, il sistema Aem consente all’utilizzatore di identificare il codice sorgente effettivo che viene eseguito in un determinato periodo di tempo come visualizzato dal grafico dell’energia. In questo modo il progettista può avere un’indicazione istantanea di ogni parte del programma che provoca consumi elevati e quindi ottimizzare il codice in modo da garantire i consumi più ridotti possibili.
