Bild 1 zeigt die Ergebnisse des Benchmarks. Der kurze Peak in der Mitte (0x01) stellt den Beginn eines neuen Messzyklus dar. Im Messpunkt 0x02 führt die Benchmark-Applikation eine Referenzmessung aus, wechselt dann in den Schlafmodus. Die Messpunkte 0x03 bis 0x07 markieren jeweils den Beginn eines Benchmarks mit geänderten DMA-Einstellungen.
Die wesentliche Erkenntnis aus dieser ersten Untersuchung lautet: Das Programm selbst hat keinen signifikanten Einfluss auf die Stromaufnahme, der DMA-Transfer dafür umso mehr. Die Tests wurden Script-gesteuert über den kompletten Frequenzbereich wiederholt. Abgesehen von der Höhe der Stromaufnahme führten die Messungen, wie nicht anders zu erwarten, immer zum gleichen Ergebnis.
Zu beachten ist, dass die Untersuchungen sich auf die Betrachtung der reinen Rechenleistung beziehen und weitere Aspekte, zum Beispiel die Leistungsaufnahme der Peripherieeinheiten, vernachlässigt wurden. Das heißt, alle nicht benötigten Peripherieeinheiten waren deaktiviert.
Wer schneller rechnet, muss länger warten. Somit ist auch die Ruhestromaufnahme zu berücksichtigen. Der Controller wird nach den Tests jeweils in den Schlafmodus versetzt, aus dem er ohne nennenswerte Verzögerungen aufwachen kann. Dies dürfte für die meisten Aufgabenstellungen am zweckmäßigsten sein, da sonst eine erhebliche Auswirkung auf das Zeitverhalten der Applikation eintreten würde.
Um jedoch einschätzen zu können, wie groß der Vorteil durch das Wechseln in den Schlafmodus ist, musste die Stromaufnahme im aktiven und im Schlafmodus ermittelt werden. Hierzu wurde die Frequenz variiert und für jede Frequenz diese Messungen durchgeführt. Das Ergebnis zeigt Bild 2.
Grundlage der Überlegungen ist, dass der Controller immer schnell genug ist, um alle anfallenden Aufgaben zu erledigen. Dies ist in der verwendeten Applikation der Fall. Bei einer Konfiguration mit höherer Geschwindigkeit wartet der Baustein also die verbleibende Zeit im Schlafmodus unter Strom. In einem weiteren Schritt wurde nun in einer realen Applikation die Stromaufnahme gemessen. Die Applikation muss zyklisch einen Messwert erfassen, verarbeiten und zum PC übertragen. Wie sich zeigt, ist die MCU bei 100 MHz zu mehr als 90% der Zeit im Bereich zwischen 30 mA und 50 mA; dies ist der Schlafmodus. Bei einer Frequenz von 100 MHz ist die Anwendung also nur etwa 10% der Zeit aktiv. Da der Mikrocontroller auch im Ruhezustand viel Strom aufnimmt, ließe sich die Applikation nun leicht optimieren. Durch Absenken der Betriebsfrequenz sinkt nämlich die Stromaufnahme im aktiven und passiven Modus, allerdings steigt dadurch auch die benötigte Rechenzeit.
Um den optimalen Arbeitspunkt einfacher ermitteln zu können, wurden nun die Ergebnisse des obigen Benchmarks mit den Ergebnissen der Leistungsmessung kombiniert. Dadurch lässt sich die Auswirkung der hohen Frequenz und den damit verbundenen Wait-States auf die Rechenleistung ins Verhältnis zur Leistungsaufnahme setzen.
Bild 3 zeigt die Leistungskurve der Applikation. Interessant ist dabei, dass sich bei 40 MHz und 70 MHz offensichtlich Punkte ergeben, bei denen die Leistungsaufnahme gegenüber niedrigeren Frequenzen sinkt. Das hat zur Folge, dass bei einer benötigten Frequenz von 60 MHz es wohl besser ist, den Mikrocontroller mit 70 MHz zu fahren.
CPU-Auslastung als Gradmesser
Die Gesamtenergieaufnahme, die nötig ist, um eine vorgegebene Rechenaufgabe zu bewältigen, sinkt mit steigender Frequenz. Dadurch erscheint es zunächst vorteilhaft, den Controller auf maximale Geschwindigkeit zu trimmen. Allerdings nimmt mit zunehmender Frequenz die Energieaufnahme im Ruhezustand linear zu. Dies hat zur Folge, dass insgesamt die Energieaufnahme in der Regel bei steigender Frequenz ebenfalls steigt.
Als Faustregel kann man festhalten: Die niedrigste Energieaufnahme korrespondiert mit der niedrigsten Betriebsfrequenz, bei der die anstehende Aufgabe gerade noch bewältigt werden kann. In den meisten Fällen ist also das Optimum erreicht, wenn die CPU nahezu zu 100% ausgelastet ist. Zu beachten ist, dass diese Annahme nur für die oben genannten Rahmenbedingungen gilt und – wie die Messungen zeigen – in der Praxis nicht immer zutreffen.
Im Beispiel wechselt die CPU nur in den Schlafmodus, aus dem sie schnell wieder aufwachen kann; dabei verbraucht sie jedoch relativ viel Strom. Wechselt die CPU in einen Energiesparzustand, der deutlich weniger Strom benötigt, jedoch die Aufwachzeit länger ist, muss eine neue Untersuchung angestellt werden.
Für die Optimierung Mikrocontroller- basierter Systeme ergibt sich somit folgende Vorgehensweise:
Es sollte nicht versucht werden, zwecks Optimierung der Energieaufnahme, den Punkt der niedrigsten Leistung exakt einzustellen. In diesem Fall würde man sonst Gefahr laufen, bei unerwarteten Ereignissen nicht mehr genügend Rechenleistung zur Verfügung stehen zu haben. Die Geschwindigkeit sollte daher immer etwas höher gewählt werden.
Eine Programmoptimierung darf nur erfolgen, wenn die Einhaltung von Echtzeitanforderungen dadurch nicht eingeschränkt wird. Jedoch darf man nicht von einem linearen Verlauf der Leistungsaufnahme in Abhängigkeit von der Frequenz ausgehen. Wie Messungen, die mittels PowerScale durchgeführt wurden, zeigen, sind die Angaben der Hersteller auf jeden Fall durch eigene Messungen zu verifizieren.
Die Messungen zeigen eindeutig, dass der Zusammenhang zwischen der MCU-Frequenz und der Energieaufnahme nicht linear und schon gar nicht proportional verläuft. Wer also in der Praxis eine Anwendung auf beste Leistungsaufnahme trimmen möchte, kommt um geeignete Messgeräte nicht herum.
Autor:
Joachim Klein ist Manager Training bei Hitex Development Tools.