Wie kriegt man es am besten/einfachsten hin, einen Betriebsstunden- oder kWh-Zähler zu bauen, ohne den EEPROM innerhalb kurzer Zeit zu verschleißen? Die Daten im RAM halten ist klar, aber wie erkennt man am besten wann das Gerät abgeschaltet wird, so daß man die Daten noch zuverlässig in's EEPROM bekommt?
Vielleicht mit Hilfe einer kurzen Pufferung der Versorgungsspannung des µC. Wird festgestellt, dass die Spannung ausgefallen ist, werden die Daten noch schnell vom RAM ins EEPROM geschrieben?
@ Ben B. (Firma: Funkenflug Industries) (stromkraft) >Die Daten im RAM halten ist klar, aber wie erkennt man am besten wann >das Gerät abgeschaltet wird, so daß man die Daten noch zuverlässig in's >EEPROM bekommt? https://www.mikrocontroller.net/articles/Speicher#EEPROM_Schreibzugriffe_minimieren
Ben B. schrieb: > Wie kriegt man es am besten/einfachsten hin, einen Betriebsstunden- oder > kWh-Zähler zu bauen, ohne den EEPROM innerhalb kurzer Zeit zu > verschleißen? Was für Eeprom ? Was für Daten ? Wie oft ? Welcher Zeitraum ?
Wie oft wird denn ein- und aus geschaltet? Und kommt es auf jede Sekunde an, oder reicht es, wenn alle 1/ 10/ /30 /60 Minuten mal ein Wert ins den EEPROM geschrieben wird? 100.000 Schreibzyklen sind schon eine Menge, und man kann ja einen kleinen wear-leveling Funktion einbauen, bei der immer ein eine Adresse bzw. Page weiter geschrieben wird. Das dürfte schon einiges bringen.
Falls es sich um einen externen EEPROM handelt, statt des EEPROM einfach einen FRAM einsetzen. Die sind sehr haltbar ( 10^14 Schreib- und Lesezyklen), ziemlich flink und im pinkompatiblen Gehäuse erhältlich.
:
Bearbeitet durch User
Wear Leveling könnte man zusätzlich machen und da wüßte ich auch wie. Allerdings möchte ich nicht jede Änderung der Daten direkt ins EEPROM schreiben. Ich würd lieber den Datenblock zusammen mit einem Änderungs-Flag im RAM vorhalten und beim Abschalten ins EEPROM schieben wenn Daten geändert wurden. Okay, ich komme also wohl nicht drum herum, die Betriebsspannung extern zu messen. Schade, ich dachte da wüßte jemand was. Ich muß mal messen... das Netzteil ist ein ATX-Standby-Netzteil, es erzeugt 12V und 5V, wobei die 12V nicht so stark gepuffert, aber gut belastet (FET-Treiberleistung und PWM-Controller, ggf. 100mA Lüfter) sind. Die 5V sind ähnlich belastet (Controller, LCD mit Hintergrundbeleuchtung und Messtechnik), aber deutlich besser gepuffert. Vielleicht brechen die 12V ausreichend schnell ein, so daß ich da mit Z-Diode und normaler Diode (plus Pull-Down) einen Controller-Pin auf Masse kriege, bevor die 5V zu weit eingebrochen sind. Würdet ihr den internen EEPROM benutzen oder einen externen? Intern hätte den Vorteil, daß ich die Daten nicht verschlüsseln brauche weil niemand der sie manipulieren will so einfach da drankommt. Externer EEPROM heißt halt man müßte die Daten verschlüsseln und eine Kennung für den EEPROM im Controller hinterlegen (damit der nicht einfach ausgetauscht oder entnommen werden kann), aber dafür altert der Controller nicht.
Dafür gibts z.B. den Brownout Detektor. Wenn man den hoch genug einstellt (z.B. auf 4,3V) dann hat er genug Zeit, um die EEPROM Schreibroutine zu triggern und ist längst fertig, wenn die Spannung unters Limit für den EEPROM gefallen ist. Wenn das ein komplettes ATX Netzteil ist, liefert das auch ein PowerGood Signal, klingt aber so, als würdest du nur ein Stückchen vom Netzteil benutzen?
:
Bearbeitet durch User
Es gibt dazu diverse Verfahren. Das hir könnte lesenswert sein: http://www.atmel.com/images/doc2526.pdf Ein FRAM oder Batteriegepuffertes SRAM ist da natürlich schöner. Noch eine Anmerkung: Die oben erwähnte Vorausfallsmeldung / Pufferung der Versorgung oder irgendwie gestaltete andere Maßnahmen braucht man eigentlich immer wenn man im Betrieb Daten in nichtflüchtige Speicher schreibt. Wenn nämlich die Versorgung während eines beliebigen Schreibvorgangs im Speicher einbricht, kann man sich schon mal auf Datenverlust einstellen. Bei meinem Arbeitgeber hat sich beispielsweise ein (beim Ausschalten) unterversorgtes FPGA sich sporadisch in einem Flash verewigt, in Form eines Page Erase Kommandos. Zumindest hat das Flash den "Todesschrei" des FPGA dahingehend interpretiert. Für eine Lösung gegen sowas reichen aber oft ein paar 100µF, eine Diode und ein Resetbaustein oder Komparator. Manchmal reichen schon die ohnehin nötigen Pufferkondensatoren. Wenn man das schon hat, kann man auch gleich den Betriebsstundenzähler schreiben, wenn sich das zeitlich ausgeht.
Matthias S. schrieb: > Dafür gibts z.B. den Brownout Detektor... Funktioniert das auch auf einem ATMEL AVR8?
Nein, es ist kein komplettes ATX-Netzteil. Manchmal findet man in diesen Dingern 5V-Standby-Netzteile, die auf einer extra Platine sitzen. Sowas hab ich verwendet weil ich von 80..230Vdc, mit denen der Wandler läuft, runter muß.
Beim klassischen AVR nutzt man den Analog-Komparator, der die interne Referenz mit der über einen Spannungsteiler passend eingestellten Betriebsspannung vergleicht. Wird diese zu niedrig, wird ein Interrupt ausgelöst, der den Inhalt der nötigen RAM-Zellen in das EEPROM sichert.
:
Bearbeitet durch User
Ah nein, ich bezog mich auf den Vorschlag mit dem BOD.
S. Landolt schrieb: > Wie geht das? Im AVR8 ist das tatsächlich nicht drin, weil der BOD das Reset nur dann freigibt, wenn die Spannung wieder steigt. Bleibt Vcc unter dem BOD Level, wird Reset nicht verlassen. Alternativ ist aber der Analog Komparator ein denkbarer Auslöser. Der Vorteil hier wäre, das direkt eine ISR zur Verarbeitung zur Verfügung steht.
:
Bearbeitet durch User
Wie steil muß denn bei einem AVR die fallende Flanke am Pin für einen PinChange-Interrupt sein? Wenn die Eingänge über Schmitt-Trigger verfügen, könnte man den Analog Comparator sparen.
Wenn es nicht um Tausende Stück geht, nehme ich auch einen externen FRAM für solche Sachen. Die ganz kleinen mit 512Byte gibts für 20Ct. Und Betriebsstunden kann man ja sogar ohne alle Faxen direkt auf dem internen EEPROM speichern (in 11 Jahren hat man dann die garantierte Zyklenzahl erreicht, also immer noch Luft :-) Aber wie fast immer - es gibt mehrere Lösungen für ein Problem. Mir gefällt das einfache mit einem FRAM gegenüber ausgefeilten Strategien aller Art für solch ein triviales Problem.
Hallo zusammen, mich wundert, dass die klassische Methode hier noch nicht erwähnt wurde. Meines Wissens nach wurde, zumindest früher, in elektronischen Kilometerzählern in KFZs folgendes gemacht: Statt z. B. eines Bytes für die 1 km-Zählung wurden 32 Bytes verwendet. Zunächst sind alle 256 Bits gelöscht (= 1). Dann wird jeden km ein (weiteres) Bit gesetzt (-> 0). Sind alle 256 Bits gesetzt, wird zum ersten Mal ein Byte echt inkrementiert. Das bedeutet: Statt bei bei jedem Ereignis ein LSByte zu ändern, wird nur in 8 von 256 Ereignissen ein Byte verändert. Und das muss auch nicht vorher gelöscht werden, denn es wird nur ein zusätzliches Bit gesetzt. Erst nach 256 Ereignissen wird ein Löschvorgang erforderlich. Mit noch mehr Bits für die unteren Stellen geht das natürlich noch fast beliebig zu steigern. Ich hatte diese Aufgabenstellung auch einmal. Ich hatte damals versucht, herauszubekommen, ob das Setzen einzelnen Bits tatsächlich, wie ich vermutete, das EEPROM weniger stresst, als das Löschen. Vielleicht stresst das Setzen aller 8 Bits nacheinander die Zellen gar nicht oder zumindest weniger als das anschießende Löschen des Bytes. Ich habe leider keine verlässliche Antwort bekommen. Vielleicht gibt es auch spezielle EEPROM-Technologieen, die dafür optimiert sind. Wahrscheinlich ist es auch klug, beim Setzen des neuen Bits nicht nur die Bits, die gelöscht bleiben sollen, sondern auch die, die bereits gesetzt sind, mit 1 zu beschreiben und nur für das neue Bit eine 0 auszugeben. Grüße, Uwe
Uwe B. schrieb: > Statt z. B. eines Bytes für die 1 km-Zählung wurden 32 Bytes verwendet. > Zunächst sind alle 256 Bits gelöscht (= 1). Dann wird jeden km ein > (weiteres) Bit gesetzt (-> 0). Sind alle 256 Bits gesetzt, wird zum > ersten Mal ein Byte echt inkrementiert. Ich bin nicht sicher, ob das so mit dem internen EEPROM eines AVR zu machen ist. Auch bei externen EEPROMs gibt es ja das Problem, dass nur ganze Pages geschrieben werden können. Welche Art von EEPROM braucht man für deine Technik?
Ben B. schrieb: > Wie kriegt man es am besten/einfachsten hin, einen Betriebsstunden- oder > kWh-Zähler zu bauen, ohne den EEPROM innerhalb kurzer Zeit zu > verschleißen? Beitrag "Seltsames Bauteil / Was ist das" Megaeinfach und ganz ohne Mikroprozessor :-) Butzo
H.Joachim S. schrieb: > Aber wie fast immer - es gibt mehrere Lösungen für ein Problem. Mir > gefällt das einfache mit einem FRAM gegenüber ausgefeilten Strategien > aller Art für solch ein triviales Problem. Ja, in der Tat trivial. Aber da der TO anscheinend selber nicht weiss, was und in welchen Intervallen er messen will, in welchen Intervallen er die Messwerte aufschreiben will, wie genau das Ganze sein soll... Mit max. 15KWh sind es 250W pro Minute, das passt in ein Byte. Man nimmt ein DS3231 mit AT24C32 - RTC mit 4KB Eeprom - sekundengenaue Zeit und 4KB Eeprom dazu. Für eine Minute in 10 Sekundenabstand und 16bit Wert reichen 192 Bytes. Für 24 Stunden in Minutenabstand und 8bit Wert reichen 1440 Bytes. Für 31 Tage in Stundenabstand und 16bit Wert reichen 1488 Bytes. Wearcounter, Pointer und alles andere passt in < 16 Bytes. Startzeit, Datum, letzte Übernahme der Daten < 16 Bytes. Kontrollvariablen für ev. StromAusfall und Zeitdiskrepanzen < 16 Bytes. Wenn man sich alle 3 Monate um 192 Bytes aufwärts bewegt, dauert es fast 4 Jahre bis der Eeprom seine 1Mio. Schreibzyklen erreicht. Dann opfert man wieder 1,1 Euro für neuen Modul, 0,4 Euro für CR2032, steckt 4 Kabel um und gut isses. P.S. Alles im Kopf gerechnet, ich weiss, jetzt kommen die grossen Mathematiker mit Fehlern von mehreren Tagen oder sogar Wochen...
:
Bearbeitet durch User
> Aber da der TO anscheinend selber nicht weiss, was und in welchen > Intervallen er messen will, in welchen Intervallen er die > Messwerte aufschreiben will, wie genau das Ganze sein soll... Erzählt doch nicht immer so einen Scheiß. Ich hab schon meine Vorstellungen. Ich nehme an, daß 40 Bit für die Variablen groß genug sind. 40 Bit reichen bei sekundengenauer Zählung für grob überschlagen 34.860 Jahre. Bis dahin kennt die Menschheit schon gar keine EEPROMS mehr. 40 Bit reichen bei 1/1000 Auflösung für knapp 1,1 Terawattstunden. Davon ausgehend, daß das Ding 2kW Maximallast können soll bräuchte es 62.750 Jahre Volldampf damit er Zähler überläuft. Reicht, übertrifft den Betriebsstundenzähler. 40*2 Bit sind 80 Bit, 10 Byte. Ein Controller mit 4kByte EEPROM könnte 409 Wertepaare speichern. Ärgerlich, da brauchen wir 2 Byte extra für den Blockzähler, 1 Byte reicht nicht. Macht also 12 Byte, passt der Block 341mal in das EEPROM. Sprich Wear Leveling erhöht die Lebensdauer des EEPROM (davon ausgehend, daß sich nur jede geschriebene Zelle abnutzt und für 12 Byte schreiben keine Pages mit 128..256 Byte gelöscht werden müssen) um den Faktor 341. Macht beim AVR mit 100.000 Schreibzyklen 34,1 Millionen Schreibzugriffe. 34.860 Jahre sind etwa 12,7 Millionen Tage. Bei optimaler Anzahl Schreibzugriffe (einer am Tag bei Sonnenuntergang) hält das EEPROM länger als die Zähler laufen. Angenommen wir haben dauerhaftes Pech und beschreiben das EEPROM 1000mal am Tag, hält das EEPROM 34.100 Tage. Das entspricht etwa 95 Jahren. Ich glaube das reicht. Um die Neuanschaffung werde ich mich wahrscheinlich nicht mehr kümmern müssen. Das interne EEPROM des verwendeten ATMega1284 bekommt den Job. Aber FRAM schaue ich mir trotzdem mal an, evtl. gehts damit einfacher. Gute Nacht!
Ben B. schrieb: > 40 Bit reichen bei sekundengenauer Zählung für grob überschlagen 34.860 > Jahre. Bis dahin kennt die Menschheit schon gar keine EEPROMS mehr. Erstens ist das eine Milchmädchenrechnung. Und zweitens, wenn du es wirklich so machen willst, genügt das hier vollkommen: Klaus B. schrieb: Beitrag "Seltsames Bauteil / Was ist das" > Megaeinfach und ganz ohne Mikroprozessor :-) Ben B. schrieb: > wahrscheinlich nicht mehr kümmern müssen. Das interne EEPROM des > verwendeten ATMega1284 bekommt den Job. M1284 um eine 40bit Variable hochzuzählen ? > Aber FRAM schaue ich mir trotzdem mal an, evtl. gehts damit einfacher. LOL. Noch einfacher ?
:
Bearbeitet durch User
Ben B. schrieb: > Wie kriegt man es am besten/einfachsten hin, einen Betriebsstunden- oder > kWh-Zähler zu bauen, ohne den EEPROM innerhalb kurzer Zeit zu > verschleißen? Wenn du wirklich nur Stunden zählen willst: Nimm immer zwei EEPROM-Zellen zusammen als eine 16-Bit-Zahl, die du herunter zählst. Das ergibt maximal 65536 Schreibvorgänge und liegt damit unterhalb der garantierten 100000. Wenn die ersten beiden Bytes auf diese Weise „verbraucht“ sind, nimm die nächsten beiden. Jedes dieser EEPROM-Zellen-Paare kann dabei 7,5 Jahre lang die Betriebsstunden zählen, vermutlich wirst du also mit 4 Paaren (8 Bytes) gut auf der sicheren Seite liegen. ;-)
> Erstens ist das eine Milchmädchenrechnung. Eine Machbarkeitsstudie. > Und zweitens, wenn du es wirklich so machen willst, genügt das hier > vollkommen: > Klaus B. schrieb: > Beitrag "Seltsames Bauteil / Was ist das" >> Megaeinfach und ganz ohne Mikroprozessor :-) Ja, vor allem ist das so schick digital auszulesen. Die notwendige Kamera und Bildauswertung wird ohne Mikroprozessor schwierig. Nee - schicke Technik - aber keine Option. Das Ding hat ein Display und da sollen auch die Betriebsstunden und erzeugte kWh drauf. > Ben B. schrieb: >> wahrscheinlich nicht mehr kümmern müssen. Das interne EEPROM des >> verwendeten ATMega1284 bekommt den Job. > M1284 um eine 40bit Variable hochzuzählen ? Nö, zwei 40 Bit Variablen. Und dann noch so Dinge wie MPP-Tracking und Displayansteuerung. Kriegt man auch mit einem ATMega8 hin, aber der 1284 liegt rum und ich verwende in der Entwicklung gerne einen dickeren Controller als nötig. Verkleinern kann man hinterher immer noch. >> Aber FRAM schaue ich mir trotzdem mal an, evtl. gehts damit einfacher. > LOL. > Noch einfacher ? Klar, wenn es sowas genau wie einen SPI/I2C-EEPROM gibt? Mehr Anlässe zum Meckern hast Du nicht gefunden? Schade. Wo gibts dieses FRAM eigentlich kaufbar und ist das anfällig gegenüber Magnetfeldern? Etwa wenn jemand seinen neuen tollen Mega-Neodymmagneten da drauflegt?
Ben B. schrieb: > Mehr Anlässe zum Meckern hast Du nicht gefunden? Schade. Doch, aber es wird nicht helfen. Genauso wie aus deinem "Projekt" nichts wird. Das, was du angeblich machen willst, kann man auf einem Stromzähler umsonst lesen.
:
Bearbeitet durch User
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.