Sinnvoller Standard-Verdrahtungstyp für Langstrecken-I2C

I2C ist in gewisser Weise ein sehr ordentliches Protokoll, aber sein Designzweck besteht darin, Geräte auf einer einzigen Platine miteinander zu verbinden. Sogar über Probleme der Signalisierungspegel hinaus gibt es einige Protokollprobleme, die Probleme bei der Verwendung für Multi-Board-Kommunikation aufwerfen können.

Nehmen wir beispielsweise an, dass zwei Slave-Geräte angeschlossen sind, die es einem Master ermöglichen würden, eine beliebige Anzahl von Bytes zu lesen, und die für eine beliebige Anzahl dieser Bytes Null zurückgeben können. Wenn, während ein Gerät Daten an den Master sendet, ein zweites Gerät einen Teil der Daten fälschlicherweise als "START"-Folge gefolgt von seiner Leseadresse interpretiert, wäre es möglich, dass für jeden nachfolgenden Taktzyklus mindestens eines der Geräte fehlt um ein Datenbit "0" auszugeben. Ein solches Szenario würde es dem Master unmöglich machen, jemals wieder die Kontrolle über den Bus zu erlangen. Während es möglich ist, Single-Board-Kommunikation so zu gestalten, dass Streuimpulse "einfach nicht passieren", ist dies oft nicht machbar, wenn viele Geräte angeschlossen werden. Man kann versuchen, die Wahrscheinlichkeit des Auftretens von Streuimpulsen zu minimieren, Sie sollten jedoch nicht erwarten, sie vollständig zu vermeiden. Es kann akzeptabel sein, dass ein Sensormesswert einmal im Monat aufgrund eines Streuimpulses beschädigt wird, aber wenn das System einmal im Monat gesperrt wird, ist dies wahrscheinlich weniger der Fall.

Wenn Sie ein Single-Master-Setup verwenden, würde ich vorschlagen, dass es sich lohnen könnte, separate Drähte für den SDA-Ausgang zu den Slaves und den SDA-Return zu verwenden. Wenn die Slaves Handshaking verwenden, kann es sich lohnen, dasselbe für SCK zu tun. Der Ausgang des Masters könnte dann aktiv hoch und niedrig getrieben werden (anstatt aktiv niedrig getrieben und passiv hoch gezogen zu werden). Wenn die Anschlüsse "Ein"- und "Aus"-Seiten bezeichnet hätten, könnte jede Platine in der Kette die Rückkehr vom vorherigen Gerät mit dem Pin-Zustand ihres eigenen Geräts "UNDen" und aktives High-and-Low in der Rückkehrrichtung ausgeben sowie. Ein solches Design würde wahrscheinlich die Verwendung eines Bit-Bang-Masters anstelle eines Hardware-Masters erfordern, aber angesichts der Tatsache, dass Software-Master-Implementierungen oft eine bessere Fehlerwiederherstellung leisten können als Hardware-Master, die das nicht sollten.

Zusätzlich zu der verbesserten Robustheit, die sich aus dem Active-High/Active-Low-Antrieb ergibt, vermeidet die Verwendung separater Ausgangs-/Rückleitungsdrähte für SDA die Möglichkeit, dass ein Slave-Gerät die Versuche des Masters stört, ein anderes Gerät zum Schweigen zu bringen, da selbst wenn alle aber ein Slave-Gerät wollte Low auf SDA ausgeben, der Master hätte kein Problem damit, einen Low-to-High-Übergang am SDA-Pin des letzten verbleibenden Slaves zu erzeugen.

Wenn Sie die zusätzlichen Drähte nicht verwenden möchten, um den SDA-Ausgang von der SDA-Rückgabe zu trennen, wäre es möglich, die Slaves so zu verdrahten, dass ihre Pulldown-Stärke auf SDA begrenzt ist, und den Master so zu verdrahten, dass er den sicher überwältigen kann Sklaven. Dies würde im Falle einer Slave-Fehlfunktion eine saubere Wiederherstellung ermöglichen, aber nicht die Vorteile der Signalreinheit bieten, die die Verwendung separater Drähte mit sich bringt. Außerdem würde es nur dann gut funktionieren, wenn kein Handshaking verwendet wird. Ein robuster I2C-Betrieb erfordert, dass die Übergänge auf SCK und SDA um eine Zeit getrennt werden, die über dem ungünstigsten Übertragungsversatz liegt. Wenn der Master die alleinige Kontrolle über SCK hat, kann er dies sicherstellen. Slaves, die Handshaking verwenden, können jedoch asynchron Ereignisse auf SCK und SDA generieren, ohne dass der Master deren Trennung steuern kann.

Folie 68, Seite 25 aus AN10216:

Obwohl es vielleicht nicht ideal ist, wird dies von Philips empfohlen (meine Version des Dokuments ist vom März 2003). Twisted-Pair-Telefonkabel.