Das CLKPR-Register und das Geheimnis der Stromaufnahme

[thomas_st]

Kapitel 1: Das CLKPR-Register

Hallo zusammen,

ich beginne mal wieder mit einer kurzen Story. Vor ein paar Wochen mit einem befreundeten Cacher verabredet, um an einem seiner Caches eine RL-Stage zu installieren - das RL hatte er schon und war nun dabei etwas Tarnung drumherum zu bauen ... da kam der Anruf: die Tag-/Nachschwelle passt noch nicht (das RL wäre wohl nie in den Tagmodus gegangen) und ob man das nicht anpassen könnte. Also das alte Notebook mit dem alten seriellen Programmer eingepackt und los.

Tja und da saß ich nun. Der auf 128kHz getaktete Tiny ließ sich mit dem Programmer nicht ansprechen (keine Ahnung warum, früher war das kein Problem) und so endete das Ganze damit, dass ein neuer Tiny programmiert wurde und nun mit der originalen Taktfrequenz von ca. 1MHz im Baum hängt.

Aber nach diesen Problemen fiel mir doch wieder ein, was ich schon lange mal ausprobieren und für die RL nutzen wollte: das CLKPR-Register! Dieses Register hat eine ähnliche Aufgabe wie das CKDIV8-Fuse: es teilt den vom Oszillator bereitgestellten Takt runter, bevor daraus der µC-Takt erzeugt wird. Allerdings kommt das CLKPR-Register erst während der Programmlaufzeit zum tragen und es kann den Takt etwas feiner unterteilen (nicht nur 1:8, sondern von 1:2 bis 1:256 in allen Zweierpotenzen).

Hat jemand Erfahrungen mit diesem Register und hat es schon einmal genutzt? Folgende Hoffnung hatte ich damit jedenfalls: man lässt den µC auf den Werkseinstellungen (9,6MHz Oszill. (des Tiny 13) mit gesetzter CKDIV8-Fuse: Takt = 1,2MHz) und teilt den Takt erst im Programm durch Setzen des CLKPR-Registers weiter runter (ginge bis runter auf 37,5kHz). Damit hätte man beim Programmieren einen ordentlich flotten Tiny und während des Programmlaufs einen schön sparsamen. So dachte ich jedenfalls! Aber da hat mir Atmel einen Strich durch die Rechnung gemacht.

Die Experimente zum Runterteilen des Taktes habe ich mit einem Tiny 25 gemacht, da dieser ein CLKO-Pin besitzt, über den man den aktuellen µC-Takt von außen abfragen kann. Zunächst: das CLKPR-Register funktioniert perfekt. Man kann damit wunderbar den Takt während des Programmlaufs verändern und hoch oder runter setzen. Nur leider betrifft dieser Takt auch den Programmiermodus. Jedenfalls war es nichts mit "programmieren bei höherer Frequenz".

Mal ein Beispiel: der Tiny läuft mit dem 8MHz Oszill. des Tiny 25 ohne gesetztes CKDIV8-Fuse, wobei das CLKPR-Register im Programm auf 1:256 gesetzt wird. Damit müsste der Tiny im "Normalfall" mit 8MHz laufen (gemessen habe ich 8,42MHz) und nach setzen des CLKPR-Registers nur noch mit 31,25kHz (gemessen habe ich 32,1kHz). Soweit so gut. Allerdings sollte das Programmieren bis 8,42MHz/4 = 2,10MHz möglich sein. Es klappt allerdings nur bis zu einem Takt von ungefähr 8kHz! Offensichtlich wird beim Eintritt in den Programmiermodus das CLKPR-Register nicht gelöscht und der Tiny schwingt weiter mit 32kHz Damit waren meine Hoffnungen bzgl. "es ist doch alles so einfach" dahin.

Eine Lösung hätte ich jetzt mit Hilfe des Watchdog-Timers: Diesen initialisiere ich am Anfang und lasse ihn nach 8s einen Interrupt auslösen. Erst in dessen ISR wird dann das CLKPR-Register gesetzt, so dass ich nach einem RESET eben diese 8s Zeit habe, um mit dem Programmieren zu beginnen. Das klappt auch wunderbar, nur hätte ich es gerne einfacher gehabt.

Für mein RL-Programm würden die Änderungen folgendermaßen aus sehen (stark abgespecktes Listing, welches nur die Änderungen zeigt):

[...]
#include <avr/power.h>
[...]
BOOL fInitCLKPR;				// Wurde das CLKPR-Register schon initialisiert?
[...]
ISR(SIG_WATCHDOG_TIMEOUT)
{
    [...]
	if(!fInitCLKPR)
	{
		clock_prescale_set(clock_div_256);  // Hier wird as CLKPR-Register gesetzt
		fInitCLKPR = TRUE;
	}
    [...]
}
[...]
int main (void)
{
    [...]
	fInitCLKPR = FALSE;
    [...]
}

Vielleicht hat ja mal jemand das Bedürfnis einen AVR bis fast zum Stillstand zu verlangsamen. Jedenfalls kann man auf diese Art und Weise den Takt bis auf 500Hz runter bringen - an so einen langsamen Tiny kommt man nämlich normal kaum noch heran, wie AVR Studio einen wissen lässt:


Bild 1.1: Warnung AVR-Studio

Soweit zum CLKPR-Register und viele Grüße,
Thomas(_st)

 

[thomas_st]

Kapitel 2: Das Geheimnis der Stromaufnahme

Tja, wenn man die Möglichkeit hat den Takt des Tinys recht feinfühlig zu beeinflussen, kann man dies ja ausnutzen und den Stromverbrauch eines Reaktivlichtes in Abhängigkeit der Taktrequenz zu ermitteln - und dieses Ergebnis empfinde ich als recht interessant.

Für die Untersuchungen habe ich jetzt unser ganz normales RL genutzt, über ein RC-Glied die Versorgung stabilisiert und den Stromverbrauch mit einem DMM gemessen (meine Hoffnung ist, dass ich so den mittleren Strom bestimmt habe). Die Schaltung des Messaufbaus sieht so aus:


Bild 2.1: Schaltung

Das Ganze hab eich jetzt für den Tag- und den Nachmodus des RL mit und ohne Schlafenlegen des Tinys gemessen (mit und ohne "set_sleep_mode(SLEEP_MODE_PWR_DOWN); sleep_enable(); sleep_cpu();"). Hier die Ergebnisse:


Bild 2.2: Stromaufnahme mit 9,6 MHz Oszillator

Betrachten wir erstmal die Werte, die man erhält wenn der interne Oszillator mit 9,6MHz läuft. Mittels CLKPR-Registers kann man hier den Takt zwischen ca. 37kHz und 9,6MHz ändern. Die Welt ist noch in Ordnung, wenn man die Stromaufnahme ohne Schlafzyklen betrachtet (die gestrichelten Linien). Hier steigt sie mit steigendem Takt stark an und ist auch sonst um Größenordnungen größer als die, die der Tiny mit Schlafzyklen dazwischen benötigt. Auch erklärlich, wenn auch erstaunlich, ist die Stromaufnahme mit Schlafzyklen im Tagmodus (durchgezogene, gelbe Linie): sie ist unabhängig vom Takt. Zu erklären ist das wohl so: der µC nimmt aufgrund des höheren Taktes bei seiner Arbeit zwar mehr Strom auf, ist aber mit seiner Arbeit auch schneller fertig und kann sich wieder schlafenlegen - im Mittel heben sich beide Effekte auf und die Stromaufnahme bleibt gleich. Für mich erstmal nicht zu erklären ist die Stromaufnahme im Nachtmodus (blaue, durchgezogene Linie). Diese sinkt (!) mit steigendem Takt.


Bild 2.3: Stromaufnahme mit 128kHz Oszillator

Wenn man den internen Oszillator mit 128kHz laufen lässt, sieht die Sache noch interessanter aus: hier sinkt die Stromaufnahme unter Ausnutzung des Schlafmodusses im Tag- und im Nachtmodus mit steigendem Takt. Ob das Ganze irgendwie mit meinem RL-Programm zusammenhängt, habe ich nicht überprüft - für mich sieht es jedenfalls so aus, als ob ein Tiny mit maximalem Takt (9,6MHz) unter Ausnutzung des Schlafmodusses am stromsparensten ist. Einen Grund konnte ich dafür noch nicht ausmachen.

Vielleicht hat ja jemand eine Erklärung dafür, ansonsten würde ich empfehlen, den Takt nicht auf Biegen und Brechen runter zuschrauben - das bringt nur Probleme beim Programmieren mit sich und führt dazu, dass die Batterie viel zu flott leer gesaugt ist.

So weit für heute und viele Grüße,
Thomas(_st)

 

[Dr.Schmock]

Ein schöner Beitrag, der mich zum Grübeln gebracht hat!
Ich denke, ich weiß jetzt, woran es liegt.

Der Watchdog-Timer verwendet einen Oszillator, der unabhängig von der System-Clock-Frequenz ist. Dadurch bleibt die Dauer der Sleep-Perioden gleich, auch wenn man CLKPR verändert. Bei sinkender Frequenz wird aber die Periode im Active-Modus länger. Das Verhältnis SLEEP/ACTIVE wird also kleiner – der Stromverbrauch steigt.
Ist der Sleep-Modus aber ausgeschaltet, dann spielt die Watchdog keine Rolle und der Stromverbrauch steigt wie erwartet mit steigender Frequenz.


Angewendet auf das RL bedeutet das:

Beim Warten aufs Auslösen des RL (Tag und Nacht) sollte das Verhältnis SLEEP/ACTIVE möglichst groß sein. (Anders ausgedrückt: das Abfagen des ADC muss schnell gehen, um schnell wieder in den Sleep-Modus zurückzukehren.)
Die System-Clock-Frequenz sollte groß sein (zB. 1-8 MHz) und der Watchdog-Prescaler auch (->Sleep-Zeit lang).

Wird das RL ausgelöst, dann soll die unvermeidbare längere Blink-Zeit möglichst wenig Strom verbrauchen (vor allem bei Morse..).
CLKPR wird dafür mit einem größeren Wert beschrieben.
Also zusammengefasst:
Warten --> (ausgelöst) --> CLKPR rauf --> Blinken --> CLKPR runter --> warten


Ich hoffe, ich habe zu so später Stunde nichts fehlinterpretiert.
Ohne deine Nachforschungen wär ich nicht draufgekommen, darüber nachzudenken.

Grüße

 

[stonewood]

Die CKDIV8-Fuse wird übrigens über CLKPR realisiert. Wenn die Fuse gesetzt ist wird CLKPR beim Reset auf 8 gesetzt. Viel mehr passiert da nicht.
(hab ich mal im Datenblatt von einem Tiny gelesen - sinnigerweise haben sie den Absatz beim Tiny13 weggelassen ...)

Man kann den Prescaler dann nach wie vor im Programm ändern, sollte dann nur bedenken daß z.B. CLKPR=4 den Tiny schneller macht als er eigentlich laut Fuses ist.

 

[thomas_st]

Ein schöner Beitrag, der mich zum Grübeln gebracht hat!

Dies war u.a. die Absicht

Ich denke, ich weiß jetzt, woran es liegt.

Der Watchdog-Timer verwendet einen Oszillator, der unabhängig von der System-Clock-Frequenz ist. Dadurch bleibt die Dauer der Sleep-Perioden gleich, auch wenn man CLKPR verändert. Bei sinkender Frequenz wird aber die Periode im Active-Modus länger. Das Verhältnis SLEEP/ACTIVE wird also kleiner – der Stromverbrauch steigt.

Ich denke, dass Du hier einen Effekt übersehen hast: in den kürzeren ACTIVE-Phasen ist der Stromfluss höher, so dass sich beides gegenseitig aufheben könnte - das war die Erklärung für den von der Taktfrequenz unabhängigen Stromfluss im Tagmodus mit Schlafphasen.

Ich versuche es anderes zu erklären. Wozu benötigt ein µC eigentlich Strom? Ich sehe da nur das Umladen der Gate-Kapazitäten beim Schalten der Transistoren. Wenn man den µC zwischen den aktiven Phasen schlafen lässt, ist die Anzahl der Schaltvorgänge unabhängig von der Taktfrequenz und damit ist eigentlich auch die Stromaufnahme davon unabhängig.

Anders, wenn man den µC nicht pennen lässt: hier muss er zwischen den aktiven Phasen Warterunden drehen in denen Schaltvorgänge Strom benötigen. Genau, wie von Dir beschrieben:

Ist der Sleep-Modus aber ausgeschaltet, dann spielt die Watchdog keine Rolle und der Stromverbrauch steigt wie erwartet mit steigender Frequenz.

Warum der Stromfluss nun im Nachtmodus absinkt ... Könnte es mit dem ADC zusammenhängen?

Viele Grüße,
Thomas(_st)

 

[thomas_st]

Die CKDIV8-Fuse wird übrigens über CLKPR realisiert. Wenn die Fuse gesetzt ist wird CLKPR beim Reset auf 8 gesetzt. Viel mehr passiert da nicht.

Stimmt! Hätte ich irgendwo erwähnen können.

(hab ich mal im Datenblatt von einem Tiny gelesen - sinnigerweise haben sie den Absatz beim Tiny13 weggelassen ...)

Nöp, haben sie nicht :

If CKDIV8 is programmed, CLKPS bits are reset to “0011”, giving a division factor of eight at start up.

Man kann den Prescaler dann nach wie vor im Programm ändern, sollte dann nur bedenken daß z.B. CLKPR=4 den Tiny schneller macht als er eigentlich laut Fuses ist.

Das ist in jede Richtung zu sehen: wenn man am CLKPR Register Änderungen vornimmt, ist das CKDIV8 Fuse ab dieser Stelle ohne Bedeutung.

Viele Grüße,
Thomas(_st)

 

[huzzel]

Klingt nett
Und hier der Bascom Code

CONFIG CLOCKDIV = constant

Auf wieviel Jahrzehnte kann so die Laufzeit eines RL vergrößert werden .
Aber Spaß beiseite, so ist vllt noch Potenzial für kleiner Batterien drin

 

[Dr.Schmock]

Ich bin bei der Erklärung davon ausgegengen, dass der Sleep-Modus immer viel weniger Strom braucht als der Active-Modus, selbst wenn man die Frequenz (theoretisch) gegen 0 bringen würde.
Laut Datenblatt ist das auch so (tiny24/44 Datenblatt)
Der Brownout-detektor alleine braucht schon 20uA, der Oszillator auch noch mal was.
Die beiden werden ja im Power-Down-Modus abgestellt.


Von daher kann die Rechnung mit der Erklärung

Ich versuche es anderes zu erklären. Wozu benötigt ein µC eigentlich Strom? Ich sehe da nur das Umladen der Gate-Kapazitäten beim Schalten der Transistoren. Wenn man den µC zwischen den aktiven Phasen schlafen lässt, ist die Anzahl der Schaltvorgänge unabhängig von der Taktfrequenz und damit ist eigentlich auch die Stromaufnahme davon unabhängig.

...nicht aufgehen.

@huzzel:
Etwasl Potential zum Energiesparen ist schon drin.
Man kann den Verbrauch im Warte-Modus jetzt auch in der Nacht unter 5uA drücken und somit mit einer Knopfzell (CR2032) eine Lebensdauer von 5 Jahren erreichen!! Ohne LED auslösen, allerdings

Viele Grüße
Tobi

 

[Dr.Schmock]

Hab noch etwas rumgerechnet:

Wenn die LED 20mA verbraucht
und das RL 500mal im Jahr ausgelöst wird
und pro Auslösen eine Gesamt-Leuchtdauer der LED von 5 sek entsteht..

..dann verbraucht das RL ca. 14 mAh Strom fürs Blinken pro Jahr

Hinzukommen 44 mAh für den Wartemodus pro Jahr (bei 5uA).
->Zusammen 58mAh pro Jahr
Die Knopfzelle (CR2032) hat 210 mAh,

es ergibt sich eine Lebensdauer von 3,6 Jahren.
Nicht schlecht, oder?

 

[thomas_st]

Auf wieviel Jahrzehnte kann so die Laufzeit eines RL vergrößert werden .

Noch nicht ausgerechnet - allerdings hatte ich für das normale RL mit AA Zellen mit angenommenen 2000mAh ohne Auslösung der LEDs und ohne Selbstentladung mal was von 36 Jahren abgeschätzt .

Der Brownout-detektor alleine braucht schon 20uA, der Oszillator auch noch mal was.
Die beiden werden ja im Power-Down-Modus abgestellt.

Der BrownOut-Detektor ist egal (da abgeschaltet) aber den Oszillator selbst hatte ich nicht mit betrachtet. Kann man den Stromverbrauch des µC im IDLE-Mode den Oszillatoren zuschreiben (CPU und Flash werden zumindest nicht mehr mit einem Takt versorgt)? Der ist nämlich mit ungefähr 1mA bei Vcc=3V / T=25°C / f = 9,6MHz beträchtlich hoch. Jep, das könnte die Erklärung sein und im Tagmodus macht es sich nicht bemerkbar, da der Anteil der aktiven Phase von vielleicht 0,001% auf 0,0001% sinkt - also so oder so sehr klein ist.

Von daher kann die Rechnung mit der Erklärung

Ich versuche es anderes zu erklären. Wozu benötigt ein µC eigentlich Strom? Ich sehe da nur das Umladen der Gate-Kapazitäten beim Schalten der Transistoren. Wenn man den µC zwischen den aktiven Phasen schlafen lässt, ist die Anzahl der Schaltvorgänge unabhängig von der Taktfrequenz und damit ist eigentlich auch die Stromaufnahme davon unabhängig.

...nicht aufgehen.

Na die geht auf, wenn der Anteil des Oszillators gering ist - eben im Tagmodus.

Viele Grüße,
Thomas(_st)

 

[stonewood]

(hab ich mal im Datenblatt von einem Tiny gelesen - sinnigerweise haben sie den Absatz beim Tiny13 weggelassen ...)

Nöp, haben sie nicht :

If CKDIV8 is programmed, CLKPS bits are reset to “0011”, giving a division factor of eight at start up.

Doch, haben sie. Ich hab hier 'ne Rev. I, da fehlt der Absatz. In der Rev. E ist das aber tatsächlich drin. Selbst im Datenblatt zum Tiny13A, Rev. A ist das nicht drin. Schau da mal jeweils ins Kapitel 6.4.2 CLKPR – Clock Prescale Register. Bei der Rev. E ist das noch nicht numeriert, einfach nur wie Du oben geschrieben hast betitelt.

 

[thomas_st]

(hab ich mal im Datenblatt von einem Tiny gelesen - sinnigerweise haben sie den Absatz beim Tiny13 weggelassen ...)

Nöp, haben sie nicht :

If CKDIV8 is programmed, CLKPS bits are reset to “0011”, giving a division factor of eight at start up.

Doch, haben sie. Ich hab hier 'ne Rev. I, da fehlt der Absatz. In der Rev. E ist das aber tatsächlich drin.

In Rev. H ist es auch noch drin (das war meine aktuellste Version bislang). Aber Atmel ist schon lustig, da erstellen sie eine neue Version des Datenblatts, blähen dabei die Datei beinah aufs doppelte auf und dann fehlt da mehr als vorher Ok, ich habe jetzt das DB natürlich nicht komplett durchgearbeitet, so könnte es noch irgendwo anders auftauchen ... aber in der aktuellen Version fehlt der Passus :hilfe:

Auf die Idee, das dieser Passus später hinzu gefügt wurde, bin ich schon gekommen und habe daher die Errata durchgesehen; auf die Idee, dass sie es später vergessen, bin ich aber nicht gekommen

Selbst im Datenblatt zum Tiny13A, Rev. A ist das nicht drin.

Das habe ich nicht, da es die entsprechenden Schaltkreise noch nicht auf meinen Tisch geschafft haben

Viele Grüße,
Thomas(_st) - man muss mit allem rechnen ps:

 

[waste1]

Für mich erstmal nicht zu erklären ist die Stromaufnahme im Nachtmodus (blaue, durchgezogene Linie). Diese sinkt (!) mit steigendem Takt.

Hallo Thomas,

ich nehme an, dass der ADC-Clock bei deinen Messungen sich genauso verändert wie der Takt des µC. Da der ADC konstant etwa 200µA zieht, wirkt sich das bei niedrigerem Takt stärker aus, da er längere Zeit läuft. Bei höherem Takt ist der ADC kürzere Zeit eingeschaltet und verbraucht im Mittel weniger Strom.

Ich verwende bei meinen RLs auch nicht den 128kHz Oszillator und lasse die Fusebits wie ab Werk. Erst im Programm bei der Initialisierung wird dann der Takt auf etwa 500 bis 600 kHz eingestellt.

Viele Grüße
Waste1

 

[thomas_st]

ich nehme an, dass der ADC-Clock bei deinen Messungen sich genauso verändert wie der Takt des µC.

Jep. Das Verhältnis ADC-Takt zu "Haupt"-Takt hatte ich nicht verändert.

Da der ADC konstant etwa 200µA zieht, wirkt sich das bei niedrigerem Takt stärker aus, da er längere Zeit läuft. Bei höherem Takt ist der ADC kürzere Zeit eingeschaltet und verbraucht im Mittel weniger Strom.

Stimmt. Wenn die Stromaufnahme des ADC unabhängig von Takt ist, wäre dass neben der Stromaufnahme des Taktgenerators die zweite Erklärung für die sinkende Stromaufnahme mit steigenden Takt.

Ich verwende bei meinen RLs auch nicht den 128kHz Oszillator und lasse die Fusebits wie ab Werk. Erst im Programm bei der Initialisierung wird dann der Takt auf etwa 500 bis 600 kHz eingestellt.

Warum auf diesen Bereich? Nach den Messungen sieht es ja erstmal so aus, als wenn maximaler Takt ideal wäre.

Viele Grüße,
Thomas(_st)

 

[waste1]

Ich verwende bei meinen RLs auch nicht den 128kHz Oszillator und lasse die Fusebits wie ab Werk. Erst im Programm bei der Initialisierung wird dann der Takt auf etwa 500 bis 600 kHz eingestellt.

Warum auf diesen Bereich? Nach den Messungen sieht es ja erstmal so aus, als wenn maximaler Takt ideal wäre.

Weil ich den ADC nicht zu sehr übertakten wollte und bei der Frequenz der Stromverbrauch (5-6µA) ausreichend niedrig war.

 

[thomas_st]

Ich verwende bei meinen RLs auch nicht den 128kHz Oszillator und lasse die Fusebits wie ab Werk. Erst im Programm bei der Initialisierung wird dann der Takt auf etwa 500 bis 600 kHz eingestellt.

Warum auf diesen Bereich? Nach den Messungen sieht es ja erstmal so aus, als wenn maximaler Takt ideal wäre.

Weil ich den ADC nicht zu sehr übertakten wollte und bei der Frequenz der Stromverbrauch (5-6µA) ausreichend niedrig war.

Der ADC hat doch einen eigenen Prescaler mt dem man auch einen z.B. 8MHz Takt auf ADC verdauliche 50 bis 200kHz runter teilen kann. Damit ist der ADC dann zwar wieder länger an und eine Einsparung von dieser Seite kaum noch zu erwarten, aber der Oszillator wird dann entsprechend kürzer aktiviert, was eine Einsparung bringen würde (und der säuft IMO recht ordentlich )

Viele Grüße,
Thomas(_st)

 

[waste1]

Der ADC hat doch einen eigenen Prescaler mt dem man auch einen z.B. 8MHz Takt auf ADC verdauliche 50 bis 200kHz runter teilen kann. Damit ist der ADC dann zwar wieder länger an und eine Einsparung von dieser Seite kaum noch zu erwarten, aber der Oszillator wird dann entsprechend kürzer aktiviert, was eine Einsparung bringen würde (und der säuft IMO recht ordentlich )

Viele Grüße,
Thomas(_st)

Wenn der ADC mit konstantem Clock läuft, dann ist er auch immer eine konstante Zeit eingeschaltet. Während dieser Zeit läuft auch parallel der Oszillator des Prozessors mit, ohne Programmausführung. Je höher da die Frequenz ist, umso mehr Strom wird verbraucht. Es bringt also nichts hier den Prozessortakt schneller zu machen.

In der anderen Phase, also während der Programmausführung ohne ADC-Messung ist es egal, weil sich da die kürze Laufzeit mit dem höheren Stromverbrauch bei höherer Frequenz aufhebt.

Bei festem ADC-Clock gibt es also ein Optimum für den günstigsten Stromverbrauch und zwar wenn der Prescaler für den ADC auf Minimum (also 2) steht. Wenn man also den ADC innerhalb der vorgeschriebenen 50 - 200 kHz Rate betreiben will, dann sollte der Prozessortakt nicht höher als 400 kHz sein. Ich erlaube mir eine kleine Übertaktung, deshalb läuft bei meinen RLs der ATtiny13 mit 600 kHz und der ATtiny45 mit 500 kHz.

Viele Grüße
Waste1

 

[thomas_st]

Wenn der ADC mit konstantem Clock läuft, dann ist er auch immer eine konstante Zeit eingeschaltet. Während dieser Zeit läuft auch parallel der Oszillator des Prozessors mit, ohne Programmausführung.

Ich glaube bei der untersuchten Variante, habe ich den µC nach Start des ADCs schlafen gelegt und per ADC-Fertig IRQ aufwecken lassen. Sicher bin ich mir aber nicht, da ich dieses Verhalten später rausgenommen habe.

In der anderen Phase, also während der Programmausführung ohne ADC-Messung ist es egal, weil sich da die kürze Laufzeit mit dem höheren Stromverbrauch bei höherer Frequenz aufhebt.

Nur teilweise, wie ich gelernt habe:
1.: der Oszillator läuft immer gleich schnell und verbraucht dabei immer gleichviel Strom, unabhängig davon, wie schnell der µC läuft. Der µC-Takt wird ja erst nach dem Oszillator durch den Prescaler runter geteilt.
2.: der Oszillator selbst schluckt ganz ordentlich (ich habe so den Eindruck: im mA-Bereich) - also viel im Vergleich zur CPU des µC
3.: der summarische Verbrauch der CPU ist relativ unabhängig von der Taktfrequenz: die Anzahl der notwendigen Takte und der Strom, der für das Umladen der Gate-Kapazitäten notwendig ist ist gleich (wie von Dir oben ja schon geschrieben und was auch meine Vermutung gewesen wäre)
Aber: 4.: wenn die CPU schon nach der Hälfte der Zeit mit ihrer Arbeit fertig ist und sich wieder schlafen legt, wird eben auch der Strom hungrige Oszillator nach der Hälfte der Zeit wieder ausgeschaltet. ... und damit spart man dann Strom.

Bei festem ADC-Clock gibt es also ein Optimum für den günstigsten Stromverbrauch und zwar wenn der Prescaler für den ADC auf Minimum (also 2) steht. Wenn man also den ADC innerhalb der vorgeschriebenen 50 - 200 kHz Rate betreiben will, dann sollte der Prozessortakt nicht höher als 400 kHz sein.

Das gilt, wenn der Stromverbrauch des ADCs einen großen Anteil am Gesamtstromverbrauch besitzt. Das kann ich jetzt nicht aus meinen Messungen direkt ableiten, da ich den ADC-Takt nicht im erlaubten Bereich gehalten hab (sondern ihn mit steigendem µC-Takt auch erhöht habe) und weiterhin µC zwischen den Messungen schlafen geschickt habe (allerdings in diesem Fall mit laufendem Oszillator).

Ich werde die Messungen entsprechend nochmal wiederholen.

Viele Grüße,
Thomas(_st)

 

[waste1]

Okay, mach nochmal Messungen mit konstantem ADC-Clock, vielleicht wird es dann klarer.

Meine Messungen sind schon über 2 Jahre her. Ich kann mich nicht mehr so genau an alle Details erinnern. Ich hatte aber damals die Stromaufnahme über einen Shunt mit dem Oszilloskop gemessen. Da konnte ich den zeitlichen Verlauf der Stromaufnahme sehen und herausfinden wer/was wieviel Strom braucht.

Ich bin mir auch nicht sicher, ob ich den alternativen Clock-Oszillator damals getestet habe. Wenn ja, dann hat er aber nicht so viel Ersparnis gebracht, denn sonst hätte ich ihn verwendet.

2.: der Oszillator selbst schluckt ganz ordentlich (ich habe so den Eindruck: im mA-Bereich) - also viel im Vergleich zur CPU des µC

So viel kann es nicht sein, denn nach deinen Messungen (Nachtmodus/ohne Sleep) kommt man bis auf 150µA runter und da läuft der Oszillator immer mit. Aber grundsätzlich hast Du Recht, der Oszillator verbraucht auch Strom.

Wenn man schon 5µA (Tagmodus) und 6µA (Nachtmodus) erreicht hat, dann sind die noch möglichen Stromsparpotentiale sowieso sehr gering, da laut Datenblatt der ATtiny13 im Power-Down mit Watchdog Timer schon etwa 4µA braucht.

Viele Grüße
Waste1

 

[thomas_st]

Okay, mach nochmal Messungen mit konstantem ADC-Clock, vielleicht wird es dann klarer.

Ich hätte nicht gedacht, dass der ADC so ins Gewicht fällt. Aber was Du weiter unten feststellst: die 150µA die ohne schlafenden Tiny erreicht werden können, stimmen natürlich. Und damit kann der Oszillator gar nicht so viel schlucken, wie ich vermutet hatte.

Ich habe aber die Messung dennoch gemacht (bin halt neugierig) und siehe da: da ist im Nachtmodus ein Optimum bei ungefähr 1MHz (ADC-Takt hatte ich (bis auf die letzten zwei Messungen mit einem Haupttakt < 150kHz) fest auf 75kHz gelassen).
.

Ich hatte aber damals die Stromaufnahme über einen Shunt mit dem Oszilloskop gemessen.

Das hatte ich auch kurz angedacht, allerdings aufgrund der großen Unterschiede der interessanten Zeitbereiche (Stromaufnahme der CPU bei 9,6MHz im Zeitbereich von 100ns / Spanne eines kompletten Schlafzyklus im Tagmodus ca. 8s) wieder verworfen.

Ich bin mir auch nicht sicher, ob ich den alternativen Clock-Oszillator damals getestet habe. Wenn ja, dann hat er aber nicht so viel Ersparnis gebracht, denn sonst hätte ich ihn verwendet.

Was meinst Du mit "alternativ"? Den 4,8MHz Oszillator oder den 128kHz Oszillator?

So wie es jetzt aussieht, ist das RL mit den Werkseinstellungen, das sparsamste. So groß sind die Differenzen zwar nicht; aber man muss sich nicht zu 128kHz oder gar 16kHz Takt quälen -> das bringt nichts.

Viele Grüße,
Thomas(_st)