Frage zu I2C Startbedingung

Moin,

ich habe ein Problem mit dem I2C-Protokoll. Es gibt eine "unangenehme" Situation bei diesem Protokoll, zu dem ich keine Lösung gefunden habe. --Auch google hats nicht d'rauf. :-k

Nehmen wir an, die Kommunikation ist so weit gediehen, dass der Master fortwährend Daten vom Slave einlesen kann. Er empfängt 8 Bits und sendet danach ein ACK oder NACK je nachdem, ob weitere Daten übertragen werden sollen. Bei ACK "gehört" dem Slave die SDA-Leitung und er belegt sie mit dem ersten Bit, des nächsten Bytes. Wenn dies 0 ist, legt er SDA aktiv auf low.

Wenn nun die Kommunikation aus irgendwelchen Gründen unterbrochen wird, d.h. es kommen erst einnal keine weiteren Clock-Signale, hat der Master keine Chance, die Startsequenz einzuleiten (SDA: high -> low, bei SCL: high), weil SDA vom Slave auf low gahlten wird. Was muss der Master in einem solchen Fall tun?

Ich werde mich zunächst damit behelfen, solange Clock-Signale zu geben, bis SDA auf low geht. Aber ist das normgerecht?

vg
Red Baron

Du meinst, der Master ist der Meinung dass der Slave "Clock Stretching" betreibt, die Kommunikation also bremsen will?

Hm... wenn der Slave die Leitung immer noch auf Low hält, kann der Master nicht viel machen, da dann der ganze Bus "versaut" ist. Beim CAN wärs so, dass ein Bus"versauer" einfach getrennt werden kann und gut ist. Beim I2C gibts sowas leider nicht.

Wenn der Slave aber nicht mehr dran hängt, dann wird die Leitung ja von den Pullups wieder hochgezogen => Clock-"Puls" vollständig. Die Clock-Pulse erzeugt eh der Master. D.h. für die restlichen Bits (in denen der Slave schon fehlt) empfängt er halt immer 1.

Nein, kein Clock-Stretching. Dabei würde SCL low gehalten. Es geht um die reguläre übertragung eines Bytes und dabei SDA. Wenn eine 0 vom Slave an den Master gesendet wird, setzt der Slave SDA auf low. Wenn jetzt kein weiteres Clock kommt, weil irgendwetwas gehakt hat, bleibt SDA auf low... Und damit kann der Master SDA nicht mehr auf high ziehen (open collector!). SDA auf high zu legen ist aber zwingend notwendig, wenn ein neuer Übertragungszyklus begonnen werden soll.

Ist der Slave ein Controller? Dann macht es Sinn dort eine timeout-Funktion einzubauen, die im Fehlerfall den I²C im Slave resettet.

Rajko

In diesem Fall muss eines der folgenden Szenarien greifen:

1.) Der Slave implementiert einen Timeout und gibt SDA frei
2.) Der Master hat die Möglichkeit den Slave zu resetten (z.B. über Reset-Leitung oder schaltbare VCC)
3.) Der Slave implementiert eine spezielle 'Recovery-Sequenz' (es gibt hierfür aber keine Spezifikation oder Standard, das ist etwas völlig bausteinspezifisches)

Der Fall 3 ist z.B. beim folgenden RTC-Baustein realisiert:
http://www.sii-ic.com/en/product1.js...productID=1356
(ein sehr preisgünstiger Baustein, deshalb die etwas krude Recovery-Sequenz', siehe Seite 35 im Datenblatt, Überschrift 'Reset After Communication Interruption'.)

Viele Grüße

Im Rahmen des TWI-Protokolls ist der Spass auf dem Bus ganz einfach aus, wenn aus irgend einem Grund eine oder beide der Leitungen gegen GND gehalten wird. Kann ja auch ein HW-Fehler sein.
Denn selbst, wenn das ein Teilnehmer erkennt, kann er eigentlich nix dagegen tun, ausser irgendwie Alarm zu schlagen. Mit externem Gerät (allgemeine reset leitung) kann man das dieses oder jenes tun.

Die div. I2C chips würden aber eher nicht innerhalb eines Bytes hängen bleiben, da ja das von der Chip-Hardware abgewickelt wird.
Eher reagiert er nicht mehr aus weitere Abfragen und der Master bekommt FF's statt Daten.

Hallo PicNick,

im Allgemeinen stimmt das natürlich so, es gibt aber auch Sch...- Chips wie die oben erwähnte billig-RTC, die sich ganz übel verhalten können:
Z.B. gibt es chips wie EEPROMs, die während sie ihren internen Schreibzyklus durchführen auf dem I2C nicht ansprechbar sind. Um festzustellen, wann das EEPROM wieder bereit ist, führt man ein ACK-Polling aus, d.h., man versucht in kurzen Abständen einen Read-Zugriff auf das EEPROM zu machen und sobald es darauf wieder ein I2C-ACK bringt, weiß man, dass der interne Schreibzyklus beendet ist.
Wenn nun die oben angeführte RTC mit an diesem Bus hängt, dann kommt es tatsächlich vor, dass sie durch das ACK-Polling auf das EEPROM so verwirrt ist, dass sich ihre I2C Logik aufhängt und SDA auf immer und ewig Low hält. Da die RTC keinen Reset-Eingang hat und Abschalten der Power nicht schön ist (weil sie dabei die Uhrzeit verliert), hilft nur, die krude Recovery-Sequenz genau so zu implementieren wie im Datenblatt beschrieben.

Es gibt also durchaus Bausteine, die einem das Leben am I2C Bus unnötig erschweren können...

Viele Grüße

Ah ja. Offenbar ist Microsoft nicht das einzige, das einem den Spass versauen kann.