Hallo, wie ist Eure Meinung zu folgendem Problem: Wichtige Parameterwerte (insg. ca. 100 Byte) eines Gerätes werden in einem externen EEPROM abgespeichert. Einmal speichern reicht mir nicht, da ich so nicht erkennen kann, ob der Parameter noch richtig gespeichert ist ... könnte ja mittlerweile Unfug drin stehen. Die Frage ist: Reicht es die Werte 2 Mal abzuspeichern, in 2 unterschiedliche Zellen und diese beim Auslesen immer vergleichen. Oder besser ein CRC Check über das ganze Parameterfeld ? Vorteil des ersteren ist die einfachste Umsetzung und es kostet weniger Rechenzeit. Der CRC erkennt Fehler aber vielleicht zuverlässiger ?
Zweimaliges Ablegen hat doch ein ganz offensichtliches Problem: Wenn eine Abweichung detektiert wird, welches ist dann der richtige Wert?
> Der CRC erkennt Fehler aber vielleicht zuverlässiger ?
Ein CRC Check erkennt eine Abweichung von einer vorhandenen Prüfsumme
und nicht die Fehler selbst.
Doppelt speichern ist blödsinnig. Ich mach sowas immer nach diesem
Prinzip:
[2Byte: länge der Datenfolge][Byte0 - ByteN][XOR-Checkbyte der Daten -
1]. Das reicht meist vollkommen. Die Chance, dass du dann die falsche
Folge als richtig interpretierst steht bei 1:255 und so unzuverlässig
sind die EEPROMs ja auch nicht. Bei einem Medizinischen Gerät würde ich
es natürlich penibler behandeln...
Gast
#1178077
Ich würd es über ne CRC absichern. Denn bei doppelter Speicherung must ja schliesslich zweimal den kompletten Datensatz schreiben und lesen (und beim Lesen sogar auf Plausibilität vergleichen) Ob das unter´m Strich schneller ist, als ne CRC drüber zu rechnen, wage ich zu bezweifeln
Doppelt abspeichern ist in jedem Fall langsamer, das Berechnen eines 16-Bit CRC dauert bei 16MHz mit Algorithmus (ohne LookUp-Table) etwa 10µs pro Datenbyte, das Wegspeichern hingegen 4-8ms.
Gast
#1178092
Der kluge Bauer legt nie alle Eier in EINEN Korb. Wenn der EEPROM stirbt, ist die Prüfsumme auch mit weg? Wer allerdings an 2 Orten speichert, sollte wissen, welcher Wert dann richtig ist. Prüfzahl+ laufende Nummer ?
Gast
#1178096
Wichtige Parameter speichere ich dreifach im EEPROM ab. Beim Auslesen wird verglichen. Sollten nur zwei Werte gleich sein, wird der dritte Wert verworfen und eine Warnung ausgegeben. Bei drei unterschiedlichen Werten kann keiner der drei Werte mehr verwendet werden. Diese Vorgehensweise hat mir schon mehrfach sehr geholfen.
Gast
#1178099
speichere es einfach auf 3 verschiedene eeproms dann gehts auf jeden fall
Gast
#1178110
Wenn du Fehler nur erkennen willst, nimm den CRC. Dann musst du im Fehlerfall auf DEfaultwerte zuruecksetzen. Wenn du Fehler auch korrigieren willst, speicher es zweimal jeweils mit CRC. Wenn dann beim Schreiben einer Kopie ploetzlich der Strom weg ist, gib es noch die andere.
Gast
#1178113
für sowas gibts den ad wandler + Kondensator um diese Stromprobleme zu verhindern
Gast
#1178118
@oszi40 Ja, da hast recht, aber es nützt nix, wenn der Bauer meint, dass zwei gegenüberligende Ecken des Korbes genauso gut, wie zwei getrennte Körbe sind. geht das EPROM kaputt und die liest nur noch 0xFF, dann merkst du u.U. nichtmal, dass das nicht stimmt, denn der Plausitest ist ok. Aaaber du merkst, dann die CRC falsch und somit die Daten Schrott sind. Ne alte Bauernregel sagt: "Lupft´s dem EPROM mal die Mütze, sind darin alle Daten Grütze" Du könntest natürlich auch drei EPROMs nehmen und alle Daten in drei unteschiedliche EPROMs ablegen und dann per "Mehrheitsentscheid" die richtigen Daten rausfinden. Aber das wäre wohl ein wenig übertrieben
Nun übertreibt mal nicht! Wie wärs den mit einem einfachen fehlerkorrigierendem Code? z.B. BCH-Code oder Eight-to-Fourteen-Modulation wie's bei CDs eingesetz wird Der Softwareaufwand ist zwar etwas höher aber dafür sparst du dir 2 EEPROMs und damit Kosten und potentielle Fehlerquellen.
@Thomas: Sobald ein Fehler erkannt wird bleibt das Gerät aus und kommt in den Service der es dann richtet. Ganz unabhängig ob CRC oder doppelt speichern. @∀ℜτ∪ℜ ΦΥΗΚ: Das habe ich falsch ausgedrückt, sorry. Erkennen eines abweichens von der Prüfsumme reciht mir völlig, bei welchem Parameter der Fehler genau auftritt spielt keine Rolle. Was ist konkret blödsinnige am doppelt speichern ? Mathematisch/statistisch gesehen, sowas muss man doch berechnen können (wenn nur die EEPROM Hersteller statistische Daten in Ihren Datenblättern haben). @Schrotty Das stimmt. Aber beim doppelt speichern würde ich immer nur einen Wert sporadisch lesen oder speichern. Wenn ich einen CRC über das ganze Feld mache, muss ich das jedesmal bei jedem Wert. Auf jeden Fall Danke für Eure Antworten. Ich werde jetzt mal beides umsetzen und ein Testprogramm schreiben das fleissig liest und schreib und sich Fehler merkt. Vielleicht bekomme ich so ein paar Zahlen/Fehler-Wahrscheinlichkeiten heraus. Rein aus Interesse. Die Frage ist wie hoch ist die Wahrscheinlichkeit, das die 2 Zellen die zu einem Parameter gehören beide Ihren Wert identisch falsch haben (also z.B. statt in beiden 0xff,0xff steht in beiden 0x01,0x01). Nur dann würde das 2 Mal speichern versagen. Rein aus dem Bauch heraus sehe ich nicht, warum ein CRC sicherer ist als 2 Mal speichern.
Gast
#1178134
Ich meine, ich hätte am Ende meines Posts angefügt, dass das wohl übertrieben wäre ;-) Aber wir wissen nicht, wie wichtig die Daten sind. Geht es nur darum, nen falschen Datensatz zu verwerfen, dann reicht ne einfache CRC, geht es darum, die Daten bis zu einem bestimmten Umfang korrigieren zu können, dann eben mit nem fehlerkorrigierenden Code. Geht es darum, dass beim Verlust der Daten ein Atomkraftwerk in die Luft fliegt, dann würd ich gern auch mehr als drei EEPROMs dafür opfern, um die Daten zu sichern.
Hätte ich fast vergessen: Im Controller der das EEPROM speichert sind alle Parameter zusätzlich im internen EEPROM gespeichert (doppelt) und werden mit den externen EEPROM Werten verglichen (im Moment immer jeder Wert wenn er gebraucht wird).
@ Schrotty Das mit den 0xFF Werten spricht ja recht eindeutig für CRC. Danke. Mikrocontroller.net , da werden Sie geholfen :)
Gast
#1178153
Für so etwas gibt' z.B. das hier: http://de.wikipedia.org/wiki/Hamming-Code Den als Tabelle im µC unterzubringen ist kein großer Aufwand, Einbitfehler werden korrigiert, 2-3 Bit Fehler sicher erkannt. Und falls das nicht ausreichend sein sollte, gibt's noch andere Verfahren: http://de.wikipedia.org/wiki/Fehlerkorrekturverfahren Einfach aussuchen was am besten paßt.
Gast
#1178154
@Frank Helux Also mit dem Wissen, dass der Verlust der Daten eben nur zu einem Geräteausfall und damit verbundenen Servicefall führt, hat sich die Frage der Rekonstruktion der Daten erübrigt. Es geht also nur noch darum zu erkennen, DASS die Daten falsch sind. wie hoch die Wahrscheinlichkeit, dass exakt zwei Zellen den exakt falschen Wert zurückliefern, kann ich nicht beurteilen. Sterben die Zellen einfach den bösen Zellentod oder ging beim schreiben oder Lesen was schief, dann halte ich die Wahrscheinlichkeit für sehr gering. Ist allerdings z.B. das ganze EEPROM kaputt, dann liest du da nur noch 0xFF (z.B), dann sieht die Sache anders aus, denn dann liegt die Wahrscheinlichkeit bei nahezu 100%, dass der Fall eintritt. Den erkennst du aber nicht, wenn du nur auf Plausibilität vergleichst. Dann solltest du noch ne gewisse Erwartungshaltung an die Daten haben und darüber erkennen, dass das EEPROM gestorben ist. Letztendlich musst du entscheiden, wie häufig die Parameterdaten sich ändern und entpsrechend festlegen, welche Methode (CRC oder doppelte Daten) sinnvoll ist. Nur noch ein kleiner Hinweis: ein EEPROM ist nicht dafür gedacht, alle Nase lang beschrieben zu werden und wird dir sowas mit einem recht frühzeitigen Ableben quittieren.
Gast
#1178173
Na wenn du deine Daten eh doppelt hältst in zwei unterschiedlichen Bausteinen, dann ist auch die Wahrscheinlichkeit, dass im Falle des Ablebens des EEPROMs (lauter 0xFF) die Daten im Flash des Prozesoors genau den gleichen Wert aufweisen, doch sehr gering. Somit würde ein Plausitest meines Erachtens völlig ausreichen. Daten einfach in´s EEPROM schreiben (einfach) und beim Lesen mit denen im Flash vergleichen. Das sollte ausreichend sein. Die CRC bringt dir da nicht mehr viel zusätzliche Sicherheit. Ggf kannst du dir ja auch einfach an einer oder mehreren Stellen des Datenfeldes ein paar Dummies einfügen, die immer einen festen Wert haben müssen, den du kennst und z.B. beim Power-On einmalig abfragst, so weisst, dass das EEPROM an sich noch lebt.
Gast
#1178181
Übrigens bei seltenen Bus-Problemen kann bei doppelten speichern der GLEICHEN Daten auch der gleiche Fehler 2x auftreten. Man könnte z.B. auch ein Komplement speichern oder ein anderes Medium wählen.
Gast
#1178200
Ext. EEProms haben meist einen WP (Write-Protektion) als PIN. Diesen so beschalten, daß ein Schreibvorgang wirklich gewollt sein muß.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.