Le tecniche di power management per i dispositivi C8051F30x e C8051F31x: il calcolo della potenza e le tecniche di risparmio.
Il C8051F30x e il C8051F31x di Silabs sono ottime scelte per applicazioni in low power. Dotati di un flessibile clock hardware e lavorando a 3V, consentono un risparmio di energia. In questo articolo vedremo le varie tecniche di gestione della potenza, il funzionamento del clock interno ed esterno. Elencheremo anche alcuni esempi e faremo vedere come realizzare un tipo di funzionamento “mode sleep” che consente il risparmio assoluto della potenza. Come conclusione analizzeremo altre teccniche di Power management e forniremo importanti nozioni sulle loro conseguenze in campo industriale.
Il C8051F30/1x
Il processore C8051F301 è un potente sistema integrato con le seguenti caratteristiche:
➤ High speed pipeline;
➤ Oscillatore interno a 25 MHz;
➤ 256 bytes di RAM;
➤ Contatore programmabile.
La memoria è costituita da 8 kbyte di memoria Flash con possibilità di riprogrammarla (512 bytes). La famiglia del C8051F30x include SMBus/I2C e un fullduplex UART. Inoltre dispone di un convertitore Analogico/digitale a 8 bit 10 canali. In figura 1 lo schema a blocchi.
Figura 1: schema a blocchi C8051F30x.
Calcolo della potenza di consumo
La progettazione di un dispositivo segue il calcolo del suo consumo di energia; stimare la capacità di consumo è un elemento fondamentale. Lo scopo è cerca re di progettare il dispositivo in modo da minimizzare il suo consumo di energia. Bisogna tener conto dei singoli dispositivi: oscillatore, CPU, porte I/O, periferiche analogiche. Il contributo dell’oscillatore si ha sia nel caso oscillatore interno che esterno. La CPU ha un ruolo predominante e dipende dal tipo di modalità di funzionamento (mode). Le periferiche analogiche sono quelle relative all’ADC, sensori di temperatura e altre. Le principali tecniche di funzionamento dell’oscillatore esterno sono:
➤ Oscillatore a cristallo: è la modalità di maggior consumo di energia ma fornisce un riferimento temporale molto preciso;
➤ Oscillatore CMOS: consumo di energia minimo (fattore trascurabile). Può essere usato come riferimento per altre periferiche, CPU, PCA. Nelle figure 2 e 3 riportiamo, invece, le caratteristiche relative rispettivamente ad altre configurazioni di oscillatori: oscillatore capacitivo e oscillatore RC.
Figura 2: oscillatore capacitivo a 33pF (C8051F30x).
Figura 3: oscillatore RC.
Il consumo di potenza digitale è dominato dal consumo della CPU. I fattori che hanno un ruolo maggiore nel determinare questo consumo sono: la modalità di lavoro della CPU, tensione di alimentazione, clock della CPU. La temperatura e altre periferiche digitali hanno un minimo effetto nel consumo di potenza digitale. La CPU ha 3 modalità di lavoro: normal, Idle e Stop. Un ruolo molto importante nel consumo di corrente è dato dalla tensione di alimentazione. Questo può essere osservato a tutte le frequenze ma un impatto maggiore si verifica alle alte frequenze. I sensori di temperatura, invece, non hanno un effetto significativo nel consumo della potenza. Ma ritorniamo alla CPU. Un effetto significativo si ha a seconda della modalità di frequenza con cui lavora. Le figure 4 e 5 mostrano l’effetto di questa frequenza sul consumo della potenza in normal mode; in prossimità dei 15 MHz la corrente subisce un salto, cambia pendenza e ricomincia ad aumentare.
Figura 4: consumo in normal mode in funzione della frequenza operativa della CPU (C8051F30x).
Figura 5: consumo in normal mode in funzione della
frequenza operativa della CPU (C8051F31x).
Quando la modalità della CPU è in Idle mode, invece, l’andamento del consumo della corrente ha la forma descritta nelle figure 6 e 7.
Figura 6: consumo in Idle mode in funzione della frequenza operativa della CPU (C8051F30x).
Figura 7: consumo in Idle mode in funzione dela frequenza operativa della CPU (C8051F30x).
Le altre periferiche e le porte I/O (Timer, UART, PCA…) hanno un ruolo nel consumo della potenza che risiede nel 1-2 %. Valori di consumo di corrente sono dell’ordine del centinaio del microampere.
Strategie di power saving
In molte applicazioni si ha la necessità di minimizzare i consumi di potenza. Secondo le nozioni elencate nel paragrafo precedente “lavorare” sulla tensione di alimentazione sembrerebbe essere una ottima strada. L’idea è sempre di progettare i dispositivi che usano la minima tensione operativa. La modalità funzionale che dovrebbe essere implementata è lo sleep mode; quest’ultima può essere usata utilizzando il dispositivo in Idle o normal mode. Lo scopo è di far lavorare il sistema in intervalli di tempo con diversi consumi di corrente, minimizzandoli lì dove è necessario. E’ necessario spegnere, durante lo sleep mode (in generale necessita di un oscillatore esterno), ogni tipo di periferica.
Esempio: ADC Sampling
Questo esempio compara la potenza di due differenti ADC (listato 1).
void main (void) {
// disable watchdog timer
PCA0MD &= ~0x40; // WDTE = 0 (clear watchdog timer enable)
PORT_Init(); // initialize the Crossbar and GPIO
SYSCLK_Init(); // start external oscillator
Timer2_Init(EXTCLK/8/SAMPLERATE); // configure Timer2 to overflow
at
// <SAMPLERATE> times per second
EA = 1; // enable global interrupts
while(1){
PCON |= 0x01; // put the device in Idle mode
}
}
| Listato 1 |
Uno usa un oscillatore a cristallo a 32 kHz, l’altro usa invece un oscillatore interno. Entrambi i sistemi lavorano in modalità Idle. Si osserva (figure 8 e 9) il differente consumo a differenti instanti di lavoro.
Figura 8: corrente vs Time (ADC sampling).
Figura 9: corrente vs Time (ADC Sampling).
Power management ACPI
L’ACPI è l’evoluzione di un precedente standard di PM, l’Advanced Power Management (APM). Il vecchio standard era basato principalmente sul BIOS, nel quale era presente del codice che veniva eseguito quando la CPU si trovava in uno stato di idle ed usava dei semplici timeouts per determinare le transizioni dei dispositivi in stati di low power. Le interfacce ed i concetti definiti dall’ACPI sono adatti potenzialmente per tutte le classi di computer: desktop, mobile, workstation e server. Tutte le ultime versioni di Windows (98, ME, 2000, XP) e di Linux supportano l’ACPI. Windows CE, la versione dell’OS (Sistema operativo) per computer palmari o dispositivi embedded in generale, ad oggi invece non supporta alcuno standard di PM: si limita a permettere agli Original Equipment Manufacturer (OEM) di effettuare una gestione ad hoc della potenza, attraverso Application Programming Interfaces (APIs) scritte per i vari componenti del sistema. Alcune versioni di Windows CE progettate per specifici campi applicativi, come ad esempio Windows CE for Automotive, adottano un modello di PM specifico, studiato tenendo conto delle particolarità e delle criticità proprie del contesto in cui verrà usato. Altri importanti standard che in qualche modo sono collegati con l’ACPI sono l’OnNow di Microsoft, lo SpeedStep di Intel e lo Smart Battery System. Lo standard ACPI è stato usato da molte aziende come base sulla quale costruire avanzate tecnologie per risolvere specifici problemi di PM (Power Management) e di gestione del sistema. L’ACPI è stato quindi progettato per raggiungere i seguenti obiettivi:
➤ fare in modo che i costruttori dei sistemi possano implementare funzioni di PM con gli appropriati tradeoffs di costo/funzionalità, permettendo un’ampia gamma di soluzioni, dalle più semplici alle più sofisticate. Una larga adesione a questo standard infatti rende conveniente anche agli sviluppatori delle applicazioni includendo il supporto al PM, con la conseguenza che si potranno creare nuovi usi per il PC e si potranno rendere più economici quelli già esistenti.
➤ Migliorare la robustezza e le funzionalità del PM. Infatti certe politiche di PM sarebbero troppo complicate per essere implementate nel BIOS ed inoltre, avendo a disposizione a livello di OS informazioni sugli utenti, le applicazioni e l’hardware insieme, si possono adottare nuove politiche, come ad esempio gli algoritmi di Dynamic Power Management. Un esempio concreto di ciò che può essere fatto con l’ACPI è il poter dividere nell’OS (Sistema operatico) le operazioni di I/O in “normali” e “lazy”. Queste ultime, ad esempio i salvataggi in background, possono essere messe da parte ed eseguite solo quando il dispositivo di I/O richiesto è acceso per qualche altra ragione. Una politica di questo tipo richiede di conoscere quando un dispositivo è acceso, quali richieste provenienti dalle applicazioni sono “lazy” e di assicurare che non vi siano operazioni in stato di starvation. La specifica ACPI prevede per l’hardware ACPI-compatibile due tipi di modelli: Fixed e Generic. Le features di un sistema implementate tramite Fixed hardware dovranno essere manipolate tramite registri residenti all’interno di uno spazio di indirizzamento specificato dall’ACPI e dovranno avere un comportamento prefissato. Al contrario al Generic hardware è permesso un più alto grado di flessibilità, ad esempio non vi sono limitazioni riguardo alla posizione dei registri da usare, registri a cui l’OS non accederà direttamente ma tramite chiamate a codice AML. Il vantaggio del modello Generic è quello di permettere agli OEMs di potersi differenziare dalla concorrenza tramite una differente implementazione dell’hardware (che potrà risiedere nello spazio di indirizzamento dell’I/O, della memoria, del PCI, di un controller embedded o del System Management Bus), di poter inserire nel loro hardware del valore aggiunto, che verrà utilizzato tramite i metodi di controllo proprietari scritti in AML. L’architettura ACPI opera una distinzione logica fra eventi di tipo “hardware” e di tipo “interrupt”. I primi, come ad esempio un evento di wake, causano incondizionatamente una qualche operazione, ad esempio una transizione di stato da G1 a G0. Gli eventi di tipo interrupt causano invece l’esecuzione di un interrupt handler. In entrambi i casi verrà generato un interrupt di tipo System Control Interrupt (SCI), che è visibile all’OS, al contrario di quanto accade per sistemi legacy che normalmente generano un System Management Interrupts (SMI), trasparente per l’OS, visto che in sistemi non-ACPI non deve gestire questo tipo di eventi. Per dare all’OS informazioni sul sistema vengono usate le System Description Tables, memorizzate in parte nello spazio di indirizzamento della memoria del sistema, in parte nell’area dati del BIOS. La struttura dati usata per implementarle è piuttosto complessa. In pratica è una struttura ad albero nella quale si può accedere alle informazioni ed ai metodi di controllo delle varie features del sistema passando attraverso diversi livelli di puntatori.
