Alles um uns herum wird immer intelligenter und zunehmend mit anderen Dingen vernetzt. Schuhe können jetzt Sensoren enthalten, die dem Besitzer sagen können, wie er die Zeit verlängern kann, die er im Gehen verbringt. Dazu zeigen sie die Schritte auf dem Smartphone des Besitzers an. Die Waage des Benutzers kann automatisch sein Gewicht in einer Cloud-gestützten Tracking-Anwendung speichern. Dann teilt sie ihm über eine Warnung auf dessen Smartphone an, warum das letzte süße Teilchen, das er gegessen hat eine schlechte Idee war. Ein Home Security System kann den Benutzer dank eines kleinen Funksensors direkt am Heißwasserboiler per SMS über ein Leck in dessen Garage informieren.
Dank der technischen Fortschritte der letzten Zeit sind tragbare, batteriebetriebene Anwendungen immer beliebter geworden. Entwickler bemühen sich laufend, in jedem ihrer aufeinanderfolgenden Designs den Funktionsumfang ihrer Produkte zu vergrößern und dabei gleichzeitig deren Gesamtabmessungen zu verringern. Diese zusätzlichen Funktionen stellen immer größere Anforderungen an die Stromversorgung. So besteht die Herausforderung darin, wie man diese neuen Funktionen bei erweiterter Batterielaufzeit und kleinerem Platzbedarf implementieren kann.
8-Bit-MCUs sind sparsamer als 32-Bit-Architekturen
Traditionell bemühte man sich bei der Entwicklung batteriebetriebene Anwendungen, soviel Module so lange wie möglich in einem Low-Power Status zu halten, und sie nur gelegentlich zur Ausführung der benötigten Aufgaben aufzuwecken, bevor sie wieder in einen Sleep-Modus zurückkehren. In einem komplexen Design mit mehreren MCU/MPUs und Komponenten dient ein 8-Bit Mikrocontroller mit geringer Pinzahl oft als System-Supervisor. Dieser übernimmt Verwaltungsaufgaben wie das Ein- und Ausschalten von Modulen je nach Bedarf, um damit ein Höchstmaß an Energieeffizienz zu erzielen.
Eckdaten
Die Entwicklung von batteriebetriebenen Applikationen ist wegen ihres zunehmenden Funktionsumfangs komplizierter geworden. Wer ein Höchstmaß an Effizienz bei der Batterienutzung erzielen möchte, muss das Stromverbrauchsprofil jedes Bausteins in seinen unterschiedlichen Leistungs- und Aktivitätsmodi analysieren und genau verstehen. Das Angebot an Core-unabhängigen Peripherieschaltungen in 8-Bit Mikrocontrollern der nächsten Generation erlaubt Entwicklern einen kreativen Umgang mit ihren Designs, ohne dabei auf Leistung verzichten zu müssen.
Nach wie vor enthalten die allermeisten Designs zur Implementierung der erforderlichen Systemfunktionen nur einen zentralen Mikrocontroller mit einer Reihe von integrierten Peripherieschaltungen. Der Stromverbrauch dieses Mikrocontrollers wird daher zum kritischen Parameter. In Bezug auf Low-Power-Leistung sind allerdings nicht alle Mikrocontroller gleich. Hier kann ein 8-Bit Mikrocontroller oft einen 32-Bit Baustein übertreffen. Manche 8-Bit MCUs verbrauchen nur 20 nA in ihrem Modus mit geringstem Stromverbrauch, während 32-Bit bestenfalls einen zehn- bis 20-mal höheren Minimalverbrauch aufweisen.
Energiesparende Wakeup-Kontrolle
Ein Mikrocontroller lässt sich auf mehreren Wegen aus dem Sleep-Modus aufwecken. Es ist gängige Praxis, die internen Timer eines Mikrocontrollers zu nutzen, um das System in regelmäßigen Zeitabständen aufzuwecken. Der Timer lässt sich so konfigurieren, dass er bei einem Überlauf einen Interrupt auslöst. Ein 16-Bit Timer mit einem 1:8 Prescaler, der an einem stromsparenden, internen 31 kHz Oszillator (oder mit einem externen Quarz) arbeitet, kann den Baustein für etwa 17 s im Sleep-Zustand halten. Als weitere Option könnte man den Watchdog-Timer (WDT) der MCU nutzen, und damit idealerweise eine maximale Leerlaufzeit von 256 s erreichen. Der WDT würde zirka 440 nA verbrauchen. Zur Erinnerung, eine typische 32-Bit MCU mit aktiviertem WDT verbraucht wenigstens den dreifachen Strom einer 8-Bit MCU.
Es sei eine Applikation angenommen, die nicht regelmäßig aufwachen muss, wie etwa ein Umwelt-Monitor. Dieser wacht ca. alle 4 Stunden auf und liest einen Feuchtigkeitssensor aus, bevor er wieder in den Schlafzustand geht. Heißt das, dass eine solche Schaltung aufgrund der Einschränkungen seiner internen Timer häufiger aufwachen muss? Nicht unbedingt. Eine Möglichkeit wäre, einen Real Time Clock (RTC) mit einem Quarz zu nutzen, der bei Bedarf einen genauen Takt in Stunden, Tagen, Monaten oder sogar Jahren vorgibt. Da nicht alle Mikrocontroller (oft aus Kostengründen) einen integrierten RTC mit Quarz enthalten könnte man auch einen eigenständigen RTC in Betracht ziehen.
Integrierte Peripherieschaltungen für längere Leerlaufperioden
Eine weitere Möglichkeit zur Verlängerung der Leerlaufperiode ohne zusätzliche Bauteile oder Stromverbrauchs-Nachteile ist die Nutzung spezieller Peripherieschaltungen, die in einigen 8-Bit Mikrocontrollern der nächsten Generation enthalten sind (wie etwa in den PIC-MCUs von Microchip). So können Entwickler beispielsweise eine der konfigurierbaren Logikzellen (CLC, Configurable Logic Cell) und deren numerisch gesteuerten Oszillator (NCO, Numerically Controlled Oscillator) dieser MCUs mit dem 16-Bit Timer verbinden. Dies erlaubt es, den Zeitraum bis zum Auslösen eines Interrupts für das Aufwecken der MCU (Bild 1) von 17 Sekunden auf 205 Tage auszudehnen. Natürlich kommt es selten vor, dass eine Applikation für einen so langen Zeitraum im Leerlauf bleiben muss, für den Fall der Fälle gibt es aber diese Möglichkeit.
Nutzt man den internen Low-Power Oszillator (31 kHz) zur Ansteuerung des so möglichen (Langzeit-) Timers, so ergibt dies eine Lösung mit minimalem Kostenaufwand. Allerdings lässt sich der Stromverbrauch dieser Implementierung noch um weitere 50 % auf ca. 2,3 µA verringern, wenn man einen externen 32 kHz Quarz an den sekundären Oszillator (SOSC) anschließt, was aber geringfügig mehr kostet.
Die MCU über externe Interrupt-Quelle aufwecken
Man kann auch externe Interrupt-Quellen wie ein Schalter oder ein Sensor zum Aufwecken des Mikrocontrollers nutzen. Einige der größeren MCU/MPUs besitzen mehrere Interrupts mit Prioritätsebenen, die meisten MCUs mit geringer Pinzahl auf dem Markt besitzen diese Funktionen aber nicht. Erinnern wir uns noch einmal an das CLC-Modul, mit dem wir im letzten Beispiel die Timer-Periode verlängert haben. Dieses Modul lässt sich nicht nur zum Aufbau zusätzlicher Interrupt-Quellen nutzen, wenn die MCU nur einen System-Interrupt besitzt. Mit ihm können Entwickler auch konditionelle oder sequenzielle Logik in die Aufwach-Routine einbinden und die MCU ohne zusätzlichen Strombedarf mit mehr Intelligenz ausstatten.
Wenn das System eine Reihe von Signalen zur Darstellung eines bestimmten Zustands benötigt, und wenn man diesen Zustand eigentlich vor dem Aufwecken der CPU überprüfen müsste, dann wurde die CPU oft schon aufgrund einer einzigen Signaländerung aufgeweckt, nur um herauszufinden, dass sich die anderen Signale noch nicht geändert hatten. Heute kann man die verfügbaren Logikfunktionen und Zustandsmaschinen im CLC konfigurieren und miteinander kombinieren oder sogar mehrere CLC Module miteinander verbinden. Damit kann man spezielle Wakeup-Bedingungen erzeugen, um häufige, falsche Triggerungen und unnötigen Stromverbrauch zu vermeiden.
Die Wakeup-Zeit eines Bausteins kann einen großen Bestandteil der aktiven Laufzeit im periodischen Profil einer Anwendung ausmachen. Beim internen Oszillator eines 8-Bit Mikrocontrollers beschränkt sich diese Aktivität meist auf einige wenige Taktzyklen (3 bis 5 Zyklen entsprechend 200 ns bis 1 µs). Bei einer 32-Bit Architektur dauert die Nutzung von Deep-Sleep Techniken zur Begrenzung von Leckströmen 10 µs oder mehr. Dies kann bestimmte oder alle Vorteile aus der anschließend meist schnelleren Ausführungsgeschwindigkeit zunichtemachen.
Aufgabenausführung im Aktiv- oder Sleep-Modus?
Auch wenn man gerne alles im Sleep-Modus abarbeiten würde, lassen sich bestimmte Aufgaben nur im aktiven Modus ausführen, in dem der MCU-Kern im Vergleich zu allen anderen Modulen die meiste Energie verbraucht. Hier kann es kompliziert werden. Bild 2 zeigt eine vereinfachte grafische Darstellung des System-Stromverbrauchs über die Zeit. Die Fläche unter der Stromverbrauchs-Linie entspricht der gesamten Entladung über die Zeit (gemessen in Coulomb). Wenn die Summe aller Flächen in der Sleep-Modus Periode bedeutend größer ist als die im aktiven Modus, dann werden der Wert des Sleep-Stroms und die im Sleep-Modus verbrachte Zeit irrelevant.
Anwendungen mit drahtloser Datenkommunikation wie Wi-Fi oder Bluetooth Low Energy sind in Systemen eine besondere Herausforderung, wenn der Stromverbrauch verringert werden soll. Wer ein solches System entwickelt, muss die Menge der zu sendenden oder empfangenden Daten berücksichtigen, da sich diese direkt auf den Gesamt-Stromverbrauch auswirkt. Wireless-Module lassen sich in einem “Beacon-Modus” betreiben, in dem sie periodisch aufwachen und nach Signalen suchen, oder sie können bei Nicht-Verwendung in einen Standby-Modus übergehen.
In solchen Wireless-Systemen ist die MCU-Verarbeitungsgeschwindigkeit oft unwesentlich, da die Applikation oft vom I/O-Datenverkehr bestimmt wird. Allerdings hat die Aufwachzeit der MCU einen starken Einfluss auf das Anwendungsprofil, da dann der Stromverbrauch der HF-Schaltung steigt (typisch 10 – 20 mA), und schließlich die Energiebilanz der Anwendung dominiert.
Analogsensoren nutzen das auf der MCU integrierte A/D-Wandler-Modul. Meist dauert das A/D-Wandler Sampling wesentlich länger als die Wandlungszeit. Je mehr Zeit aber im aktiven Modus verbracht wird, umso höher ist der Stromverbrauch. Manche MCUs besitzen jedoch A/D-Wandler-Module, die eine Signalwandlung im Sleep-Modus ausführen können. Dies spart Energie, weil die im aktiven Modus verbrachte Zeit damit auf ein Minimum sinkt.
In manchen MCUs sind zahlreiche aktive Low-Power-Betriebsarten integriert. Diese Betriebsarten ermöglichen eine Abschaltung des Prozessorkerns oder eine Verringerung seiner Taktgeschwindigkeit, während der System-Takt selektiv für die auf dem Chip integrierten Peripherieschaltungen aktiv bleibt.
Voll funktionsfähige Peripherie im Sleep-Modus
Häufig hört man die Aussage „je höher die Core-Leistung, umso schneller ist die Task-Ausführung, und umso eher lässt sich der Core zurück in den Sleep-Modus versetzen“. Auch wenn dies in manchen Fällen zutrifft, ist die Logik dieser Aussage fehlerhaft. Man darf nicht vergessen, dass der Core mehr Energie verbraucht als irgendein anderes Modul in der MCU. Außerdem müssen alle Aufgaben, die den Core benötigen, unabhängig von der Arbeitsgeschwindigkeit sequenziell (FIFO) ausgeführt werden. Der Core lässt sich also erst dann abschalten, wenn der letzte Task abgearbeitet ist. Wenn ein Mikrocontroller einige der benötigten Tasks unter Verwendung integrierter, vom Core unabhängig arbeitender Peripherieschaltungen ausführen kann, dann wird die Core-Geschwindigkeit irrelevant, und zugleich lässt sich der Gesamt-Stromverbrauch deutlich reduzieren. Core-unabhängige Peripherieschaltungen sind voll funktionsfähig, während sich der MCU-Core im Sleep-Modus befindet.
Dank der neuesten Fortschritte beim Funktionsumfang von Mikrocontrollern ist die Implementierung verschiedener integrierter Funktionen und Peripherieschaltungen, sowie eines Powermanagements in Embedded-Designs intelligenter und einfacher geworden. Solche MCUs erlauben auch die Nutzung besserer Design-Techniken.
Jin Xu
(jwa)