Ich habe ein kleines Mikrocontroller Project. Die 5V Versorgungsspannung kann über einen Schalter an- und ausgeschaltet werden. Nun würde ich gerne einen Zustand der sich ca. 1mal pro Sekunde ändert merken. Kontinuierlich schreiben sind zu viele Schreibzyklen fürs EEPROM. Also muss der Wert geschrieben werden sobald die Versorgungsspannung ausgeschaltet wird. Nun ist die Frage wie man das am besten im Detail umsetzt. Eine Option wäre natürlich: Per Kondensator noch ein bisschen Zeit verschaffen, den Spannungsabfall erkennen und dann speichern. Aber das klingt nach einer Menge Timing und herum probieren. Andere Option könnte sein, dass der Schalter quasi nur zum Anschalten genutzt wird (Latching), der Mikrocontroller erkennt den Schalter Status, wenn der wieder auf aus ist schreibt er ins EEPROM und schaltet sich dann selber aus. Irgendwelche Vorschläge wie man das am besten umsetzen könnte? Gruss, Torsten
Torsten C. schrieb: > Aber das klingt nach einer Menge Timing und herum probieren. Für mich hat da immer Analyse und Berechnung ausgereicht. Zum Speichern eines einzelnen Bytes musst du gerade mal dafür sorgen, dass die Betriebsspannung für 10ms noch nicht unter den Brownout Pegel fällt. > Andere Option könnte sein, dass der Schalter quasi nur zum Anschalten > genutzt wird (Latching), der Mikrocontroller erkennt den Schalter > Status, wenn der wieder auf aus ist schreibt er ins EEPROM und schaltet > sich dann selber aus. Und was passiert bei einem Stromausfall? > Nun würde ich gerne einen Zustand der sich ca. 1mal pro Sekunde ändert > merken. Du könntest auch extern ein serielles SRAM anschließen und mit einem Goldcap oder eine Lithiumzelle puffern. Das hat dann nch viel, viel mehr Platz...
:
Bearbeitet durch Moderator
Torsten C. schrieb: > Eine Option wäre natürlich: Per Kondensator noch ein bisschen Zeit > verschaffen, den Spannungsabfall erkennen und dann speichern. Genau so. > Aber das klingt nach einer Menge Timing und herum probieren. Nö, die Dauer, die eine EEprom Zelle zu beschreiben braucht ist im DB Deines uC genau definiert. Ebenso der Stromverbrauch für die Dimensionierung des C. Bsp: Vor dem Spannungsregler 470uF parallel. Dann ebenfalls vor dem Spannungsregler einen Spannungsteiler vorsehen (so, daß die max Vadc nicht überschritten werden) und die Spannung via ADC überwachen. Dann hast Du alle Zeit der Welt, Dein EEprom zu beschreiben. Das habe ich so bei meiner Zimmerbeleuchtung realisiert, die immer den letzten Zustand beim Lichtausschalten (primär) speichert. Lothar M. schrieb: > noch nicht unter den Brownout Pegel fällt. Das könnte für das EEprom schon zu knapp werden, daher vor dem Spannungsregler messen.
:
Bearbeitet durch User
Oder ein FRAM benutzen. Das hat so viele Schreib- und Lesezyklen (ja, die zählen da mit), das man hundert Jahre lang jede Sekunde lesen kann ohne das es knallt. Und das ist nur der garantierte Wert...
Jens M. schrieb: > Oder ein FRAM benutzen. Das finde ich dafür Overkill. Es braucht nur einen Spannungsteiler, einen ADC Eingang und einen etwas größeren Elko als standardmäßig vorgesehen.
Andreas B. schrieb: > Jens M. schrieb: >> Oder ein FRAM benutzen. > Das finde ich dafür Overkill. Naja, wenn man den größeren Elko, die ADC-Geschichte und den Programmieraufwand zusammenrechnet, dann erscheint so ein FRAM vom Schlage FM 24C04B-G für einfuffzich nicht mal sooo arg teurer oder größer oder aufwändiger...
Lothar M. schrieb: > Andreas B. schrieb: >> Jens M. schrieb: >>> Oder ein FRAM benutzen. >> Das finde ich dafür Overkill. > Naja, wenn man den größeren Elko, die ADC-Geschichte und den > Programmieraufwand zusammenrechnet, dann erscheint so ein FRAM vom > Schlage FM 24C04B-G für einfuffzich nicht mal sooo arg teurer oder > größer oder aufwändiger... Abgesehen davon, daß auch ein FRAM nicht ohne Spannung beschrieben werden kann. Aber ok, es mag schneller gehen. Das I2C darfst Du dann gegen den ADC aufrechnen. Das Beschreiben des FRAM muß übrigens auch programmiert werden. Bleibt ein größerer Elko gegen das FRAM. ;-)
:
Bearbeitet durch User
Andreas B. schrieb: > Das I2C darfst Du dann gegen den ADC aufrechnen. Ich habe zwar noch nie ein FRAM eingesetzt, aber man wird trotzdem vermeiden müssen, das während dem Abfallen der Spannung noch ein Schreibversuch stattfindet. Das genannte FRAM will 4.5V...5.5V, viele Prozessoren würden auch unter 3V noch arbeiten und im schlechtesten Fall einen Schreibversuch unternehmen und ggf. zu korrupten Daten führen. Also: der ADC wird bleiben müssen, der Speicher-C auch, nur wird er etwas kleiner sein können. Dann ist der Vorteil nur noch, dass ich bei Spannungsabfall nicht noch schnell schreibe, sondern einfach das Schreiben unterlassen muss.
Andreas B. schrieb: > Es braucht nur einen Spannungsteiler, > einen ADC Eingang und einen etwas größeren Elko als standardmäßig > vorgesehen. Früher™ hat man dafür einen Komparator an einem /Int benutzt. Aber wenn eh ein Speicher nötig ist, kann man mehr oder weniger ohne große Änderungen an der Hardware und Software statt des EEPROMs ein FRAM einsetzen und das nach Herzenslust beschreiben, ohne das man sich einen Kopp um die Lebensdauer machen muss. Andreas B. schrieb: > Abgesehen davon, daß auch ein FRAM nicht ohne Spannung beschrieben > werden kann. Aber ok, es mag schneller gehen. Das I2C darfst Du dann > gegen den ADC aufrechnen. Das Beschreiben des FRAM muß übrigens auch > programmiert werden. Bleibt ein größerer Elko gegen das FRAM. Nope. Programm so lassen wie jetzt (schreiben jede Sekunde oder so), keine besonderen Vorkehrungen und erst recht keine Hardware für/gegen Netzausfall. Chip tauschen, Adresse in der Software anpassen, Ende. Nicht "schreib ins FRAM bei Netzausfall, das geht schneller", sondern "nutze ein FRAM, da kannst du schreiben so viel du willst, jederzeit, das macht nix" HildeK schrieb: > Ich habe zwar noch nie ein FRAM eingesetzt, aber man wird trotzdem > vermeiden müssen, das während dem Abfallen der Spannung noch ein > Schreibversuch stattfindet. Das kann man algorithmisch lösen. Mehr als das eine aktuell geschrieben Byte wird nicht zerstört. Wenn ein BOD bei 4,3V den Stecker zieht sollte das reichen. Zugegeben, eine Netzausfallerkennung wäre besser, aber eben ein neues Layout. EEPROM -> FRAM bestenfalls leichte Softwareänderungen.
Torsten C. schrieb: > Aber das > klingt nach einer Menge Timing und herum probieren. Blöd, das man sich anstrengen muss, oder? Diode + Kondensator in die Versorgungsspannung, vor der Diode abgreifen und auf Komparator legen. Bei Komparator IRQ Daten wegschreiben und schlafen legen.
echt jetzt? schrieb: > Bei Komparator IRQ Daten wegschreiben und schlafen legen. Und wenn dann die Spannung nicht weiter fällt und die Resetschwelle des µC erreicht, sondern die Spannungsversorgung sich wieder berappelt, dann schläft diese Steuerung ab hier bis zum Sanktnimmerleinstag. HildeK schrieb: > Das genannte FRAM will 4.5V...5.5V Die gibts aber auch für 2,7V. Und wenn dann der Brownout kommt und den µC anhält, dann hat der "letzte" Schreibvorgang vor dem Brownout noch sicher geklappt.
Jens M. schrieb: > Das kann man algorithmisch lösen. Mehr als das eine aktuell geschrieben > Byte wird nicht zerstört. Wenn du erkennen kannst, dass das Byte ein zerstörtes Byte ist. Hängt halt davon ab, ob man noch eine Redundanz dazu packen kann. Und ob das letzte richtig geschriebene Byte als Info auch brauchbar ist. Jens M. schrieb: > Chip tauschen, Adresse in der Software anpassen, Ende. Ich denke, er wollte das interne EEPROM dafür verwenden. Also, nichts mit tauschen ... > Nicht "schreib ins FRAM bei Netzausfall, das geht schneller", sondern > "nutze ein FRAM, da kannst du schreiben so viel du willst, jederzeit, > das macht nix" Klar, das war die Idee mit dem FRAM.
Jens M. schrieb: > Nicht "schreib ins FRAM bei Netzausfall, das geht schneller", sondern > "nutze ein FRAM, da kannst du schreiben so viel du willst, jederzeit, > das macht nix" Ja, nur das der Fall "nutze ein FRAM, da kannst du schreiben so viel du willst" verknüpft werden muss, "aber nur wenn die Versorgung stabil ist, sonst kann es sein das dann Unsinn drin steht". Die Netzausfallerkennung brauchts doch sowieso. Wenn dir während des Schreibvorgangs die Energie ausgeht, dann steht Mist im Speicher. Ja, mit einem FRAM sinkt die Wahrscheinlichkeit, da der Schreibvorgang schneller ist. Für ein "richtiges" Produkt musst du das aber beachten. Das fliegt dir sonst um die Ohren, und zwar genau da wo das Produkt am weitesten weg ist oder der Kunde sowieso schon zickig ist. Fürn Hobbyprojekt kannste es auch so lassen und musst dann damit leben, das es irgendwann mal nicht klappt. Ist z.B. bei so einer Lichtsteuerung ein geringes Problem.
Lothar M. schrieb: > Und wenn dann die Spannung nicht weiter fällt und die Resetschwelle des > µC erreicht, sondern die Spannungsversorgung sich wieder berappelt, dann > schläft diese Steuerung ab hier bis zum Sanktnimmerleinstag. Wenn man jede Sekunde schreiben will, dann kann man das auch zum Aufwecken nehmen. Oder einfach vor dem Schlafen den WD-Interrupt aktivieren, so dass er bei wieder ansteigender Spannung auch geweckt wird. > Die gibts aber auch für 2,7V. Und wenn dann der Brownout kommt und den > µC anhält, dann hat der "letzte" Schreibvorgang vor dem Brownout noch > sicher geklappt. Auch bei dem Szenario muss man doch unterbinden, dass der Brownout mitten in einem Schreibvorgang zuschlägt und ein korruptes Byte hinterlässt. Ich fürchte, man muss immer das Ausschaltereignis erkennen können, um rechtzeitig reagieren zu können.
Jens M. schrieb: > Aber wenn eh ein Speicher nötig ist, kann man mehr oder weniger ohne > große Änderungen an der Hardware und Software statt des EEPROMs ein FRAM > einsetzen und das nach Herzenslust beschreiben, ohne das man sich einen > Kopp um die Lebensdauer machen muss. Die meisten uC haben EEprom bereits eingebaut. Zumindest gehe ich davon aus, daß dies bei dem TO so ist. uC mit FRAMs habe ich dagegen noch nicht gesehen.
Lothar M. schrieb: > dann > schläft diese Steuerung ab hier bis zum Sanktnimmerleinstag. Manno... Was machen wir denn da nun bloß? Unglaublich welch komplexes Problem Du hier aufgedeckt hast. Ja dann kann das alles ja unmöglich funktionieren und ohne Notstromdiesel kommt man da nicht weiter. Oder 5sek Nachdenken. Na dann doch lieber den Notstromdiesel, oder? Trollen jetzt schon die Mods?
Prometheus schrieb: > Die Netzausfallerkennung brauchts doch sowieso. Wenn dir während des > Schreibvorgangs die Energie ausgeht, dann steht Mist im Speicher. Nicht, wenn die Information in 1 Byte passt. Denn dann gibt es nur 2 kritische Zustände: entweder läuft die Übertragung und wird abgebrochen, dann wird auch nichts geschrieben oder ist die Übertragung grade noch fertig geworden, dann braucht das FRAM geschlagene 100ns zum Übernehmen ins RAM. echt jetzt? schrieb: > Trollen jetzt schon die Mods? Nein, ich kenne solche "beim Powerfail noch kurz schreiben und dann schlafen" Probleme aus der Praxis und wollte das nur nochmal erwähnt haben. > Unglaublich welch komplexes Problem Du hier aufgedeckt hast. Nicht, dass einer deinen halbgaren Vorschlag einfach so als Vorlage nimmt und auf dem Glatteis ausrutscht, auf das du ihn geführt hast. > Oder 5sek Nachdenken. Und zu welchem Ergebnis bist du gekommen?
Es wird doch wohl einen AVR geben, der alles nötige in HW mitbringt, nicht nur das EEPROM sondern auch ein "High/Low-Voltage Detect-Modul"!? Und genau so einen würde ich mir aussuchen.... 8-O Dann ist auch ohne spezielles Design um die Stromversorgung des µCs, genug Zeit um 1-2 Dutzend Byte zu schreiben. Sinnvoll ist es natürlich auch, das der µC nicht bereits bei 4,5V die Grätsche macht. Das Ganze noch mit einer Fleißarbeit, als quasi Ringspeicher ausführen. Damit sich da auch ja nix "einbrennt". ;)
Danke erst einmal für die ganzen Rückmeldungen. Zur Option 1: Elko Prinzipiell sehe ich Stromausfall als kein relevantes Scenario an. Ich kann mich nicht daran erinnern in den letzten 15 Jahren je einen gehabt zu haben. Aber es wäre natürlich das "sicherste". Ich müsste dafür allerdings die Stromversorgung für den uC separat Puffern (die gesamte Schaltung verbraucht zu viel) - und eben auch schnell genug reagieren. Ich weiss nicht ob ich noch einen Pin frei habe der einen IRQ erlaubt. Sonst müsste das eben in der Main Loop ausreichen. Zur Option 2: Selber Herunterfahren Da hat noch niemand was zu geschrieben. Dabei finde ich die von der Idee her eigentlich recht elegant :) Zur Option 3: FRAM Externes RAM generell klingt zwar gut - aber auch da müsste ich ja den Schreibzyklus schützen um korrupten Daten zu vermeiden. Da ist man dann schnell wieder bei Option 1. Und EEPROM ist halt auch schon on board.
Andreas B. schrieb: > Die meisten uC haben EEprom bereits eingebaut. Zumindest gehe ich davon > aus, daß dies bei dem TO so ist. uC mit FRAMs habe ich dagegen noch > nicht gesehen. Dann solltest du mal bei Texas Instruments vorbeischauen. https://www.elektroniknet.de/messen-testen/sensorik/hochintegration-fuer-geringe-leistungsaufnahme.154297.html Ich finde es wäre an der Zeit, daß der TO mal sagt, um welchen uC es sich hier handelt.
Lothar M. schrieb: > Prometheus schrieb: >> Die Netzausfallerkennung brauchts doch sowieso. Wenn dir während des >> Schreibvorgangs die Energie ausgeht, dann steht Mist im Speicher. > Nicht, wenn die Information in 1 Byte passt. Denn dann gibt es nur 2 > kritische Zustände: > entweder läuft die Übertragung und wird abgebrochen, dann wird auch > nichts geschrieben oder ist die Übertragung grade noch fertig geworden, > dann braucht das FRAM geschlagene 100ns zum Übernehmen ins RAM. Danke für den Hinweis, dann hat sich mein Einwand auch damit erledigt.
Lothar M. schrieb: > Nicht, dass einer deinen halbgaren Vorschlag einfach so als Vorlage > nimmt und auf dem Glatteis ausrutscht, auf das du ihn geführt hast. Wenn man nicht von alleine darauf kommt, das man auch den Zustand 'Spannung wieder da' als Aufwachgrund konfigurieren kann, ist wohl jeder weitere Rat vergebene Liebesmüh. Es hätte also gereicht zu erwähnen das man sich auch um das Aufwachen Gedanken machen muss anstatt weiter das FRAM Pferd zu reiten. Solche trivialen Probleme wurde schon 100.000 fach gelöst, bevor FRAM schick wurden. Die Zeit die eine MCU braucht um den Zustand zu erkennen und die Daten wegzuschreiben, ist so kurz gegenüber der Speicherzeit eines kleinen Elkos, das FRAM hier mit Kanonen auf Spatzen schiessen ist.
> Ich finde es wäre an der Zeit, daß der TO mal sagt, um welchen uC es > sich hier handelt. ATmega328
Andreas B. schrieb: > uC mit FRAMs habe ich dagegen noch > nicht gesehen. Manche MSP430 haben den. Torsten C. schrieb: > Ich > kann mich nicht daran erinnern in den letzten 15 Jahren je einen gehabt > zu haben. Der Schalter schaltet die 5V. Das ist technisch ein Stromausfall.
>> Ich >> kann mich nicht daran erinnern in den letzten 15 Jahren je einen gehabt >> zu haben. > > Der Schalter schaltet die 5V. > Das ist technisch ein Stromausfall. Siehe Thread Start. Bei Option 2 wäre das eben nicht der Fall. Da gäbe es nur einen Stromausfall wenn jemand den Stecker zieht oder das Netz wirklich ausfällt.
Torsten C. schrieb: > Ich müsste dafür > allerdings die Stromversorgung für den uC separat Puffern (die gesamte > Schaltung verbraucht zu viel) - und eben auch schnell genug reagieren. Das ist das geringste Problem. Lösung steht oben. > Ich weiss nicht ob ich noch einen Pin frei habe der einen IRQ erlaubt. Tja, mit anderen Worten, das komplette Konzept nicht richtig überlegt. Du brauchst auch keinen IRQ, sondern einen freien ADC Eingang. Aber auch bei einem Schalter via uC benötigst Du einen zusätzlichen Pin. Jens M. schrieb: > Andreas B. schrieb: >> uC mit FRAMs habe ich dagegen noch >> nicht gesehen. > > Manche MSP430 haben den. Dann benutzt man den eben. Aber bevor ich irgendwelche externen Speicher dran flansche, nehme ich das was schon da ist. Torsten C. schrieb: > ATmega328 also EEprom
Torsten C. schrieb: > Zur Option 2: Selber Herunterfahren > > Da hat noch niemand was zu geschrieben. > Dabei finde ich die von der Idee her eigentlich recht elegant :) Was soll man da groß schreiben, es gibt hier viele Wege nach Rom. Z.B. Man schalte einen PMOS Transistor in die 5V Versorgung, nehme ein CMOS RS-Flip-Flop (einfach aus 2 NOR Gattern aufgebaut) dessen Ausgang den Transistor ansteuert, einen Taster (nach 5V) am Set-Eingang des Flip-Flop und 2 IO-Pins des uC. Ein Eingangspin mit dem Set-Eingang verbunden (um über den Taster dann das Ausschalten einzuleiten) und ein Ausgangspin an den Reset-Eingang des Flip-Flop. Beide Flip-Flop Eingänge bekommen noch einen Pulldown Widerstand um undefinierte Zustände zu verhindern.
6040 schrieb: > Solche trivialen Probleme wurde schon 100.000 fach gelöst, bevor FRAM > schick wurden. Hast du bei der Einführung der Mosfets seinerzeit auch so argumentiert? Wer kein FRAM nehmen will, oder sich nicht vorstellen kann, dass ihn das irgendwas vereinfachen könnte, der nimmt halt keines. Ganz einfach. Torsten C. schrieb: > Prinzipiell sehe ich Stromausfall als kein relevantes Scenario an. Ich > kann mich nicht daran erinnern in den letzten 15 Jahren je einen gehabt > zu haben. Ich kann dir von mindestens 6 Stück im vergangenen Jahr berichten. Und das sagen die Stromlieferanten dazu: https://www.wa-stromerzeuger.de/stromausfaelle-in-deutschland/ Und die überwachende Behörde: https://www.bundesnetzagentur.de/DE/Sachgebiete/ElektrizitaetundGas/Unternehmen_Institutionen/Versorgungssicherheit/Versorgungsunterbrechungen/Auswertung_Strom/Versorgungsunterbrech_Strom_node.html Wenn der Stromausfall egal ist, ist denn dann dieser Status, der sich alle Sekunde mal ändert, tatsächlich so relevant? BTW: aus gegebenem Anlass (manch einer kann sich da mit den vielen Namen schon mal vertun) gilt weiterhin "nur 1 Nutzername pro Thread". Mehr dazu in den Nutzungsbedingungen.
:
Bearbeitet durch Moderator
Du könntest einen EERAM anstatt EEPROM nutzen: https://www.microchip.com/design-centers/memory/serial-eeram Dir stehen damit unbegrenzte Schreibzyklen zur Verfügung und der Baustein speichert bei Spannungsausfall selbstständig die Daten in das EEPROM.
Der AVR kann seine VCC mit der internen Band-Gap reziprok messen. Wenn z.B. VCC auf 4,5V abgesunken ist, schaltet man alle unnötigen Verbraucher ab und speichert im EEPROM. Der Elko muß dann so berechnet werden, daß beim letzten Byte noch >1,8V anliegen. Zur Sicherheit speichert man 2 Datensätze mit CRC.
Lothar M. schrieb: > Hast du bei der Einführung der Mosfets seinerzeit auch so argumentiert? Hast Du gleich nach Einführung der Mosfets jedes noch so triviale Problem, das seit Generationnen mit NPN / PNP gelöst wurde, gleich mittels Redesign auf Mosfet umgestellt, einfach weil das geht? Der TO hat bereits eine Schaltung und eine MCU mit der er arbeitet, das Problem ist lächerlich klein, warum also auf zusätzliches FRAM oder MCU Exot mit FRAM wechseln?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.