Der Weg zum geringsten Energieverbrauch in MCU-Systemen (Teil 1)

Autor / Redakteur: Horst Diewald * / Johann Wiesböck

Diese mehrteilige Artikelserie beleuchtet die wachsenden Anforderungen an Mikrocontroller, den gegenwärtigen Stand der Technik und entsprechende Low-Power-Optionen in einem Beispiel-Controller. Der Weg zum geringsten Energieverbrauch wird aufgezeigt.

Firmen zum Thema

Diese Serie zeigt Mechanismen und Wege für geringsmöglichen Energieverbrauch in MCU-Systemen
Diese Serie zeigt Mechanismen und Wege für geringsmöglichen Energieverbrauch in MCU-Systemen
(Bild: ©chombosan - stock.adobe.com)

Energieeffizienz von MCU und SoCs ist ein Kernthema für die Entwicklung von Produkten. Solche MCUs haben ein durchdachtes Energiemanagement und viele Einstellmöglichkeiten, die die verfügbare Energie fundiert zu nutzen. Diese mehrteilige Artikelserie beleuchtet die wachsenden Anforderungen an MCUs, den gegenwärtigen Status, die Optionen in einem Beispiel-Controller, die Festlegungen der Hardware und Power-Modi im MCU-System.

Anhand einer Beispielanwendung werden autonom arbeitende Abläufe untersucht. Je nach Aufgabe beeinflusst autonom arbeitende Hardware die Effizienz stark. Im letzten Teil der Artikelserie zeigt ein Ausblick Möglichkeiten, die vorgegebenen Wechsel der Energiemodi von der Software zu entkoppeln, die Wechsel effizienter zu gestalten und Energieeffizienz und Sicherheit in der Systemarchitektur optimal zu gestalten.

Bildergalerie

Der 1. Teil der Artikelserie zeigt grundsätzliche Fragestellungen auf bzw. zeigt Beispielparameter, die in extrem energiesensitiven Anwendungen wichtig sind. Bestimmen Hardware oder Software den Energieverbrauch oder deren Zusammenspiel? Die ständig wachsende Komplexität der Anforderungen der Anwendungen macht den Schritt in kleinere Prozessgeometrien notwendig. Die notwendigen neuen Schaltungskonzepte benötigen komplexere Betriebsmode-Steuerungen. Wie sind diese Betriebsmode-Steuerungen in aktuellen MCUs der „Low-Power“-Schienen gelöst?

Im Teil 2 betrachtet der Autor einen Beispiel-MCU-Baustein in Kontext einer einfachen Anwendung. Ein analoges Signal soll abgetastet werden (ADC) und die Datenbehandlung wird definiert. Die Abbildung erfolgt mit den Hardwareelementen eines Beispielcontrollers STM32L4xx betrachtet. Welche Entscheidungen müssen getroffen werden um den Controller so zu betreiben, dass die Spezifikation der Anwendung bei minimalem Energieeinsatz erfüllt wird? Welche Daten sind verfügbar und was können wir daraus entnehmen?

Im Teil 3 und 4 werden die Hardware, die Software und die Anwendung im Zuge einer energie-optimierten Applikation betrachtet. Grundsätzliche Überlegungen für beste Energieeffizienz werden angestellt. Es wird eine Vorgehensweise betrachtet, die die Power-Zustände, Takteinstellungen, Power-Modi und autonomer Betrieb zum energieeffizienten Zusammenspiel bringt.

Der 5. Teil betrachtet abschließend neue Möglichkeiten, die die autarke, weitgehend Software unabhängige Bearbeitung von Betriebsmode-Wechsel ermöglichen. Optimal angepasste Betriebsmode-Wechsel unterstützen sowohl weitere Energieeinsparungen als auch sichere Betriebsmodi. Das Zusammenwirken von energetisch optimierten und dabei sicheren Systemen wird künftig der Schlüssel für erfolgreiche I-o-T-Sensorsysteme sein.

Teil 1: Die Betriebsmode-Steuerungen in Low-Power-MCUs

Einfaches Austauschen von MCU-Bauteilen bei Änderungen von Anforderungen wäre natürlich ein Eldorado für die Anwender. Eine Definition, eine Hardware, eine Software – und los geht’s. Die beste Qualität, die besten Lieferbedingungen ermittelt und schon kann die Entwicklung starten. Stimmt es, dass die gleiche Architektur alles einebnet und die Suche nach dem energieeffizientesten Baustein obsolet ist?

Gut, das Pinning könnte anders sein… Bei den Smartphones geht das doch auch – Store aufrufen, Applikation herunterladen, öffnen und los geht es. Aber warum sind dann extra Spar-Modi und Ultra-Spar-Modi vorhanden? Warum muss dann das Smartphone neu gestartet werden, wenn der Ultra-Spar-Mode verlassen wird?

Wenn bestimmte Eigenschaften der Hardware den effizientesten Betrieb bestimmen, muss an die Hardware-Funktionen Hand angelegt werden, um eine maßgeschneiderte Energiesparlösung zu bekommen.

Gibt es Gemeinsamkeiten und Unterschiede zwischen performanten und hoch-effizienten MCUs und SoCs? Ja, viele Methoden sind in beiden Bereichen anwendbar, aber die verfügbare Energiemenge macht den Unterschied. Wenn ein Aufladen eines 2700mAh Akkus nach 2 Tagen – nach dem Motto „keiner kann es besser“ - akzeptiert ist, verhagelt der Dauerbetrieb eines Quarzoszillators mit z.B. 200uA keine Energiebilanz.

Hochenergie-effiziente Anwendungen (z.B. Grundlage des ULPBench™) haben eine durchschnittliche Gesamt-Stromaufnahmen von typisch 2 bis 6 µA. Alleine ein Quarzoszillator im „MHz“- und Dauerbetrieb macht dann jede Langzeitanwendung zunichte.

Zuerst (1. Teil) werden wir Hardware, Software, und die Anwendung dahingehend betrachten, was dominiert die energie-optimierten Anwendung. Grundsätzliche Überlegungen für beste Energieeffizienz werden angestellt. Worauf soll sich der Entscheider und Entwickler fokussieren?

Im 2. Teil dieser Artikelserie wird eine einfache Anwendung mit Signal- und Datenbehandlung definiert und die Abbildung auf die Hardwareelemente eines Beispielcontrollers STM32L4xx betrachtet. Welche Entscheidungen müssen getroffen werden um den Controller so zu betreiben, dass die Spezifikation der

Hardware bestimmt Energieaufnahme und Systemleistungen

Beginnen wir mit der Hardware. Sie bestimmt grundsätzlich, wie Energieaufnahme und Systemleistungen bedient werden und zu welchen Resultaten führen. Die aktuell wesentlichen Funktionen zur Energieeinsparung sind in vier Kategorien einzuordnen:

  • Instruktionen [1]
  • Hardware, die im gewählten Power-Modi betriebsbereit ist
  • das Taktsystem und Clock-Gating
  • das Power-System und Power-Gating

Es gibt zum Beispiel in der Cortex-M ISA (Instruction Set Architecture) drei Instruktionen die Powermodi auslösen können und die Bedingungen für die Rückkehr zum aktiven (RUN) Mode setzen. Dies sind „Wait for Interrupt (WFI)“, „Wait for Event (WFE)“, und „Send Event (SEV)“. Dazu sind dann die Implementierung eines (ARM) Interrupt-Kontrollers „Nested Vectored Interrupt Controller (NVIC)“ und „Wake-up Interrupt Controllers (WIC)“ vorgesehen, die das Bereitstellen der MCU-Funktionalität sicherstellen.

Der NVIC ist dabei Bestandteil des Architektur-IPs. Wenn der Prozessor und der NVIC in den “Very Low-Power Sleep“-Mode gebracht ist, behandelt der WIC die Ereignisse die einen Systemstart anfordern. Daneben gibt es noch die Instruktion SLEEPONEXIT die den Prozessor in den „Sleep Mode“ setzt nach dem Rückkehren von einem „Exception“-Handler in einen Thread-Mode. Mit diesem Prinzip rufen Instruktionen die Sparmodi aus einem laufenden Programm auf. Wenn der Controller aufgeweckt wird, werden die Takt- und Energiequellen so betrieben wie sie vor dem „Low-Power“-Mode eingestellt waren.

Die Energieaufnahme wird von der jeweiligen Hardware-Implementierung in einem Baustein bestimmt. Im aktiven (RUN) Mode dominiert die Architektur des Instruktionssatzes (ISA) sowie die Leistungsfähigkeit der Instruktions- und Datenspeicher mit den Busstrukturen. Energietechnisch ausbalancierte Caches bzw. eng gekoppelte Speicher (TCM – tighly coupled memory) sparen in der Regel Energie in der Codeausführung.

Bei energiesparenden MCU/SoCs ist das System meist in einem Stromsparmodus. Typische Zeiten sind <1% aktiver Mode und >99% im Stromsparmodus. Zunehmend wird der Energieverlust beim Umschalten zwischen den Betriebsmode und den Stromsparmodi wichtig.

Was bestimmt wesentlich den Energieverbrauch?

Das Versorgungsspannungssystem, Taktgebersystem, Clock-Gating und Power-Gating, Interrupt- und Aufwach-Behandlung und eine eventgetriebene Systemarchitektur (≠Befehlsarchitektur ISA) sind bestimmend für den Energieverbrauch. Diese Hardware-Struktur (Systemarchitektur) bestimmt wesentlich das gesamte Verhalten und zwar nicht nur den Energieverbrauch des Systems.

Aus der energetischen Sicht werden meistens digitalen Verbraucher genutzt um die Energieeffizienz zu betonen, so auch beim ULPBench™-CP vom EEMBC-Konsortium. Die beteiligten analogen Komponenten sind das Versorgungssystem, die Schaltungsteile die den Eintritt und das Verlassen der Betriebsbedingungen überwachen, und ein Quarzoszillator für die genaue Wiederholfrequenz. Gerade im I-o-T-Bereich ist jedoch die Erfassung von Umgebungsdaten analog geprägt. Analoge Signale erfordern eine differenzierte Behandlung von der Erfassung und Digitalisierung.

Neben diesen Betrachtungen sind die Spezifikationen der Hersteller ein wichtiger Faktor. Werte in Spezifikationen können sich beispielsweise von vorläufigen Werten gegenüber Produktionswerten und bei Bauteil-Revisionen ändern. Ist erst einmal ein Produkt beim Endkunden durch die Verifikation wird es schwierig, laufend die Auswirkungen der Änderungen der Spezifikationen auf die Produkteigenschaften zu verfolgen. Sind sie noch innerhalb der garantierten Werte?

Nun zum Taktsystem, wobei allen sehr energiesparenden Systemen gemeinsam relative komplexe Taktsysteme sind. Für die Grundzeitgeber stehen Quarzoszillatoren (32 768Hz Uhrenquarz), ein schnell startender voll integrierter Oszillator (RC-Type), sowie ein Quarzoszillator im „MHz“-Bereich zur Auswahl. Die Einstellungen werden in der Regel einmal gemacht. Die Interrupt-/Handler-SW greift dann darauf zurück. Eine energetische Anpassung ohne Software an die aktuelle Situation erfolgt nicht.

Das „Power“- und „Power-Gating“-System von energie-effizienten Produkten, die in den letzten Jahren auf den Markt gekommen, haben zwei LDOs und einen „Low-Power“-DC/DC-Konverter. Sie nutzen „Power-Gating“ um tiefe Energielevels zu erreichen. Die Einstellungen des „Power“-Systems als auch der „Power“-Inseln werden mittels Hardware-Einstellungen und teils durch automatische „Power“-Modi-Umschaltung bedient. Beim Interrupt-Handling wird immer automatisch der hohe Energie-Level des Betriebs-Modes (RUN) gewählt. Ob dieser benötigt wird, oder nicht.

Software ist mitentscheidender Faktor für die Energieaufnahme

Andererseits, die Software ist in vielen Fällen ein mitentscheidender Faktor für die Energieaufnahme. Wichtige Faktoren sind beispielhaft aufgeführt:

  • die Programmiertechnik, hardwarenah oder viele Abstraktionsebenen (HAL, API, RTOS, OS, etc.) und intensive Nutzung der Abstraktion
  • Wechsel/falsche Wahl der Power-Modi
  • Rechnen mit Fest-/Gleitkommazahlen
  • Compiler gerechte Programmierung, Auswahl der richtigen Compiler-Optionen
  • Fortschritt in der Compileroptimierung
  • „universelle“ statt optimierte Software.

Fazit, eine gute strategische Produktplanung der Hardware- und der Softwareeigenschaften wichtig ist. Der Energieverbrauch über Produktlebensdauer und Wartung der Produkte ist neben der Funktionalität ein essentieller Teil der Design-/Verifikationskette. Neue Compiler-, HAL-, RTOS-Versionen etc. können zu mehr oder weniger Energieverbrauch führen. Wiederverwendbarkeit über die gesamte Entwicklungs- und Produktionskette verlangen unter Umständen, dass binäre Objekte verwendet werden müssen.

Steht die Hardware, Software oder die Applikationsanforderung im Zentrum des Denkens? Bei dieser Frage wird die große Mehrheit dafür plädieren, dass die Anwendung erfüllt werden muss. Die Hardware wird dementsprechend aus dem großen Portfolio an MCU/SoCs ausgewählt und die Software „muss eben“ so geschrieben sein, dass das Pflichtenheft getroffen wird. Wieviel Reserve eingeplant wird oder werden muss, hängt von der Ausrichtung und dem Zweck der Anwendung ab - eine mitunter schwierige Entscheidung.

Es gibt mindestens zwei Rahmen die das Pflichtenheft vorgeben kann. Erstens, alles ist bis in „letzte“ Detail festgelegt. Dies kann zutreffen, wenn ein System 1-zu-1 ersetzt werden muss. Zweitens, ein System wird anhand der Eigenschaften und den äußeren Erfordernissen beschrieben. Damit sind die Lösungsmöglichkeiten in Grenzen variabel und können weitgehend optimal mit verfügbarer Hardware und Software gestaltet werden. In der Mehrheit der Entwicklungen sind variable Lösungsansätze möglich.

Tue nur dann etwas, wenn es unbedingt sein muss!

Diesen „Kernsatz der Energieeffizienz“ bedenkend sind verschiede Lösungsansätze möglich, die positiv auf die Energieeffizienz abgebildet werden können. Als Beispiel nehmen wir an, dass eine Kommunikation mit hoher zeitlicher Genauigkeit notwendig ist und einen quarzgenauen Takt erfordert. Die einfachste Lösung ist dauernd einen Quarzoszillator zu betreiben.

Nehmen wir weiter an, dass die Kommunikation eine Latenzzeit zwischen Kommunikationsanforderung und voller Betriebsbereitschaft erlaubt, können auch andere Lösungen im Sinne der Energieeffizienz angedacht werden. So kann der Quarzoszillator erst mit der Aufforderung zur Kommunikation gestartet werden. Der Einsatz eines PLL-Systems ist eine andere Alternative die als Referenztakt zum Beispiel ein Uhrenquarz-Taktsystem nutzt.

Im Bild 1 ist exemplarisch eine Erkennung einer Kommunikations-Anforderung gezeigt die auch in effizienten Energie-Modi die MCU/SoC ansprechbar halten. Die meisten MCU/SoC haben jedoch nur „Wake-up“-Implementierungen die mit digitalen Ein-/Ausgängen verbunden sind. Ein Beispiel für „Wake-up“-Implementierung finden wir in der MCU-Familie STM32L4xx.

Der Signalempfang im U(S)ART und LPUART Module ist im Stop(2)-Mode (~1,4uA mit RTC) funktionsfähig und generiert einen „Wake-up“-Interrupt beim Kommunikationsstart, bei einer Adressübereinstimmung oder einem Ereignis eines „Frames“. Diese Implementierung ist jedoch nicht bereit, wenn der Standby oder Shutdown-Mode aktiv ist.

Im Bild 2 ist exemplarisch eine Erkennung einer Kommunikations-Anforderung gezeigt die nur mit Hilfe von digitalen Ein-/Ausgängen wirkt. Damit ist keine reine Hardware-gesteuerte Betriebsmode-Umschaltung möglich – zumindest bei heutigen Implementierungen – sondern bedingt Software-Unterstützung. Die Software-Unterstützung ist üblicherweise verknüpft mit dem Einschalten des leistungsfähigsten Betriebs-Modes. Dies ist der RUN-Mode, der vor dem Low-Power-Mode aktiv war. Dabei werden dann die Hauptstromverbraucher, Memory (e.g. Flash), das Bussystem, die CPU und das Power/Takt-System aktiv – meist zusätzlich mit entsprechender Latenzzeit.

Kosteneffiziente Halbleiterprozesse nutzen und dennoch energieeffizient sein

In energieeffiziente Anwendungen nutzen die allermeisten MCU/SoC-Bausteine Clock- und Power-Gating und können so kosteneffiziente, kleinstrukturelle Halbleiterprozesse nutzen und dennoch energieeffizient sein.

Clock-Gating schaltet den Betriebstakt aus, wenn er nicht benutzt wird. Dies wurde schon in den 1990ern genutzt, und zwar war dort eine automatische Ein-/Ausschaltmethode verwendet. In aktuellen Bausteinen werden meist ein oder mehrere Kontrollbits verwendet um diese Technik zu nutzen. Da bei dieser Technik auch Clocks abgeschaltet werden können, die noch zum Beenden einer Aufgabe notwendig sind, wird vereinzelt von den entsprechenden Schaltungsteilen eine anhaltende Clock-Anforderung ausgegeben.

Diese können dann verwendet werden um den Clock so lange weiter zur Verfügung zu haben wie er gebraucht wird. Diese Funktion ist auch für eine sichere und energiesparsame Betriebsbereitschaft bedeutsam. Vor mehr als einer Dekade wurde dies in MSP430-Produkte [3] eingeführt. [3] Texas Instruments Inc., „MSP430x1xx Family User's Guide, SLAZ671A, April 2015, Revised December 2016“.

Power-Gating wird angewandt, wenn die Clock-Abschaltung nicht ausreicht um den Energieverlust (oder Temperaturanstieg durch Verlustleistung) durch Leckströme zu minimieren. Dabei werden Teile des Systems von der Versorgungsspannung abgetrennt. Die Power-Gates dürfen nur sehr geringe Leckströme aufweisen um effektiv eine starke Reduktion der Ströme zu erreichen.

Diese Methode hat den Nachteil, dass diese Systemteile ihre Konfigurationen und aktuellen Einstellungen verlieren, wenn keine zusätzlichen Schaltungsmaßnahmen getroffen sind. Ein automatisches Speichern und Rückspeichern ist eine Option, um die Auswirkungen des Abschaltens der Versorgung vom Anwender möglichst gering zu halten. Auswirkungen sind beispielsweise der Verlust der Einstellungen, Konfiguration, des I/O-Status.

Um solche Informationen oder Daten zu erhalten werden Datenspeicher nun meist mit zwei SRAM-Speicher ausgestattet. Einer dieser Speicher ist kleiner und ist bei wirksamen Energiesparmodi weiter vom Power-Gating ausgenommen. Eine sorgfältige Speicherplanung ist damit für einen sicheren Betrieb erforderlich.

Fazit zum ersten Teil dieser Mikrocontroller-Artikelserie

Die Grundbetrachtungen des 1. Teils zeigen, dass kleinste Stromverbräuche die Energiebilanz für Applikationen in tragbaren, schwer zugänglichen, fernversorgten Produkten eine Anwendung erst ermöglichen. Besonders starkes Augenmerk gilt dem abgestimmten Verhalten von Hardware und Software auf die jeweilige Aufgabe.

Verstärkt wird das Feld der IoT-Anwendungen mit Kommunikation verknüpft. Viele Produkte werden damit über drahtlose Funkverbindungen in ein Gesamtsystem eingebunden. Damit verbunden, werden mehr Controller (über reine Kontrollanwendungen hinaus) auch in die Datenbehandlung, zum Beispiel Datenvorverarbeitung, münden. Jedes übertragene oder längere Protokoll verbraucht Energie, die bei smarter Aufgabenverteilung zum Gelingen energetisch effizienter System wesentlich beitragen werden.

* Horst Diewald ist Mitgründer der ProJoule GmbH. Er entwickelt Ideen für Mikrocontroller in anwendungsspezifischen Energie-effizienten Systemen. Bei Texas Instruments entwickelte er den ersten hocheffizienten 16-Bit-Mikrocontroller MSP430.

(ID:45104002)