Zitat Zitat von RoboHolIC Beitrag anzeigen
Bei keinem der (wenigen) I2C-Bausteine, die ich bisher verwendet habe, gibt es Clockstretching. Alle liefern auf Anfrage Daten und kennen keine unvorhersehbaren Verzögerungen bei der Buskommunikation, weil sie die I2C-Engine in Hardware haben.
Das sagst du so locker.

Clockstretching tritt sogar ohne Slave auf. Nimm mal einen "sauber" implementierten I2C Master und betreibe ihn mit 400kHz, bei höheren Geschwindigkeiten ist der Effekt leichter zu erkennen. Ein Slave ist nicht angeschlossen, die Pullups sind so 10kOhm. Die 400kHz sind leicht nachzumessen. Nun schalte mal 400pF zwischen SCL und GND, das ist die maximale kapazitive Buslast nach der Spec. Der Bus wird jetzt merkbar langsamer (solange der Master sauber implementiert ist). Der Grund ist einfach: der Master setzt SCL für die halbe Bitzeit passend zu 400kHz auf low. Dann läßt er das Signal los und wartet, daß es high wird. Durch die hohe Kapazität des Busses dauert es aber eine Zeit, bis der High-Pegel erreicht wird. Erst dann startet er den Timer, wieder eine halbe Bitzeit, für die High-Phase von SCL. Die messbare SCL-Frequenz wird damit langsamer, die Clock "gestreckt". Es ist egal, wer oder warum SCL länger low ist, als der Master vorgibt. Der häufigste Fall ist natürlich, daß sich der Slave beim ACK erwas Zeit nimmt indem er SCL low hält.

Bei einer Prozessor-Prozessor Verbindung ist Clockstretching eigentlich unvermeidlich und sehr hilfreich. Man kann im Slave wesentlich lockerer mit Interrupten und Interrupt-Sperren umgehen ohne die Integrität der Übertragung zu gefährden.

MfG Klebwax