Druckbare Version
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
Anhang 32429
SDA
Anhang 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 ;)
sieht irgendwie nach (überforderter) software-I2C aus, schon ein wenig merkwürdig.
warum misst du AC? Das könnte dein Messergebnis auch verfälschen!
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?
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.
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.Zitat:
Zitat von Cysign
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 - - -
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.Zitat:
Zitat von Ceos
MfG Klebwax
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.
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.Zitat:
Zitat von Ceos
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)
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.Zitat:
Zitat von Peter(TOO)
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.
Hallo 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
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.