Hallo liebe Leute,
ich weiß ich weiß bei dem Titel denk sich jetzt "Nicht schon wieder diese leidige Frage nach der Reichweite von I2C"
Aber mir geht es um ein bisschen was anderes, nämlich um die Vergrößerung der Reichweite durch Verwendung von differentiellen (symmetrische) Übertragung. Ich würde gerne wissen ob da jemand schon mal erfahrungen gemacht hat?
Ich denke wenn man da ein CAT Kabel verwendet (ein Twisted Pair hat einen Wellenwiderstand 100 Ohm; Bei einer Übertragungsgeschwindigkeit von 5Mbit/s =^ 5MHz tretten spätestens bei ca 15m Wellenphänomene auf) dann müsste man doch theoretisch recht weit kommen. Ein CAT hat 8 Adern, davon verwende ich 1 für die Masse, 2 für eine bipolare Spannungsversorgung, 2 für symmetrische SDA Leitung und 2 für symmetrische SCL Leitung.
Die Taktleitung (SDA) müsste ja nur unidirektional implementiert werden, denn da gibt der Master einfach den Takt vor und fertig. Also müsste man beim SDA Anschluss des Masters eine Konvertierung von single-ended auf differential machen und dann vor jedem Slave eine Rückwandlung. Die Wandlung beim Master könnte man etwa mit dem AD8476 machen. Die Rückwandlung müsste reichen einfach die zwei leitungen an den Eingang eines OPVs legen. Sorgen würde mir da die Anpassung auf die 100 Ohm machen. Wenn man etwa den AD8476 verwendet: wie passe ich den Ausgang dann auf die 100 Ohm an?
Die Daten könnnen auf der SCL ja in beide Richtungen geschoben werden, also bidirektional. Da wirds schon ein wenig tricky weil ich weder einen IC kenne der das macht noch mir eine Schaltung einfallen würde.
Naja soweit ein paar Gedanken von mir dazu. Würde mich freuen wenn es vielleicht ein paar Erfahrungen schon gibt und wenn eine nette Diskussion entsteht!
Mit lieben Grüßen
Andi
Hallo!
Für konkrete (gemessene) Kapazität (C) einer Leitung und Übertragungsgeschwindigkeit muss für vorhandene Länge und Impedanz des Kabels ausreichend "starker" Treiber fürs Umladen von C verwendet werden um die Dämpfung zu minimieren.Zitat von PeruNova
MfG (Mit feinem Grübeln) Wir unterstützen dich bei deinen Projekten, aber wir entwickeln sie nicht für dich. (radbruch) "Irgendwas" geht "irgendwie" immer...(Rabenauge) Machs - und berichte.(oberallgeier) Man weißt wie, aber nie warum. Gut zu wissen, was man nicht weiß. Zuerst messen, danach fragen. Was heute geht, wurde gestern gebastelt. http://www.youtube.com/watch?v=qOAnVO3y2u8 Danke!
Probiers doch einfach aus. I²C ist grundsätzlich ein ziemlich ungeeignetes Langstreckenprotokoll, und außerdem gilt: je mehr du rumfummelst und selberstrickst, desto weniger wird wahrscheinlich funktionieren.
Wenn es unbedingt I²C über lange Strecken sein muß würde ich bei folgendem ansetzen:
-Takt runterschrauben, so richtig runter
-Pegelwandler 12V
-sonst nix weiter
Warum muß es I²C sein? Wäre z.B. CAN keine Alternative? Und wie weit muß as eigentlich...
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
Strom fließt auch durch krumme Drähte !
Hallo Andi,
Scheinbar hast du dich noch nicht wirklich mit der Funktion des IIC beschäftigt.
Das Kabel ist das kleinste Problem, hier stellt sich nur die Frage nach dem Timing, was wiederum vom Bustakt abhängt.
SDL ist auch schon bidirektional. Wenn es dem Slave zu schnell geht, kann er einfach die SDA-Leitung nach Masse ziehen. Der Master sieht dann dass SDA auf Masse bleibt und deshalb die Flanke für das nächste zu übertragende Bit fehlt. Der Master wartet dann, bis SCL wieder auf H-Pegel geht.
Bei SDA ist das so ähnlich mit dem ACK/NAK.
Deshalb verwendet IIC OpenCollektor Treiber und einen Pull Up für den H-Pegel. Bei dieser Konstruktion kann man jederzeit einen H-Pegel mit einem L-Pegel überschreiben ohne das es zu einem Kurzschluss kommt.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Hallo,
Klebwax hat den Hinweis für Leitungstreiber P82B96 vermittelt.
Meine Erfahrungen mit IC sind positiv. Mit Takt 200kHz, Spannung 5V und „Normalkabel“ noch keine Probleme gehabt.
In einem Projekt ist die Leitungslänge ca. 160 Meter. Musste nur die Leitungswiderstände anpassen.
Ja der alte „Schrott“ funktioniert eben noch. Kann sein der Aufbau und die Örtlichkeiten spielen eine Rolle.
Nun kommt noch die „Auflösung“ der I2C Teilnehmer hinzu. Einige mache es locker mit 400kHz Takt zB.(PCF8574x) aber der PCF 8591 wohl kaum (braucht halt die Zeit den internen Puffer zu aktualisieren).
Datenaustausch MC zu MC mit I2C ist nicht mein Ding. Dies mache ich mit Uart.
Natürlich wer Ethernet anwendet ist „Modern“ und auf jedem Fall die bessere Variante.
Gruß der alte Mann
Geändert von fredred (09.11.2015 um 16:53 Uhr)
Hallo Andi,
Hier gibt's einiges zu deinem Thema:
http://www.nxp.com/documents/applica...te/AN10364.pdf
http://www.nxp.com/documents/applica...te/AN10658.pdf
I²C wurde halt als günstiges System zum Verbinden von On-Board-Modulen entwickelt, wie z.B. in Fernsehern.
Nun ist es halt nicht ganz einfach eine Ente in einen Porsche umzubauen.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Das ist prinzipiel richtig. Für etwas mehr taugt das aber schon. Seit einigen Jahren findet ein großangelegter Feldtest für Verbindungen über Kabel mit bis zu 5m statt. Das nannte sich am Anfang DVI und wird jetzt als HDMI fortgesetzt. Dabei wird an einigen 100 Millionen Geräten getestet, ob ein Computer die technischen Daten eines Monitors mit I2C auch über längere Kabel auslesen kann. Bisher scheint das recht erfolgreich zu sein.
MfG Klebwax
Strom fließt auch durch krumme Drähte !
Hallo Klebwax,
Kannst du mir das mal erklären?
Die einzige Gemeinsamkeit zwischen IIC und DVI/HDMI ist die synchrone Übertragung.
Aber diese ist schon einiges älter als IIC! Diese gab es schon 1964 in der V.24-Norm.
MfG Peter(TOO)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
Auf den HDMI Stecker Pins 15,16 liegt ein I2C Bus und auf 18 liefert der PC die 5V dazu. So kann der PC die Daten eines Monitors auslesen, selbst wenn der kein Power hat. Mit dem Videosignal hat das nichts zu tun.
MfG Klebwax
Strom fließt auch durch krumme Drähte !
Berechtigungen
Zitieren
Lesezeichen