I²C mit Bitrate > 100 kHz - nur mit Treiber ?

[oberallgeier]

Einige häufig publizierte und einsehbare Standardempfehlungen für den I²C-Bus sind: kurze Leitungen. In einer ausführlichen Darstellung zum Thema lese ich z.B.

... Kapazität zwischen den Leitern kann durch Verringern der Leitungslängen vermindert werden ...Weitere Ansätze für die Reduzierung von Übersprecheffekten sind eine Erhöhung der Serienwiderstände sowie eine Verringerung der Terminierungswiderstände ...

Ok, die geringeren Terminierungen habe ich. Aber wie kriege ich die Erhöhung der Serienwiderstände bei möglichst kurzen Leitungen hin? Hauchdünne Litzen mit zwei, drei Drähten? Möglichst aus Eisen (nein, kein Konstantan) oder so?

Aus dem und Anderem zusammen mal die Frage:

Wie sieht ein erfahrungsbasierter I²C-Kabelbaum für ein bis eineinhalb Meter Gesamtlänge mit etwa fünf bis sieben Abzweigen - keine Verästelung - aus?

[PICture]

Eine Reduzierung von Übersprecheffekten in Flachbandkabeln bringt auch einer mit GND verbundene Leiter zwischen jeden zwei Signalleitungen. Bei I²C wäre es einfach nur eine GND Leitung zwischen den beiden Signalleitungen.

[Klebwax]

Ok, die geringeren Terminierungen habe ich. Aber wie kriege ich die Erhöhung der Serienwiderstände bei möglichst kurzen Leitungen hin? Hauchdünne Litzen mit zwei, drei Drähten? Möglichst aus Eisen (nein, kein Konstantan) oder so?

Bei einem Open Collector Bus ist das mit den Serienwiderständen Mist. Auf dem Bild in dem Link kann man da etwas sehen. In der Mitte etwa ist SCL ein Stück wesentlich niedriger. Da treibt wohl ein Slave den Bus (clock stretching). Änliches sieht man bei SDA. Da der Master es nicht auf so niedrige Werte schafft, hat er wohl einen Serienwiderstand bekommen. Das verkleinert den Störabstand. Insbesondere wenn SM-Bus Devices im Spiel sind. Die schalten nach TTL Pegel, also mit Low bei ca. 0,8V. Bei diesem Bild würde ich mir mehr Sorgen um den Low-Pegel machen, als um das bißchen Übersprechen.

Und das mit "Terminierung" ist bei einem Open Collector System Unsinn, die Widerstände sind die Arbeitswiderstände der Treiberstufen.

Zum Kabel, es ist wie bei einem Kondensator. Je größer der Abstand zwischen den Leitern, desto geringer die Kapazität. Und je größer die Fläche (also Länge) desto größer auch die Kapazität. Bei einem Meter ist das alles noch harmlos. Wenn man Kabel mit Paaren hat, sollte man SCL und SDA nicht im gleichen Paar führen, um Übersprechen zu vermindern. Also GND und SCL als ein Paar, Vcc und SDA als ein anderes. Und wenn es flach ist, wie PICture sagt, GND, SCL, Vcc und SDA.

MfG Klebwax

[oberallgeier]

Hi PICture, hallo Klebwax,

denke für die Antwort. Die Separierung der Flachkabel-Adern habe ich schon, zwar nur durch je eine GND-Ader. Das fand ich zwar selbst sinnvoll, ABER es kam einfach von den beiden aktuellen Platinen von robotikhardware, deren I²C-Stecker schon automatisch diese Funktion hergibt.

Und Klebwax danke ich für das theoretische Privatissimum. So komme ich ja wieder ein Stück weiter in die tieferen Geheimnisse der Elektronik. Danke! Da fehlts mir ja wirklich an allen Enden und Ecken.

[oberallgeier]

Was bisher geschah:
- Eigene Platine für 10 Servos wurde fertiggestellt und entwanzt (SCL auf SDA und umgekehrt *greuel*). Fertig.
- Die I 2C-Bibliotheken des Forumkollegen (danke ...) wird durchgearbeitet. Ich bin noch dran.
- Die Application Notes von Atmel zu TWI, AVR311, ~12 und ~15 wurden durchgelesen. Fertig.
- Das U SB-I 2C-Testteilchen von ELV, Basis ATmega 88, wurde zusammengesteckt und getestet. Fertig.
- Das U SB-Teilchen wurde auf 400kbps gesetzt.
- Alle drei Platinen (2 fertige von robotikhardware, 1 eigene) sind mit dem U SB-Teilchen bei 400 kbps sicher ansprechbar. Getestet wurden z.B. Sendesequenzen von 16 Bytes und sofort anschließend 10 Bytes zurücklesen. Dabei traten keine Störungen auf.
- Die Tests mit dem U SB-I2 C-Tester wurden mit der identischen Hardwareausrüstung wie die Platine-zu-Platine-Tests durchgeführt - es wurde nur eben der Master gewechselt und ein Stück verdrilltes Kabel, 20 cm - 4 Drähte, an das ursprüngliche Flachbandkabel ZUSÄTZLICH angeschlossen.
- Alle drei Platinen sind als Master und als Slave mit und ohne Timerinterrupts, die unabhängig von der I2C-Geschichte sind, getestet worden.
- Mit den genannen drei Platinen sind Sendefrequenzen um 100 kHz (TWBR > 90) praktisch störungsfrei, höhere Sendefrequenzen werden sofort oder nach mehreren Datentelegrammen gestört.

Die AVR315 empfielt "TWBR should be 10 or higher if the TWI operates in Master mode". Ausserdem berichtet diese AppNote, dass die "CPU clock frequency in the Slave must be at least 16 times higher than the SCL frequency". Daraus müsste bei meinen 20MHz-an-20MHz-Platinen eine Kommunikation theoretisch mit 800 kbps möglich und eine mit 400 kHz eben schon sicher sein. 400 kbps sind mit dem U SB-Teilchen offenkundig möglich (die tatsächliche Taktrate bei eingerasteter 400 kHz-Kommunikation wurde noch nicht gemessen/bestätigt). Leider kenne ich auch nicht den Code dieses praktischen Werkzeugs.

Wo die Kommunikation hängen bleibt, konnte ich noch nicht feststellen, aber ich würde es schon gerne wissen.

Weitere Bemühungen zum I 2C pausieren aktuell.

[Klebwax]

@oberallgeier

I2C ist so ein Hobby von mir (ich würde also gerne helfen). Ich hab aber leider im Moment einen großen Brocken am Hals, so daß ich mich deinem Problem nicht mit der erforderlichen Sorgfalt widmen kann. Sei also nicht böse, wenn Antworten ausbleiben.

MfG Klebwax

[oberallgeier]

... Weitere Bemühungen zum I 2C pausieren aktuell ...

... Nur pausiert das Gehirn nachts nicht immer. Das scheint nicht nur bei mir so zu sein, wenn ich mir so manches 2- (3- oder 4-) -Uhr-nachts-Posting ansehe.

Mir war ein-/aufgefallen, dass der Abbruch der I2C-Kommunikation immer nach einer ganz bestimmten, genau lokalisierbaren Aktion (UART-Ausgabe eines rückgelesenen Datensatzes) erfolgte, auch wenn oft vorher die gleiche oder ähnliche Test-Schreib- und Leseaktion durchgefahren wurde (läuft RC-5-gesteuert). Der Abbruch erfolgte mal nach mehr, mal nach weniger Durchläufen, manchmal sofort nach dem Lesen - je nach I2C-Geschwindigkeit. An dieser Stelle wurde die Leseadresse geschrieben - und danach ein "i2c_start(SLAVE_MoCo+I2C_READ)" gesendet. Jetzt, nachdem ich VOR diesem Readbefehl, nach dem Schreiben der Leseadresse ein i2c_stop gesetzt habe, rauscht mein I2C mit maximaler Geschwindigkeit - maximal nach ATMEL-Spezifikation: TWBR should be 10 or higher... , aktuell habe ich TWBR = 10.

Testaufbau: RNControl, m1284/20MHz, Eigenbau Servoplatine, m328/20MHz, 9-poliges Flachbandkabel, ca. 1m20.

Danke für die vielen hilfreichen Tips, danke m..c..


Anmerkung: Manche Menschen machen keinen Fehler zweimal, aber sie lassen auch keinen aus . . .

[oberallgeier]

... I2C mit maximaler Geschwindigkeit ... TWBR = 10 ...

So, nun ist meine Stimmung doch deutlich gestiegen. Ich habe endlich einen halbwegs realistischen Testaufbau - drei Controller. Dazu ein fast zweieinhalb Meter langes 10fach-Flachkabel. Und I2C läuft mit TWBR = 5. Master wie vor mit 20 MHz. Da machts einfach gute Laune, wenn der Master bei einem Rundruf in seine - hier noch unbekannte I²C-Welt (...for ( uint8_t look=0x00; look <= 0xFC; look = look + 2 )...) auch die tatsächlich vorhandenen Controller erkennt , siehe Dump vom Terminal :

 C501 R5M_x15-16 m1284p/20MHz 28Nov2012 16:46
 I2C >>400kHz [t05], I2C mit Taste [gelb], dann [OK] zu MoCo328
 Motoren rauf+runter mit Taste [P100]
 Gute Funktion mit extINT2 für RC-5
 Initialisierung ADC auf ADC5/PA5=Poti
 UbattADC5 Min = 2 , Mess = 678

 Es folgt Aufruf i2clook
 Suche vorhandene I²C-Devices von 0x00 bis 0xFE
-----------------------------------------------------------------
 Slave erkannt auf 130 dez = 0x82
 Slave erkannt auf 132 dez = 0x84
------------------------------------------------------------
 Rückkehr von i2clook

 Beginn Schleife/RC-5-lesen in ~r1n15~
 Aktiv :  Taste [MIX], [P100], [9] und [gelb]
 Bitte um Aktion _

Ach so - jedes Minus oben im Slave-Suchabschnitt ist eine nicht-antwortende Adresse.

[Sternthaler]

Hallo oberallgeier.

Gratulation zum Erfolg bei diesem Teil-Problem.


Gruß Sternthaler