Ein weit verbreiteter Fehler, der zu einem unnötigen Leistungsverbrauch führen könnte, liegt in der Verwendung einer Abfrageschleife (Poll Loop), um auf die Zustandsänderung beispielsweise eines Peripheriegeräts zu warten. Code-Konstruktionen wie die folgenden Beispiele laufen ohne Unterbrechung, bis sich der Status-Wert in den erwarteten Zustand verändert.
while (USBD_GetState() < USBD_STATE_CONFIGURED);
while ((BASE_PMC->PMC_SR & MC_MCKRDY) != PMC_MCKRDY);
Eine weitere Code-Konstruktion in diesem Zusammenhang ist die Implementierung einer Softwareverzögerung als for- oder while-Schleife wie im folgenden Beispiel:
i = 10000; // SW Delay
do i--;
while (i != 0);
Dieses Stückchen Code hält die CPU sehr damit beschäftigt, einen Befehl auszuführen, der nichts anderes tut, als Zeit zu zählen. In beiden Situationen könnte der Code geändert werden, um die Leistungsaufnahme zu minimieren. Zeitverzögerungen lassen sich weitaus besser durch die Verwendung eines Hardware-Taktgebers implementieren.
Der Timer-Interrupt wird eingestellt, und danach geht die CPU in den Energiesparmodus, bis die Unterbrechungsanforderung sie aufweckt. Auch das zyklische Abfragen einer Änderung des Gerätezustands sollte, wenn irgend möglich, entweder mit Interrupts gelöst werden oder durch die Verwendung eines Timer-Interrupts, damit die CPU während der Abfragen in den Ruhezustand gehen kann.
DMA oder polled I/O?
DMA wurde bislang zur Steigerung der Übertragungsgeschwindigkeit verwendet. In einigen Architekturen kann die CPU während des DMA-Transfers in den Sleep-Modus versetzt werden. Power-Debugging erlaubt es dem Entwickler zu experimentieren und über den Debugger zu beobachten, welche Auswirkungen diese DMA-Techniken im Vergleich zu einem herkömmlichen, CPU-gesteuerten Abruf-Lösungsansatz (polled) haben.
Viele Embedded-Applikationen verbringen die meiste Zeit damit, zu warten, dass irgendetwas geschieht. Wenn der Prozessor im Leerlauf immer noch mit voller Geschwindigkeit läuft, wird Batterie-lebensdauer verbraucht, während nur sehr wenig geschieht. Deshalb ist in vielen Anwendungen der Mikroprozessor nur während eines sehr kurzen Bereichs der Gesamtzeit aktiv. Indem man ihn während der Leerlaufzeit in einen Energiesparmodus versetzt, lässt sich die Lebensdauer der Batterie um Größenordnungen verlängern.
Eine gute Methode besteht im Einsatz eines Task-orientierten Designs und eines Echtzeitbetriebssystems (RTOS). In einem Task-orientierten Design kann eine Task mit der niedrigsten Priorität definiert werden, die nur dann abläuft, wenn gerade keine andere Task ansteht. Diese Task im Leerlauf ist der perfekte Platz zur Implementierung eines Power-Managements. In der Praxis versetzt die Leerlauf-Task immer dann, wenn sie aktiviert wird, den Prozessor oder Teile von ihm in eine von möglicherweise einer ganzen Reihe von Energiespar-Betriebsarten. Eine Rolle spielt auch die Taktfrequenz der CPU.
Die Leistungsaufnahme einer CMOS-MCU folgt theoretisch folgender Formel:
wobei f die Taktfrequenz, U die Versorgungsspannung und k eine Konstante ist. Power-Debugging erlaubt es dem Entwickler, den Leistungsfaktor als einen Faktor der Taktfrequenz zu verifizieren. Ein System, das bei 50 MHz nur sehr wenig Zeit im Sleep-Modus verbringt, wird sich erwartungsgemäß 50% dieser Zeit im Energiesparbetrieb befinden, wenn es mit 100 MHz läuft. Die Leistungsdaten im Debugger ermöglichen dem Entwickler die Verifizierung des zu erwartenden Verhaltens, um dann, wenn eine nichtlineare Abhängigkeit zur Taktfrequenz besteht, die Betriebsfrequenz zu wählen, die zum geringsten Leistungsverbrauch führt.
Interrupt-Behandlung
Bild 4 zeigt ein Diagramm des Leistungsverbrauchs eines Event-gesteuerten Systems, bei dem sich das System bei t0 in einem inaktiven Betrieb befindet und der Strom I0 beträgt. Bei t1 wird das System aktiviert, woraufhin der Strom auf I1 ansteigt, was die Verlustleistung des Systems im aktiven Betrieb mit einem gleichzeitig verwendeten Peripheriegerät bedeutet. Bei t2 wird die Ausführung durch einen Interrupt unterbrochen, der mit höherer Priorität verarbeitet wird. Peripheriegeräte, die bereits aktiv waren, werden nicht abgeschaltet, auch wenn der Thread mit höherer Priorität sie nicht verwendet.
Stattdessen aktiviert der neue Thread mehr Peripheriegeräte; das führt zu einem Stromanstieg auf I2 zwischen t2 und t3, wo dann die Steuerung an den Thread mit geringerer Priorität zurückgeht. Der Funktionsumfang des Systems kann hervorragend sein, und es kann hinsichtlich Ausführungsgeschwindigkeit und Codegröße optimiert werden. Doch lassen sich im Leistungsbereich weitere Optimierungen vornehmen.
Der gelbe Bereich repräsentiert die Energie, die hätte eingespart werden können, wenn die zwischen t2 und t3 nicht verwendeten Peripheriegeräte abgeschaltet worden wären, oder wenn die Prioritäten der beiden Threads geändert werden könnten. Der Einsatz von Power-Debugging hätte es leicht gemacht, den außergewöhnlichen Anstieg im Leistungsverbrauch zu entdecken, der beim Auftreten des Interrupts entsteht und hätte ihn als abnormal identifiziert.
Um eine schwebende Eingabe zu vermeiden, ist es in der Entwicklung üblich, nicht verwendete I/O-Pins der MCU mit Masse zu verbinden. Wenn die Software versehentlich einen der auf Masse gezogenen I/O-Pins als einen logischen Ausgang »1« konfiguriert, kann auf diesem Pin ein Strom von 25 mA abfließen. Dieser hohe, unerwartete Strom lässt sich leicht erkennen, und zwar durch Ablesen des Stromwerts auf dem Power-Sampling-Display. Außerdem ist es möglich, durch Beobachtung während des Einschaltvorgangs den zugehörigen fehlerhaften Initialisierungscode zu finden.
Auch eine analoge Interferenz kann einen Einfluss haben. Die Mischung von analogen und digitalen Schaltungen auf derselben Leiterplatte bringt ihre eigenen Probleme mit sich. Layout und Routing der Leiterplatte werden wichtig, um die analogen Rauschpegel auf niedrigem Niveau zu halten und so ein genaues Sampling von Analogsignalen mit niedrigem Pegel zu gewährleisten. Die Erstellung eines guten Mixed-Signal-Designs setzt sorgfältige Erwägungen und Können bezüglich der Hardware voraus.
Über die Autoren:
Lotta Frimanson und Anders Lundgren sind im Product Marketing bei IAR Systems tätig.