Hallo zusammen, ich hab mal eine (hoffentlich nicht allzu dumme) Frage zum I2C-Timing. Hintergrund ist, ich möchte ein ähnliches Protokoll wie I2C nur langsamer und mit anderer Adressierung auf einem AVR in Software implementieren. In den Spezifikationen ist immer davon die Rede, dass sich das Datensignal nur während der Low-Phase des Clock-Signals ändern darf (Ausnahme: Start- und Stop-Condition). Heisst das nun, "mitten" während der Low-Phase, oder darf man das auch quasi gleichzeitig mit dem Ziehen von SCL auf low machen? (also ca. 1 Taktzyklus nachher) Anders gefragt: wird der SDA-pegel während der steigenden Flanke gemessen, oder während der fallenden, oder wirklich "dazwischen"? Alle Soft-I2C-Implementierungen die ich bisher gesehen habe, arbeiten "an der Flanke" Da mein Protokoll eh sehr langsam ist (500-5000 Hz) macht es keinen Unterschied, die Delays sozusagen "zu vierteln". Danke, Michi
Gast
#3281308
Michael Reinelt schrieb: > ich möchte ein ähnliches Protokoll wie I2C nur > langsamer und mit anderer Adressierung auf einem AVR in Software > implementieren. Warum?
Gast
#3281309
Michael Reinelt schrieb: > ich möchte ein ähnliches Protokoll wie I2C nur > langsamer und mit anderer Adressierung auf einem AVR in Software > implementieren. Warum? Brauchst Du mehr Adressen? Oder ist Dir I2C zu einfach und Du suchst die Herausforderung?
Gast
#3281319
Michael Reinelt schrieb: > ich möchte ein ähnliches Protokoll wie I2C nur langsamer Das wird nicht möglich sein. Es gibt in der I2C Spec keine untere Geschwindigkeitsgrenze. Egal wie langsam du auch bist, I2C kann immer noch langsamer. MfG Klaus
Sorry, ich hab mich wohl unklar ausgedrückt: ich möchte Sensoren der Firma E+E ansprechen, diese verwenden ein proprietäres "E2-Bus" Protokoll, welches aber sehr ähnlich wie I2C funktioniert, nur langsamer, und mit einem ganz anderen Adressierung.
Etwas, was mich beim Bau meiner Programmiergeräte für 89C2051 geärgert hat: Da wurde im Datenblatt ständig von einem "gleichzeitig" ausgegangen. "gleichzeitig" gibt es eigentlich nicht. Irgendwelche Belastungen von SDA oder SCL können die Anstiegszeiten ändern und damit das "davor" oder "danach" beim Überschreiten der 0-1-Schwelle. Auch ein Übersprechen von SDA auf SCL kann die Flanken zeitlich verschieben. Die Software muss auf jeden Fall eine Verzögerungszeit enthalten, die auf die Anstiegszeiten der Signale auf dem Bus angepasst sind. Mal so eine grobe Schätzung: Ein Zehntel der Bitdauer als Zeitabstand sollte es schon sein.
schupf mag noch jemand was zum i2c timing sagen?
Gast
#3281746
>mag noch jemand was zum i2c timing sagen?
Nee, wozu? Du willst doch E2-Bus.
Schau da in die Datenblätter. Da steht mit Sicherheit
drin was du machen musst. Wenn nicht frag den Hersteller
oder dein Osci.
Wozu also soll man sich hier noch zu I2C äussern?
Das ist komplett sinnfrei.
holger schrieb: > Nee, wozu? Du willst doch E2-Bus. Manno, sei nicht so kleinlich. Ja, ich will E2, aber trotzdem interessiert mich, wie man i2c "richtig" implementiert.
Gast
#3281768
http://www.nxp.com/documents/user_manual/UM10204.pdf Da werden alle deine Fragen beantwortet.
holger schrieb: > http://www.nxp.com/documents/user_manual/UM10204.pdf > > Da werden alle deine Fragen beantwortet. Danke, jetzt ist alles klar. Und mein E2-Bus tut nun auch was er soll...