Ist der Signalverlauf bei I2C so üblich?

Mike schrieb:
> Warum
> sollte da der Bus zwischendurch nicht kurz hoch gehen?

Ja, das ist genau der Grund. Der Bus wird ja durch den R getrieben. 
Deshalb hat I2C in der SPEC auch eine Anforderung, spikes mit 50ns zu 
unterdrücken.

Martin T. schrieb:
> Ich vermute, dass der Raspi die
> Leitung schneller los lässt, als der MCP zum ACK sie wieder auf GND
> zieht.

Ich schließe mich der Meinung der Mehrheit an :-)

Allerdings - ich hätte selbst solche peaks noch nie beobachtet. 
Vermutlich deshalb, weil in meinen Fällen der Master für eine gewisse 
"hold time" SDA weiter am Pegel hält (oder erst später "loslässt") und 
der Slave sehr schnell mit dem ACK bei der Hand ist, sodaß sich diese 
zwei Aktionen überschneiden, und der Peak erst gar nicht auftritt.

Aber, wie du richtig vermutest - während SCL low ist, darf alles 
mögliche passieren, und sollte nicht stören.

Die Peaks sind OK, nicht jeder Slave ist schnell... Sehr oft kann man 
auch an einem leicht höheren low-Pegel sehen, das jetzt der Slave die 
Leitung treibt und nicht nur der Master kaputt ist ;)

Vielen Dank für eure Antworten!

Jetzt habe ich zusätzlich zwei I2C-Buffer PCA9600 dazwischen geschaltet. 
Also Raspi <--> PCA9600 <--> PCA9600 <--> MCP23017.

Die Kommunikation läuft stabil, aber der Signalverlauf sieht ganz anders 
aus.

Der erste Screenshot zeigt die Messung am Master, der zweite die Messung 
am Slave. Die Buffer scheinen den Pegel nicht mehr vollständig auf GND 
ziehen zu können. Der Low-Pegel befindet mit 0,7V zwar noch innerhalb 
der Spezifikation (0,3 x 3,3 = 0,99), ist aber schon ganz schön knapp. 
Gibt es dafür eine Erklärung? Kann man dies ändern?

VG, Martin

Eventuell zuviel Pullup auf der Busseite oder zuwenig auf der Leitung 
zwischen den beiden Buffern? Im Datenblatt zum PCA gibts noch Referenzen 
auf Application-Notes, evtl. steht da noch mehr drin...

Martin T. schrieb:
> Meine Frage dazu wäre, ist das normal?

Ja. Das ist vollkommen innerhalb der Spezifikation. Zwischen der 
abfallenden und der nächsten aufsteigenden Taktflanke haben die Geräte 
Zeit ihre Ausgangstreiber zu schalten, gesampled wird an der 
aufsteigenden Flanke und während der Takt high ist muss der Pegel gleich 
bleiben aber sobald und solange der Takt auf low ist darf sich der Pegel 
ändern.

Der Master schaltet hier den Ausgang hochohmig beinahe im selben 
Augenlick wie er den Takt auf low zieht und erst wenn der Takt auf low 
ist wagt es der Slave sich zu bewegen (vorher darf er nicht, er muß auf 
low warten). Diesen Peak kann man mehr oder weniger stark ausgeprägt 
oftmals messen, mal so stark ausgeprägt wie bei Dir, manchmal auch gar 
nicht.

Deine Vermutung zur Ursache ist also korrekt, und auch die daß es die 
Übertragung nicht stören kann, es geschieht ja während der Takt low und 
die Datenleitung per Definition undefiniert ist.

Georg A. schrieb:
> Eventuell zuviel Pullup auf der Busseite
Da hängen nur 1,8k intern vom Raspi.

> oder zuwenig auf der Leitung zwischen den beiden Buffern?
Hab mal einige durchprobiert (4,7k, 10k, 15k, 100k). Am Low-Pegel ändert 
sich nichts. Wie zu erwarten, reduzieren sich die Überschwiniger bei 
höheren Werten, bei 100k wurde das Timing so schlecht, dass Fehler in 
der Kommunikation auftauchten. Als guter Kompromiss scheinen sich 10k 
darzustellen.

> Im Datenblatt zum PCA gibts noch Referenzen
> auf Application-Notes, evtl. steht da noch mehr drin...

Mein Englisch ist nun nicht das Allerbeste, aber ich vermute hier die 
Begründung aus dem Datenblatt:

1

 A logic LOW is transmitted to TX when the voltage at I2C-bus pin SX

2

 is below 0.425 V. A logic LOW at RX will cause I2C-bus pin SX to be

3

 pulled to a logic LOW level in accordance with I2C-bus requirements

4

 (maximum 1.5 V in 5 V applications) but not low enough to be looped

5

 back to the TX output and cause the buffer to latch LOW.

Wenn ich es richtig verstehe, muss das so sein, um wegen der 
bidirektionalen Kommunikation Feedback-Schleifen zu verhindern. Richtig?

VG, Martin

Martin T. schrieb:
> Meine Frage dazu wäre, ist das normal? Ich vermute, dass der Raspi die
> Leitung schneller los lässt, als der MCP zum ACK sie wieder auf GND
> zieht. Da dies alles innerhalb der Low-Phase des Takts passiert, sollte
> es keine negativen Auswirkungen auf die Kommunikation haben. Ist das
> richtig?

Der BCM2835 des Raspberry Pi hat anscheinend einen schweren 
Design-Fehler im Zusammenhang mit clock-stretching slaves in der 
I2C-Hardware. Siehe 
http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=13771, 
http://elinux.org/BCM2835_datasheet_errata#p35_I2C_clock_stretching, 
http://www.advamation.de/technik/raspberrypi/rpi-i2c-bug.html und 
https://github.com/raspberrypi/linux/issues/254.

LG, Sebastian

Vielleicht kannst Du das im Slave deaktivieren?

Im obigen Oszillogramm findet überhaupt kein Clock Stretching statt. Die 
Signale sehen übrigens vollkommen normal aus.

Martin T. schrieb:
> A logic LOW is transmitted to TX when the voltage at I2C-bus pin SX
>  is below 0.425 V. A logic LOW at RX will cause I2C-bus pin SX to be
>  pulled to a logic LOW level in accordance with I2C-bus requirements
>  (maximum 1.5 V in 5 V applications) but not low enough to be looped
>  back to the TX output and cause the buffer to latch LOW.

> Wenn ich es richtig verstehe, muss das so sein, um wegen der
> bidirektionalen Kommunikation Feedback-Schleifen zu verhindern. Richtig?

Und wenn man weiter liest, dann steht dort

1

The LOW level this chip can achieve on the I2C-bus by a LOW at RX is typically 0.64 V when sinking 1 mA.

Und weiter...

1

A ‘regular I2C-bus LOW’ applied at the RX/RY of a PCA9600 will be

2

propagated to SX/SY as a ‘buffered LOW’ with a slightly higher voltage

3

level.

Ich glaube, bzgl. der Low-Level sind jetzt alle Klarheiten beseitigt. 
Und wer lesen kann, ist klar im Vorteil :-)

VG, Martin