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.
:
Bearbeitet durch User
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?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.