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

[oberallgeier]

Zusammenfassung vom 03. Dez. 2012, 09:20.
Die Aufgabe ist für mich gelöst, die durch Intitialisierung vorgegebene Übertragungsrate beträgt deutlich mehr als 400 kHz: TWBR=5 läuft fehlerfrei, mit TWBR=17 erhalte ich laut Rechnung mit dem 20MHz auf Master und Slave 400 kHz.
In diesem Posting (klick) ist das verdächtige Codeteil zu sehen nach "i2cdmy = i2c_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen".
In diesem Posting (klick) wird über den letzten, sehr gut funktionierenden Stand berichtet.

- - - - - Es folgt der ursprüngliche Beitrag - - - - -

Hallo Alle, bitte um Ratschläge.

Aufgabe:
o Eine Platine als Master, derzeit mit mega1284/20 MHz, I²C mit je 1x10kΩ, soll mehrere Slaves - weniger als zehn - treiben, die verschiedene Aufgaben erledigen.
o Derzeit hängt an einem Flachbandkabel 55cm EIN einziger Slave mit mega328/20MHz, I²C mit je 1x10kΩ.
o Auf Master und Slave wird zum I²C-Betrieb die Fleurylib benutzt.

Die Kommunikation läuft in dieser Konfiguration nur dann störungsfrei, wenn ich sie mit gemächlichen 100 kHz betreibe. Tests mit 200 gehen öfters schief, ein Test mit 400 funktioniert gleich garnicht. Diese 100 kHz sind mir eigentlich schon bei diesem 1-Slave-Aufbau zu wenig, da der Slave als Motorsteuerung arbeitet und zukünftig recht viel Rechenarbeit schon zu Regelung und Fahrplanung haben wird.

Nun möchte ich ja später mehrere Slaves dranhängen - da fürchte ich, dass dann der Master (und der Bus) recht viel zu tun bekommen. Ne ganz grobe Milchmädchenrechnung (Daumenlutschen) lässt vermuten, dass ich mit der geplanten Kommunikation bei der derzeitigen Datenrate das spätere, ganze System recht ausbremsen würde.

MUSS ich für höhere Bitraten unbedingt einen Treiber verwenden - z.B. den PCA9600? Da ich fertige Platinen verwende (~n möchte) käme mir ein aufge"klebter" Bustreiber garnicht gelegen . . .

Danke für Eure Hilfe.



PS: GAAAANZ grosses Manko im Forum: die Suche mit dem Suchbegriff "I2C" wird abgelehnt:

Die folgenden Probleme traten bei deiner Suche auf:

1. Die folgenden Wörter sind sehr allgemein, zu kurz oder zu lang und wurden daher in der Suchanfrage ignoriert:
   I2C

[djdune]

Schon mal einen kleineren Pull-up versucht? Je höher der Takt, desto niedriger der Pull-up. Ich nehme für 400kHz (mit PIC) 4k7 und hatte noch nie Probleme

[PICture]

Hallo!

Bei jedem Bus wird die Bandbreite per Tiefpass aus "pull up's" und Kapazitäten des Kabels bestimmt. Daher glaube ich, dass bei gleichem Kabel eine Senkung von "pull up's", die durch alle I2C Teilnehmer noch auf "low" gezogen werden können, helfen wird.

[Crazy Harry]

Hab ich das richtig verstanden ?

Eine Platine als Master, derzeit mit mega1284/20 MHz, I²C mit je 1x10kΩ, soll mehrere Slaves - weniger als zehn - treiben, die verschiedene Aufgaben erledigen.

Am Master keine PullUps würde ich mal sagen und du kannst auf 2K runter gehn (ich schließe mich also meinen Vorrednern an ). Eine ähnliche konfiguration habe ich laufen mit 2.5m Kabel dazwischen und eben 2K PullUps.

[oberallgeier]

Hallo Kollegen,

für die prompten Anworten danke ich euch. Ich hatte (vor dem ersten Posting natürlich, gestern fast Mitternacht) die I2C-Tutorials im Ro boterNETZ/RN-W issen , im mikrocontroller.net , dort auch ziemlich genau mein Thema - daher auch der Trick mit dem PCA9600, und die ausführliche Dokumentation bei i2c-bus.org gelesen. Bei allen steht ja etwa das Gleiche drin das ihr mir ratet - bei den letzteren Leuten auch sehr ausführlich und anschaulich mit Terminierungen und Entstörungen durch C´s und R´s. Aber was genau wie klappt - da wollt ich mal ausnahmsweise nicht so viel experimentieren.

Hab ich das richtig verstanden ... ähnliche konfiguration ... 2.5m Kabel ... 2K PullUps ...

Danke! Das lässt ja hoffen. Also werd ich mal DOCH experimentieren und die Bedrahtung der PullUpWiderstände am Master mal einfach aufknippsen. Auslöten und 2K PullUps krieg ich dann, wenn nötig, immer noch hin.

Danke !

[oberallgeier]

... DOCH experimentieren und ... PullUpWiderstände am Master mal einfach aufknippsen ...

Na ja, die Arbeit stand dafür. ABER ich hätte natürlich den Leuten von der i2c-bus.org glauben sollen - die haben sehr hübsch dargestellt, wieso das eine Ende des I²C-Bus ne andere Aufgabe hat als das andere Ende *ggg*.

Kurz:
o Beide 10k am Master aufgeknipps - also ohne PullUp.
o Kommunikation schrittweise von 100k über 200k, 400 und 600 auf 800. Bis 600k läuft die Master-Slave-Übertragung, aber oberhalb von 200 läuft das Lesen des Masters (vermutlich wohl das Senden des Slave) nicht mehr, bei 200 bis 400 recht eingeschränkt.

Nun könnt ich mir mal nen Speicheroskar besorgen und das Ganze ansehen, vermutlich werden die 2k von Cracy Harry ne Weile reichen. Ähhh - natürlich könnte ich auch einen zukünftigen Kabelbaum (annähernd) aufbauen, die Kapazitäten messen und nach den Ausführungen in der NXP-Dokumentation UM10204 Rev. 4 — 13 February 2012 die Widerstände berechnen. Aber ich werde wohl gleich die Lösung mit dem Bustreiber machen. Scheint mir weniger Aufwand zu sein. Den gibts beim grossen R, SO-8 oder TSSOP8 - den kriegt man vermutlich sogar ganz gut an der Steckbuchse unter . . .

Fazit:
Gleich richtig gemacht ist manchmal die halbe Arbeit.

[Valen]

Etwas spät: http://www.dsscircuits.com/articles/...resistors.html

[Klebwax]

Na ja, die Arbeit stand dafür. ABER ich hätte natürlich den Leuten von der i2c-bus.org glauben sollen - die haben sehr hübsch dargestellt, wieso das eine Ende des I²C-Bus ne andere Aufgabe hat als das andere Ende *ggg*.

Kurz:
o Beide 10k am Master aufgeknipps - also ohne PullUp.
o Kommunikation schrittweise von 100k über 200k, 400 und 600 auf 800. Bis 600k läuft die Master-Slave-Übertragung, aber oberhalb von 200 läuft das Lesen des Masters (vermutlich wohl das Senden des Slave) nicht mehr, bei 200 bis 400 recht eingeschränkt.

Ich hab zwar nicht gelesen, was i2c-bus.org über die unterschiedlichen Seiten des Busses schreiben, elektrisch gibt es keinen. Sowohl SCL als auch SDA können und werden sowohl vom Master als auch vom Slave getrieben. Deine Tests ergeben das gleiche Bild.

Ich würde es daher symmetrisch machen. Die Treiber müssen 3mA liefern können und dabei noch einen logischen Low-Pegel erzeugen. Modernen CMOS-Bausteinen fällt das leichter, da sind leicht 20mA möglich, daher dürfen es auch etwas mehr als 3mA sein. Aus der Busspannung und 3mA läßt sich leicht der passende (kleinste) Widerstand ausrechnen. Diesen würde ich zur Hälfte auf der einen und der anderen Seite plazieren, also bei 3,3V je 2,2k. Selbst mit etwas größeren Widerständen hab ich mehrere Meter hinbekommen. In einem DVI-Kabel ist auch ein I2C Bus, das geht locker über 5m.

Ein weiteres häufig anzutreffendes Problem bei längeren Kabeln ist übersprechen. SCL und SDA sollten auf keinen Fall nebeneinander liegende Adern nutzen oder etwa miteinander verdrillt werden. 1 Meter Kabel hat typisch 50pF, wirkt also als ob man 50pF direkt von SCL nach SDA schaltet. Das kann man auch leicht mit einem Scope (auch ohne Speicher) ansehen. Einfach in einer Endlosschleife Start, ein Byte, Stop senden. Am besten sendet man so was wie 0x0f, dann kann man das Übersprechen von SCL sowohl bei SDA 0 und 1 sehen. Ein halber Meter verdrillter Klingeldraht liefert da tolle/erschreckende Bilder.

Die Verwendung von Buffern ist ein zweischneidiges Schwert. Da es kein Signal zur Richtungssteuerung des Busse gibt, leben sie davon, auf beiden Seiten einen leicht unterschiedlichen Low-Pegel zu haben. Das sind so etwa 200mV. Da je nach Device möglicherweise ein Low-Pegel nach TTL, also 800mV verlangt wird, reduziert sich der Störbstand signifikant. Manche Buffer darf man deshalb nicht kaskadieren. Sollte es ein Problem mit Übersprechen geben, können sie es verstärken, da sie steilere Flanken erzeugen.

Auf einem PC-Mainboard finden sich unter verschiedenen Name einige I2C Busse. Obwohl z.B. am SMBus alle Ramriegel die Temperatursensoren und manchmal auch die Lüftersteuerungen angeschlossen sind, habe ich dort noch keine Buffer gesehen. Und auf dem DVI gehts direkt über 5m und mehr zum Monitor.

Inwieweit die Software hereinspielt, kann ich nicht sagen. Ich kenne die Fleurylib nicht. Die paar Zeilen, um mit dem I2C Controler zu reden, mache ich selbst und die Initialisierung der Hardware ist hochgradig Chipabhängig. Ich habe aber vor kurzem einen Fall verfolgt, wo das I2C Problem in der Software lag. Es gab da einen Programmpfad, wo kein Stop gesendet wurde, kann passieren und ist leider blöd zu finden.

Ich hoffe, nicht zur allgemeinen Verunsicherung beigetragen zu haben

MfG Klebwax