So ein wenig gehen da SDA, die Daten, und SCL, der Takt, durcheinander. Beide müssen bidirektional sein, sonst kann man nicht mit jedem Slave kommunizieren.

Die Geschwindigkeiten bei I2C bewegen sich im Bereich bis 0,5MHz, da sind Reflexionen oder ähnliches kein wirkliches Problem. Außerdem hat ein einseitig arbeitender OC-Treiber keinen definierten Wellenwiderstand, das spielt hier also keine Rolle. Die I2C Spec sagt, der Treiber muß eine Leitungskapazität von 400pF treiben können. Das entspricht einer Leitungslänge von ca. 5m. Mit Pullups, die die zulässigen 3mA ausschöpfen, kann man das auch gut erreichen. Die Datenrate spielt dabei keine Rolle, es geht immer nur um die Flanken. Erst wenn sie langsamer werden, als eine halbe Bitlänge, kann das ein Problem werden. Aber selbst dann passt sich der Bus durch Clockstretching auf der SCL-Leitung automatisch an.

Will man mehr, braucht man Treiber. Der P82B96 oder der PCA9600 erhöht die kapazitive Treiberleistung auf 4000pF, so das längere Kabel möglich sind. Gleizeitig kann man die Spannung auf der Leitung bis 15V erhöhen, was den Störabstand massiv verbessert. Philips schreibt von 20m, die möglich sind. Man findet aber auch Beschreibungen von Hausbussystemen, die von bis zu 100m berichten. Insgesamt ist das eine recht einfache Lösung. Am Anfang und am Ende der langen Stecke ein Treiber im 8pin Gehäuse, und davor oder danach hat man einen I2C Bus ohne irgendwelche Einschränkungen. Da stehen dann jeweils wieder die oben erwähnten ca. 5m zur Verfügung.

Wesentlich mehr Aufwand da rein zu stecken, lohnt sich IMHO nicht. Ethernet kost auch nicht die Welt. Es bietet eine wesentlich höhere Datenrate und bringt, was bei großen Entfernungen mit ungeklärten Masseverhältnissen wichtig werden kann, noch eine galvanische Trennung mit.

MfG Klebwax