Framework im RTOS

Einfacheres Power Management für Mikrocontroller-basierte IoT-Knoten

Seite: 2/3

Firmen zum Thema

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.

(ID:44376479)