TWI/IIC SDA Signal

[Ceos]

sieht irgendwie nach (überforderter) software-I2C aus, schon ein wenig merkwürdig.

warum misst du AC? Das könnte dein Messergebnis auch verfälschen!

[Cysign]

Das ist mir erst aufgefallen, nachdem ich das Foto hochgeladen hatte (Mein Oszi hat so nen bequemen Automatik-Knopf...der das Signal dann einfängt). Ich habs dann nochmal auf DC gestellt aber der Graf hat sich nicht verändert (außer dass er n bisschen nach oben in den positiven Bereich gewandert ist).

Das ist an den AtMega2560 TWI-Pins abgegriffen. Ich bin mir nicht sicher, ob der Arduino-Bootloader auf Hardware- oder Software-TWI zugreift.
Aber wie kommst du auf überfordert?

[Ceos]

es wirkt, als ob er erst das OUT Register schreibt und dann 2.5µS später das DIR Register, sodass im ersten Moment Pull-Up gegen Pull-Down kämpft und dann wenn das DIR auf Output steht erst vollständig runterzieht.

Solche "Zwischenlevel" erlebe ich sonst nur auf der CLK Leitung wenn ein I2C Device ein Clockstretch länger als 25mS macht, dann erzwingt die I2C Logik eine Clock und je nach Pull-Stärke des Slave kann man da Pegelunterschiede erkennen.

Das mit dem Clockstretch von maximal 25mS sollte ma übrigens IMMER in hinterkopf halten wenn man Slaves mit der Funktion bearbeitet, das hat mir beim Debuggen schonmal graue Haare gemacht XD .... kommt daher dass der I2C mit SMBus Logik arbeitet und die Regel von da kommt.

[Peter(TOO)]

kommt daher dass der I2C mit SMBus Logik arbeitet und die Regel von da kommt.

I²C wurde 1982 von Philips erfunden und diente der einfachen Verdrahtung von ICs in TVs. (Davor musste man den Daten- und einen Teil des Adress-Busses verdrahten.) Die Elektronik bestand damals aus einem µC und einigen komplexen ICs, welche z.B. Bild oder Ton verarbeitet haben.

1995 definierte dann Intel, basierend auf dem I²C, den SMBus. Bei Computern sind die Anforderungen aber etwas anders. Beim SMBus darf es mehrere Master geben, was auch den Timeout nötig macht damit der Bus nicht blockiert werden darf. Zudem gibt es noch die ALERT#-Leitung, welche eine Art Interrupt ist um dringende Meldungen abzusetzen.

MfG Peter(TOO)

[H.A.R.R.Y.]

[...] Beim SMBus darf es mehrere Master geben [...]

Beim I²C auch. Ist so in der I²C-Spec (3.1.8 Arbitration) beschrieben und ich bin mir 100%ig sicher, daß es auch schon in der Version 2.0 so war. Eine ältere I²C-Spec habe ich nicht.

Aber irgendwie riecht das wirklich nach HW-Problem. Hast Du eventuell einen PCF8574 greifbar? Dann nimm das Display weg, programmier ein Testprogramm um auf den PCF zuzugreifen (irgendwas zum LED blinken, muß ja keine LED dran) und untersuche die Verhältnisse auf dem Bus. Der 8574 ist normgemäß und kann als Referenz gut herhalten. Wenn es mit dem nämlich auch auftritt, dann liegt es doch am mega bzw. dem SW-Master.

[Feuerring]

der SCL sollte aber symmetrisch sein ...

http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.png

die 5 uS habe ich glatt übersehen, wären 100 kHz ...

>> sieht sehr nach Clock-streching aus ... I2C-Slave zieht dabei weiter runter als der AtMega
macht aber auf der SDA wenig Sinn ...

@Cysign
bist Du dir sicher das Du SDA und SCL beim messen nicht vertauscht hast ?!
2 Kanal Oszi wäre jetzt super, dann könnte man beide Signale im Vergleich sehen

[H.A.R.R.Y.]

Ne, direkt ne RTC und ein PCF8574 an den Ports des AtMega.

Im ersten Post schriebst Du von Display am I²C. Ist das Display über den PCF8574 angeschlossen? Falls ja, könntest Du die RTC vom Bus nehmen (Chip aus dem Sockel oder Adresse am Chip verstellen oder wie auch immer) und die Leitungen nochmals mit dem Scope untersuchen?

Etwas merkwürdig finde ich aber auch die Pulsfolge auf dem SDA und dem SCL. Beide schön abwechselnd 0 und 1, bei Datenübertragung wechselt SDA normalerweise nur wenn nötig.

Ich schließe mich Feuerring an: Ein Scope-Shot mit 'nem Zweikanal-Oszi wäre hilfreich.

Grüße
H.A.R.R.Y.