Bei der Entwicklung eines Wireless Wearable Device muss man jede Gelegenheit zur Optimierung des Energieverbrauchs nutzen (Bild 2). Das Gerät sollte so schnell wie möglich aktiviert werden, die Daten schnell sammeln und verarbeiten und so schnell wie möglich wieder in den Sleep-Modus zurückkehren. Wenn ein Prozessor nur 10% mehr Zeit im Aktivmodus verbringt als ein anderer Prozessor, beeinflusst dies die Batterielebensdauer erheblich. Angenommen, Prozessor 1 verbringt 99,9% seiner Zeit im Deep-Sleep (1 µA) und 0,1% im Aktivmodus (10 mA), Prozessor 2 jedoch 99,89% im Deep-Sleep und 0,11% im Aktivmodus, steigt der Gesamtstromverbrauch des zweiten Prozessors um 9,1%.
Interessant dabei: Sind die Prozessoren 1 und 2 alle sechs Stunden nur 100 ms beziehungsweise 110 ms aktiv, unterstreichen die Ergebnisse die Bedeutung des Stromverbrauchs im Very-Low-Deep-Sleep-Modus. Denn in diesem Fall verbraucht Prozessor 2 nur 0,44% mehr Strom als Prozessor 1. Ist die Zeitdauer im Aktivmodus jedoch die gleiche und erhöht sich der Deep-Sleep-Stromverbrauch von 1 µA auf 1,1 µA, steigt
der Gesamtstromverbrauch um 9,6%.
Je nach Funktion müssen Wearables mit integrierter Peripherie interagieren oder diese überwachen – und das regelmäßig oder sogar dauerhaft. Müsste die CPU in diesen Fällen jedes Mal aktiviert werden, würde sich die Batterielebensdauer drastisch verkürzen. Arbeitet die On-Chip-Peripherie dagegen autonom und ohne CPU, kann das System in einem Energiesparmodus verbleiben und trotzem anspruchsvolle Aufgaben ausführen. Zu dieser Art von Peripherie zählen: serielle Schnittstellen (stromsparende UARTs, quarzloses USB), I/O-Ports (externe Interrupts, GPIO), Timer und Trigger (stromsparende Timer, Sensorschnittstellen), Analogmodule (A/D-Wandler, LCD-Controller) und Sicherheit (AES-Beschleuniger).
Einfluss der Peripherieblöcke
Es gibt auch Situationen, in denen Peripherieblöcke untereinander kommunizieren müssen. Dabei kann eine Peripherie ein oder mehrere Ereignisse erzeugen, die sofort von einer anderen On-Chip-Peripherie bearbeitet werden können. Ein Timer zum Beispiel kann so eingestellt werden, dass er ein Ereignis erzeugt, das den A/D-Wandler für eine Abtastung aktiviert. Der autonome Betrieb zwischen diesen Peripherieblöcken ohne CPU garantiert den niedrigsten Systemstromverbrauch. Diese Funktion ist ein wichtiger Bestandteil der MCU-Architektur des EFM32 und heißt »Peripheral Reflex System« (Bild 3).
Irgendwann ist dennoch nötig, die CPU für eine bestimmte Aufgabe zu wecken. Die meisten MCUs werden über einen festgelegten Zeitplan aktiviert, um die Schnittstellen zu überwachen. Ist keine weitere Aktion erforderlich, kehrt die CPU in den Sleep-Modus zurück. Allerdings verbrauchen solche periodischen Aktivierungszyklen unnötigerweise viel Strom. Die »LESENSE«-Architektur (Low Energy Sensor Interface) der EFM32-MCUs kann Analogsensoren (resistiv, kapazitiv und induktiv) autonom überwachen und aktiviert die CPU nur bei relevanten oder bedingten Ereignissen. Zum Beispiel kann LESENSE einen Temperatursensor autonom abfragen und über das Peripheral-Reflex-System erst dann die CPU wecken, wenn ein voreingestellter Schwellenwert überschritten wird.
Neben der CPU müssen natürlich auch die Peripherieblöcke auf niedrigen Verbrauch getrimmt werden, denn der Autonomiebetrieb erreicht nur wenig, wenn die Peripherie selbst viel Strom verbraucht oder wenn Taktsignale unnötigerweise aktiviert sind. Als Peripherie spielt deswegen die Taktmanagement-Einheit eine wichtige Rolle bei der Ermittlung des MCU- oder WMCU-Gesamtstromverbrauchs. Die Einheit kann die verschiedenen Taktsignale und Oszillatoren individuell steuern und optimiert die Taktauswahl auf Basis des Betriebsmodus und der aktivierten Peripherie. Eine energieeffiziente Taktmanagement-Einheit bietet: stromsparende Oszillatoren, kurze Start-up-Zeiten, dynamische Taktteilung, Takt-Pre-Scaler für 32-kHz-Peripheriemodule und Clock-Gating.