Forum: Mikrocontroller und Digitale Elektronik AVR Energieverbrauch vs Takt


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich würde gern Kommentare zu einem grundsätzlichen Verständnisproblem 
meinerseits erhalten.

Man liest überall, dass man das Ziel eines möglichst geringen 
Energieverbrauchs eines uC erreicht, indem man dessen Taktfrequenz so 
klein wie möglich wählt.

Ich habe aber das Gefühl, dass eher das Gegenteil richtig ist.
Folgende Argumentationskette:

1. Man nehme an, der uC soll irgendetwas machen, dieses möglichst 
energiesparend. Zur Vereinfachung nehme ich an, dieses Irgendetwas 
benötige 100 Taktzyklen; außerdem sei Vcc 5V.

2. Bei 20MHz dauert dies dann also 100 * 50ns = 5us.  Für 20MHz sagt das 
Datenblatt über den ATmega328P (den ich hier mal als Beispiel auswähle), 
dass dieser 12mA braucht, also für meine Aktion Q = 12mA * 5 us = 60 nC 
(NanoCoulomb), und somit bei 5V eine Energie von E = 60nC * 5V = 300nJ.

3. bei 100kHz (kleinste Angabe im Datasheet) entsprechend:
T = 100 * 10us = 1ms
Q = 1ms * 0.1mA= 100nC
E = 100nC * 5V = 500nJ

ALSO: fast doppelt so hoher Energieverbrauch bei kleinstem Takt!

Die gleiche Berechnung für Vcc = 1.8V liefert:
E(100kHz) = 100 *  10us x  40uA x 1.8V =   72nJ
E(4MHz)   = 100 * 250ns x 0.9mA x 1.8V = 40.5nJ

dito!

Meine Schlussfolgerung:
Man wähle die Taktfrequenz so hoch wie möglich, um Energie zu 
sparen...

Wo denke ich falsch?
Wäre um jeden Schubser dankbar...

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
sigma9 schrieb:
> Wo denke ich falsch?

nirgendwo.
So ist das nunmal und das findet sich so eigentlich auch in den meisten 
Quellen.
Gilt natürlich nur, wenn man anschließend auch in den Sleep Mode geht.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Gilt natürlich nur, wenn man anschließend auch in den Sleep Mode geht.

Wenn das nicht möglich ist, spielen nämlich die Umschaltspitzen der 
MC-internen CMOS Buffer die grosse Rolle. Da sie während der 
Umschalterei kurz mal High- und Lowside gleichzeitg offen haben, sind 
viele Umschaltereien (hoher Takt) stromfressender als wenige (niedriger 
Takt). Im Dauerbetrieb kann es also sinnvoll sein, Takt zu senken.

von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> sigma9 schrieb:
>> Wo denke ich falsch?
>
> nirgendwo.
> So ist das nunmal und das findet sich so eigentlich auch in den meisten
> Quellen.

naja... ich lese ehr das Mantra RUNTER mit der Taktfrequenz...


> Gilt natürlich nur, wenn man anschließend auch in den Sleep Mode geht.

ja klar: das setze ich voraus - Joules kann man immer auch durch NOPs 
verbrauchen

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

deine Rechnung ist schon richtig. Das Ergebnis ist natürlich nur 
insofern relvant als das der μC die gesamte "Nichtproduktive" Zeit in 
einem Sleepzustand verbringt.

Sascha

von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> chris schrieb:
>> Gilt natürlich nur, wenn man anschließend auch in den Sleep Mode geht.
>
> Wenn das nicht möglich ist, spielen nämlich die Umschaltspitzen der
> MC-internen CMOS Buffer die grosse Rolle. Da sie während der
> Umschalterei kurz mal High- und Lowside gleichzeitg offen haben, sind
> viele Umschaltereien (hoher Takt) stromfressender als wenige (niedriger
> Takt). Im Dauerbetrieb kann es also sinnvoll sein, Takt zu senken.

Verstanden.

Nur würde ich versuchen energiesparende SW so zu entwerfen, dass man so 
oft und lange wie möglich im tiefstmöglichen sleep mode ist. Ich bin mir 
auch im Klaren, dass dies nicht immer möglich ist.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
sigma9 schrieb:
> Man liest überall, dass man das Ziel eines möglichst geringen
> Energieverbrauchs eines uC erreicht, indem man dessen Taktfrequenz so
> klein wie möglich wählt.

Veraltet. Bei modernen µCs macht man "Race-to-Idle", d.h. man taktet 
kurz hoch für Berechnung und schickt danach den µC in einen tiefen 
Sparmodus möglichst ganz ohne Takt (oder z.B. Uhrenquarz Takt).

Daher haben moderne µCs auch einen komplexen Clock (und teilweise sogar 
Power-) Tree, damit nur aktuell benötigte Logik mit Strom und Takt 
versorgt wird.

Deine Berechnung oben berücksichtigt nicht die Zeit in der der µC nix zu 
tun hat. Wenn Dir 100kHz für die Aufgabe reichen würde das bei 20 MHz 
den größten Teil der Zeit ausmachen. Preisfrage: In welchem Zustand ist 
der µC in dieser Zeit?

von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> chris schrieb:
>> Gilt natürlich nur, wenn man anschließend auch in den Sleep Mode geht.
>
> Wenn das nicht möglich ist, spielen nämlich die Umschaltspitzen der
> MC-internen CMOS Buffer die grosse Rolle. Da sie während der
> Umschalterei kurz mal High- und Lowside gleichzeitg offen haben, sind
> viele Umschaltereien (hoher Takt) stromfressender als wenige (niedriger
> Takt). Im Dauerbetrieb kann es also sinnvoll sein, Takt zu senken.

[nach einigem Nachdenken...]
Verstanden - technisch gesehen. Ich verstehe deine Erklärung und würde 
auch so denken. Nur: das Datenblatt sagt was anderes...
In meinem Beispiel hatte ich 100 Takte angenommen, doch das gleiche gilt 
auch für 1000, 10000, 1, ... beliebig viele Takte: die Absolutzahlen 
ändern sich, das Verhältnis nicht. Also schließt man: AUCH im 
Dauerbetrieb ist hoher Takt effizienter.

???

von Tilo R. (joey5337) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Im Prinzip ja, aber...

der Stromverbrauch eines uC ensteht (im Wesentlichen) aus 3 Teilen
a) statische Verluste (z.B. durch dünne Isolation oder fixe 
Arbeitspunkte im uC) - diese sind technologieabhängig und der Strom fix 
oder proportional zur Betriebsspannung.

b) "Umladeverluste" dadurch, dass bei jedem Signalwechsel die 
Gate-Kapazitäten im Chip umgeladen werden müssen. Die benötigte Ladung 
ist ungefähr proportional zur Betriebsspannung und der druchschnittliche 
Strom damit proportional zum Takt

c) der "Kurzschlussstrom" beim Umschalten (ich weiß nicht wie viel das 
konkret ist, aber dier Hersteller versuchen, den so gering wie möglich 
zu halten)

Niedriger Takt spart Strom bei b), dafür dauert es aber auch länger.

Intel kam daher mal zum Schluss "Run to sleep" - also lieber schnell 
machen und früher schlafen gehen. In den winzigen Strukturgrößen 
moderner CPUs spielt der Strom aus a) eine nicht unerhebliche Rolle und 
im Sleep kann man Teile abschalten.

Für viele uC ist hauptsächlich b) entscheidend. D.h. bei gegebener 
Betriebsspannung ist es fast egal, ob man "run to sleep" macht oder eher 
langsamer taktet.

Mit niedrigerer Taktfrequenz kann man aber auch mit der Spannung runter. 
Und weil die Umladearbeit proportional U² ist, spart man mit niedrigerem 
Takt UND niedrigerer Spannung Leistung.

von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
?? schrieb im Beitrag #4802799:
>> energiesparende SW
>
> what?
>
> Versuchs lieber mit stromsparenden MCs.
> Habe so nen Bullshit noch nie in meinem Leben gelesen. Ihr Ökoheinis
> habt meines Erachtens einen an der Waffel, Sorry.


Vielen Dank für deinen freundlichen Ton.

Auch halte ich mich nicht für einen Öko-Heini: jeder kann das halten wie 
er will, ganz am Anfang sagte ich, es handelt sich um ein 
Verständnis-Problem.

Und ich sagte auch, dass ich den 328 als BEISPIEL nehme. Na klar gibt es 
andere die effizienter/stromsparender sind.
Und verzeihe bitte vielmals den Ausdruck "stromsparende SW". Dieses habe 
ich sehr ungeschickt als Abkürzung gewählt für "ein Design, in welchem 
sowohl Software als auch Hardware im Rahmen der gegebenen Möglichkeiten 
und Randbedingungen so konzipiert sind, dass die Batterielaufzeit meines 
Gerätes so lang wie möglich ist".

Ich hoffe, dass empfindest du nicht als Bullshit und wünsche weiterhin 
einen wunderschönen Abend!

von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rechne den Leerlauf (z.B. pro Sekunde) mal mit ein

https://www.mikrocontroller.net/articles/Sleep_Mode

wenn einmal pro Sekunde 100 Taktzyklen "verbraten" werden. Der ist 
nämlich auch abhängig von der Taktfrequenz ...

von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> sigma9 schrieb:
>> Man liest überall, dass man das Ziel eines möglichst geringen
>> Energieverbrauchs eines uC erreicht, indem man dessen Taktfrequenz so
>> klein wie möglich wählt.
>
> Veraltet. Bei modernen µCs macht man "Race-to-Idle", d.h. man taktet
> kurz hoch für Berechnung und schickt danach den µC in einen tiefen
> Sparmodus möglichst ganz ohne Takt (oder z.B. Uhrenquarz Takt).
>

das verstehe ich. Werde mal "race-to-idle" googlen (oder hast du ne gute 
Quelle zur Hand?)


> Daher haben moderne µCs auch einen komplexen Clock (und teilweise sogar
> Power-) Tree, damit nur aktuell benötigte Logik mit Strom und Takt
> versorgt wird.
>
> Deine Berechnung oben berücksichtigt nicht die Zeit in der der µC nix zu
> tun hat. Wenn Dir 100kHz für die Aufgabe reichen würde das bei 20 MHz
> den größten Teil der Zeit ausmachen. Preisfrage: In welchem Zustand ist
> der µC in dieser Zeit?



sorry, hatte ich am Anfang nicht explizit gesagt: ja natürlich sollen 
mögliche sleep modes so oft wie möglich ausgenutzt werden.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
>  Ihr Ökoheinis habt meines Erachtens einen an der Waffel, Sorry.

Wusstest du, dass das Online Lesen von Nachrichten umweltschädlicher 
ist, als eine gedruckte Zeitung zu lesen?

Das kommt daher, weil wir mit unseren Computern eine Menge Strom 
vergeuden.

Mein Netbook läuft auf den Webseiten von Conrad, Nickelodeon, Saturn und 
RP-Online regelrecht heiß. Während er bei der microcontroller.net Seite 
kalt bleibt.

Spätestens bei der Benutzung von Smartphones ist Schluss mit Lustig, 
wenn Apps viel Strom verbrauchen. Da geht es nicht um Öko, sondern um 
Komfort. Denn nicht jeder will einen Zusatzakku mit Kabel herum 
schleppen.

Wer viele Server betreibt (wie z.B. Amazon, Vodafone, IBM, SAP, etc) für 
den ist das auch ein wichtiges Thema, denn Strom kostet Geld.

Jeder Programmierer sollte sich mit dem Thema auseinander setzen. Das 
ist definitiv keine Spinnerei.

Bei Spielzeugen und anderen batteriebetriebenen Geräten ist das Thema 
ebenfalls keineswegs Unsinnig.

von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Im Prinzip ja, aber...
>
> der Stromverbrauch eines uC ensteht (im Wesentlichen) aus 3 Teilen
> a) statische Verluste (z.B. durch dünne Isolation oder fixe
> Arbeitspunkte im uC) - diese sind technologieabhängig und der Strom fix
> oder proportional zur Betriebsspannung.
>
> b) "Umladeverluste" dadurch, dass bei jedem Signalwechsel die
> Gate-Kapazitäten im Chip umgeladen werden müssen. Die benötigte Ladung
> ist ungefähr proportional zur Betriebsspannung und der druchschnittliche
> Strom damit proportional zum Takt
>
> c) der "Kurzschlussstrom" beim Umschalten (ich weiß nicht wie viel das
> konkret ist, aber dier Hersteller versuchen, den so gering wie möglich
> zu halten)
>
> Niedriger Takt spart Strom bei b), dafür dauert es aber auch länger.
>
> Intel kam daher mal zum Schluss "Run to sleep" - also lieber schnell
> machen und früher schlafen gehen. In den winzigen Strukturgrößen
> moderner CPUs spielt der Strom aus a) eine nicht unerhebliche Rolle und
> im Sleep kann man Teile abschalten.
>
> Für viele uC ist hauptsächlich b) entscheidend. D.h. bei gegebener
> Betriebsspannung ist es fast egal, ob man "run to sleep" macht oder eher
> langsamer taktet.
>
> Mit niedrigerer Taktfrequenz kann man aber auch mit der Spannung runter.
> Und weil die Umladearbeit proportional U² ist, spart man mit niedrigerem
> Takt UND niedrigerer Spannung Leistung.



Danke für die fundierten Ausführungen. Verstehe ich alles.
Nur sagt eben das Datenblatt (z.B. des 328) was anderes. In den dort 
abgedruckten Graphen für den Stromverbrauch fließen doch alle deine oben 
aufgelisteten Punkte mit ein (oder nicht??). Oder liegt es daran, dass 
das Design dieses uC dann doch schon etwas älter ist?

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Die Diagramme im Datenblatt geben keine Auskunft darüber, wie viele 
Befehle du mit wie viel Energie ausführen kannst. Sie zeigen nur die 
Stromaufnahme in Abhängigkeit der Taktfrequenz OHNE Schlaf-Phasen.

Die Schlaf-Zeiten hängen von deiner Anwendung ab, die kann das 
Datenblatt nicht berücksichtigen. Wie hoch die Stromaufnahme in diesen 
Phasen ist, steht auch im Datenblatt.

von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Die Diagramme im Datenblatt geben keine Auskunft darüber, wie
> viele Befehle du mit wie viel Energie ausführen kannst. Sie zeigen nur
> die Stromaufnahme in Abhängigkeit der Taktfrequenz OHNE Schlaf-Phasen.
>
> Die Schlaf-Zeiten hängen von deiner Anwendung ab, die kann das
> Datenblatt nicht berücksichtigen. Wie hoch die Stromaufnahme in diesen
> Phasen ist, steht auch im Datenblatt.


ja klar: schlafen spart immer am meisten...
und ja auch klar: es gibt Anwendungen, wo das nicht (oft) möglich ist.

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Wie üblich gibt es die eine richtige Antwort auch hier nicht.

Mikrocontroller sind üblicherweise keine reinen Rechenknechte, sondern 
sind gehalten, auch die reale Welt zur Kenntnis zu nehmen. Eine Welt, 
die sich nicht um das Tempo des µC schert, sondern die eigene 
Zeitvorstellungen hat.

Weshalb es nicht immer möglich ist, Aufgaben eines Mikrocontrollers mit 
reiner vom Takt des µC bestimmten Geschwindigkeit laufen zu lassen. Und 
es ist auch nicht immer möglich, tote Zeiten im stromarmen Modus zu 
verbringen.

Zwei Beispiele:

- Der 1-Wire Bus hat ein definiertes Timing und wenn man dafür nur 
Bitbanging einsetzt, dann ist der µC mindestens im untere Zeitrahmen des 
Timings permanent aktiv. Höherer Takt führt dann nur zu schnellerem 
Däumchendrehen in Warteschleifen.

- Wenn man den µC meist schlafen legt und hauptsächlich in Interrupts 
aktiv werden lässt, dann kann man darin Wartezeiten kriegen, die nicht 
vom Takt abhängen. Zeugs wie ADC/Referenz hochfahren, erste Wandlung 
verwerfen, zum asynchronen 32kHz Timer synchronisieren etc. Schneller 
als schnell genug kostet dann unnötig Strom.

Auch wenn es gelingt, alle inaktiven Zeiten Strom sparend zu verbringen: 
Wenn man einen präzisen Takt benötigt den Takt auch nicht abschalten 
kann, dann braucht allein der Oszillator schon proportional zum Takt 
Strom. Timer-Prescaler auch.

: Bearbeitet durch User
von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wie üblich gibt es die eine richtige Antwort auch hier nicht.

A. K. schrieb:
> Auch wenn es gelingt, alle inaktiven Zeiten Strom sparend zu verbringen:
> Wenn man den Oszillator nicht abschaltet, dann braucht allein der schon
> proportional zum Takt Strom. Timer-Prescaler auch.

Und?

Dieter F. schrieb:

> https://www.mikrocontroller.net/articles/Sleep_Mode

mal gelesen?

von A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Dieter F. schrieb:
> mal gelesen?

Und?

von Dieter F. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Natürlich wird auch für das Warten auf Ereignisse oder einen bestimmten 
Zeitpunkt Strom "verbraten" - irgendwie muss der MC ja auch das noch 
"abhandeln".

von sigma9 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wie üblich gibt es die eine richtige Antwort auch hier nicht.
>
> Mikrocontroller sind üblicherweise keine reinen Rechenknechte, sondern
> sind gehalten, auch die reale Welt zur Kenntnis zu nehmen. Eine Welt,
> die sich nicht um das Tempo des µC schert, sondern die eigene
> Zeitvorstellungen hat.
>
> Weshalb es nicht immer möglich ist, Aufgaben eines Mikrocontrollers mit
> reiner vom Takt des µC bestimmten Geschwindigkeit laufen zu lassen. Und
> es ist auch nicht immer möglich, tote Zeiten im stromarmen Modus zu
> verbringen.
>
> Zwei Beispiele:
>
> - Der 1-Wire Bus hat ein definiertes Timing und wenn man dafür nur
> Bitbanging einsetzt, dann ist der µC mindestens im untere Zeitrahmen des
> Timings permanent aktiv. Höherer Takt führt dann nur zu schnellerem
> Däumchendrehen in Warteschleifen.
>
> - Wenn man den µC meist schlafen legt und hauptsächlich in Interrupts
> aktiv werden lässt, dann kann man darin Wartezeiten kriegen, die nicht
> vom Takt abhängen. Zeugs wie ADC/Referenz hochfahren, erste Wandlung
> verwerfen, zum asynchrone 32kHz Timer synchronisieren etc. Schneller als
> schnell genug kostet dann unnötig Strom.
>
> Auch wenn es gelingt, alle inaktiven Zeiten Strom sparend zu verbringen:
> Wenn man den Oszillator nicht abschaltet, dann braucht allein der schon
> proportional zum Takt Strom. Timer-Prescaler auch.


sehr interessante Anmerkungen.
Klar: wenn die Aussenwelt Randbedingungen vorgibt, kann der uC nicht 
machen was er will...
Und du hast auch mit dem zweiten Teil recht: die wirklich 
energieeffizienteste Variante zu finden kann ziemlich komplex werden.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.