Wie fehlersicher ist I2C, oder doch protokoll mit CRC

Hallo,

ich habe hier ein multimaster netzwerk mit 4 mastern und einem slave der als server fungieren soll.
Jeder master holt oder übergibt dem slave seine daten, der slave spielt also server und speichert die daten ab.
Ich muss eine Koruption der Daten während der Komunikation auf alle Fälle ausschließen können.
Nun die Frage, wie sicher ist I2C bezüglich Fehleranfälligkeit.
Soll ich doch auf ein simples Protokoll zurück greifen um etwaige Komplikationen im Vorhinein auszuschließen.
Ich dachte an folgendes, Datenpaket besteht aus 1 Startbyte, 1 Längenbyte(gibt Datenlänge an, maximal 20 bytes), X Datenbytes, 2 bytes CRC, 1 Stopbyte.

Anregungen und Ideen sind wilkommen. Danke

Hi

Wenns besonders sicher sein soll, würde ich das so machen, ja.

Andere Frage, wie willst du den Slave die Daten verwalten lassen, du brauchst ja dann ein Filesystem... (Und eine Art ID, dass der Master auch weis was er wann wo Speichert)

VLG Tobi

Im Prinzip hast du recht, nur würde ich die Kirche im Dorf lassen.
Start / Stop sind im I2C ausreichend definiert.
Längenbyte bringt wenig
Was IMHO einen Sinn hat, ist ein CRC hinten nach, damit auch ein Receiver (Master oder Slave) weiß, ob die Daten ok sind.
Bei max 10 Byte Länge tut's aber sicher auch ein 8-Bit BCC (Daten x-oren)
Wesentlich unterhaltsamer ist die Abhandlung aller Zustände, die bei einem kollisions-behaftetem Bus möglich sind. (auch wenn die Avr-TWI da recht hilfreich ist)

Hallo,

Gespeichert wird es vom slave(server) auf einem externem EEPROM per SPI.
Simples filesystem ist in Tabellenform vorhanden, es werden neben Einstellungen wie Grenzwerte eine Statistik über 28 Tage mit je 4 Werten tabelarisch gespeichert.
In abhängigkeit von der ID und Datum wird die zugehörige Zelle beschrieben.
Ich habe das ID-byte im Paket vergessen.
Noch eine Frage, wird mir das S.N.A.P. protokoll dienlich sein können, mein eigenes zu schreiben?
Ich dachte an folgendes:
Multimaster sendet Paket.
Slave(server) antwortet mit JA, Paket ist angekommen.
ODER
Slave antwortet mit NEIN, Paket ist korrupt.
Multimaster sendet Paket wiederholt.
ODER
Slave meldet sich nach einer Wartezeit von X Zyklen nicht.
Multimaster sendet Paket wiederholt.
Komunikation kann weitergehen:

Da fählt mir grad ein, ich brauche noch eine Art Regel ob der Multimaster schreiben oder lesen will, die Komunikation ändert sich ja da gewaltig.
Will der Multimaster lesen, muss ihm der Slave ja noch die benötigten Daten zurückschicken. - noch ein weiteres Steuerbyte(lese/schreibe) im Paket vieleicht?

mfg

Zitat:

---

Zitat von terny

Da fählt mir grad ein, ich brauche noch eine Art Regel ob der Multimaster schreiben oder lesen will, die Komunikation ändert sich ja da gewaltig.
Will der Multimaster lesen, muss ihm der Slave ja noch die benötigten Daten zurückschicken. - noch ein weiteres Steuerbyte(lese/schreibe) im Paket vieleicht?

---

Das ist ja schon über das I2C-Protokoll geregelt. Jeder Slave hat ja eine Lese- und ein Schreibadresse (R/W Bit gesetzt oder nicht), und das TWI im AVR erkennt dadurch, ob es Daten empfangen oder senden soll.

Wird dann folgende Paketgröße ausreichend sein?:
1 Längenbyte(Anzahl an Datenbytes die übertragen werden)
1 ID-byte
X Datenbytes
2 CRC-bytes(oder änliches)

Bezüglich R/W Bit:
Beispiel, Master will vom Slave Daten hollen:
1) I2C Start.
2) Setzte Write Bit (Multimaster fordert Daten vom slave mit einer bestimmten ID an)
3) Setzte Read Bit(Multimaster holt Antwort ein "Paket war in Ordnung"/"Paket war fehlerhaft")
4) Wenn "Paket war in Ordnung" als Antwort kommt. gehe zu Punkt 5.
Wenn "Paket war fehlerhaft" gehe zu Punkt 2 zurück.
5) Warte auf Paket mit benötigten Daten.
6) I2C Stop

Beispiel, Master will zum Slave Daten schicken:
1) I2C Start.
2) Setzte Write Bit (Multimaster schickt Daten zum slave mit einer bestimmten ID)
3) Setzte Read Bit(Multimaster holt Antwort ein "Paket war in Ordnung"/"Paket war fehlerhaft")
4) Wenn "Paket war in Ordnung" als Antwort kommt. gehe zu Punkt 5.
Wenn "Paket war fehlerhaft" gehe zu Punkt 2 zurück.
Wenn nach X Zyklen keine Antwort vom Slave kommt, gehe zu Punkt 2 zurück(sollte nie eine Antwort kommen, hängt sich das Gerät auf)
5) I2C Stop

So wie ich das sehe, braucht der Slave doch noch ein Signal ob er nun Daten zurück schicken soll oder ob er Daten speichern soll.
Oder der Slave entscheidet selber anhand des Längenbytes im Paket(sollte dieses 0 sein, nimmt er an, er soll Daten mit entsprechender ID an den Master zurück schicken) wie die restliche Komunikation auszusehen hat.

mfg

Hallo,

ob sich der Slave meldet oder nicht, bekommt man schon mit, nachdem man die SlaveID über I2C gesendet hat, denn da müsste der Slave mit ACK antworten, wenn das nicht kommt, weiss der Master-AVR, das der Slave grad nicht kann.
Ebenfalls so wenn grad ein anderer Master den Bus belegt, das ergibt sich schon, wenn die Startsequenz nicht klappt, dann kann man nur nach einer gewissen Zeit nochmal probieren. (Ähnlich einer Collision beim Ethernet)

Danke noch mal für den Input, hat mir sehr weiter geholfen.

mfg