L’aumento della popolarità dei dispositivi microcontroller (MCU) a 32 bit nella comunità embedded non è una sorpresa. Questi dispositivi ricchi di funzioni si adattano a una serie di applicazioni diverse, il che spiega perché molti sviluppatori embedded li scelgono per i loro prossimi progetti. I progettisti riconoscono che tali dispositivi complessi offrono tutto ciò di cui hanno bisogno in termini di potenza di calcolo grezza, un ricco set di periferiche e un facile accesso a una vasta gamma di strumenti di sviluppo e librerie.
Molti di questi dispositivi a 32 bit sono basati su core ARM di grande successo. Così, gli sviluppatori si sentono sicuri nell’avere accesso a dispositivi second source e un set completo di strumenti di sviluppo, test e validazione disponibili sul mercato.
Tuttavia, uno sguardo più attento alle recenti tendenze del mercato MCU rivela che i dispositivi a 32 bit non sono gli unici a registrare una forte crescita (Tabella 1). Il nascente mercato delle MCU a 8 bit vanta un tasso di crescita composto (6,4%) vicino a quello del 32 bit (6,9%). Altri analisti del settore prevedono tassi di crescita identici per i microcontrollori a 8 e 32 bit.
La ripresa dei dispositivi a 8 bit evidenzia chiaramente che ci devono essere delle ragioni convincenti per usare un dispositivo a 8 bit al posto di un MCU a 32 bit. Questo articolo cerca di far capire perché i dispositivi a 8 bit stanno mantenendo la quota di mercato.
Differenze essenziali
Le principali differenze tra gli MCU a 8 e a 32 bit sono il costo e la struttura del prezzo, le prestazioni della CPU, la facilità d’uso, l’efficienza nelle funzioni vicine all’hardware e il consumo di energia statica. Quando si imbarcano in un nuovo progetto, gli sviluppatori hanno bisogno di valutare attentamente i requisiti di una MCU in base alla quantità di capacità di elaborazione richiesta, il grado di interfacciamento necessario e, per i progetti alimentati a batteria, i profili di consumo energetico fondamentali. Non c’è dubbio che un MCU a 32 bit offra prestazioni più elevate di un dispositivo a 8 bit, ma l’ingegnere deve affrontare la tradizionale decisione di scegliere tra il miglior dispositivo disponibile sul mercato e le reali esigenze dell’applicazione.
Ovviamente, queste decisioni influenzano notevolmente il probabile costo della distinta dei materiali (BOM). Con un numero di gate inferiore, un dispositivo a 8 bit meno complesso sarà certamente più economico di un dispositivo a 32 bit. Quando si confrontano MCU a 8 e 32 bit dei principali fornitori, ciascuno con una quantità simile di memoria flash, pin-out ecc, i dispositivi a 8 bit costano tipicamente circa il 20% in meno. Ma questa è solo la prima di molte considerazioni. Un altro aspetto riguarda la facilità di impostazione per un nuovo sviluppo.
Facilità di sviluppo
I fornitori di MCU tendono ad aggiungere più caratteristiche e funzionalità ai loro dispositivi a 32 bit rispetto ai prodotti a 8 bit. Di conseguenza, emergono molte più considerazioni di configurazione con un dispositivo più complesso. Mentre alcune MCU a 32 bit possono funzionare con una configurazione limitata simile a quella di un dispositivo a 8 bit, non si è in grado di sfruttare le caratteristiche aggiuntive del dispositivo più potente.
 |
Scarica questo articolo in formato .PDF Questo tipo di file include grafica ad alta risoluzione e schemi quando applicabile. |
Per esempio, un tipico dispositivo ARM a 32 bit avrà impostazioni di clock indipendenti per il core stesso, il bus AHB, il bus APBA e il bus APBB. Tutti possono essere impostati a frequenze diverse. Tipicamente, dovrai anche passare al clock che vuoi usare perché è impostato nel software, non nell’hardware come la maggior parte delle parti a 8 bit. Inoltre, cambiare il clock significa che dovete impostare gli stati di attesa per la flash, possibilmente in base alla tensione VCC misurata.
Tale impostazione può essere molto più semplice con un MCU a 8 bit, però. Per esempio, i prodotti tinyAVR e megaAVR di Atmel richiedono solo l’inizializzazione del puntatore dello stack, che tipicamente richiede quattro righe di codice, prima di codificare l’applicazione. La scelta del clock, il rilevatore di brownout, la funzione del pin di reset, ecc, è tutto pre-programmato nel dispositivo.
L’architettura è anche molto più semplice di un dispositivo a 32 bit con registri interni, periferiche e SRAM tutti mappati sullo stesso bus dati. Le periferiche e la CPU funzionano normalmente alla stessa frequenza, quindi non è necessaria alcuna configurazione del bus periferico. Inoltre, i progettisti possono evitare di preoccuparsi della latenza nella sincronizzazione tra diversi domini di clock.
Performance
Quando si tratta delle prestazioni desiderate della CPU, l’ingegnere dovrebbe considerare tutti i casi d’uso. La realtà è che molti progetti embedded non hanno requisiti di calcolo elevati. Spesso, è richiesta una minima manipolazione dei dati, quindi bilanciare queste esigenze contro il consumo di energia e i requisiti di interfacciamento delle periferiche diventa cruciale.
Per esempio, una semplice applicazione termostato passerà la maggior parte della sua vita in una modalità sleep. Di tanto in tanto, si sveglierà e misurerà la temperatura e poi prenderà una decisione per accendere/spegnere un relè o inviare un’istruzione a un controller host. Poi riprenderà il sonno. I requisiti di calcolo e di interfaccia di questa applicazione sono piccoli, ma anche molte altre applicazioni come rivelatori di incendio, utensili elettrici, misuratori di flusso e controlli di apparecchi hanno un profilo d’uso simile.
Efficienza delle funzioni vicine all’hardware
Molti microcontrollori moderni incorporano alcune funzioni hardware che servono ad aiutare la CPU ad operare nel modo più efficiente possibile. Nel caso di Atmel, sia la famiglia di MCU a 8 bit AVR che quella a 32 bit basata su ARM presentano il Peripheral Event System. Un sistema di eventi è un insieme di caratteristiche basate sull’hardware che permette alle periferiche di interagire senza l’intervento della CPU. Permette alle periferiche di inviare segnali direttamente ad altre periferiche, garantendo un tempo di risposta breve e prevedibile al 100%.
Quando si utilizzano completamente le capacità del sistema di eventi, il chip può essere configurato per fare operazioni complesse con pochissimo intervento da parte della CPU, risparmiando sia la preziosa memoria del programma che il tempo di esecuzione. Nel caso del rilevamento di un evento hardware, è importante prima rilevare l’evento e poi passare il controllo alla routine di servizio degli interrupt (ISR) desiderata.
In queste situazioni, la velocità della CPU non è il singolo fattore determinante. È una questione di quanto tempo, in termini di cicli, ci vuole per rispondere all’interrupt, eseguire l’ISR e ritornare. Come l’esempio seguente mostrerà, i dispositivi a 8-bit possono essere più efficienti nella gestione delle azioni vicine all’hardware.
Considera di ricevere un byte sulla SPI, usando un interrupt per rilevarlo, e poi eseguire una semplice routine ISR per leggere il byte dalla periferica SPI e memorizzarlo nella SRAM. Usando questo scenario, la tabella 2 fa un confronto tra un dispositivo AVR a 8 bit di Atmel e un MCU a 32 bit basato su ARM Cortex M0+ di Atmel. Calcolati con le informazioni disponibili, i risultati sono basati su implementazioni minime. Tuttavia, gli ingegneri dovrebbero controllare con le loro applicazioni poiché il rilevamento dell’interrupt e il ritorno dall’interrupt potrebbero richiedere più cicli di quanto mostrato nella tabella. Richiedere 12 cicli contro 33 cicli equivale ad avere una larghezza di banda SPI massima teorica di 1,67 MB/s per la CPU a 8 bit e una larghezza di banda di 606 kB/s per una CPU a 32 bit quando funziona a 20 MHz.
Il grado di elaborazione numerica può anche avere un impatto sullo stack e sulla memoria richiesta. L’applicazione dell’algoritmo di Fibonacci è un metodo particolarmente buono per testare i requisiti di memoria. Poiché usa solo una variabile locale, tutto deve essere spinto sullo stack.
Facendo un confronto tra un AVR a 8 bit e un dispositivo ARM a 32 bit basato su CM0+, e usando un algoritmo ricorsivo di Fibonacci a 15 stadi, l’AVR usa un totale di 70 byte di stack, inclusi 30 per il return stack (15 chiamate in profondità). Il dispositivo basato su ARM usa 192 byte (60 dovrebbero essere lo stack di ritorno). Questo significa che il CSTACK è più di tre volte più grande della soluzione a 8 bit. Nel tipico codice C, la maggior parte delle variabili sullo stack sono spesso in un formato compresso, quindi questo è un angolo estremo. Tuttavia, dire che da 1,5 a 3 volte più SRAM è necessaria per la stessa applicazione 8-bit-centrica su un dispositivo a 32-bit (contro un 8-bit nativo) è una stima corretta.
Consumo di energia
Nessun articolo MCU sarebbe completo senza indagare sul consumo di energia statica. Questo da solo può essere un fattore chiave nella scelta tra un dispositivo a 8 o 32 bit, specialmente per applicazioni alimentate a batteria. La tabella 3 illustra le differenze di consumo energetico tra i dispositivi a 8 e 32 bit sia in modalità attiva che statica.
Le tecnologie di produzione aggressive aumentano la corrente di dispersione dei transistor, che raddoppia approssimativamente con ogni generazione di processo ed è proporzionale al numero di porte. La corrente di dispersione aumenta esponenzialmente alle alte temperature, il che può essere facilmente trascurato quando si progetta un design consumer. I telefoni cellulari e i lettori multimediali personali vengono trasportati ovunque, e come tutti abbiamo scoperto, le temperature sperimentate durante l’estate all’interno di un’auto possono facilmente salire sopra i 40°C.
La quantità di tempo che il microcontrollore passerà in modalità attiva rispetto alla modalità statica contribuisce in modo significativo al budget complessivo di potenza dell’applicazione.
Naturalmente, il rapporto tra modalità attiva e statica varierà a seconda dei requisiti dell’applicazione. Riprendendo l’esempio precedente dell’interrupt SPI (Tabella 2, di nuovo) e assumendo una larghezza di banda dati SPI di 80 kb/s, la CPU a 8 bit spenderà l’1,2% del suo tempo in modalità attiva rispetto a quella a 32 bit, che spenderà il 3,3% in modalità attiva (Tabella 4).
Conclusione
Contemplare se usare un microcontrollore a 8 o a 32 bit per un progetto futuro può coinvolgere un’applicazione Internet delle cose (IoT). Il modo in cui l’IoT prende effettivamente forma provoca molti dibattiti, ma certamente sfiderà gli ingegneri a fare una valutazione dettagliata del requisito MCU. La connettività wireless, specialmente ZigBee, sarà anche un componente essenziale, ma questo non significa automaticamente che avrà bisogno di un dispositivo di potenza superiore.
|
Scarica questo articolo in .PDF Questo tipo di file include grafica ad alta risoluzione e schemi quando applicabile. |
Un certo numero di prodotti microcontroller a 8 bit disponibili soddisfano il bisogno di bassi livelli di elaborazione e connettività wireless. Uno di questi esempi è la serie ATmegaRFR2 di Atmel, che fornisce una soluzione di microcontroller wireless a 2,4 GHz, conforme a IEEE 802.15.4, a chip singolo, adatta ai progetti IoT a batteria e a basso costo.
Ingar Fredriksen, direttore marketing MCU di Atmel per la regione EMEA, ha sede a Trondheim, Normandia. Ha conseguito la laurea in ingegneria elettrica presso il Trodheim University College.
Paal Kastnes, ingegnere dello staff del team Applicazioni MCU, specializzato nella formazione del personale e dei clienti Atmel nell’utilizzo dei microcontrollori e degli strumenti Atmel, ha anch’egli sede a Trondheim. Ha conseguito la laurea in ingegneria elettrica presso il Trondheim University College.