Hallo, ich möchte in Zeitabständen 1 sec - 10min Daten eines Zählers in in das NVRAM einer RTC Speichern. Dazu stehen mir 56 Bytes zur verfügung. Ich möchte insgesamt 4 32 Bit breite Zahlen speichern. Aus jeder soll eine Prüfsumme gebildet werden, die als 5.Byte geschrieben wird. Dann wird das ganze nochmals gespiegelt also mit insgesamt 10 Bytes gespeichert. Somit sind dann 40 Bytes belegt. Wenn beim zurücklesen dann die Prüfsumme nicht korrekt ist, so kann immer noch auf den 2. Wert zugegriffen werden. Das ist allerdings nur beim Start des systemes erforderlich, es existiert ein 1:1 Spiegel im RAM des AVR. Einmal Täglich sollen dann die gesammelten Wert auf ein EEProm geschrieben werden. Aber nicht zwecks Datensicherheit, sondern nur zum Auslesen und weiterverarbeiten in EXCEL. Evtl. könnte man auch den letzten EEProm wert zurücklesen, falls die Batterie schlapp werden sollte. Welche Art der Prüfsummenbildung würdet ihr mir hier empfehlen? Dachte schon an ein einfaches addieren und nur die letzten 8 Bit speichern. was ist dann aber, falls der NV-RAM komplett auf 0 Steht, dann wäre ja aufgrund der Prüfsumme alles ok - ist es aber nicht. Wollte eigentlich auf CRC8 verzichten, da es ja wirklich nur 4 Bytes sind. gruß, Tubie
@ Tubie (Gast)
>Welche Art der Prüfsummenbildung würdet ihr mir hier empfehlen? Dachte
Man kann auch einfach ein Parity per XOR berechnen. Und mit ungerader
Parität klappt das dann auch mit einem leeren EEPROM.
MfG
Falk
Das würde dann also so aussehen?
1 | ldi r16,1 |
2 | eor r16,r18 |
3 | eor r16,r19 |
4 | eor r16,r20 |
5 | eor r16,r21 |
r16 = prüfsumme ist das dann sicherer als:
1 | ldi r16,1 |
2 | add r16,r18 |
3 | add r16,r19 |
4 | add r16,r20 |
5 | add r16,r21 |
...es kommen bei beiden Varianten andere Ergebnisse bei raus, welches ist dazu aber besser geeignet? gruß, Tubie
Parität or CRC lassen nur erkennen, ob die Daten defekt sind. Es wäre bessr, ein Fehlerkorrekturverfahren einzusetzen, wenn diese Daten sehr wichtig sind. Fang doch mal hier an zu lesen, und danach ist Google Dein bester Freund: http://de.wikipedia.org/wiki/Fehlerkorrekturverfahren
@ Tubie (Gast) >Das würde dann also so aussehen? Fast, eher so. [avrasm] ldi r16,$FF eor r16,r18 eor r16,r19 eor r16,r20 eor r16,r21 ; r16 : Prüfsumme [avrasm] >...es kommen bei beiden Varianten andere Ergebnisse bei raus, welches >ist dazu aber besser geeignet? Ist schwer zu sagem. Jetzt könnte man das mit viel Mathematik und Wahrscheinlichkeitsrechung noch zerlegen, praktisch wird aber kein nenneswerter Unterschied rauskommen. MfG Falk
Wenn die Batterie des NV-RAMS schlapp macht, wird es leider nicht so sein, dass nur einzelne Bits verloren gehen. Das RAM wird vielmehr komplett gelöscht. Ich hab dazu mal einen Test gemacht; RAM mit Daten gefüllt, Speisespannung herabgesekt, wieder erhöht und gelesen - es waren nur noch 0x55 0xAA 0x55 0xAA .... drin. Wenn die Batterie also wirklich schlapp machen sollte, dann sind nicht nur deine gespeicherten Werte weg, sondern auch noch deine mühsam berechneten CRCs oder Paritätsbits. Verwende besser ein NV-RAm wie z.B. das MK48Z02 von ST. Dies hat ein sogenanntes BatteryOK-Flag drin. Beim einschalten des Microprocessors musst du nur auf eine bestimmte Speicheradresse schreiben und den Wert zurücklesen. Liest du denselben Wert zurück, wie du geschrieben hast, ist alles OK, wenn jedoch die Batterie langsam schwächer wird, wirst du 0 zurücklesen. Das MK48Z02 würde ich die allerdings nicht unbedingt empfehlen, ist nämlich leicht veraltet und glaub' ich ziemlich teuer. Schaue ggf. im Datenblatt der RTC nach, obs da in einem Control Register evtl. ein Battery-Flag gibt. Bei den Dallas-Typen DS1287 / DS12887 / DS12C87 beispielsweise gibts dazu ein eigenes Register, das Control Register D, wo Bit Nr. 7 den Batteriezustand angibt. Wenn das Bit = 1 ist, ist alles OK, wenn das Bit auf 0 ist solltest du die Batterie (resp. halt den Chip) wechseln.
@ Falk Brunner (falk) dann ist es auch egal, welches Format ich dann verwende ;) Mein Code enthält schon die Addition - kann dann wohl auch so bleiben... @Dietrmar E (Gast) So wichtig, das ich mit Fehlerkorrektur arbeiten muß sind die Daten auch wieder nicht. Es geht eigentlich nur darum, wenn gerade gespeichert wird (5 Bytes) und bei Byte 2 wird die Stromversorgung unterbrochen noch ein Backup zu haben. Desshalb werden alle Werte 2x gespeichert. Also reicht hier eine einfache erkennung gut/defekt. Soll wenns fertig ist ein Energiemengenzähler werden, um am Jahresende festzustellen, wieviel mit Gas/Holz/Solar an WW/Heizung geheizt wurde. Desshalb auch das Speichern auf EEProm am Ende des Tages, um einen Jahresüberblick zu bekommen. Gruß, Tubie
@ Tobias Plüss (hubertus) Der DS1307 hat leider dieses Flag nicht. Layout ist auch schon fertig, so dass ein neuer Chip auch nicht ohne weiteres in frage kommt. Könnte höchstens Softwaremäßig dafür sorgen, dass die Batterie alle 2 Jahre ausgetauscht werden muß. Gruß, Tubie
nimm einen FRAM, dann hast du alle Nachteile erschlagen. Platz genug für mehrere Datensätze.
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.