Frage zu I2C Timing

[Michael R. (Firma: Brainit GmbH) (fisa)]

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

[Nicolas S. (Gast)]

Michael Reinelt schrieb:
> ich möchte ein ähnliches Protokoll wie I2C nur
> langsamer und mit anderer Adressierung auf einem AVR in Software
> implementieren.

Warum?

[Nicolas S. (Gast)]

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?

[Klaus (Gast)]

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

[Michael R. (Firma: Brainit GmbH) (fisa)]

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.

[Peter R. (pnu)]

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.

[Michael R. (Firma: Brainit GmbH) (fisa)]

schupf

mag noch jemand was zum i2c timing sagen?

[holger (Gast)]

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

[Michael R. (Firma: Brainit GmbH) (fisa)]

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.

[holger (Gast)]

http://www.nxp.com/documents/user_manual/UM10204.pdf

Da werden alle deine Fragen beantwortet.

[Michael R. (Firma: Brainit GmbH) (fisa)]

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