Version vom 30. Juni 2014, 09:54 Uhr

...derzeit in Arbeit!

Motivation

Nicht erst seitdem der Begriffe "Green IT" aktuell wurde, kümmern sich Hard­- und Softwareentwickler um die Minimierung des Energieverbrauchs ihrer Produk­te. Viele Einsatzszenarien erfordern den effizienten Umgang mit der zur Verfügung stehenden Energie. Geräte wie eine elektronische Armbanduhr oder Fernbedienung sollen nicht jeden Tag an ein Ladegerät angeschlossen werden. Ein Mobiltelefon soll in der Hosen­ oder Handtasche Platz finden. Unbemannte Messstationen, Signalbo­jen etc. müssen monatelang oder, im Extremfall, über Jahre permanent und war­tungsfrei funktionieren. Nicht immer steht eine Steckdose zur Stromversorgung in unmittelbarer Reichweite zur Verfügung.

Mit modernen Batterien und Akkumulatoren (Akkus), vielfach in Verbindung mit sogenannten "Energy Harvesting"-Energiequellen (z.B. Photovoltaik), stehen Tech­nologien zur Verfügung, die die Konzeption und den Aufbau von platz­ und ge­wichtssparenden Geräten ermöglichen. Dabei reicht es nicht aus, "Ultra­ Low Power"-­Hardware nur einfach einzusetzen. Vielmehr muss auch die Firmware die zur Verfügung gestellten Möglichkeiten nutzen.

Der Autor betreibt eine Außenstation mit diversen Sensoren zur Wetterbeobach­tung, welche drahtlos an eine Hauptstation angebunden ist. Die Energieversorgung sollte dabei unabhängig von stationären Stromquellen gelöst werden. Um dies leis­ten zu können, setzte er sich mit den Begriffen "Ultra­ Low Power" und „energieeffi­ziente Programmierung“ intensiv auseinander.

"Ultra Low Power"-Hardware

Grundsätzlich werden die elektrischen Eigenschaften von Halbleiterschaltungen, und damit auch deren Stromverbrauch, durch die eingesetzten Technologien und den damit gegebenen physikalischen Gesetzmäßigkeiten bestimmt. Die Auswahl der geeigneten elektronischen Bauteile für ein konkretes Produkt ist eine verantwortungsvolle Aufgabe. Diese wird meist dem Hardwareentwickler überlassen, der diese Zusammenhänge kennen sollte. Einige dieser Eigenschaften sind aber auch für den Softwareentwickler interessant.

Viele moderne MCUs bieten die Möglichkeit die interne CPU und weitere interne Peripherie­-Komponenten (z.B. ADC, DMA, WDT) unabhängig voneinander, teil­weise oder vollständig abzuschalten. Dazu sind softwareseitig meist nur entspre­chende Steuerbits in den dafür vorgesehenen MCU­Registern (siehe Datenblätter) zu manipulieren. Durch vorher konfigurierte interne und externe Ereignisse kann dieser Ruhezustand jederzeit wieder verlassen werden. Ähnliches gilt auch für viele externe Komponenten und Baugruppen diverser Hersteller.

Dabei wird der Stromverbrauch teilweise drastisch gesenkt. Im Fall einer ATmega8L­-MCU reduziert sich der Bedarf beispielsweise von 3mA im Aktiv­-Modus auf unter 1μA bei der Abschaltung der CPU und aller weiteren inter­nen Komponenten. Weitere Stromeinsparungen können durch die Absenkung der CPU­-Taktfrequenz (z.B. ATmega8L mit 3V Versorgungsspannung: 8MHz, 6mA → 4MHz, 3mA) und die Minimierung der Zugriffe auf die verschiedenen Speicherbe­reiche (RAM, FLASH, EEPROM etc.) außerhalb der CPU erzielt werden.

Stromeffiziente Firmware entwickeln

Der überwiegende Teil, der durch eine MCU abzuarbeitenden Aufgaben lässt sich mit dem EVA-­Prinzip beschreiben. Es tritt ein Ereignis (Signal, Timer etc.) ein, auf welches der Prozessor entsprechend reagieren muss (Daten ermitteln, Berechnun­gen etc.). Die Verarbeitung endet mit einer geeigneten Ausgabe des Ergebnisses. Eine ausreichend schnelle MCU vorausgesetzt, wird man feststellen, dass zwischen diesen „EVA­-Zyklen“ Wartezeiten entstehen. Der Prozessor und weitere nicht benö­tigte Peripherie kann abgeschaltet und damit in einen der zur Verfügung stehenden stromsparenden Zustände versetzt werden. Dies bedeutet, kurze Verarbeitungszei­ten innerhalb der MCU verlängert deren Wartezeiten und reduziert damit den Strombedarf des Gesamtsystems.

Für ihre Entwicklungsumgebung „Code Composer Studio“ bietet die Firma Texas Instruments das Analysetool „ULPAdvisor“ an. Dieses Werkzeug ist auf die Ana­lyse von C-­Quelltexten für die hauseigene MCU­-Familie MSP430 zugeschnitten. Die zugrunde liegenden Kriterien sind aber ohne weiteres verallgemeinerbar und damit auch auf vergleichbare Hardwareprodukte anderer Hersteller anwendbar. Die fol­genden Empfehlungen beziehen sich deshalb auf die implementierten Analysekrite­rien des „ULPAdvisor“.

Nutze die Stromspar­-Modi der MCU, wann immer es geht

In einem der „Low Power“­-Betriebsmodi verbraucht eine MCU am wenigsten Strom. Deshalb sollte einer dieser Zustände immer Ausgangs­ und Endpunkt einer jeden Verarbeitung sein. Die Realisierung dieser wichtigen Empfehlung erfordert bereits in der Konzeptionsphase eine gewissenhafte Planung der Softwarestruktur:

Tabelle mit Bilder...

Damit unterscheidet sich die Steuerung der Software von den üblichen Konzepten. Statt ständig aktiv Zustände abzufragen, wartet man auf deren Auftreten und akti­viert erst dann die notwendigen Komponenten.

Hinweis: Als Schlafmodus ist jeweils derjenige zu wählen, der ein Wecken durch den oder die zu erwartenden Interrupt­Ereignisse zulässt14. Welche das sind, ist in den entsprechenden Datenblättern der jeweiligen MCU­Hersteller zu finden.

Verwende Interrupts statt „Flag­-Polling“

Viele der internen Peripherie­-Baugruppen einer MCU spiegeln ihren momentan Zustand mit Hilfe von Status­Bits (Flags) wider. Stößt man beispielsweise auf einem ATmega815 eine A/D­Wandlung an, wird das Ende der Messung mit einem Low­-Wert des ADSC­Bit des ADCSRA­-Register gemeldet. Das Löschen dieses Flags könnte man mit einer while-­Schleife im Programm abfragen. Dabei ist aber die CPU ständig aktiv und verbraucht viel Strom.

uint16_t  adc_read(uint8_t channel) 
{
   ADMUX |= (channel & 0x1F);
   ADCSRA |= (1<<ADSC);
   while (ADCSRA & (1<<ADSC)) {}
   return ADCW; 
}

uint16_t  adc_read(uint8_t channel) 
{
  ADMUX |= (channel & 0x1F);
  set_sleep_mode(SLEEP_MODE_ADC);
  ADCSRA |= (1<<ADSC)|(1<<ADIE);
  sleep_mode();
  return ADCW; 
}

ISR(ADC_vect)
{
}

Besser ist es, vor Anstoß der A/D-­Messung den ADC-­Interrupt zu aktivieren. Jetzt kann man die MCU in den „ADC Noise Reduction“­Schlafmodus 16 versetzen (Stromverbrauch ca. 0,3mA) oder währenddessen andere Aufgaben erledigen las­sen, um die Verarbeitungszeit insgesamt zu verkürzen. Ist die A/D­-Wandlung been­det, wird automatisch die ADC­-Interrupt-­Routine gestartet. Es können nun die er­mittelten ADC­-Werte verarbeitet werden. Ähnliches ist auch mit vielen anderen Komponenten diverser MCU möglich. Für Einzelheiten wird auf die jeweiligen Da­tenblätter verwiesen.

Verwende Timer statt Pausenschleifen

Viele Softwareentwickler realisieren zeitlich definierte Programmpausen mit while­-, until­- oder for­-Schleifen. Dabei muss die CPU der MCU aber aktiv sein und ständig die entsprechenden Schleifenbefehle ausführen. Zielführender ist es, einen der internen MCU­-Timer so zu konfigurieren, dass nach der gewünschten Pausendauer ein Interrupt ausgeführt wird. Während der Pause schaltet man in einen der möglichen Schlafmodi.

void long_delay(uint16_t ms) 
{
    for(; ms>0; ms--) _delay_ms(1);
}

int main(void) 
{
    DDRC |= (1<<PC1);
    while(1) 
    {
       PORTC ^= (1<<PC1);
       long_delay_ms(500);
    }
}

int main(void) 
{
    DDRC |= (1<<PC1);
    TCCR1B |= (1 << WGM12);
    TIMSK |= (1 << OCIE1A);
    OCR1A   = 7812;
    sei();
    while(1) 
    {
        // was anderes machen...
        // … oder Sleep-Mode...
    }
}

ISR(TIMER1_COMPA_vect) 
{
    PORTC ^= (1<<PC1);
}

Hinweis: Bei sehr kurzen Pausen muss man abwägen, ob sich das Umschalten lohnt, da sowohl hierfür als auch das Wecken ebenfalls Rechenzeit benötigt wird.

Vermeide Funktionsaufrufe innerhalb von Interrupt­-Routinen

Aus den bisherigen Punkten ist erkennbar, dass Interrupt-­Routinen eine zentrale Rolle bei der Steuerung stromeffizienter Firmware spielen. Durch sie sollen vor al­lem schnelle Reaktionszeiten auf interne und externe Zustände realisiert werden. Dazu müssen Interrupt­-Routinen möglichst kurz sein und dürfen sich nicht über­lappen. Im Idealfall setzt man dort nur Flags, auf deren Zustände später im Haupt­programm entsprechend reagiert wird.

int main(void) 
{
    // INT0 konfigurieren...
    while(1) 
    {
        // ...mache etwas
    }
}

ISR(INT0_vect) 
{
    printf(“Signal an INT0-Pin!\n“);
}

volatile uint8_t flag=0;

int main(void) 
{
    // INT0 kongigurieren
    while(1) {
        if (flag) 
        {
            printf(“Signal an INT0-Pin!\n“);  
            flag=0;
        }
        // ...mache etwas
    }
}

ISR(INT0_vect) 
{
    flag=1;
}

Hinweis: Diese Flags sollten als volatile Variablen deklariert sein.

Vermeide rechenintensive Operationen

Auf MCUs ohne FPU sollten Floating­-Point­-Berechnungen vermieden werden, da hierfür sehr langer Maschinencode vom Compiler generiert wird. Dessen Abarbei­tung verkürzt die Verweildauer in einem der stromsparenden Modi. Gleiches gilt auch für Ganzzahlmultiplikationen ohne Hardware­-Multiplizierer, Modulo­-/Divi­sions­-Operationen und viele weitere mathematische Funktionen. Jede Verwendung im Programmcode sollte deshalb kritisch überdacht und auf ein Minimum be­schränkt werden. Für einige MCU­-Plattformen existieren speziell angepasste Ma­thematik­-Bibliotheken. Weiterhin sind beispielsweise Festkomma­-Arithmetik und Lookup­-Tabellen ebenfalls geeignete Mittel zur Code-­Reduzierung.

Aus diesen Gründen sollte man außerdem die Verwendung von „Universal“­-Funk­tionen (z.B. printf(), sprintf() und String­-Funktionen) aus den C-­Standard­-Bibliothe­ken vermeiden. Besser ist hier eine Neu­-Implementierung mit genau dem Funkti­onsumfang, der in dem konkreten Anwendungsfall tatsächlich benötigt wird.

Verwende, wenn vorhanden, DMA

Steht in der MCU ein DMA­-Controller zur Verfügung, ist dieser zum Transfer großer Datenmengen zwischen zwei Speicherbereichen (z.B. anstatt der C­-Funktion memcpy()) oder interner Peripherie und Speicher (z.B. Senden/Empfangen über die serieller Schnittstelle) zu verwenden. Während des DMA­-Betriebs kann die CPU abgeschaltet und damit insgesamt Strom gespart werden.

#define LEN 100
char str1[LEN], str2[LEN];
uin8_t i;

...

for (i=LEN; i>0; i--) 
{
    str2[i-1]=str1[i-1];
}

...

memcpy(str2, str1, LEN);

...

#define LEN 100
char str1[LEN], str2[LEN];

...

DMA0DA = (unsigned int)str2;
DMA0SA = (unsigned int)str1;
DMA0SZ = LEN;
DMA0CTL |= DMAEN;
DMA0CTL |= DMAREQ;      
while (!(DMA0CTL & DMAIFG)) ;

...

(Beispiel MSP430Fxxxx: große Variable kopieren)

Hinweis: die while-Schleife sollte konsequenterweise natürlich durch den entsprechenden DMA-Interrupt ersetzt werden.

Benutze, wenn möglich, lokale statt globale Variablen

Viele Compiler versuchen bei der Übersetzung lokale Funktionsvariablen freien Re­gistern der CPU zuzuordnen. Der daraus resultierende Maschinencode ist kürzer und damit schneller. Es entfällt das Umkopieren vom Speicher in die CPU­-Register.

uint8_t i;

...

void do_it(void) 
{
    for (i=0; i<10; i++) 
    {
        Printf(“%d\n“, i);
    }
}

void do_it(void) 
{
    uint8_t i;
    for (i=0; i<10; i++) 
    {
        Printf(“%d\n“, i);
    }
}

Verwende „call by reference“ bei großen Variablen

Wenn Funktionsparameter über den Zeiger auf ihre (globale) Speicheradresse refe­renziert werden („call by reference“), generiert der Compiler keinen Maschinencode zum Umkopieren der entsprechenden Speicherinhalte in die CPU­-Register bzw. den Stack. Es reduziert sich die aktive Zeit der CPU. Diese Empfehlung steht im Widerspruch zur vorhergehenden Regel, weil hierfür global deklarierte Variablen Voraussetzung sind. Hier muss der Softwareentwickler entscheiden bzw. experimentieren, welche der beiden Empfehlungen zum ge­wünschten Ergebnis führt. Bei kleineren Variablengrößen ist meist „pass by value“ vorzuziehen.

void call_by_value(int z) 
{
    printf(“Antwort %d“, z);
}

int answer = 42;

...

pass_by_value(answer);

...

void call_by_reference(int *z) 
{
    printf(“Anwort %d“, *z);
}

int answer = 42;

...

pass_by_reference(&answer);

...

Verwende „const“ und „static“ bei Variablen­-Deklarationen

...

Verwende keine vorzeichenbehafteten Variablen, wenn nicht erforderlich

...

Verwende Bitmasken statt Bitfelder

...

Zähle in bedingten Schleifen rückwärts statt vorwärts

...

Wie lange reicht eine Batterie-Ladung?

...

Ein konkretes (und "lebendes") Beispiel...

Kontakt

Uwe