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

[Sternthaler]

Ahhh, Wetterbericht live. Das lobe ich mir, da ich nun eine Justage meiner Wetteraufzeichnungen vornehmen kann. Was war das nochmal? MSL? Mars Science Laboratory oder doch nur eher vollkommen durchschnittliches, von dir weit entferntes, Salzwasser?


Hallo oberallgeier,

schön, dass du selbst mit weit mehr als 400kHz durch die Berge 'tikst'. So langsam werde ich aber echt ungeduldig da ich immer noch nicht mitbekommen habe warum du so viele Servos steuern willst. Ich kann mir nicht vorstellen, dass du dir einen elektrischen Konkurrenten für das Wandern und Bergsteigen bastelst. Es muss also irgendetwas anderes Sinnvolles sein. Oktopussy für 008?
Warum nur dein Satz: "Dabei drängt mich in meinem neuen Projekt die Zeit."?

Ich bin gespannt, was die Mathefraktion beisteuert und was du daraus wieder zusammenstricken wirst.

Frohes schaffen und eisfrei Straßen wünscht
Sternthaler

[oberallgeier]

Ahhh, Wetterbericht live ... MSL? Mars Science Laboratory ...

Na sooo weit rauf reichen unsere Berge nicht. Die langen nicht mal für Höhenkrankheit . . . Der MSL ist zwar keine bodenständige Sache - im wahrsten Sinne des Wortes - aber doch terrestrisch gebunden; weißt Du ja.

... immer noch nicht mitbekommen habe warum du so viele Servos steuern willst ...

Top secret.

... muss also irgendetwas anderes Sinnvolles sein ... Warum nur ... "... drängt ... die Zeit."? ...

Danke, dass Du mal was Nicht-Sinnfreies von mir erwartest. Denn so richtig sinnig ist es nicht, Getränkedosen so zu modden, dass man nicht mehr den Pullring mit der Hand ziehen muss, sondern die Dose mit der TV-Fernbedienung aufkriegt. Einen Vorteil aber hat mein "... drängt ... die Zeit ..." - Du musst nicht so lange warten, bis der Vorhang aufgeht. Hoffen wir beide jedenfalls.

[Sternthaler]

Ohh, Sternthaler hatte MIST geschrieben!!!

Bitte seht nochmal hier: https://www.roboternetz.de/community...l=1#post562501 nach meiner Korrektur. Ich hoffe, ihr könnt mir verzeihen.

Tenor ist, dass die Fleurylib-Lib auf Slave-Seite sehr wohl per Interrupts läuft.

Gruß, und jede Menge Ablassbriefe
Sternthaler

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