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 ?
Haben alle Eingänge einen sauberen High oder Low Pegel? Offene unbenutzte Eingänge verbrauchen mehr Strom.
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.
Laut Datenblatt: "A sine wave generator with rail-to-rail output is used as clock source." auch erfüllt?
Kann Timer0 durch Timer2 im Async-Mode ersetzt werden? Mit Uhrenquarz? Dann geht auch mehr als IDLE.
> 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.
langsammer als 250kHz kann ich nicht gehen, aber bei 500kHz ist der Activ- und Idle-Strom gösser als bei 250kHz;
> 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.
:
Bearbeitet durch User
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.
Bitte 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.