Liste der Anhänge anzeigen (Anzahl: 5)
Zitat:
Zitat von
modtronic
Ich habe 4M mit dem i2c Bus noch nie geschaft.
Das hab ich nicht einfach nur dahin gesagt, das hab ich verfiziert. Ich beschäftige mich mit I2C schon eine Weile. Vollständig verstanden, wie da alles zusammenspielt, habe ich den Bus, als ich einen Master in Software (bitbanging) geschrieben habe. Und da nicht nur hier der I2C Bus den Ruf hat, nur für ganz kurze Strecken brauchbar zu sein, habe ich selbst einige Versuche gemacht. Ein paar Aufzeichnungen hab ich gefunden.
Der Testaufbau war ein PIC24 mit Hardware I2C. Da der einen eigenen Baudrategenerator für I2C hat, kann man da beliebig leicht an der Frequenz drehen. Er hat außerdem zuschaltbare Pullups an den Pins, man kann also leicht mit internen und externen Pullups testen. Als Slave habe ich damals einen LIS3LV02 Accelerometer auf einem Breakouboard genommen. Da musste man nicht viel löten. Die Software ist simpel: man erzeugt ein Start, schickt die richtige Adresse und ein WRITE und dann ein Stop. Kommt ein ACK, hat der Slave die Adresse erkannt. Ansonsten ist der Bus gestört. So machen das die I2C-Bus Scanner.
Ein Bild, das ich gefunden habe ist dies vom LA
Anhang 34555
Es zeigt, daß der LIS3L auf kurzer Strecke mit 1MHz funktioniert. Das ist das 2,5 fache des garantierten Wertes von 400kHz. Hier der Testaufbau dazu
Anhang 34556
Und auch mit diesem Aufbau waren mehr als die 400kHz erreichbar. Hier habe ich zwei Pullups von 4,7k jeweils an den Enden verwendet. Das Kabel war rund 3,5m lang, ein gewönliches Telefonkabel mit 4 Adern.
Anhang 34557
Das einzige was da zählt ist die Kombination von Kabelkapazität und Pullup. Diese bilden einen Tiefpass für die steigende Flanke des Signals. Je länger das Kabel, desto flacher wird der Anstieg und desto niederohmiger muß der Pullup werden. Ansonsten erreicht der Highpegel bei gegebenem Takt nicht mehr gültige Werte. Aufgrund der I2C Spezifikation gibt es eine theoretische Grenze: der Treiber muß 3mA liefern können, daraus errechnet sich je nach Busspannung ein minimaler Pullup. Und er muß 400pf treiben können, daraus errechnet sich die mögliche Kabellänge. Nimmt man mal typische 50pf pro Meter und weitere 50pf für die übrigen Kapazitäten an, kommt man auf 5m. Praktisch habe ich auch 10m erreicht, dann aber nicht mehr mit 1MHz.
Das diese Überlegungen nicht ganz daneben liegen, zeigen käufliche HDMI Kabel. In denen liegt ein normaler I2C Bus, über den der PC die Daten des Monitors aus einem I2C-EEPROM liest. Und die gibt es bis 5m.
Die Treiber, wie der P82B96, habe mehrere Funktionen. Als erstes erhöhen sie den Strom von 3mA auf 30mA und die Kapazität von 400pF auf 4000pF. Damit kann man also ein längeres Kabel mit größerer Kapazität mit kleineren Pullups und damit gleicher Zeitkonstante betreiben. Aus den 5m werden so 50m. Deine 330Ω stammen aus einer solchen Rechnung, als Kabelkapazität wird hier 3000pF, also eine Länge von rund 60m, angenommen.
Gleichzeitig sind sie auch Levelshifter. Die Busse an beiden Seiten können verschiedene Spannungen haben. Daraus ergibt sich eine interessante Möglichkeit.
Anhang 34558
Man betreibt den Bus im Kabel mit 12V und benutzt diese gleich als Versorgung für den Slave. Wenn man dort einen Schaltregler einsetzt, kann man dort mehr Strom entnehmen, als im Kabel fließt. Da spielt dann auch der Widerstand des Kabels keine Rolle, der Schaltregler kommt auch mit weniger als 12V klar. So verwende ich diese Treiber. Meine I2C Slaves sind typisch Prozessoren mit eigner Umgebung, die über den 12V I2C-Bus gesteuert und versorgt werden. Im einfachsten Fall werden dort Tasten entprellt, Drehencoder ausgewertet und LEDs angesteuert. Es gibt noch einen weiteren positiven Effekt. Der low-Pegel muß jetzt nicht mehr kleiner als 30% von 5V bzw 3,3V sein sondern 30% von 12V. Das Gleiche gilt für den High-Pegel. Der Störabstand wird also massiv größer. Und zu guter letzt schleppt man nicht die direkte Versorgung vom µC und vom Device durch die Gegend und fängt sich dabei Störungen ein.
Und nun zum größten Problem mit längeren Leitungen, dem Übersprechen. Je länger SDA und SCL parallel verlaufen desto größer kann das werden. Hier mal ein SDA Signal, das komplett unbrauchbar ist. Da schlägt SCL voll durch.
Anhang 34559
Das Problem wird noch dadurch verschärft, daß manche die beiden Leitungen des I2C Busses mit differentiellen Signalen verwechseln und auf einem verdrillten Adernpaar führen. Die Beispiele z.B. aus dem P82B96 zeigen aber daß SDA und SCL mit je einer Versorgung ein Paar bilden sollten.
Sorry, ist etwas länger geworden
MfG Klebwax
