I2C Read Fehler dedektieren

Indem du den geschriebenen Wert mit deinem gelesenen Wert vergleichst.
Wie den sonst auch.

Ist mir noch eingefallen. Du kannst auch um sicherzugehen eine Prüfsumme
zusätzlich mit abspeichern. Dann kannst du auch nach Jahren noch
feststellen, ob da was schiefgelaufen ist.

hallo,
passt grad deshalb hänge ich das noch hier ran:

ich muss nicht nur erkennen, dass ein fehler passiert ist beim
lesen/schreiben, sondern diesen auch korrigieren können.
ich wollte mich nun noch einmal allgemein schlau machen, welche
verfahren es da gibt und wie man diese in ANSI C am besten in die I2C
kommunikation einbinden kann?

habe folgendes im anhang schon gefunden. es ist ein in c realisierter
reed-solomon code. da ich aber im programmieren nicht allzu fit bin,
sieht mir das ganze doch recht kompliziert aus.
kann mir da evtl jemand sagen, wieviel overhead ich durch solch eine
implementierung zu erwarten hätte?

desweiteren gibt es ja noch die möglichkeiten durch eine 3fache
abspeicherung der daten und dem 2of3 modus beim lesen (daten müssten
dann und verknüpft werden, oder?) und die mehrfache wiederholung beim
speichern (1010 => 1111000011110000), was eigentlich einer
verlangsamung der busgeschwindigkeit gleichkommt.

wäre dankbar, wenn mir einige ihre erfahrungen auf diesem gebiet
mitteilen könnten.

danke im voraus!

Ist denn eine solche Sicherheit erforderlich? Ich kann mich nicht
erinnern, daß ich jemals Ausfälle bei I²C-EEproms gehabt hätte.
Die Frage ist auch: Soll nur die Übertragung gesichert werden (in
diesem Fall kann man einfach nochmal wiederholen) oder der Inhalt?

Eine relativ einfache Methode:
Man fasst immer 8 Byte zu einer Gruppe zusammen. Wenn man diese insges.
64 Bit wie ein Schachbrett anordnet, kann man sowohl waagerecht als auch
senkrecht ein Parity-Bit bilden. Das ergibt dann 2 zusätzliche Bytes pro
8-Byte-Block. Der Fehler kann zurückgerechnet werden, da bei einem
defektem Bit die Parity-Bits in waagerecht und senkrecht falsch sind.
Ist der Fehler nur einmal vorhanden (also nicht in beiden
Parity-Bytes), dann ist eine der Prüfsummen falsch. Ich hoffe, das war
jetzt nicht zu verworren...

Andere Möglichkeit: Einfach die Daten inkl. Prüfsumme 2x abspeichern.
Ist die Prüfsumme in Ordnung, sind auch die Daten O.K., falls nicht,
wird auf den zweiten Datensatz zurückgegriffen. Prüfsummenbildung per
CRC-32 sollte ausreichend sein.

Wenns um die Übertragung geht: Ein Bit zu zwei Bit konvertieren. Eine
"0" wird dann zu "01" und eine "1" wird zu "10". Wenn beim
Lesen eine "11" oder "00" gelesen wird, ist etwas faul. Diese
Kodierung nutze ich erfolgreich für Funkübertragungen.

hi thkais,

vielen dank!
die fehler werden, wie du richtig vermutest, nicht durch ausfälleim
eeprom hervorgerufen, sondern evtl. bei der übertragung. die daten- und
taktleitung meiner I2C kommunikation läuft neben steuerleitungen, über
die ein sehr hoher motorstrom laufen kann, durch den ich eine hohe
störfestigkeit (I2C mit bus buffer, gute kabel, etc.) und
datensicherheit benötige.

deine letzte möglichkeit (0 => 01, etc) hört sich interessant an. diese
in verbindung mit einem evtl ECC wäre was.
jedoch sehe ich mit dem 00, bzw. 11 zwar fehler, aber das tue ich im
moment durch das reine vergleichen meiner geschriebenen daten mit
sofortigem rücklesen dieser, ja auch.

durch die kreuzparität könnte ich maximal einfache bitfehler
korrigieren, sehe ich das richtig?
über diese, in verbindung mit 2fachen abspeichern, und die 2of3 methode
(3 faches abspeicher, beim lesen und-verknüpfen) hab ich auch schon
nachgedacht.
hast du/ihr da noch eine erfahrung?

und kennt sich vllt jemand mit dem oben angehängten Reed-Solomon
verfahren aus?