47 / 86
DIGITAL
BENCHMARK
47
- ELETTRONICA OGGI 442 - GENNAIO/FEBBRAIO 2015
te la CPU non è il componente più
critico perché spesso viene appo-
sitamente astratta dagli algoritmi
scritti per i compilatori in linguag-
gio C orientati a generare codici
altamente ottimizzati. Ciò serve per
portare più facilmente i codici da
un’architettura a un’altra purché
gli utenti si prendano cura di poche regole di base come,
ad esempio, utilizzare solo codici ANSI C e definizioni dati,
conformi allo standard C99 per le variabili. Quest’ultimo
standard definisce la larghezza in bit dei dati con valo-
ri fissi, indipendentemente dall’architettura impiegata,
come si vede nella tabella 1. Inoltre, la CPU non è l’uni-
ca che assorbe energia nelle applicazioni perché anche
le periferiche e l’intera architettura di sistema possono
contribuire al consumo dell’energia. Ciò rende più dif-
ficile la scelta dell’equilibrio ottimo su cui basare i test
sulle prestazioni, affinché possano essere davvero agno-
stiche rispetto al processore impiegato e questo perché
le periferiche variano moltissimo le loro caratteristiche
in funzione del costruttore e spesso anche fra le diverse
famiglie dei prodotti di ciascun costruttore. Ciò significa
che le procedure di test sulle prestazioni devono essere
sviluppate in modo tale da offrire una certa flessibilità e
una relativa semplicità di integrazione per tutti i sistemi a
microcontrollore. Queste procedure devono, inoltre, ser-
vire per stabilire un set di funzionalità ad alto livello otti-
mizzate per le applicazioni ULP ma senza favorire qualche
particolare funzione dei microcontrollori. Dopo la CPU
e le periferiche, il più importante contributo al consumo
di potenza è legato all’intervallo di tempo impiegato dal
microcontrollore per risvegliarsi dalla modalità di stand-
by. In effetti, spesso si cerca a tutti i costi di abbassare il
consumo di energia durante le sue funzionalità operative
ossia quando il duty cycle è ON ma ci si dimentica che
non c’è microcontrollore che non passa la maggior parte
del tempo in standby. Tuttavia, quest’aspetto va bilanciato
con le esigenze in tempo reale del sistema di microcon-
trollo come, per esempio, le funzioni “calendario” che de-
vono essere aggiornate una volta ogni secondo. Un altro
esempio riguarda i sensori industriali che richiedono una
raccolta dati dall’ADC con velocità di 1 kSps e in base a
questa velocità i dati sono poi valutati e processati. D’al-
tro canto, molte applicazioni si svegliano ogni dieci se-
condi o anche per un solo minuto ogni giorno e perciò
può essere difficile valutare tutte le possibili casistiche
di duty cycle. Il tool ULPBench usa per questo motivo un
intervallo di risveglio di un secondo che soddisfa sia la
necessità di fornire un ragionevole tempo di analisi sul
funzionamento in tempo reale, sia la possibilità di adattare
il test alle differenti modalità a risparmio energetico. L’e-
nergia assorbita durante le fasi di risveglio non è sempre
specificata dai costruttori di microcontrollori e perciò di-
venta un parametro importante per i test sulle
loro prestazioni.
EEMBC ULPBench Phase 1: CoreProfile
Come descritto nell’introduzione, l’estrema
variabilità delle applicazioni ULP spiega per-
ché la suite di test è stata strutturata con di-
verse fasi di analisi. La prima è CoreProfile
e riguarda la CPU, l’accesso alla memoria, il
clock in tempo reale e le funzioni di rispar-
mio energetico. Questa funzione è applicabile
a un gran numero di applicazioni e offre un
valido strumento per confrontare i diversi mi-
crocontrollori. Nella fase CoreProfile, la rego-
la principale per qualsiasi applicazione ULP
è la considerazione che deve essere in grado
di utilizzare una batteria CR2032 da 225mAh
per almeno quattro anni, con un profilo appli-
cativo tipico nel quale deve avere almeno una
Tabella 1 – Le dimensioni dei dati nelle architetture CPU
Dimensioni in bit
CPU (larghezza bus dati)
Carattere
(Char)
Parola
(Word)
Minimo
(Short)
Intero
(Integer)
Uint16_t
(Senza segno
di 16 bit)
MCU 8 bit
8
-
8
16
16
MCU 16 bit
(come MSP430)
8
16
16
16
16
MCU 32 bit
8
32
16
32
16
Fig. 2 – Schermata di una fase di test generata dal tool EnergyMonitor attraverso una GUI
ULPBench. L’energia misurata durante la cattura di una finestra è illustrata nel grafico
Graph interno al CoreProfile