Zitat Zitat von oberallgeier Beitrag anzeigen
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