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...
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.
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.
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
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
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.
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?
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.
???
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.
?? 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!
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 ...
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.
> 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.
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?
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.
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.
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.
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".
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.
