Guten Morgen,
beim Lesen des Datenblatts (ATtiny85:
https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-2586-AVR-8-bit-Microcontroller-ATtiny25-ATtiny45-ATtiny85_Datasheet.pdf)
weiß ich nicht, wie ich die Diagramme zum Stromverbrauch verstehen muss
(Kapitel 22, ab Seite 172).
Wenn ich einen internen oder externen Takt von z.B. 8 MHz verwende,
schaue ich natürlich auf die Kurve von 8 MHz.
Aber wie ist es, wenn ich den Takt intern auf z.B. 1 MHz runter teile?
Gilt dann das Diagramm für 8 MHz oder muss ich bei 1 MHz schauen, weil
der Takt ja runter geteilt wurde?
Oder gilt keines der Diagramme, weil der Fall mit dem Taktteiler
irgendwie eine Mischung ist?
Vielleicht kann mir jemand einen Tipp geben.
Besten Dank!
Tim
Hallo,
maßgebend ist der Arbeitstakt nach Prescaler, in deinem Fall die 1MHz
und nicht zu vergessen, weil viel entscheidender, die Betriebsspannung.
Mit Ub kannst du bei 1MHz bei Bedarf weiter runtergehen.
Die Stromaufnahme hängt fast linear von der Taktfrequenz am, weil bei
jedem Takt ein Häppchen Strom verbraucht sind.
Dazu kommt die feste Takt-Unabhängige Stromaufnahme von
a) Watchdog, falls eingeschaltet (3 bis 7 µA)
b) Brown-Out Detektor, falls eingeschaltet (15 bis 25 µA)
c) ADC, kann man abschalten (150 µA)
d) Oszillator
e) Diverse Leckströme, stark Temperaturabhängig (0,05 bis ca 1µA)
Vielen Dank für die Erklärungen, jetzt weiß ich, in welches Diagramm ich
schauen muss.
Die nicht benötigten Module wie ADC usw. habe ich auch schon
abgeschaltet.
Eine bisher ungeklärte Frage ist aber, wie ich mit dem Takt noch weiter
runter gehen kann. Per Register (CLKPR) kann der Prescaler ja noch
vergrößert, also der Takt verringert werden.
Das Problem: In der Arduino-IDE kann ich für den ATtiny85 als kleineste
Frequenz 1 MHz bzw. 128 kHz einstellen. Mit dem Prescaler hätte ich gern
250 kHz eingestellt, das reicht für meine Anwendung allemal und würde
noch etwas mehr Batterie sparen.
Leider funktioniert das Programm dann nicht mehr, vermutlich wegen den
eingebundenen Bibliotheken.
Ich habe auch schon einige Varianten wie z.B.
1
#define F_CPU 250000UL
oder
1
#ifdef F_CPU
2
#undef F_CPU
3
#define F_CPU 1000000L
4
#endif
versucht, alles ohne Erfolg.
Naja, wahrscheinlich wird es mir nicht gelingen, die letzten paar uA
einzusparen...
Oder gibt es eine Möglichkeit, die Arduino-IDE dazu zu bringen, dass sie
noch andere Frequenzen zur Auswahl bietet?
Wenn du den Mikrocontroller mit dem 128 kHz Oszillator taktest, wird die
ISP Schnittstelle so langsam, dass viele Programmieradapter damit
versagen.
Tim schrieb:> hätte ich gern 250 kHz eingestellt> Leider funktioniert das Programm dann nicht mehr, vermutlich wegen den> eingebundenen Bibliotheken.
Was genau heißt denn in deinem Fall "funktioniert nicht mehr"?
> #define F_CPU 250000UL
F_CPU muss mit der tatsächlichen Taktfrequenz überein stimmen, weil der
Wert verwendet wird, um Baudraten und Timings zu berechnen. F_CPU wird
normalerweise nicht im Quelltext eingestellt (dann ergibt sich nämlich
die Frage: in welchem Quelltext?), sondern per Kommandozeilenparameter
an den Compiler übergeben. Auch bei Arduino.
Bedenke, dass alle drei Oszillatoren (128 kHz, 8 Mhz und Quarz) ungefähr
gleich viel Strom aufnehmen, wenn sie laufen.
Es macht fast keinen Unterschied, ob du einen 16 Mhz Quarz durch 128
teilst oder den 128 kHz Oszillator verwendest.
Aber der Quarz hält seine Frequenz viel genauer ein.
Manchmal kann es Sinn machen, mit maximaler Frequenz zu arbeiten (z.B.
der Tiny85 kann maximal 16,5MHz intern(?)), aber dafür dann umso längere
Schlafphasen einzulegen.
Zumindest hält man so die Reaktionszeiten möglichst klein.
EAF schrieb:> Manchmal kann es Sinn machen, mit maximaler Frequenz zu arbeiten (z.B.> der Tiny85 kann maximal 16,5MHz intern(?)), aber dafür dann umso längere> Schlafphasen einzulegen.> Zumindest hält man so die Reaktionszeiten möglichst klein.
Jain. Leider ist es nämlich so, dass bei diesen Dingern mit PLL-Takt
zwar der eigentliche Taktgenerator sehr schnell wieder da ist, die PLL
aber einige Zeit braucht, bis sie wieder einen stabilen Takt zu liefern
vermag.
Die nötige Aufwachzeit liegt irgendwo zwischen reinem RC-Takt und
Quarztakt, aber auf jeden Fall sehr deutlich über dem reinen RC-Takt.
Sprich: die Idee, mittels höherem Takt schneller wieder schlafen gehen
zu können und/oder kürzere Responsezeiten zu haben, kann deutlich nach
hinten losgehen...
Stefan Frings:
> Bedenke, dass alle drei Oszillatoren (128 kHz, 8 Mhz und Quarz) ungefähr> gleich viel Strom aufnehmen, wenn sie laufen.>> Es macht fast keinen Unterschied, ob du einen 16 Mhz Quarz durch 128> teilst oder den 128 kHz Oszillator verwendest.
Dieses "fast" wollte ich denn doch quantifiziert haben:
S. Landolt schrieb:> Dieses "fast" wollte ich denn doch quantifiziert haben:
OK, macht doch einen deutlichen Unterschied. Das hatte ich falsch in
Erinnerung. Danke für die Korrektur.
Zum Vergleich wäre der 8 Mhz R/C Oszillator in deiner Auflistung noch
hilfreich gewesen.
Stefan Frings:
> Zum Vergleich wäre ... noch hilfreich gewesen.
Also eigentlich wäre das ja Ihre Aufgabe gewesen! (und vielleicht
messe ich ja auch falsch)
S. Landolt schrieb:> Also eigentlich wäre das ja Ihre Aufgabe gewesen!
Das stimmt. Ich habe die Infos allerdings nicht im Datenblatt gefunden,
nur die Gesamt-Stromaufnahme mit bestimmten Oszillatoren.
Danke für deine Hilfe, wo hast du die Angaben gefunden?
EAF schrieb:> Manchmal kann es Sinn machen, mit maximaler Frequenz zu arbeiten> (z.B.> der Tiny85 kann maximal 16,5MHz intern(?)), aber dafür dann umso längere> Schlafphasen einzulegen.> Zumindest hält man so die Reaktionszeiten möglichst klein.
Meine Rede (s.o.).
Ist meist die bessere Lösung, den Prozessor in Pausen schlafen zu legen
- sofern man ein Signal (z.B. Interrupt) hat, das diesen wieder
aufweckt.
Wimre braucht so'n Tiny 4 zusätzliche Takte um wieder auf Trab zu
kommen. Diese paar Takte sind in den meisten Fällen schnell wieder
reingeholt - gegenüber einem Kontroller, der mit "angezogener Bremse"
werkeln muss.
Wär das meine Projekt, würde ich mir das, unter Berücksichtigung aller
Nebenbedingungen, aber noch mal genauer ansehen.
Hallo,
interessante Diskussion, da muss ich offenbar noch einiges überdenken...
Trotzdem nochmal zur ursprünglichen Frage:
Stefan schreibt (Beitrag oben mit dem Screenshot der Compiler-Ausgabe),
dass man die CPU-Frequenz dem Compiler mitteilen muss statt sie irgendwo
in den Code zu schreiben. Das ist sicher richtig.
Aber wie mache ich das in der Arduino-IDE?
Und wie bekomme ich die Ausgabe, wie sie im Screenshot gezeigt wird? Ich
habe zwar in den Einstellungen die "Ausführliche Ausgabe" aktiviert,
bekomme aber nicht angezeigt, das dem Screenshot ähnelt. Jedenfalls
finde ich nichts über die verwendete CPU-Frequenz und andere
Compiler-Optionen.
Tim schrieb:> Aber wie mache ich das in der Arduino-IDE?
Da steht die Frequenz, wie auch die Fuses, in der betreffenden
boards.txt Datei.
Für manche Boards sind darin auch Menüeinträge definiert, um die
Frequenz in der IDE auswählen zu können.
Die Datei kann man ändern.
Sollte aber besser eine boards.local.txt daneben legen, welche die
unerwünschten Parameter überschreibt und neue hinzufügt.
