-         

Ergebnis 1 bis 8 von 8

Thema: Wie fehlersicher ist I2C, oder doch protokoll mit CRC

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    12.03.2005
    Beiträge
    22

    Wie fehlersicher ist I2C, oder doch protokoll mit CRC

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    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

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    16.06.2004
    Ort
    Bad Schussenried in Oberschwaben
    Alter
    28
    Beiträge
    1.461
    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
    http://www.tobias-schlegel.de
    "An AVR can solve (almost) every problem" - ts

  3. #3
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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)
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  4. #4
    Neuer Benutzer Öfters hier
    Registriert seit
    12.03.2005
    Beiträge
    22
    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

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    06.02.2005
    Ort
    Hamburg
    Alter
    31
    Beiträge
    4.255
    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.

  6. #6
    Neuer Benutzer Öfters hier
    Registriert seit
    12.03.2005
    Beiträge
    22
    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

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    22.05.2005
    Ort
    12°29´ O, 48°38´ N
    Alter
    48
    Beiträge
    2.731
    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)

  8. #8
    Neuer Benutzer Öfters hier
    Registriert seit
    12.03.2005
    Beiträge
    22
    Danke noch mal für den Input, hat mir sehr weiter geholfen.

    mfg

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •