Framework im RTOS Einfacheres Power Management für Mikrocontroller-basierte IoT-Knoten

Autor / Redakteur: Nick Latheby * / Sebastian Gerstl

Sensoren und Aktoren machen Power Management zur kritischen Komponente in IoT-Anwendungen. In Mikrocontroller verbaute Features erleichtern das Design – sofern auch die Software dem Entwickler beisteht.

Firmen zum Thema

Interaktionen verschiedener Softwarekomponenten: Bestandteile wie z.B. die Gerätetreiber sind stromverbrauchsbewusst und informieren den Power Manager, wenn er aggressivere Power-Modi nutzen kann. Der Power Policy Manager führt diese Informationen mit Daten zum nächsten geplanten Ereignis aus dem TI-RTOS Clock Module zusammen, um den richtigen Modus zu wählen.
Interaktionen verschiedener Softwarekomponenten: Bestandteile wie z.B. die Gerätetreiber sind stromverbrauchsbewusst und informieren den Power Manager, wenn er aggressivere Power-Modi nutzen kann. Der Power Policy Manager führt diese Informationen mit Daten zum nächsten geplanten Ereignis aus dem TI-RTOS Clock Module zusammen, um den richtigen Modus zu wählen.
(Bild: Texas Instruments)

Das Internet of Things (IoT) stößt die massenhafte Verwendung kostengünstiger Sensoren und Aktoren in zahlreichen verschiedenen Märkten an, deren Spektrum von Smart-Home-Anwendungen über die Energietechnik und das Transportwesen bis zu industriellen Applikationen reicht. In vielen dieser Anwendungen, von denen Bodenfeuchte-Sensoren für die Landwirtschaft nur ein Beispiel sind, ist es notwendig, dass die IoT-Knoten (Sensoren und Aktoren) monate- oder gar jahrelang mit Knopfzellen oder AA-Batterien auskommen. In diesen Fällen stellt das Erreichen der nötigen Energieeffizienz eine gravierende Herausforderung für die Entwickler dar.

In Desktop-Computern und Smartphones ist das Betriebssystem dafür verantwortlich, stromsparende Aktivitäten zu veranlassen, wie etwa das Dimmen des Displays oder das Abschalten der FPGA nach einer bestimmten inaktiven Zeitspanne. Die in diesen Systemen zum Einsatz kommenden Betriebssysteme wie etwa Windows, Linux oder Android sind für die kostengünstigen Mikrocontroller (MCUs) von IoT-Anwendungen nicht geeignet, da deren chipinterner Speicher hierfür schlicht zu klein ist. Gleichwohl wird die Ausstattung von MCU-basierten IoT-Knoten mit ähnlichen, einfach anwendbaren und effektiven Power-Management-Funktionen immer wichtiger, und dies gleich aus mehreren Gründen:

  • Die für die neuesten MCU-Generationen verwendeten Halbleiterprozesse verursachen verglichen mit älteren CMOS-Bausteinen deutlich höhere Leckströme. Um die Energieeffizienz-Anforderungen von IoT-Knoten zu erfüllen, mussten die Halbleiteranbieter ausgefeiltere Power-Management-Features entwickeln, die jedoch eine längere Einarbeitungszeit für die Entwickler mit sich bringen.
  • Das Erreichen optimaler Energieeffizienz erfordert jetzt die Nutzung komplexerer Power-Down-Modi, die größere Teile der MCU (CPU, Peripherie und Speicher) dauerhaft oder zeitweise abschalten.
  • Vielen Entwicklern von IoT-Applikationen fehlt es an Erfahrung im Entwickeln von Embedded-Software. Damit sie erfolgreich arbeiten können, werden diese Entwickler ein Power-Management-Paradigma benötigen, das sich deutlich stärker an die von Windows oder Linux gebotenen Funktionen anlehnt, wo es reicht, einen bestimmten Energiespar-Modus auszuwählen oder dem Betriebssystem das aktive Management des Stromverbrauchs zu überlassen.

Der folgende Beitrag befasst sich mit einem Power-Management-Framework, das in einem Embedded-Betriebssystem eingerichtet wurde. Dieses nachfolgend als ‚OS Power Manager‘ (OS steht für ‚Operating System‘) bezeichnete Framework automatisiert nahezu alle Power-Management-Entscheidungen und befähigt Entwickler zum Bau energieeffizienter IoT-Knoten, ohne dass sie irgendwelche Aspekte der Power-Management-Features auf der Halbleiter-Ebene erlernen müssen. Da die Implementierung eines OS Power Managers aber von den Power-Management-Fähigkeiten des jeweiligen Halbleiterbausteins abhängt, beleuchtet dieser Artikel zunächst einige hardwaremäßige Power-Management-Features von Low-Power-MCUs.

Hardwareseitige Power-Management-Features

Ein fundiertes Verständnis der grundlegenden Hardware-Features, die Hilfestellung beim effektiven Power-Management leisten, ist sehr hilfreich, da der OS Power Manager auf diese Hardware-Ressourcen zurückgreifen muss:

  • Clock Gating: Mit dem Clock Gating lässt sich der Takt für eine bestimmte Peripheriefunktion abschalten, um deren Stromverbrauch zu reduzieren.
  • Power Domains: Obwohl das Abschalten des Takts für eine Peripheriefunktion einen Großteil von deren Stromverbrauch eliminiert, bleibt durch Leckströme ein gewisser Verbrauch bestehen. Zur Vermeidung solcher Leckströme können in einer MCU so genannte Power Domains eingerichtet werden, mit denen sich die Stromversorgung für eine bestimmte Schaltung komplett abschalten lässt.
  • Wake-up Generator: In Ultra-Low-Power-Betriebsarten werden neben der CPU auch praktisch alle Peripheriefunktionen abgeschaltet. Interrupts können die CPU unter diesen Umständen normalerweise nicht erreichen. Deshalb wird zusätzliche ‚Always-on‘-Logik benötigt, damit ein Teil der Peripherie die CPU aufwecken kann.
  • CPU-unabhängiger hochauflösender Timer: Damit der Applikation während langer Power-Down-Phasen eine präzise Zeitbasis zur Verfügung steht, muss die ‚Always-on‘-Logik über einen Timer mit einer Auflösung von 1 ms oder weniger sowie mit einer ausreichend großen Breite enthalten, damit es auch während langer Deep-Sleep-Perioden zu keinem Überlauf kommt.
  • Kurze Aufweckzeiten und Laufzeit-Performance: Die Fähigkeit der MCU, schnell aufzuwachen, Aufgaben zügig zu erledigen und anschließend sofort wieder in den Low-Power-Modus zurückzukehren, ist entscheidend dafür, dass möglichst viel Zeit in stromsparenden Betriebszuständen verbracht werden kann. Hier sind hochfrequente, sich schnell stabilisierende Taktquellen sowie die richtige Taktfrequenz und Performance der CPU gefragt.

Automatisiertes Power Management in der MCU

Tabellarischer Überblick: Stromverbrauch in den verschiedenen Power-Modi. Aufweckzeiten und Stromaufnahmen beziehen sich auf die Ultra-Low-Power-MCU SimpleLink CC2650 von TI, die einen mit 48 MHz getakteten ARM Cortex-M3-Core und eine BLE-Funktion enthält. Bei den Messungen in den Betriebsarten WaitForInterrupt und IDLE waren keine Peripherie-Bereiche aktiv.
Tabellarischer Überblick: Stromverbrauch in den verschiedenen Power-Modi. Aufweckzeiten und Stromaufnahmen beziehen sich auf die Ultra-Low-Power-MCU SimpleLink CC2650 von TI, die einen mit 48 MHz getakteten ARM Cortex-M3-Core und eine BLE-Funktion enthält. Bei den Messungen in den Betriebsarten WaitForInterrupt und IDLE waren keine Peripherie-Bereiche aktiv.
(Bild: VBM nach Vorlage von TI)

Erfahrungen mit früheren Generationen des OS Power Managers, für die es einen reichhaltigen Bestand an APIs zur Nutzung hardwaremäßig implementierten Power-Management-Features gab, haben gezeigt, dass die vielen gebotenen Fähigkeiten von den Entwicklern häufig gar nicht genutzt wurden, sodass ihre Applikationen nicht so energieeffizient waren, wie sie es eigentlich hätten sein können. Zur Lösung dieses Problems wurde ein automatisches Konzept für das Power Management entwickelt, das die MCU ohne Zutun des Anwenders effektiv in Ultra-Low-Power-Zustände versetzt.

Erreicht wurde diese Automatisierung mithilfe eines integrierten Power-Management-Konzepts, das sich auf Verbesserungen an den Stacks, den Gerätetreibern und dem Betriebssystem-Kernel stützen, durch die sie ‚verbrauchsbewusster‘ werden. Es wurde ein Power Manager mit allen maschinennahen Routinen entwickelt, die notwendig sind, um den Mikrocontroller in die Ultra-Low-Power-Betriebsarten zu versetzen oder aus ihnen herauszuholen.

Darüber hinaus speichert der Power Manager wichtige Daten für die Power-Management-Entscheidungen – zum Beispiel die Latenz eines Low-Power-Modus oder die Beteiligung eines bestimmten Peripherie-Subsystems an einer kritischen Datenübertragungs-Operation. Der OS-Kernel weiß prinzipbedingt, welche Ereignisse für die Zukunft geplant sind. Eigens hinzugefügte APIs ermöglichen den Applikationen (einschließlich der Power-Management-Software) die Abfrage, wann das nächste geplante Ereignis ansteht. Neu implementiert wurde auch das Zeitmanagement des Betriebssystems, damit Timer-Interrupts nicht bei jedem Takt-Tick, sondern nur dann ausgelöst werden, wenn tatsächlich Aktivitäten auszuführen sind.

Ein als Power Policy Manager bezeichnetes Programm ist von Grund auf so konfiguriert, dass es automatisch entscheidet, wann eine Änderung der Power-Betriebsart vorgenommen werden kann, und anschließend den Betriebsartwechsel und die Aufweckbedingungen koordiniert. Entwickler können den Power Policy Manager jedoch anders konfigurieren, um sein Verhalten zu modifizieren.

Sobald eine Multitasking-basierte Applikation nichts zu tun hat, fällt sie in eine Leerlaufschleife. In diesem Fall ruft das OS den Power Policy Manager auf, der die Aufgabe hat zu ermitteln, in welchen Low-Power-Modus gewechselt werden kann. Es ist immer sicher, einen ARM-Core in einen WFI-Status (WaitForInterrupt) zu versetzen, in dem die Registerinhalte erhalten bleiben und die Applikationsverarbeitung mit minimaler Latenz wiederaufgenommen werden kann. Da die MCU-spezifischen Power-Modi jedoch exponentiell größere Energieeinsparungen bieten, muss der Power Policy Manager ermitteln, ob diese Betriebsarten genutzt werden können. Hierzu berücksichtigt er die existierenden Constraints, die Latenz und die Zeit bis zum nächsten geplanten Ereignis.

Applikationen fallen häufig in die Leerlaufschleife, wenn sie auf die Beendigung von peripherieseitigen I/O-Operationen warten. Sofern der Abschluss der betreffenden I/O-Operation entscheidend für den ordnungsgemäßen Betrieb des Systems ist, muss die Applikation dies dem OS Power Manager signalisieren. Dies geschieht mit einem als ‚Constraint‘ (Restriktion) bezeichneten Konzept.

Das Übertragen von Daten über eine BLE-Funkverbindung (Bluetooth Low Energy) ist ein Beispiel für einen Fall, in dem das Setzen eines Constraints angezeigt ist. Eine Applikation, die auf eine Bestätigung oder Daten von einem Drahtlos-Netzwerk wartet, bleibt in der Regel an einem Semaphor stehen, wobei potenziell die Power Policy aufgerufen wird. In dieser Situation wäre es offensichtlich unangebracht, die MCU in einen Deep-Sleep-Modus zu versetzen, in dem der Funk-Teil und die CPU deaktiviert werden, denn hierdurch würden die ankommenden BLE-Pakete verlorengehen.

Um dies zu vermeiden, wird der BLE-Stack oder der Funk-Treiber so ergänzt, dass kritische Operationen durch Constraints eingegrenzt werden. Nach Ende der kritischen Operationen werden die Constraints wieder aufgehoben. Üblicherweise sind die Constraints nur auf diejenigen Stromspar-Betriebsarten beschränkt, die einen erfolgreichen Betrieb vereiteln würden. Zum Beispiel kann der Wechsel in einen IDLE-Status (siehe die Übersicht über verschiedene MCU-spezifische Stromspar-Modi in Tabelle 1) für eine bestimmte Operation unkritisch sein, während dies für den Übergang in einen STANDBY-Zustand nicht gilt. Der Power Manager geht davon aus, dass Power-Down-Zustände ungeachtet laufender Peripherie-Aktivitäten unkritisch sind, solange der Treiber oder der Stack für eine bestimmte Peripheriefunktion kein Constraint gesetzt hat.

Wenn keine Constraints das System vom Wechsel in eine Stromspar-Betriebsart abhalten, muss der Power Policy Manager durch Gewichtung von Informationen aus verschiedenen Quellen entscheiden, ob genug Zeit bleibt, um in einen bestimmten Power-Modus zu wechseln (und ihn auch wieder zu verlassen). Jeder Stromspar-Modus ist nämlich durch eine gewisse Latenz gekennzeichnet, die aus der Zeit zum Ausführen der Power-Down-Operation und der Zeit besteht, die die MCU benötigt, um wieder vollständig reaktiviert und für den normalen Systembetrieb bereitgemacht zu werden.

Der Power Policy Manager vergleicht die Latenzen der verschiedenen Power-Modi mit der Zeit, die bis zum nächsten geplanten Ereignis (z. B. einer periodischen Funktion oder einem Timeout) bleibt. Der Power Policy Manager wählt daraufhin die Betriebsart mit dem geringsten Stromverbrauch und programmiert die Wake-up-Konfiguration so, dass die vollständige Reaktivierung des Prozessors rechtzeitig vor dem nächsten geplanten Ereignis erfolgt. Wenn die MCU in einen neuen Power-Modus wechselt, rufen an die Treiber gesandte Sleep-Benachrichtigungen Callback-Funktionen auf, um die Aktivität der Peripheriefunktionen abzuschalten. Die Default-Implementierungen dieser Callbacks sind minimalistisch gehalten und schalten die jeweilige Peripheriefunktion so schnell wie möglich ab.

Die Power-Modi des Wireless-Mikrocontrollers

Der OS Power Manager stellt erprobte Implementierungen eines vorgegebenen Satzes an Power-Modi für die Wireless-MCU zur Verfügung. Diese sind auf zuverlässige Übergänge in den betreffenden Modus und aus ihm heraus geprüft. Die in Tabelle 1 aufgeführten Power-Modi für eine Ultra-Low-Power Wireless-MCU sind als Beispiele für die Betriebsarten eines Mikrocontrollers gedacht, der hinsichtlich seines Stromverbrauchs für einen IoT-Knoten optimiert ist. Wie den Angaben in der Tabelle zu entnehmen ist, sind die MCU-spezifischen Power-Modi von kritischer Bedeutung für einen extrem geringen Stromverbrauch.

Der WaitForInterrupt-Modus, der einfach das Abschalten des Takts für bestimmte Teile der Haupt-CPU bewirkt, kann in praktisch jeder Situation eingesetzt werden, da er praktisch keine Latenz besitzt. Der Power Policy Managers soll hauptsächlich prüfen, ob der IDLE- oder STANDBY-Modus in Frage kommen, die den Stromverbrauch beide deutlich senken (insbesondere letzterer).

Im STANDBY-Modus wird die Stromversorgung aller Peripherie-Bereiche abgeschaltet – mit Ausnahme der für den Aufweckvorgang erforderlichen Always-On-Logik. Der Echtzeit-Takt im Always-On-Bereich stellt das präzise Timing während dieses Zustands sicher. Der SRAM-Speicher des Bausteins wird in den Speichererhalt-Modus versetzt, und das Tastverhältnis der Stromversorgung wird so reduziert, dass einerseits der Stromverbrauch abgesenkt wird und andererseits wichtige Zustände erhalten bleiben, damit keine Register- oder Speicherinhalte verlorengehen.

Der SHUTDOWN-Modus ist hauptsächlich für Anwendungen gedacht, die über Stunden, Tage oder noch länger inaktiv sein müssen. Der Power Policy Manager nutzt diese Betriebsart in seiner Grundkonfiguration nicht. Die Applikation kann sie jedoch bei Bedarf direkt aufrufen, und der Entwickler kann den Power Policy Manager so modifizieren, dass er ebenfalls von diesem Modus Gebrauch macht.

Power Management als kritische Technologie im IoT

Der vorliegende Beitrag beschrieb ein integriertes Konzept für Power-Management-Software, die einen Power Policy Manager einschließt. Letzterem obliegt die Entscheidung, wann in eine Betriebsart mit reduzierter Leistungsaufnahme gewechselt wird, sowie die Wahl des optimalen Low-Power-Zustands, sodass sich weder der Entwickler noch die Applikation um diese Details kümmern müssen.

* Nick Latheby ist IoT Ecosystem und TI-RTOS Manager bei Texas Instruments.

(ID:44376479)