Das Internet der Dinge (IoT) wird Milliarden intelligenter Knoten umfassen und jeden Aspekt unseres modernen Lebens beeinflussen. Dazu zählen Wearables wie Smartwatches, Knoten in vernetzten Haushalten (Smart Home), verschiedene Industrieeinrichtungen oder ganze Smart Cities. Hier überwachen IoT-Knoten ihre Umgebung und reagieren sofort auf relevante Ereignisse. Dazu müssen sie über Jahre mit einer kleinen Batterie auskommen oder sich über Energy Harvesting aus der Umgebung versorgen. Ein äußerst stromsparender Betrieb ist daher entscheidend und erfordert eine sorgfältige Auswahl der Bauelemente.
Die Hauptkomponenten eines IoT-Knoten neben seinem Mikrocontroller sind Sensoren, die Benutzereingaben oder Umgebungsinformationen sammeln, außerdem Schnittstellen wie USB oder Bluetooth Smart für die Kommunikation mit der Cloud oder einem Smartphone sowie eventuell Aktoren, mit denen der Knoten seine Umgebung verändert oder Benutzerinformationen über ein Display oder einen Lautsprecher ausgibt.
So tun als ob
IoT-Geräte brauchen ein gewisses Maß an Determinismus: ein Berührungsbildschirm muss sofort auf eine Benutzereingabe reagieren, eine Funkschnittstelle muss die Timing-Anforderungen des Funkprotokolls erfüllen und ein Pulsmesser darf keinen Herzschlag verpassen. Diese Geräte müssen als immer betriebsbereit erscheinen (always on), sind in der Praxis aber fast immer ausgeschaltet (almost always off): Dieser Trick spart sehr viel Energie.
Bei Sensoren hängt der Gesamtstromverbrauch nicht nur vom Spitzenstromverbrauch im Betriebsmodus ab, sondern auch vom Zeitanteil im aktiven und abgeschalteten Modus. Wie lange er eingeschaltet sein muss, hängt von der Art des Sensors ab. Ein Pulsmesser kann eine Abtastfrequenz von 50 Hz benötigen, während für Temperatursensoren in Smart-Home-Thermostaten eine Abfrage pro Sekunde ausreicht.
Öfter mal abschalten
Die Einschaltdauer kann auch vom aktuellen Zustand der Anwendung abhängen. Eine Smartwatch kann zum Beispiel alle Sensoren abschalten wenn sie inaktiv ist und vielleicht nur jede Sekunde einen Beschleunigungsmesser abfragen, um eine Aktivität zu erkennen. Bewegt sich der Träger der Uhr, kann diese die Abtastrate erhöhen, um die Aktivität genauer zu verfolgen.
Bild 1: Die MCU steuert alle anderen Komponenten innerhalb der Anwendung und schaltet sie so oft und lange wie möglich aus. Doch auch die MCU selbst muss Energie sparen.Silicon Labs
In allen Fällen muss sichergestellt sein, dass Bauteile nur dann eingeschaltet sind, wenn die Anwendung sie benötigt. Dies bringt erhebliche Energieeinsparungen mit sich. Ein Mikrocontroller wird jedoch selten komplett abgeschaltet. Er steuert alle anderen Komponenten innerhalb der Anwendung, schaltet Sensoren ab und versetzt das Funkmodul in den Stromsparmodus – wann immer es möglich ist (Bild 1). Die MCU verwaltet auch zahlreiche andere Funktionen. Sie muss die volle Kontrolle über die Anwendung behalten und dabei so wenig Energie wie möglich verbrauchen.
Um ihre Stromaufnahme zu minimieren, muss die MCU so oft wie möglich in den Sleep-Modus übergehen und trotzdem alle erforderlichen Aufgaben ausführen. Der Unterschied zwischen Aktivmodus und Deep Sleep reicht vom ein- bis zweistelligen Milliamperebereich im Aktivmodus bis unterhalb 1 µA im Sleep-Modus.
Bild 2: Wenn eine MCU keine Sleep-Modi kennt oder die Anwendung davon keinen Gebrauch macht, dann ist ein kleiner Akku sehr schnell geleert.Silicon Labs
Beispielrechnung
Als Beispiel dient eine Smartwatch, in der eine kleine Batterie mit etwa 200 mAh Kapazität steckt. Verbraucht alleine die MCU durchschnittlich etwa 10 mA (Bild 2), würde die Batterie nur für 20 Stunden Betrieb ausreichen. Neueste MCUs bieten nützliche Sleep-Modi mit weniger als 1 µA Stromaufnahme. Je länger die MCU inaktiv ist und in einem dieser Sleep-Modi verharrt, desto weiter sinkt der durchschnittliche Stromverbrauch. In der Praxis sind Durchschnittswerte von 100 µA realistisch; damit reicht die Batteriekapazität für acht Tage (Bild 3). Zwar tragen auch die anderen Komponenten zum Batterieverbrauch bei, die MCU dominiert aber häufig.
Bild 3: Verharrt die MCU hingegen die meiste Zeit im Schlafmodus und wird sie nur bei Bedarf aktiv, dann verlängert sich ihre Laufzeit erheblich.Silicon Labs
Um die Akkulaufzeit zu verlängern, sollte eine Anwendung so oft wie möglich die Sleep-Modi nutzen. Sobald die MCU eine Funktion ausführen muss, die im jeweiligen Schalfmodus nicht zur Verfügung steht, muss sie aktiv werden. Diese Aktivierung kostet Energie und Zeit. Damit das nicht den Nutzen der Sleep-Modi zunichtemacht, sollten auch die energiesparenden Modi noch wichtige Funktionen bereitstellen und die MCU daher länger schlafen lassen (Bild 4). Muss die MCU dennoch aufwachen, dann sollte die Aktivierung möglichst rasch ablaufen.
Werte im Datenblatt
Bild 4: Verbleibt die MCU die meiste Zeit im Sleep-Modus (Verbrauch: 1 µA), dann lässt sich die Batterielebensdauer der Beispielanwendung auf 20 Jahre verlängern.Silicon Labs
Egal wie stromsparend ein Ultra-Low-Power-Modus theoretisch ist, mit diesem Wert allein lässt sich die Energieeffizienz nicht beurteilen. Datenblätter führen meist Bestwerte auf Basis von Konfigurationen auf, die eher nicht realen Bedingungen entsprechen. Ein hervorragender Sleep-Strom ist jedoch nutzlos, wenn die Anwendung im Aktivmodus verbleiben muss, um ihre Aufgaben zu erfüllen. Leider gibt es keine einfache Möglichkeit, die optimale Stromsparlösung für eine Anwendung zu bestimmen. Der einfache Vergleich von MCU-Datenblättern reicht nicht aus, da sie die Funktionalität und Leistungsfähigkeit der verschiedenen Betriebsmodi unterschiedlich interpretieren.
Das EEMBC (Embedded Microprocessor Benchmark Consortium) hat die Notwendigkeit objektiver, unabhängiger Benchmarks für energieeffiziente MCUs erkannt und vor kurzem die Phase 1 seines ULPBench (Ultra-Low Power Benchmark) ins Leben gerufen. Dieser Benchmark untersucht vor allem den Stromverbrauch des CPU-Cores im Aktiv-Modus und der RTC (Real-Time Clock) im Sleep-Modus. Phase 1 berücksichtigt aber nicht die Zeit, die eine Aktivierung benötigt und auch keine fortschrittlichen Deep-Sleep-Funktionen wie Sensormessungen und Kommunikation. Für viele Anwendungen kann dieser Benchmark daher keine genaue Aussage über die MCU-Funktionen bieten. Um einige dieser Aspekte zu berücksichtigen konzentriert sich die Phase 2 des ULPBench auf die Nutzung gängiger Peripherie, um reale Anwendungen besser zu simulieren.
Eine Frage des Designs
Die meisten der heutigen IoT-MCUs basieren auf energieeffizienten ARM Cortex-M-Cores. Der reale Stromverbrauch in den Aktiv- oder Deep-Sleep-Modi unterscheidet sich aber je nach MCU-Anbieter. Die Stromaufnahme im Aktivmodus wird vor allem durch die Wahl der Prozesstechnologie und den Befehls-Cache beeinflusst. Welche Peripherie-Funktionen im Standby-Zustand zur Verfügung stehen und wie hoch der Sleep-Strom ist, hängt mehr vom Design und der Architektur ab.
Eckdaten
Wie energieeffizient ein IoT-Knoten in der Praxis arbeitet, lässt sich kaum anhand der Werte im Datenblatt abschätzen. Wie viel Strom ein Mikrocontroller im Aktiv- und im Sleep-Modus benötigt ist nicht aussagekräftig. Entscheidend ist, wie lange die MCU im Schlafmodus bleiben kann, welche Aufgabe sie dabei trotzdem noch erledigen kann, wie viel Energie sie zum Aufwachen benötigt und wie clever sie die restlichen Bauelemente und Peripherien an- und abschaltet. Selbst Benchmark-Werte geben diese Zusammenhänge nur unzureichend wieder.
Die EEMBC Working Group für die Phase 2 des ULPBench berücksichtigt, dass die Peripherie den Stromsparbetrieb erheblich beeinflusst. Die meisten Anwendungen brauchen eine bestimmte Funktionalität dauerhaft, zum Beispiel überwachen sie die Drehbewegung in einem Durchflussmesser oder warten auf eine Berührung des Touch-Panels. Um die Stromaufnahme zu minimieren, muss eine MCU nicht nur den durchschnittlichen Strom von Sensoren und anderen Komponenten senken, indem sie deren Einschaltdauer anpasst, sondern auch möglichst lange im Deep-Sleep-Modus verbleiben. Dabei sind die CPU und andere Peripherie-Einheiten abgeschaltet.
Halbschlaf
Die Sleep-Modi deaktivieren viele Funktionen des Bausteins, die auf CPU, Speicher, Peripherie zugreifen. Das einfache Abschalten der CPU durch Takt-Gating kann die Stromaufnahme erheblich verringern und dennoch eine sehr schnelle Aktivierung ermöglichen. Dies senkt die Stromaufnahme von mehreren Milliampere auf weit unter 1 mA – abhängig von der MCU und deren Taktfrequenz. Alle anderen Funktionen stehen weiter zur Verfügung, solange die Peripherie autonom bleibt. Eine DMA- oder ähnliche MCU-Funktion kann die Peripherie dabei mit Daten versorgen.
Im nächsten Schritt kann man auch die Peripherie abschalten, was die Stromaufnahme auf wenige Mikroampere oder einige 100 nA verringert. Im Extremfall kann der Baustein alle seine MCU-Funktionen abschalten, wobei nur der Leckstrom der Leistungsschalter und der wenigen Bauelemente übrigbleibt, die sich nicht abschalten lassen. In der Praxis ist dies jedoch kaum von Nutzen, da die Anwendung dann ihre Funktionalität verliert. Viel wichtiger sind Deep-Sleep-Modi, die nützliche Funktionen aufrechterhalten.
Einige MCU-Funktionen wie die Brown-out-Erkennung (BOD) sind nicht direkt mit der Anwendungsausführung verknüpft, sollten aber immer aktiv sein – selbst im Deep-Sleep-Modus. Die BOD garantiert eine zuverlässige Funktion oder ein sicheres Abschalten, wenn die Stromzufuhr unterbrochen ist oder unter die Mindestspannung abfällt. Ohne BOD kann die MCU in einem undefinierten Zustand weiterarbeiten und falsche Ergebnisse liefern.
Stromspartechniken
Es gibt verschiedene Techniken, um die aktive Leistungsaufnahme und die Effizienz zu verbessern, zum Beispiel senkt ein Befehls-Cache die Menge der CPU-Zugriffe auf den Flash-Speicher. Ein integrierter DC/DC-Wandler kann einen effizienten Betrieb an höheren Spannungen wie denen einer Lithium-Polymer-Batterie ermöglichen. Sehr hohen Einfluss hat auch die Prozesstechnologie: eine MCU, die im 90-nm-Prozess gefertigt wird, verbraucht weniger als ein Drittel der Aktivleistung als ein 180-nm-Baustein. Gleichzeitig steigt aber der Leckstrom bei kleineren Prozessgeometrien und verringert die Energieeffizienz im Deep-Sleep-Modus. Der Hersteller muss beide Effekte sorgfältig abwägen.
Im Deep-Sleep-Modus muss einiges an Peripherie aktiv bleiben: neben der erwähnten BOD zum Beispiel unabhängige Watchdogs oder RTCs. Eine Low-Power MCU kann auch Sensor-, Touch- und Kommunikations-Schnittstellen sowie LCD-Segment-Treiber im Deep-Sleep-Modus betreiben. Alle diese Funktionen können unterstützende Schaltkreise wie Oszillatoren, Regler, Bias-Schaltungen und Digitallogik erfordern. Damit steigt zwar der Sleep-Mode-Strom, dafür ist der Deep-Sleep-Modus nun sehr viel nützlicher.
Schneller reagieren
Asynchrones Verhalten ist ebenfalls wichtig, um im Deep-Sleep-Modus schnell auf externe Ereignisse zu reagieren. Da in diesem Modus nur niedrige Taktfrequenzen zur Verfügung stehen, weist jede taktabhängige Peripherie längere Reaktionszeiten auf. Bei bestimmten Interaktionen wie der Abtastung externer, sich langsam bewegender Sensoren, ist dies unproblematisch. Die Reaktionszeit kann bei anderen Ereignissen jedoch entscheidend sein.
Flexible und autonome Peripherie-Interaktionen sind sowohl im Aktiv- als auch im Sleep-Modus wichtig. Wenn mehr Aufgaben selbstständig ablaufen, kann der MCU-Core in stromsparendere oder längere anhaltende Deep-Sleep-Modi eintreten. Autonomie verbessert auch die Reaktionszeit und den Determinismus. Aus einem Deep-Sleep-Modus kann die MCU zwar innerhalb von Mikrosekunden aktiviert werden, aber Interrupts mit hoher Priorität können die Antwort auf Systemfunktionen mit niedrigerer Priorität verzögern. Autonom arbeitende MCU-Peripherie und der Datenaustausch innerhalb der Peripherie ohne CPU-Eingriff erhöhen daher die Akkulaufzeit und verbessern die Reaktionsfähigkeit.
Fit für IoT
Im IoT-Zeitalter ist ein äußerst stromsparender Betrieb unverzichtbar und berührt jeden Aspekt des Embedded-Designs. Dazu gehören MCUs mit einem äußerst geringen Stromverbrauch im Sleep- und Aktivmodus, die auch im Deep-Sleep-Modus noch Aufgaben erledigen. Die Energieeffizienz einer MCU in einer bestimmten Anwendung lässt sich mithilfe der Datenblätter aber nur schwer bestimmen.
Die neuen Ultra-Low-Power-MCU-Benchmarks (ULPBench) des EEMBC ermöglichen Entwicklern, die Stromverbrauchsangaben der MCU-Hersteller zu hinterfragen. Phase 1 des ULPBench konzentriert sich auf die wesentlichen Bauteilspezifikationen, während Phase 2 auch die Peripherie mit einbezieht. ULPBench wird die Branche weiter voranbringen und neue Kennzahlen für die MCU-Energieeffizienz einführen.
Øivind Loe
(lei)
