Startseite > Embedded > Entwicklungstools > Energie-Spar-Ratgeber

Software auf Stromverbrauch optimieren

Energie-Spar-Ratgeber

14. Juni 2012, 11:03 Uhr | von Roger Neumair und Wolfgang Lutsch

Viele batteriebetriebene Systeme werben mit sehr langen Laufzeiten zum Teil von bis zu zwanzig Jahren. Die sorgfältige Auswahl der Hardware alleine reicht aber nicht aus. Sinnvolle Partitionierung der Software, die alle Funktionen der Hardware und speziell die des Mikrocontrollers nutzt, ist Grundvoraussetzung, um diese Batterielaufzeiten zu erreichen. Ein neues Tool soll dabei helfen.

▶ Diesen Artikel anhören

Für die aktive Stromaufnahme in modernen CMOS-Bausteinen ist hauptsächlich das Umladen von Kapazitäten verantwortlich, denn jeder einzelne Schaltvorgang lädt oder entlädt solche Kapazitäten. Es gibt mehrere Möglichkeiten, den Energiebedarf zu minimieren: Erstens lassen sich durch kleinere Prozessstrukturen die Kapazitäten der CMOS-Strukturen verkleinern, was aber grundsätzlich die Leckströme vergrößert, da die Isolationsschichten und dadurch auch die Sperrwiderstände kleiner werden.

Ein zweiter Ansatz ist das Minimieren der Schaltvorgänge. Effizientere Ausführung von Programmen (Code-Effizienz) ist daher ein wichtiger Bestandteil eines Ultra-Low-Power-Prozessors. Bei kürzeren Programmlaufzeiten kann dieser mehr Zeit im Low-Power-Modus verbringen, was ebenfalls die Strom-aufnahme reduziert. Doch auch hier sind Grenzen gesetzt, da man nicht für jede Aufgabe einen eigenen Befehl zur Verfügung stellen kann.

Als dritter Punkt ist die Reduzierung der Anzahl der beteiligten Gatter zu nennen. Eine intelligente Aufteilung von Aufgaben auf optimierte Einheiten wie Timer, DMA, etc. senkt die Anzahl der beteiligten Gatter dramatisch und hat ein hohes Energiesparpotenzial. Leider gibt es auch hier Limitierungen, da man nicht für jede Aufgabe eine eigene Ausführeinheit hat.

Eine vierte Möglichkeit, den Energiebedarf zu minimieren, sind kleinere Betriebsspannungen. Jedoch sind auch hier sehr schnell die Grenzen des Machbaren erreicht, da kleinere Spannungen auch kleinere Taktfrequenzen mit sich bringen. Der letzte und fünfte Punkt in der Liste ist das sogenannte »Power Gating«. Hier werden Teile des Mikrocontrollers komplett abgeschaltet, sodass sie auch nicht zu Leckströmen beitragen. Auch hier ist schnell die Grenze des Machbaren erreicht, da auch die Schalter selbst einen Leckstrom haben. Dieser sollte natürlich deutlich kleiner sein als der Teil, der abgeschaltet wird.

Im Rahmen dieses Artikels wollen wir uns auf drei dieser Punkte beschränken, da sich diese einfach durch Software beeinflussen lassen: das Minimieren der Schaltvorgänge, die Reduzierung der Anzahl der beteiligten Gatter und das Power-Gating. In der Entwicklungsumgebung »CodeComposerStudio« (CCS) ab Version 5.2 von Texas Instruments ist dazu mit dem »ULP Advisor« ein Tool enthalten. Dieses soll den Entwickler anleiten, effizienteren Code zu schreiben, indem es auf bestimmte Merkmale der Mikrocontroller der Serie »MSP430« hinweist, die der Entwickler in vollen Umfang nutzen kann.

ULP Advisor ist eine statische Code-Analyse-Software, die das MCU-Programm zur Kompilierzeit anhand einer Checkliste auf die Einhaltung von Stromsparregeln überprüft. Verstößt ein Programmteil gegen eine dieser Regeln, hebt das Tool durch Meldungen und Anmerkungen die entsprechenden Stellen im Code hervor. Der Entwickler erhält neben der Beschreibung der Regel Informationen, wie er den Code in diesem Falle optimaler gestalten kann. Im Folgenden wollen wir die praktische Arbeit mit ULP Advisor an einem einfachen Programmbeispiel näher erklären und veranschaulichen. Wir verwenden dazu einen »MSP430G2553« aus der »MSP430 ValueLine«-Familie.

Unser Applikationsbeispiel, bei dem wir das »LaunchPad«-Board nutzen, soll einen Taster und eine serielle Schnittstelle zur Kommunikation mit einem externen Empfänger (z.B. PC oder anderer Mikrocontroller) haben. Nach dem Anlegen der Betriebsspannung soll die Applikation erst einmal nichts machen. Durch einen Druck auf den Taster aktiviert sie sich.

Jobangebote+ passend zum Thema

MACNICA ATD EUROPE - Ihre berufliche Zukunft

MACNICA ATD Europe GmbH, Ingolstadt

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Im Sekundentakt misst sie die interne Temperatur des Mikrocon-trollers und rechnet den Tempera-turwert in Grad Celsius und Fahrenheit um. Weiterhin mittelt die Software die jeweils letzten 16 Messwerte. Nach dem Speichern der Ergebnisse werden die Daten mittels serieller Schnittstelle übertragen. Durch nochmaligen Druck auf den Taster endet die Messung und die Applikation kehrt in ihren Ruhezustand zurück, um auf den nächsten Tastendruck zu warten.

Die Taste ist durch entsprechende Software entprellt. Der vollständige, unoptimierte Code für dieses Beispiel lässt sich unter dem Link unten herunterladen. Bild 1 zeigt die vereinfachte Hauptschleife des beschriebenen Programmablaufs.

Unoptimierter Code

Low-Power-Modi nutzen

Nach dem Aufsetzen eines neuen Projekts, dem Kodieren des Programms entsprechend dem oben beschriebenen Ablauf und fehlerfreiem Kompilieren weist die Entwicklungsumgebung auf Ratschläge des ULP Advisor im »Problems«-Fenster hin. Die Meldungen werden im »Problems«-Fenster unter der Kategorie »Info« angezeigt. Der erste Eintrag lautet: »(ULP 1.1) Detected no uses of low power mode state changes using LPMx or _bis_SR_register() or __low_power_mode_x() in this project«.

Mittels Hyperlink gelangen wir auf eine in CCS integrierte Wiki-Seite mit detaillierten Informationen zur ULP-Advisor-Regel 1.1. Wir erfahren, was die Regel besagt, welchem Risiko man sich aussetzt, wenn die Regel nicht befolgt wird, warum der Ratschlag von ULP Advisor angezeigt wird und wie man Abhilfe schaffen kann. Offensichtlich haben wir in unserem Programmbeispiel keine sogenannten Low-Power-Modi verwendet, sondern lassen den Mikrocontroller permanent im Aktiv-Modus laufen.

Das Programm sollte normalerweise auf die Verwendung von Low-Power Modi optimiert sein. Diese schalten unbenutzte Komponenten des Mikrocontrollers ab und sparen dadurch enorm an Strom. Einsparungen um den Faktor 1000 zwischen Aktiv- und Low-Power-Modi sind dabei durchaus üblich. Oft kommt hierbei auch Power-Gating zum Einsatz.

Entsprechend dem standardmäßigen Programmflussmodell beim MSP430 sollte die Programmarchitektur generell Interrupt-gesteuert sein. Dadurch besteht maximales Potenzial, den Mikrocontroller in einen Ruhezustand zu bringen, in dem er kaum noch Strom aufnimmt. Erst auf ein Interrupt-Ereignis hin wacht der Controller auf, verrichtet seine Arbeit und legt sich anschließend wieder schlafen - bis zum nächsten Ereignis.

Maximiert man die Ruhezeiten beziehungsweise minimiert man die Aktivzeiten, erhöht sich die Energieeffizienz der Applikation und es verringert sich der mittlere Stromverbrauch. Zugegeben, in Sachen Interrupts zeigt unser Beispielcode wirklich enorme Schwachstellen auf. Weiter unten in der Liste an ULP-Advisor-Ratschlägen finden wir eine weitere Regel, gegen die wir verstoßen haben, und noch einmal wiederholt, was wir eben schon gelernt haben.

Die Meldung lautet »(ULP 3.1) Detected flag polling using ADC10IFG. Recommend using an interrupt combined with enter LPMx and ISR«. Durch einen Doppelklick auf die Meldung gelangen wir direkt in unseren Programmcode auf die Zeile, in der wir tatsächlich das ADC-Interrupt-Flag pollen, um festzustellen, ob ein fertiges Ergebnis vorliegt.

Interrupt-gesteuerte Programmarchitektur

Kandidaten für Interrupt-Ereignisse in unserem Beispiel sind das GPIO-Eingangssignal des Tasters, der Sekunden-Timer und der vom ULP Advisor identifizierte A/D-Wandler. Mit der folgenden Umstrukturierung des Codes wird der Mikrocontroller nun unmittelbar nach der Initialisierung und Konfiguration der erforderlichen Peripheriegeräte und deren Interrupts in einen Ruhezustand geschickt.

In diesem Ruhezustand, in dem kaum Strom fließt, wartet er, bis ihn ein Interrupt-Ereignis wieder aufweckt. Der Trick dabei ist es, die Interrupt-Service-Routinen (ISR) selbst so kurz wie möglich zu gestalten, um Latenzzeiten zu minimieren und optimale Reaktionszeiten zu erreichen. In unserem Beispiel wird in den ISRs lediglich ein entsprechendes Flag für das Hauptprogramm gesetzt und der Ruhezustand in der Art deaktiviert, dass nach der Rückkehr aus der ISR der Mikrocontroller aktiv bleibt.

Die Abarbeitung der zugehörigen Aufgabe erfolgt im Hauptprogramm. Über das Flag wird mitgeteilt, was aktuell zu erledigen ist. Nach getaner Arbeit schließt sich die Hauptschleife und der Mikrocontroller kehrt zurück in einen Ruhezustand.

Bild 2 zeigt den optimierten Programmablauf. In unserem Beispiel wird eine Software-Zeitschleife benutzt, um den Taster zu entprellen.

ULP Advisor bemängelt dies mit dem Hinweis auf Regel »(ULP 2.1) Leverage timer modules for delay loops«. Der Entprellmechanismus lässt sich durch Verwendung eines Timers und entsprechender Low-Power-Modi im MSP430 weitaus energiesparender durchführen. Die CPU befindet sich im Ruhezustand und nur der Timer wird getaktet. Dadurch werden nur Gatter geschaltet, die tatsächlich für die Aufgabe benötigt werden. Nach Ablauf des Timers weckt ein Interrupt die CPU aus dem Low-Power-Modus auf, und diese setzt ihre Aufgaben fort. Wir benutzen den Timer für zwei Aufgaben:

Entprellen des Tasters.
Im Falle des Sekunden-Timers für die A/D-Wandlung kann man mit dem MSP430 noch einen Schritt weitergehen und den Timer-Interrupt komplett einsparen. Ein Timer-Ausgangssignal ist direkt als Eingangs-Trigger für die A/D-Wandlung verschaltet, sodass der Ablauf des Timers ohne Software beziehungsweise CPU-Aktivität den ADC anstößt.

Die Port-Pins des MSP430 sind als Eingang voreingestellt. Da die Eingänge sehr hochohmig sind, also »floaten«, reagieren sie empfindlich auf Störsignale, beispielsweise auf die 50-Hz-Netzspannung oder das Starten von Leuchtstoffröhren. In diesem Fall würde der Eingang kontinuierlich schalten und dadurch unnötig Strom verbrauchen. Bei Bausteinen mit vielen Pins kann das schnell einige Milliampere ausmachen.

Als Abhilfe lassen sich nicht benutzte Anschlüsse als Ausgang konfigurieren oder als Eingang extern mit einem Widerstand terminieren. Abhängig von der Anzahl an vorhandenen Ports erhält man mehr oder weniger Meldungen vom ULP Advisor aufgrund des Verstoßes gegen Regel »(ULP 4.1) Terminate unused GPIOs«. In unserem Beispiel verwendet der Mikrocontroller drei Ports. Wir erhalten zwei Meldungen für Port 2 und 3, nachdem sich an Port 1 die Taster befinden und dieser teilweise initialisiert wurde. Die Funktion »Setup_Ports« übernimmt die Initialisierung der Ports.

Lokale Variable nutzen

Existieren global definierte Variablen, die zur Laufzeit nur im Kontext einer einzigen Funktion verwendet werden, meldet sich ULP Advisor mit Bezug auf Regel »(ULP 7.1) Use local instead of global variables where possible«. Der C-Compiler wird immer versuchen, lokale Variablen in CPU-Registern zu optimieren. Das spart Zugriffe auf den Speicher und dadurch Strom.

Die Anzahl der dem Compiler verfügbaren CPU-Register ist allerdings begrenzt. Ab einer gewissen Anzahl von lokalen Variablen wird der C-Compiler den Stack zu Hilfe nehmen. In diesem Fall besteht kein strombegrenzender Vorteil mehr gegenüber globalen Variablen. Das Gegenteil ist vielmehr der Fall, da das Anlegen beziehungsweise Aufräumen der lokalen Variablen auf dem Stack zusätzliche Taktzyklen erfordert.

Werden größere Datenmengen an eine Funktion übergeben, sollte man diese mittels Zeiger, also Referenz, übergeben. C-Compiler erzeugen eine lokale Kopie der Daten, wenn man diese mittels Wert übergibt. Dies benötigt unnötig viel Speicher, zieht viele Speicherzugriffe mit sich und erfordert eine Menge zusätzlicher Taktzyklen beim Erstellen der lokalen Datenkopie.

Die Funktion »ProcessCurrentSample« zeigt die Verwendung der Referenzübergabe. Weitere Meldungen bringt ULP Advisor zu den Celsius- und Fahrenheit- beziehungsweise Durchschnittswertberechnungen. Die dazugehörige Regel lautet: »(ULP 5.1) Avoid processing-intensive operations: modulo, divide«. Es wird empfohlen, die Berechnungsroutinen zum Programmstart ins RAM zu kopieren und von dort auszuführen.

Programmausführung aus RAM ist energieeffizienter als aus nichtflüchtigem Speicher wie Flash oder FRAM. Im Normalfall verfügt ein Mikrocontroller über mehr nichtflüchtigen als flüchtigen Speicher. Hier ist sorgfältig zu planen, wie viel Speicherplatz für solche Operationen reserviert werden kann. Wir verzichten darum in unserer Applikation (512 Byte RAM) auf die Auslagerung, zumal unsere Berechnungen auch nur Beispielcharakter haben, da mit 2er-Potenzen dividiert wird. Dies kann der C-Compiler mit einer einfachen Schiebeoperation auflösen und ist daher nicht mehr wirklich rechenintensiv.

Ersetzt man die Division im Quelltext durch eine Schiebeoperation, verschwindet auch die Meldung des ULP Advisor. Das Tool bemerkt ebenfalls die Multiplikationen in unserem Beispielcode und weist darauf hin, dass der Mikrocontroller unserer Wahl keine Hardware-Unterstützung (MPY-Modul) dafür anbietet. Erfordert die Applikation jedoch eine gewisse Häufigkeit von Multiplikationsoperationen, sollte man darüber nachdenken einen Baustein mit Hardware-Multiplier zu verwenden.

Beim Kopieren von größeren Datenmengen oder oft wiederholten Kopiervorgängen wird empfohlen, einen DMA-Controller zu verwenden (nicht anwendbar in unserem Beispiel, da kein DMA-Controller vorhanden). Der DMA-Controller ist für diese Art von Operation optimiert und benötigt, verglichen mit der CPU, weniger Taktzyklen und weniger Gatter, um dieselbe Menge an Daten von einem Speicherbereich zum anderen zu bewegen. Generell gilt hier wieder: Jeder Taktzyklus entspricht einer Energiemenge, die verbraucht ist und nie wieder zurückkehrt. Weniger Taktzyklen verbrauchen weniger Energie.

Unter unten stehendem Link können Sie den optimierten Code herunterladen.

Mit ULP optimierter Code

Über die Autoren:

Roger Neumair ist System Expert für Ultra-Low-Power-Microcontroller, Wolfgang Lutsch ist MSP430 Tools Engineer, beide bei Texas Instruments.

Rechtlicher Hinweis:

"This software has been placed into the Public Domain by Texas Instruments Incorporated and is example code only THIS SOFTWARE IS PROVIDED BY TEXAS INSTRUMENTS INCORPORATED"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL TEXAS INSTRUMENTS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."