Hallo zusammen, nachdem ich die Platine für meine Raspi-Heizungsregelung aus diesem Beitrag "Re: Platinenentwurf für Heizungsregelung mit Raspberry Pi - Kritik?" in Betrieb genommen hatte, habe ich einige Kommunikationsschwierigkeiten mit einem angeschlossenen Relaisboard-Treiber. Um der ganzen Sache auf den Grund zu gehen, habe ich die I2C-Kommunikation mit meinen bescheidenen Analysemitteln (Saleae Logic 4) beobachtet. Dort fielen mir einige Signalverläufe auf, die ich durch eine Minimalvariante (Raspi <--> MCP23017) auf dem Breadboard bestätigen konnte. Dort tauchen ab und zu so halbe Spitzen auf. Nach stundenlagem Draufschauen viel mir auf, dass diese Spitzen immer an der gleichen Stelle auftauchen, nämlich direkt vor dem ACK des MCP. 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? Danke! Martin
Angehängte Dateien:
-
screenshot.png
30 KB
:
Bearbeitet durch User
Empfängt der Master denn das ACK? Wenn ja würde ich mir an dieser Stelle keine weiteren Sorgen machen. Wichtig ist das bei der positiven Flanke des SCL-Signals die SDA-Leitung einen festen Pegel angenommen hat - und das auch auf der Seite des Masters.
Martin T. schrieb: > Nach stundenlagem > Draufschauen viel mir auf, dass diese Spitzen immer an der gleichen > Stelle auftauchen, nämlich direkt vor dem ACK des MCP. Dann überleg mal, was vor dem ACK passiert. Da gibt der Sender den Bus frei und der Empfänger aktiviert für das ACK seinen Treiber. Warum sollte da der Bus zwischendurch nicht kurz hoch gehen?
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.
:
Bearbeitet durch User
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 ;)
Angehängte Dateien:
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
Martin T. schrieb: > Gibt es dafür eine Erklärung Nun, es gibt keinen wirklich "automatisch" umschaltetenden bidirektionalen Buffer. Anhand des gezeigeten Spannungsunterschied entscheidet der Treiber, in welcher Richtung er treiben muß. Schau noch mal in die Spec der Treiber. Manche schließen da explizit aus, zwei hintereinander zu schalten. MfG Klaus
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
Hi >Hab mal einige durchprobiert (4,7k, 10k, 15k, 100k). Dann lies einfach mal http://www.nxp.com/documents/user_manual/UM10204.pdf MfG Spess
Das was man hier sieht nennt sich crosstalk. Kann es sein dass deine zwei i2c Leitungen nebeneinander verlaufen ? Ansonsten beim Master Serienwiderstand erhöhen, so 250 ohm ca.
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
:
Bearbeitet durch User
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.