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
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 ...
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.
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.
@ 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
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
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
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)
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
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
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.
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
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?
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
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
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 :)
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
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
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
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
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.
@ 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
Noch mal ne Frage: Welche Funktion hat denn R3 in den Schaltungen?
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
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?
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?
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.