ich habe den ATmega168P im Einsatz, den ich in verschiedenen Modi
betreibe:
* ständig aktiv mit 8MHz aus internem RC-Oszillator;
* ständig im Power-Down: Verbrauch bei 3V ca. 1µA;
* im Idel-Mode mit 250kHz (aus 8MHz) bei 3V und alle 2ms kurz aktiv
(durch Interrupt),
hier messe ich im Idel-Mode ca. 140µA und wenn Aktiv dann 235µA
(oszillographisch),
nach Datenblatt müsste ich im Idel auf ca. 20µA kommen
(Diagramm: "ATmega168PA: Idle Supply Current vs. Low Frequency
(0.1-1.0MHz)" )
und wenn Aktiv dann auf ca. 100µA
(Digramm: "ATmega168PA: Active Supply Current vs. Low Frequency
(0.1-1.0MHz)" ),
das sind ca. 120µA weniger als ich messen in beiden Modis,
Auszug aus meinem Code:
sleep_bod_disable();
power_all_disable(); // set Power Reduction Register PRR
ACSR = (1<<ACD); // Analog Comparator Disable
ADCSRA = 0; // disable ADC
ADMUX = 0; // disable internal Vref
MCUSR = 0; // clear all RESET-flags
WDTCSR |= (1<<WDCE) | (1<<WDE); WDTCSR = 0; // disable WatchDog
nur Timer0 wird aktiviert für den Interrupt alle 2ms,
alle nicht benutzen PIO's sind Input mit Pullup,
Stromabfluss über die PIO's kann ich messtechnisch ausschliessen;
? wie lassen sich die 120µA zuviel erklären ?
Hallo Stefan,
alle PIO's haben saubere Hi-/Low-Pegel,
habe auch den Strom aller PIN's gegen GND und VCC
(mit 1k in reihe als Schutz) gemessen,
keine Auffälligkeiten;
Warum Idle und nicht Sleep? Vielleicht weil noch I/O-Module laufen? Dann
sollten Sie sich mal "Table 30-5. Additional Current Consumption for the
different I/O modules (absolute values)" im Datenblatt des ATmega168P
(weshalb zitieren sie das des PA?) anschauen.
Wenn das nicht weiterhilft, ein Minimalprogramm schreiben, welches
exakt den zu untersuchenden Zustand abbildet, und hier vorstellen.
Idle weil sonst Timer0 nicht läuft,
Timer0 ist das einzige was aktiv ist (bzw. sein soll),
in der angegebenen Tabelle wird Timer0 mit 1,5µA bei 2V/1MHz angegeben;
Ich lese zwar 2.45 uA, aber egal, das macht den Kohl nicht fett.
Tja, dann sollte man ein vollständiges Programm haben, aber ich
persönlich kann es nur durchsehen, zum Ausprobieren fehlt mir ein
ATmega168P.
> alle PIO's haben saubere Hi-/Low-Pegel,> habe auch den Strom aller PIN's gegen GND und VCC
Ich wollte nicht wisse, ob die Ausgänge funktionieren.
Hat dein Mikrocontroller irgendwelche I/O Pins, die als Eingang (ohne
Pull-Up) konfiguriert sind und nicht beschaltet sind? Bedenke dabei,
dass alle I/O Pins standardmäßig Eingänge ohne Pull-Up sind.
an Hartmut:
Entweder machen wir beide denselben Fehler, oder es ist wirklich so,
vermutlich wegen des Sachverhalts, auf den der neue PIC-Freund hinwies.
An einem ATmega328P messe ich bei 3.0 V mit 8 MHz /32 und aktivem Timer0
gut 100 uA im Idle-Modus.
Einen Ausweg zeigte Carl Drexler auf, damit kommt man auf 1 uA im
Power-save-Modus.
* Uhrenquarz ist zu langsam, ich muß alle 2ms einen Zustand auswerten;
* "habe auch den Strom aller PIN's gegen GND und VCC":
damit habe ich versucht einen Stromabfluß durch die PIO's
festzustellen,
dem ist nicht so,
damit konnte ich auch feststellen daß kein Eingang offen ist;
? "Sachverhalts, auf den der neue PIC-Freund hinwies" ?
Hartmut schrieb:> (Digramm: "ATmega168PA: Active Supply Current vs. Low Frequency> (0.1-1.0MHz)" ),
Das ist aber für Quarz/Resonator, nicht für RC-Oszillator 8MHz/32.
Kann gut sein, der 8MHz Oszillator verbraucht die 120µA.
Setz dochmal den Teiler auf 256, ob sich da noch was verringert.
> Uhrenquarz ist zu langsam, ich muß alle 2ms einen Zustand auswerten;
Hi, damit war ja auch nicht gemeint, den Uhrenquarz als Taktquelle zu
verwenden, sondern den Timer2 mit Uhrenquarz im async. Modus zu
verwenden.
Heißt: Taktquelle ist immer noch interner RC, lediglich Timer2 wird
durch Uhrenquarz getaktet. Damit kann der Prozessor im tieferen
PowerSave-Modus schlafen und sich ungefähr alle 2ms durch
Timer2-Interrupt wecken lassen.
einen Quarz einstezen erhöht die Kosten,
aber die Fragestellung ist ja:
warum stimmt mein Stromverbrauch nicht mit der Doku überein?
@pada:
Diagramm-Vergleich
"Active Supply Current vs. Low Frequency (0.1-1.0MHz)"
5V/1MHz=800µA, 3,3V/1MHz=430µA;
"Active Supply Current vs. VCC (Internal RC Oscillator, 1MHz)"
5V/1MHz=900µA, 3,3V/1MHz=500µA;
kann das die Erklärung sein ?
2ms sind 'ne Ewigkeit. Mit einem Uhrenquarz bekommst Du, wenn Du das
Teil vernünftig programmierst, die Stromaufnahme des Controllers auf 50
Mikroampere effektiv oder sogar weniger. Tiefschlaf im Verhältnis zu
aktiver Zeit ist hierbei von Bedeutung. Bei ATMEL gibt es Appnotes zum
Stromsparen. In einer Anwendung sendet ein AVR minutenlang aus einem
100uF Kondensator über UART einen Datenrahmen. Schau Dir das einmal an,
das ist bedeutend hilfreicher als nackte Zahlen aus dem Datenblatt, die,
fehlinterpretiert wie in diesem Fall, gar nichts aussagen.
Bei 8MHz / 32 sind das 4us pro SingleCycle-Befehl. Ganz schön lange.
Interessant wäre es zu wissen, wieviele Assemblerbefehle effektiv in
einem
Zyklus durchlaufen. Evtl wäre es sinnvoller, die Taktung zu erhöhen,
damit die "aktive Zeit" sehr kurz ist. Bei der Anwendung bin ich mir
aber nicht sicher, ob sich die Effekte nicht aufheben oder
verschlimmbessern ;-)
In meiner Anwendung habe ich kein präzises Intervall gebraucht.
Da reichten "ungefähr" 60ms. Ob das dann 60 oder "nur" 50 sind, spielte
eher eine untergeordnete Rolle. Der Core war dabei im Tiefschlag
(Q-Oszilltor aus) und aufgewekt wurde der uC durch den WDT im IRQ-Modus.
Alles andere an Peripherie war bis auf einen PCINT (alternative
wakeup-Quelle) tot. Waren < 100uA und man konnte das Teil im Standby
problemlos > 30 Tage aus AAA-NiMH Akkus betreiben. Aktive Stromaufname
ca. 30..40mA für wenige Millisekunden.
Der Verbrauch eines AVR hat einen frequenzabhängigen und einen fixen
Teil. Wenn man also Strom sparen will, dann muß man schnell wieder
einschlafen. Oder so schnell wie möglich rechnen.
Nach DB für M168:
F_CPU. I@3.3V I/MHz
250kHz 160μA 640μA
16MHz 5000μA 313μA
Der langsam ausgeführte Befehl braucht also doppelt so viel Energie.
Wenn man aber "Busy Wait"s im Programm hat, die ja nicht kürzer werden,
weil man "schneller wartet", muß man anders rechnen, denn dann arbeitet
man ja keine fixe Anzahl Befehle mehr ab.
Dann gibt es eine Grenzfrequenz, unterhalb derer die Anzahl ausgeführte
Befehle nicht mehr abnimmt (weil alle Warteschleifen nur noch Null mal
durchlaufen werden. Dies ist dann der energieeffizienteste Takt.
