Das CLKPR-Register und das Geheimnis der Stromaufnahme

[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

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

[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)