TWI/IIC SDA Signal

[Cysign]

Hallo zusammen,
ich frage mich grade, wie es sien kann, dass SCL sauber auf high/low zieht, SDA aber zusätzlich einen Zwischenzustand hat.

SCL
32429


SDA
32430


Ist das eine Art IDLE-Modus?

Angeschaut habe ich mir das auf einem AtMega2560 mit Arduino-IDE.
Dass die Pins in Ordnung sind und der Code funktioniert weiß ich, da über TWI ein Display angeschlossen ist ;)

[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.

[Klebwax]

Ist das eine Art IDLE-Modus?

Nein, sowas gibts es bei I2C nicht. Wenn man den Begriff "Idle" verwenden will, ist High idle, da wird der Bus nur von den passiven Pullups auf high gezogen.

Für mich sieht das so aus, als ob einer am Bus das Signal aktiv auf High treibt, während ein anderer es auf Low zieht. Ein weiteres Indiz für diese Vermutung sehe ich im SCL-Bild. Dort ist die High-Flanke "runder". Das entspricht eher einem Pullup als die schärfere Flanke bei SDA.

Stimmt diese Vermutung, ist ein Teilnehmer am Bus, nämlich der, der auf High treibt, ein fehlerhafter Software I2C. Eine Hardware Implementation von I2C hätte einen solchen fundamentalen Fehler nicht.

Das der Code funktioniert, ist positivem Karma oder Glück zu verdanken.

MfG Klebwax

- - - Aktualisiert - - -



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.

Nicht ganz. Der I2C Bus ist schon ein paar Jahrzehnte älter als der SMBus und hatte keinen Timeout. Da das in einem Computer nicht denkbar war, ein Bus der das System komplett blockieren kann, hat man den Timeout dazuerfunden und das Ganze mit der Festschreibung von TTL Pegeln und der Alert Leitung SMB genannt.

MfG Klebwax

[Ceos]

Sorry ich hab hier vergessen zu erwähnen dass sich das NUR auf Atmel Controller bezieht, steht in deren Anleitung!

I2C hat mit Clock Stretch explizit kein limit. SMBus hingegen schon und Atmel verweist bei der "TWI" Schnittstelle ausdrücklich auf diese SMBus Regel. Aber eben nur im Kleingedruckten! Daher wollte ich das dringend erwöhnt haben.

[Peter(TOO)]

kommt daher dass der I2C mit SMBus Logik arbeitet und die Regel von da kommt.
I2C 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 I2C, 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 (http://cache.nxp.com/documents/user_manual/UM10204.pdf?fsrch=1&sr=1&pageNum=1) (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]

Hallo Cysign (https://www.roboternetz.de/community/members/39408-Cysign)

hast Du einen Treiber dazwischen, da arbeitet man mit verschiedenen Pegeln um die Richtung festzustellen

siehe auch hier: http://www.nxp.com/documents/data_sheet/P82B96.pdf

die Rückantwort liegt da 0,3V höher, um einen Loop zu vermeiden

[Cysign]

Ne, direkt ne RTC und ein PCF8574 an den Ports des AtMega.
Vielleicht ist es die Mischung aus verwendeten Libs?

Das wären:
#include <Wire.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#include <LiquidCrystal_I2C.h>
#include <EEPROMex.h>
#include <Time.h>
#include <DS1307RTC.h>
#include <SPI.h>
#include <SD.h>
#include <sdelay.h>

Ich denke, dass Wire, LiquidCrystal_i2c, Time und DS1307RTC aus den TWI zugreifen.

[Feuerring]

Zu deimen oszi ....

kannst Du mal Angaben zur Zeitbasis machen.

mit wieviel kHz wird der I2C angesprochen ...

sieht sehr nach Clock-streching aus ... I2C-Slave zieht dabei weiter runter als der AtMega

[RoboHolIC]

Ich lese im ersten Bild "5µs". Mit grob zwei Kästchen je Zyklus sind das etwa 100kHz.

[Feuerring]

der SCL sollte aber symmetrisch sein ...

http://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.png (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 (https://www.roboternetz.de/community/members/39408-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.