Das Ultra-Low-Power Management des ESP32

Applikationsschrift

WiFi gilt als recht leistungshungrig, dies jedoch weniger wegen einer immanenten Ineffizienz des IEEE 802.11-Protokolls sondern wegen der Art und Weise, wie es für konventionelle Anwendungen entwickelt und eingesetzt wird.

Mit einem Energieverbrauch von 1 bis 17 Joule je MByte übertragener Daten [01] für konventionelle »High-Power«-WiFi-Geräte können nämlich sogar sehr Bild1.pngineffiziente Implementierungen mit einem einzigen Satz »AA«-Batterien jeden Tag 1 MByte an Daten über eine Dauer von vier Jahren übertragen.

Bei Aktor-/Sensorknoten für das IoT, die relativ geringe Datenmengen in großem zeitlichen Abstand senden, ist vor allem die Zeit „zwischen den Bursts“ von entscheidender Bedeutung. Während diesen Phasen so wenig Strom wie möglich zu verbrauchen bildet den entscheidenden Schlüssel zu langen Batteriestandzeiten.

Wir haben das Power Management des Espressif ESP32 SoCs mit seinem Ultra-Low-Power Coprozessor daraufhin untersucht und stellen die Ergebnisse im folgenden Beitrag vor.

ESP32-Wrover-Kit

Zur Messung des Stromverbrauchs eignet sich besonders das ESP32-Wrover-Kit[02], weil hier in der 3V3 Spannungsschiene des Moduls ein 0-Ohm Widerstand für derartige Messungen vorgesehen wurde, der sich dank „0603“-Bauform auch gut entfernen lässt.Bild2.png

Wir messen über diesen Pfad also den Stromverbrauch des gesamten Moduls, einschließlich integriertem FLASH und PSRAM, wobei die Speicher im Deep-Sleep Mode des SoCs von der Stromversorgung abgeschaltet werden und daher nahezu keinen Strom ziehen.

Das PSRAM ist ein 64 Mbit Serial Pseudo SRAM Speicher, organisiert zu 8M x 8 Bits und wird über das Serial Peripheral Interface (SPI) angesprochen. Benötigt wird der zusätzliche Arbeitsspeicher von 8 MByte vor allem bei Audio-Anwendungen. So ist das PSRAM beispielsweise bei den Alexa-Voice-Service Applikationen zwingend notwendig. Für reine IoT-Applikationen mit Sensorabfragen, Aktor-Betätigungen und einer Handvoll TCP/IP-Protokollen ist es hingegen nicht nötig, so dass in solchen Fällen das ESP32-Wroom Modul ohne PSRAM vorzuziehen ist. Wenn es auch im Deep Sleep von der Spannungsversorgung getrennt ist so braucht es doch im normalen Betriebsmodus des SoCs etwa 400 µA, auch wenn nicht gelesen oder geschrieben wird.

Der Ultra-Low-Power Prozessor des ESP32

Der ULP ist ein recht einfacher aber hoch effizienter Co-Prozessor, der auch während der Deep-Sleep Betriebsart des Haupt-SoCs aktiv bleibt. Dadurch können Programme verarbeitet werden, die im RTC-Memory gespeichert sind. Der ULP kann dabei auf Peripherieeinheiten zugreifen, auf interne Sensoren und RTC-Register und damit den Hauptprozessor bei bestimmten Ereignissen oder Parameterveränderungen wie beispielsweise steigenden Temperaturen aufwecken.Bild3.png

Der ULP verfügt über 8 kByte SRAM für Instruktionen und Daten und wird mit dem RTC_FAST_CLK von 8MHz getaktet. Er ist in allen Power-Save-Betriebsarten, also “Light Sleep” und “Deep Sleep” aktiv und kann den SOC aufwecken sowie einen Interrupt an die CPU schicken. Er beinhaltet 4 General-Purpose-Register R0 - R3 zum Handling von Daten und Speicherinhalten. Weiterhin verfügt er über ein 8-Bit stage_cnt Register für die ALU und zum Gebrauch bei JUMP Instruktionen.

Von seiner Konstruktion her ist der ULP ein programmierbarer Zustandsautomat[03], also eine Finte-State-Machine (FSM), die in allen Power-Modi des SoCs aktiv bleibt. Wie eine General-Purpose-CPU verfügt er über einen Satz an Instruktionen zur Realisierung durchaus komplexer Mimiken und auch über einige Instruktionen spezielle für RTC Controller und für die Peripherie. Auf die 8 kByte SRAM RTC-Memory können sowohl der ULP Co-Prozessor als auch die CPU zugreifen, daher wird er zum Speichern von Instruktionen für den ULP und zum Austausch von Daten zwischen ULP und CPU verwendet. Dabei hat der ULP auch Zugriff auf nahezu alle Module des RTCs, entweder über entsprechende Instruktionen oder über RTC-Register.

Der ULP kann mittels Software gestartet werden oder periodisch durch einen Timer, die Programmausführung endet schließlich durch eine HALT-Instruktion.

Weitere Informationen dazu sind im “ESP Technical Reference Manual“[04], Kapitel 29 (aktuell V3.4) zu finden.

Deep-Sleep Test-Software

Für unsere Verbrauchsmessungen des ESP32-Wrover-Moduls haben wir ein Programm aus dem ESP32-IDF Repository[05] verwendet. Es versetzt den ESP32 für 20 Sekunden in Deep-Sleep-Mode und weckt ihn über Timer oder Tastendruck wieder auf. Wahlweise kann auch konfiguriert werden, das SOC bei einem Temperaturanstieg über 5°C zu wecken. Compiliert wurde die Software auf einer Ubuntu 18.04 „Bionic Beaver“ Plattform innerhalb der Espressif Entwicklungsumgebung[06].Bild4.png

Das Programm ist mit ca. 300 Zeilen recht übersichtlich, allerdings sind die Funktionen für den ULP erwartungsgemäß kryptisch, da Assemblercode.

Ergebnisse

Unsere Messungen ergaben einen durchschnittlichen Stromverbrauch von 175 µA auf der 3.3 Volt-Schiene zum Modul und dieses Ergebnis ist auch im Einklang mit Messungen anderer User aus der Espressif Community, die noch etwas niedriger, nämlich bei etwa 150 µA liegen. Die Ursache dieser Differenz dürfte im aktiven Wakeup Timer liegen, der zum regelmäßigen Aufwachen aus dem Deep-Sleep Mode notwendig ist. Das PSRAM des ESP32-Wrover-Modules scheidet als Ursache aus, das es genau wie das serielle FLASH im Deep-Sleep Mode über einen Schaltausgang des ESP32 von der Stromversorgung getrennt wird.

Wir haben in der Software auch die Abfrage des Temperatursensors über ADC deaktiviert und konnten damit den Stromverbrauch um etwa 25 µA gegenüber einem ersten Messwert von ca. 200 µA senken.

Um nun eine Abschätzung zum Einsatz des ESP32 in einer batteriebetriebenen Anwendung zu geben, unterstellen wir eine kompakte Lithium-Batterie vom Typ CR123 mit einer Kapazität von 1.500 mAh. Dieser Batterietyp hat eine sehr geringe Selbstentladung von weniger als 1% pro Jahr, so dass dieser Effekt vernachlässigt werden kann. Weniger elegant ist der Umstand, dass dieser Batterietyp 3V Nennspannung besitzt und bis zum Ende der Standzeit[07] auf etwa 1.8 V absinkt. Deswegen ist für den Batteriebetrieb auf jeden Fall ein Dual-Mode Spannungsregler wie etwa ein Ricoh RP600[08] einzusetzen, der eine konstante Versorgungsspannung unabhängig von der Eingangsspannung gewährleistet. Wir setzen für diese Wandlung einen Wirkungsgrad von 90% an, d.h. die effektiv verfügbare Batteriekapazität sinkt auf 1.350 mAh (bei 22°C).Bild5.png

Zur Abschätzung des Energieverbrauchs bei der drahtlosen (WiFi) Datenübertragung unterstellen wir eine stündliche Datenübertragung mit einer Dauer von jeweils 1 Sekunde und einem Stromverbrauch von 140 mA. Grundsätzlich können solche WiFi-Bursts mit wenigen 100 Bytes einschließlich dem Booten eines RTOS innerhalb von etwa 100 ms durchgeführt werden, doch nehmen wir für diese Abschätzung ein worst-case Szenario an.

Nun ergibt sich für den Deep-Sleep-Betrieb pro Tag 175 µA * 24 h = 4.2 mAh, für die Sendebursts 140 mA * 1 s / 3600 s/h * 24 = 0.93 mAh, in Summe also 5.13 mAh je Tag. In Bezug zur Kapazität der Batterie ergibt das eine rechnerische Standzeit von 263,16 Tage.

Ein WiFi Sensorknoten mit dem ESP32 lässt sich also in diesem Modell etwa ein ¾-Jahr mit einer Lithium CR123 Zelle betreiben, was einen durchaus akzeptablen Wert darstellt.

ma/st

Espressif Systems Website

Macnica Linecard

Bitte nutzen Sie das Kontaktformular auf unserer Webseite für Anfragen zu unseren Produkten.

Macnica Kontaktformular