Forum: Mikrocontroller und Digitale Elektronik EEPROM-Zugriff bei Spannungstrennung


von Johannes (menschenskind)


Lesenswert?

Hallo
Ich habe hier nen MP3-Player, der regelmäßig den aktuellen Filepointer 
in den EEPROM schreiben soll, damit die Wiedergabe nach dem 
Wiedereinschalten auch genau an der Position fortgesetzt wird.
Da ich den Player aber ausschalte, in dem die Spannungsversorgung 
unterbrochen wird, wollte ich fragen, ob das evtl. zu Komplikationen 
führen kann.
Der Filepointer soll in 2 Variablen gespeichert werden:
FP und FP_Backup

Damit soll sichergestellt werden dass die Information trotzdem verfügbar 
ist, auch wenn die Spannungsversorgung genau während des 
Eeprom-Schreibzugriffs getrennt wird, und der eine Wert dadurch ungültig 
wäre.

Ich bitte um eure Meinungen.
Dankesehr

von Christian U. (z0m3ie)


Lesenswert?

Du solltest dringend die brown out detection anschalten, wenn du am 
schreiben bist wärend die Spannung einbricht, kann im EEPROm so ziemlich 
alles passieren wenn die aus ist. Falsche werte, falsche Adressen ...

von eeprom (Gast)


Lesenswert?

Um den EEPROM zu schonen solltest du auch NUR bei Spannungseinbruch in 
diesen die Pointer speichern. Ein EEPROM hält Normalerweise lediglich 
100.000 Schreibzyklen. Wenn du nun während des normalen Betriebes immer 
die 2 Variablen schreibst, kannst du dir ausrechnen wann der nicht mehr 
funktioniert. Also immer nur im Notfal speichern.

von eeprom (Gast)


Lesenswert?

Ach so, die brown out detection löst bei Einbruch einen Interrupt aus. 
Wenn du an der Spannungsversorgung einen großen C hast, kannst du noch 
so ca. 100ms arbeiten und deine Variablen sichern.

von Falk B. (falk)


Lesenswert?

@  eeprom (Gast)

>Ach so, die brown out detection löst bei Einbruch einen Interrupt aus.

Nöö, die macht knallhart einen RESET.

>Wenn du an der Spannungsversorgung einen großen C hast, kannst du noch
>so ca. 100ms arbeiten und deine Variablen sichern.

Jaja, so einfach ist es auch wieder nicht.

Eher so.

http://www.mikrocontroller.net/articles/Speicher#EEPROM_Schreibzugriffe_minimieren

MFG
Falk

von Ulrich P. (uprinz)


Lesenswert?

Viele PKW-CD Player machen das so. Dabei muss man zwei Dinge beachten:

Die EEPROMs haben auch nur eine begrenste Anzahl Schreibzugriffe pro 
Zelle. Das sind zwar 100k bis über 1Mio aber immerhin. Dadurch, dass Du 
zur Sicherheit aber schon zwei 'Images' abwechselnd beschreibst, damit 
wenigstens das aus der vorletzten Sekunde noch gültig ist, hast Du diese 
Anzahl also schon verdoppelt. Du musst Dir nur eine Prüfsumme und einen 
Zähler überlegen, damit Du erkennen kannst, welches der beiden Images 
das aktuellere ist und ob es gültig ist. Für den Zähler kann man ja auch 
einfach den Sector-Counter nehmen. Bei MP3 gibt es dann eine Varianz von 
rund 10s, sonst muss man noch den Pointer auf das richtige MP3-Frame 
innerhalb der Datei ablegen.

Bei ATMEL steht ganz klar im Datenblatt der AVRs, und ich tippe dass das 
auch für EEPROMS generell gilt, dass man bei Brown-/Blackout gefährdeten 
Schaltungen die Adresse 0 des EEPROMs nicht beschreiben sollte. Das 
liegt daran, dass anscheinend beim Spannungsabfall die Addressregister 
des EEPROMs vor der Programmierspannung zusammen klappen. Die 
Programmierspannung wird intern durch eine Ladungspumpe aufrecht 
erhalten. Das hat zur Folge, dass mitten im Schreiben einer Zelle die 
Adressen auf 0 kippen und die Ladungspumpe den Inhalt der ebenfalls 
zusammen brechenden Datenregister auf die Adresse 0 ablädt.

Generell ist es ratsam eine eigene recht empfindliche BrownOut Erkennung 
an einen Interrupt zu hängen und dann die verbleibende Zeit für ein 
komplettes Abspeichern aller nötigen Informationen über ein paar 
Pufferkondensatoren zur verfügung zu stellen.

Noch als Tip:
Die meisten EEPROM Treiber, die als open-Source existieren, legen nach 
dem Schreiben einer Page ( 32 Bytes) ins EEPROM eine feste Pause von 
10ms und mehr ein. Das ist unnötig:
1. Alle modernen EEPROMs sind bereits mit 5ms zufrieden.
2. Nutzt man ACK-Polling, stellt man fest, dass das EEPROM bereits nach 
1.5ms - 2.5ms wieder aufnahmebereit ist. Dieser Wert hängt von Spannung, 
Temperatur und Alter des EEPROMs ab.

ACK-Polling bedeutet das EEPROM nach dem Schreiben so lange zu 
adressieren, bis es wieder mit ACK antwortet. Wärend des Schreibens 
nimmt das EEPROM nämlich sein I2C vom Bus und reagiert nicht auf seine 
Adresse.
Je nach Bus-Speed kann man also in 1/4 bis 1/10 der Zeit seine Daten 
gesichert haben, was die Kondensatoren für die Brown-Out Überbrückung 
deutlich verkleinert.

Gruß, Ulrich

von markusj (Gast)


Lesenswert?

Man könnte ja auch einfach via ADC die Spannung überwachen und bei einer 
gewissen Schwellspannung vor dem Brown-Out den Filepointer sichern und 
dann in den Powerdown gehen ... und somit erst wieder aufwachen, wenn 
die Stromversorgung neu angeschlossen wurde. (Akkuwechsel)

mfG
Markus

von Johannes (menschenskind)


Lesenswert?

Hallo
Erstmal Danke für die vielen hilfreichen Antworten.
Das einfachste wird wohl sein, ich erzeuge eine Datei auf der SD-Karte, 
von der die MP3-Daten nämlich kommen und schreibe dort die gewünschten 
Informationen rein.
Da ist aber auch wieder die Frage: Welche Komplikationen können im 
schlimmsten Fall auftreten?

Aber nen großen Zeh (hihi) werd ich wohl auch noch reinlöten. Wie groß 
sollte der denn mindestens sein? Hab ja auch noch 2 Lautsprecher 
dranhängen (2x0,4W)

von Ulrich P. (uprinz)


Lesenswert?

Hi!

Ich würde nicht die SD-Card verwenden, um die Daten abzuspeichern. Du 
kannst nicht sicherstellen, an welcher Stelle die Daten abgelegt werden. 
Flash-Speicher haben eine deutlich geringere Schreibzyklen Anzahl. 
Außerdem kann niemand vorhersagen, was eine SD-Card macht, wenn sie 
schreibt, wärend ihr der Saft abgedreht wird. Im schlechtesten Fall 
zerrschießt es Dir die interne Sektor-Referenz, die die Card zum um 
schiffen defekter Sektoren braucht, und dann ist sie Schrott.

Sorry, aber ein ADC ist eine denkbar schlechte Lösung, weil man diesen 
erst einmal abfragen muss. Damit verliert man sehr viel Zeit. Eine 
brown-Out Erkennung ist dagegen sehr einfach über einen handelsüblichen 
Reset-Controller zu machen oder eine kleine Schaltung aus zwei 
Transistoren oder einem OP-Amp.

Nochwas:
Ich würde den leistungsteil des Players und den Logikteil trennen. Also 
entweder separat versorgen oder wenigstens über ein paaar Dioden 
trennen. Die PA kann bei Stromausfall natürlich sofort den betrieb 
einstellen, aber der Logikteil sollte natürlich noch weiter versorgt 
werden, damit er seine Daten sichern kann. Wenn da voll-integrierte 
Chips am Werk sind, also VLSI und sein Kopfhörer-Ausgang, dann kann man 
auch die Brown-Out Erkennung mit seinem Reset verdrahten. Setzt man 
einen der Class-D Chips ein, um etwas Wumms auf die Boxen zu bringen, 
wird die Brown-Out leitung an deren Inhibit Eingang angeschlossen, dann 
knallt es auch nicht in den Boxen.

Trotzdem sollte CPU und EEPROM über einen eigenen Pfad seine versorgun 
erhalten, weil man damit einiges an Störungen aus dem Analogteil fern 
halten kann. Und mann gewinnt mit ein paar 100µF gleich genug zeit für 
das Sichern der nötigen Infos ins EEPROM. Außerdem hat man eine simple 
Referenz für die Brown-Out Erkennung, denn die Versorgung vor dem Regler 
für die CPU fällt eben deutlich schneller ab als an der CPU selber. Hier 
reicht dann eventuell einfach ein Widerstandsteiler, ggf. ein Transistor 
für die Flankensteilheit am Interrupt-Eingang.

Einfach: Überwache die 12V aus dem Netzteil, brechen die auf 10V ein, 
sichere Deine Daten. Bis die auf 6.5V ( für einen Low-Drop-5V Regler) 
gefallen sind, ist noch Zeit zum Sichern.

Gruß, Ulrich

von Johannes (menschenskind)


Lesenswert?

Hallo Ulrich,
Danke für die wertvollen Tipps, ich hätt bestimmt ne Weile gebraucht, 
bis ich mir die ganzen Sachen angelesen hätte.

Du meinst also einen separaten Spannungsregler für den Atmega und einen 
für den VS1001?
Da ich ja ne SD-Karet einsetze, und auch der VS1001 3,6 Volt maximal 
bekommen darf, betreibe ich mein ganzes System mit 3,3V. Wandlung von 
5V. Da ist der Spannungsfall leider nicht so groß. Müsste aber trotzdem 
irgendwie gehen.

Stimmt, ich brauch ja wirklich nur die Daten in den EEPROM schreiben, 
wenn's kritisch wird. Da werd ich mir mal die 2. Schaltung hier( 
http://www.mikrocontroller.net/articles/Speicher#EEPROM_Schreibzugriffe_minimieren 
) ansehen.

Wie meinst du das "über ein paar Dioden trennen"? Einfach in den 
positiven Zweig eine in Reihe?

Bis dann

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

Ulrich P. schrieb:
> Sorry, aber ein ADC ist eine denkbar schlechte Lösung, weil man diesen
> erst einmal abfragen muss.

Aber der Analogvergleicher ist eventuell geeignet. Der kann einen 
Interrupt auslösen.

von Ulrich P. (uprinz)


Lesenswert?

Hi!

@Christian: Hey, gute Idee, der Comparator im AVR kann ja direkt einen 
IRQ auslösen.

@Johannes:
Also in meinem Fall hatte ich keinen Akku, daher habe ich die 5V über 
einen Reset-Controller überwacht. Eine Diode brauchte ich nicht, weil 
die CPU, SD und VS direkt mir 3.3V über einen kleinen DC/DC versorgt 
wurden. Das sparte die Widerstandkaskaden oder Spannungsanpassungen für 
SD und VS. Außerdem war ein ATmega32 mit 8MHz schnell genug um die Daten 
aus der SD in den VS zu schaufeln.

Habe zur Sicherung der Abbruchstelle einfach das interne EEPROM aus dem 
AVR genommen.

Ich kenne Dein Design nicht. Du kannst entewder eine Shottky-Diode in 
Reihe vor Deinen 3.3V Wandler/Regler setzen und dort mit ein paar uF 
abpuffern.
Im Datenblatt Deines 3.3V Reglers sollte aber ein Hinweis stehen, ob der 
Rückspannungsfest ist. Also was er tut, wenn am Ausgang eine höhere 
Spannung als am Eingang anliegt. (5V sind schon weg, aber 3.3V liegen 
noch gepuffert vor). Einige nehmen das nur eine Zeit lang schadlos hin. 
Anderen ist das egal und wieder andere schließen dann Ausgang nach 
Eingang kurz. Letztere würden die Diode erfordern, denn sonst entladen 
sie die 3.3V in Richtung der abfallenden 5V.
Da hilft nur lesen und einfach mal ausprobieren. Ich halte einen DC/DC 
eh für die beste Lösung wenn man lange von einem Akku haben will.

Gruß, Ulrich

von Johannes (menschenskind)


Lesenswert?

nene, ich betreibe meinen Player über ein Netzteil (ist ja auch kein 
mobiles Gerät). Denn unter Volllast verbraucht die Kiste fast 100mA.
Den Analogvergleicher werd ich mir mal näher anschauen.

Jo, mein Mega32 läuft auch mit den internen 8MHz. Ab welcher 
Taktfrequenz benötigt der denn die 5V Versorgungsspannung?

von Ulrich P. (uprinz)


Lesenswert?

Johannes Hofmann schrieb:
> Jo, mein Mega32 läuft auch mit den internen 8MHz. Ab welcher
> Taktfrequenz benötigt der denn die 5V Versorgungsspannung?

Ab mehr als 8MHz wenn ich das richtig im Kopf habe. Bei 8MHz und drunter 
kann man direkt mit 3.3V arbeiten.

Wenn Du ein Steckernetzteil verwendest, dann schalte doch am Eingang 
deines Players erst einmal eine Diode, rein schon als verpolschutz, 
falls man mal das falsche Netzteil werwendet, oder bei den ganzen 
Billig-Wandwarzen mit den Adapter-Steckern den passenden verpolt 
aufsteckt. Parallel zu dieser Diode kommt eine zweite kleine Diode, die 
diese Eingangsspannung über Widerstände herunter geteilt auf den 
Comparator schickt. Hinter der großen Diode kommen die 
Pufferkondensatoren und die DC/DC Wandler.

Zieht man das Netzteil ab, oder schaltet man Aus, fällt zuerst die 
Eingangsspannung ab. Das erzeugt einen IRQ am Comparator. Deine Software 
merkt sich einfach, welchen Datei und welchen Sektor aus der Datei sie 
zuletzt an den VLSI geschickt hat. Welche Datei, kann man schon bei der 
Auswahl selbiger im EEPROM abspeichern. Den Sektor speicherst Du aber 
erst, wenn der Comparator-IRQ kommt.

Noch etwas:
Du kannst nicht verhindern, dass Du mal die SD-Card tauschst, wenn das 
Gerät nicht eingesteckt ist. Du willst auch nicht umständlich dazu 
gezwungen werden, die Karte erst abzumelden, bevor Du eine andere 
einsteckst. Also musst Du erkennen, ob die Karte beim wieder Einschalten 
immer noch die selbe ist, von der zuletzt ein Lied gespielt wurde.
Also musst Du herausfinden, ob die Karte gewechselt wurde.
Außerdem kann es sein, dass Du den Inhalt der Karte geändert hast. Also 
reicht es für eine Identifizierung nicht, nur den Kartennamen 
(Laufwerksnamen) zu erkennen, sondern Du musst eine Prüfsumme über das 
Kartenverzeichnis ziehen. Sonst wird es sehr kompliziert.
Außerdem bennent nicht jeder seine Karte um, wenn man also mal ein paar 
Karten aus dem gleichen Stapel gekauft hat, dann haben die alle den 
gleichen Namen.
Der aufwändigere Weg wäre es, die Datei anhand ihres Namen zu 
identifizieren und sich den relativen Sektor der Datei zu merken. Dann 
kan man auch Dateien hinzufügen oder löschen ohne den Autostart 
durcheinander zu bringen. Dann muss man aber auch zusätzliche Prüfungen 
unterbringen, etwa, ob die Datei ausgetauscht wurde. Wenn die dann 
kürzer ist, gibt es nämlich merkwürdige Geräusche.

Bei dem VLSI sollte es aber reichen, einfach den Sektor mitten aus der 
Datei zu senden. Das MPG Frame, dass am Anfang nicht vollständig sein 
muss, weil es ja bereits im vorhergehenden Sektor beginnt, wird 
ignoriert.

Ach, ehe ich es vergesse... Man kann die Daten auch laufend und schnell 
abspeichern, wenn man anstelle eines EEPROMs einfach ein FRAM verwendet. 
Diese gibt es für I2C mit einem EEPROM kompatiblen Gehäuse. Sie behalten 
ihren Inhalt auch ohne Versorgung, sind aber schneller als EEPROMs. Sind 
etwas teurer, aber einfacherer zu handhaben.

Gruß, Ulrich

von Peter D. (peda)


Lesenswert?

Ulrich P. schrieb:
> Sorry, aber ein ADC ist eine denkbar schlechte Lösung, weil man diesen
> erst einmal abfragen muss. Damit verliert man sehr viel Zeit.

Du hast aber sehr seltsame Ansichten von "viel":
- ADC auslesen (8Bit reicht): 1 Zyklus
- Wert vergleichen: 1 Zyklus
- Springen: 2 Zyklen
- nächste Wandlung starten: 2 Zyklen
- und zurück zu den anderen Tasks für mindestens die Wandlerzeit

Also schlappe 6 Zyklen, da lacht Dich die CPU einfach nur aus.


Peter

von Johannes (menschenskind)


Lesenswert?

Uff, ja das ist allerdings ein ganz schöner Batzen, den ich da noch an 
Arbeit reinstecken muss.

@Ulrich
Wenn mein Atmega den VS initialisiert, dann knackt es kurz im 
Lautsprecher. Weißt du, wie ich da Abhilfe schaffen kann?
Wenn ich die Spannung wegschalte knackt es übrigens überhaupt nicht. 
Wenigstens was :)

von Ulrich P. (uprinz)


Lesenswert?

Peter Dannegger schrieb:
> Du hast aber sehr seltsame Ansichten von "viel":
> - ADC auslesen (8Bit reicht): 1 Zyklus
> - Wert vergleichen: 1 Zyklus
> - Springen: 2 Zyklen
> - nächste Wandlung starten: 2 Zyklen
> - und zurück zu den anderen Tasks für mindestens die Wandlerzeit
>
> Also schlappe 6 Zyklen, da lacht Dich die CPU einfach nur aus.

Hi Peter!

Das Problem ist nicht, dass das ADC Auslesen nicht schnell genug ist, 
sondern dass das System mit dem Datenschaufeln von der SD zum VLSI 
beschäftigt ist und deswegen nur alle paar Millisekunden Zeit hat mal 
nachzusehen, ob es sich retten muss. Diese paar Millisekunden muss man 
also dem Sicherungsprozess hizuaddieren bei der Auslegung der 
Puffer-Elkos.

Bei einem Comparator-IRQ kommt der Alarm wenige Taktzyklen später 
automatisch.

Außerdem führt ATMEL in seinen APP-Notes auf, wie man durch Abschalten 
des ADCs ein paar mA sparen kann. Wird der ADC nicht anderweitig durch 
die Software benutzt, kann  man also die Überbrückungszeit allein 
dadurch schon verlängern, bzw. die Elkos noch etwas kleiner auslegen.

Gruß, Ulrich

von Ulrich P. (uprinz)


Lesenswert?

Johannes Hofmann schrieb:
> Wenn mein Atmega den VS initialisiert, dann knackt es kurz im
> Lautsprecher. Weißt du, wie ich da Abhilfe schaffen kann?

Hi!

Ich habe es nicht mehr im Kopf, aber es gibt in der App-notes von VLSI 
einen Hinweis dazu, welche Register man in welcher Reihenfolge am besten 
initialisiert, damit der Plopp nicht auftritt.

Gruß, Ulrich

von Peter D. (peda)


Lesenswert?

Ulrich P. schrieb:
> Diese paar Millisekunden muss man
> also dem Sicherungsprozess hizuaddieren bei der Auslegung der
> Puffer-Elkos.

Das EEPROM Schreiben dauert ja schon 1,8ms pro Byte, da muß man also 
nicht mit ms geizen.
Nur alle 10ms abzufragen, sollte daher keinen riesen Elko bewirken.

Man kann aber durchaus öfter ne AD-Wandlung als Inline-Funktion ins 
Datenschaufeln dazwischen schieben, die CPU wird bestimmt noch 6 Zyklen 
Luft haben.


> Außerdem führt ATMEL in seinen APP-Notes auf, wie man durch Abschalten
> des ADCs ein paar mA sparen kann.

Das bezweifle ich.
Z.B. der ADC des ATTiny24 braucht 88µA bei 3V, die Ersparnis kann daher 
nicht "ein paar mA" betragen.


Peter

von Ulrich P. (uprinz)


Lesenswert?

Peter,

Hast ja Recht, es im Grunde gleich, ob man es halb-automatisch per ADC 
oder vollautomatisch per Comparator macht. Die erreichbaren 
Einsparpotentiale bei Software oder Elkos sind zugegeben eher 
theoretischer Natur.

Die Lösung das per Comparator in einem eigenen Stück Code, ausgelöst 
durch einen IRQ zu machen war für mich die logischere, gekapseltere 
Lösung. Sie verlangt nicht, etwas mehr oder weniger Zeitkritisches 
andauernd zu berücksichtigen und verunstaltet daher den Code nicht mit 
versprengten CheckVin(); Aufrufen.

Normalerweise würde man in einer zentralen State-Machine alle 
Transitionen von einem State zum anderen sauber durchspielen, also von 
Play nach Next, Next nach Play, Play nach Stop, u.s.w.
Hier würde man auch bei einem Power-Knopf einen State bauen, der das 
System geordnet herunter fährt.

Beim Comparator IRQ muss das System aber nicht erwarten, dass es wieder 
zurück kommt, also muss dieser keine Rücksicht auf andere IRQs nehmen. 
Hier kann man also möglichst schnell Backlight abdrehen, VLSI, LCD und 
SD in Power-Off und dann die paar Infos noch ins EEPROM.

Die ganzen Probleme hat man übrigens nicht, wenn man die Daten anstatt 
in ein EEPROM einfach in ein FRAM schreibt. Da kann man sekündlich alle 
aktuellen Laufzeitinformationen hin schieben und fertig. Der BrownOut 
vom Chip kann dann wieder aktiviert werden und es müssen weder größere 
Puffer-Elkos noch überhöhte Netzteilspannungen für eine Pufferung her 
halten. Schreibt man die Infos in 2 Pages, kann eine beim Ausfall ruhig 
geschrottet werden, man startet dann nicht mehr bei der zuletzt 
gespielten Sekunde, sondern der davor. Das stört niemanden.

Gruß, Ulrich

von Johannes (menschenskind)


Lesenswert?

In dem Tutorial steht was von ner Schaltschwelle von VCC/2.
Wo finde ich denn diese Angabe im Datenblatt des ATmega?
Bei 3,3V wären es dann ja dann 1,65 gell? Also zur Sicherheit 1,7V.

von Falk B. (falk)


Lesenswert?

@  Johannes Hofmann (menschenskind)

>In dem Tutorial steht was von ner Schaltschwelle von VCC/2.

Ja.

>Wo finde ich denn diese Angabe im Datenblatt des ATmega?

Nirgendwo. Das ist aber defacto fast immer so bei CMOS. Natürlich +/- 
5%, deshalb will ein AVR auch mind. 60% Vcc sehen, um WIRKLICH ein High 
zu erkennen und max. 20% Vcc um ein LOW zu erkennen.

>Bei 3,3V wären es dann ja dann 1,65 gell?

Ja.

> Also zur Sicherheit 1,7V.

Kann auch in die andere Richtung gehen. Rechne mit Vcc/2 +/-10% und gut.

MFG
Falk

von Johannes (menschenskind)


Lesenswert?

Noch mal ne Frage: Welche Funktion hat denn  R3 in den Schaltungen?

von Falk B. (falk)


Lesenswert?

R3 ist ein Pull-Down, vor allem in der 1. Schaltung wichtig. Wenn 
nämlich jemand einfach den Stecker abzieht, hängt das Pin für die 
Signalisierung in der Luft und schaltet nicht. In der 2. Schaltung mit 
Spannungsteiler ist er eigentlich überflüssig.

MfG
Falk

von Johannes (menschenskind)


Lesenswert?

So hab's heute mal probiert, aber irgendwie spinnt jetzt mein ATmega 
nach wohl misglücktem EEPROM-Zugriff.

Ich hab jetzt mal den Strommesser drangehängt. Der ist im absoluten 
Nullbetrieb aller Elemente bei 50 mA
Das dürfte wohl zu viel sein.
Aber wo geht denn da die Energie rein?
Hab in der Hauptroutine nur die Initialisierung drin und dann ne leere 
for(;;)-Schleife
der atmega macht also nix
Den VS1001 hab ich mittels power down-Signal schlafen gelegt.
Ach ja ich hab noch nen 7414er Schmitt-Inverter als Entpreller 
dranhängen. Den abgeklemmt sind es schon mal 9mA weniger.

Fällt euch dazu was ein?

von Johannes (menschenskind)


Lesenswert?

Ich hab jetzt mal 700uF vor den Spannungswandler gehängt.
Bei Aufruf des Interrupt für die Spannungstrennung sollte dann mal ganz 
kurz eine LED blinken. Macht sie nicht :(
Wahrscheinlich ist der Stromhunger so groß, dass die Kondensatoren 
gleich leer sind.
Jetzt ist halt die Frage, gehören die Kondensatoren, die ja dem ATmega 
noch den Restsaft für die EEPROM-Speicherung bereitstellen sollen also 
vor oder nach den Spannungswandler?

von Tobias Hagemeier (Gast)


Lesenswert?

Nur soviel zum Stromverbrauch: Die leere For-Schleife verbraucht so viel 
Energie wie jedes andere Programm auch. Intern wird die For-Schleife in 
ganz normal Assembler-Befehle übersetzt, die der µC dann abarbeitet. Ob 
diese Befehle was sinnvolles machen oder nicht ist ziemlich egal, so 
wird der µC halt die selben 2-3 Befehle unendlich oft hintereinander 
ausführen und damit den Stromverbrauch auf solche Werte treiben.
Wenn du wirklich wissen willst wieviel der µC im absoluten Minimum 
(obwohl er eingeschaltet ist) verbraucht, musst du ihn in den 
Schlaf-Modus schicken (dazu siehe Datenblatt) und sämtliche Peripherie 
abschalten (ADC, Pull-Ups, ..).

- Tobi

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
Noch kein Account? Hier anmelden.