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

Zitat:

---

Zitat von oberallgeier

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

Zitat:

---

Zitat von oberallgeier

Immerhin ist in den von Dir verlinkten Darstellungen sehr schön zu sehen, dass bei 100kbit und 10KΩ gerade noch eine Art 99%-Highpegel erreicht wird.

---

Ich sehe gerade erst diesen Post.

Das kann ich nicht sehen, da keine Scala zu sehen ist. High ist entweder 2/3 * Vcc oder TTL-maßig 2,4V. Wenn der Bus richtig implementiert ist, ist das kein Problem. Die Abläufe bei SCL sollten so sein:

der Master legt Low auf SCL
er wartet eine halbe Bitzeit
er läßt SCL los
er wartet bis er SCL High sieht
er wartet eine halbe Bitzeit
.... usw

Warum wartet er, bis er SCL High sieht? Weil der Slave ja SCL noch auf Low halten könnte, das ist sein gutes Recht. Und eine ungetriebene Leitung mit einem Pullup ist am Ende immer High.

MfG Klebwax

Zitat:

---

Zitat von Klebwax

... elektrisch gibt es keinen ...

---

Hab ich missverständlich beschrieben (aber besser krieg ich es grad nicht hin). Jedenfalls hätte ich durch die Darstellung dort gleich merken müssen, dass meine Testlösung mit den abgeknippsten 10k`s auf nur einer Seite nicht befriedigend laufen wird.

Zitat:

---

Zitat von Klebwax

... Ich würde es daher symmetrisch ...

---

Deine Erklärungen sind ja prima verständlich. Das hilft mir dabei, die für mich als Nicht-Elektroniker schwer verständlichen Sachverhalte in der Dokumentation von NXP und in den Tutorials besser zu verstehen. Vor allem Deine Richtwerte "... 1 Meter Kabel hat typisch 50pF ..." und so helfen mir beim Begreifen der Sachverhalte. Danke. So halbwegs hatte ich die durch dieses Bild

......Bild hier  
......© by i2c-bus.org

ja schon mitgekriegt. Danke, das war gute Gehirnnahrung! Und das mit den Buffern/Treibern und dem Übersprechen (sind ordentlich gesendete Elektronen zu unterscheiden von übergesprochen-/induzierten?) ist mir jetzt auch klarer. Danke!

Ach so, "... sehen, dass ... eine Art 99%-Highpegel ..." mit den 99% meinte ich etwas leichtfertig "recht viel". Auch missverständlich.

Hallo oberallgeier,

die I2C-Spezifikation gibt auch eine dynamische Lösung für den Pull-Up-Widerstand an.
Über http://www.i2c-bus.org/de/terminieru...-kapazitaeten/ findet man die dort verlinkte Spezifikation http://www.classic.nxp.com/acrobat_d...8/39340011.pdf

Auf Seite 41 ist im Kapitel "17.2 Switched pull-up circuit for Fast-mode I2C-bus devices" mit Fig.43 so eine Schaltung aufgeführt.

Ok, du benötigst hier auch noch ein zusätzliches Bauteil wie bei deinem Treiber-Chip. aber hier nur ein einfaches HCT4066 plus 2 weiterer Widerstände. (1/4 Chip + 1 R pro I2C-Leitung)

Gruß Sternthaler

Zitat:

---

Zitat von Sternthaler

... die I2C-Spezifikation gibt auch eine dynamische Lösung für den Pull-Up-Widerstand an ...

---

Hi, schön, dass Du wieder öfters im Forum zu lesen bist! Danke für den Link, ich kannte nur die vermutlich neueste NXP-Dokumentation, UM10204 User manual Rev. 4 — 13 February 2012 (kennen - den Titel, nicht den Inhalt parat haben!), da steht erheblich weniger als in der von Dir verlinkten "original Philips" THE I 2C-BUS SPECIFICATION VERSION, 2.1, JANUARY 2000 document order number: 9398 393 40011.

Eigentlich dachte ich, I²C sei easy. Einfach die Fleury-Lib einbinden und loslegen, auf den meisten käuflichen Platinen ist ja schon extra ein Stecker dafür da ... Und nun hats den Anschein, ich muss mich da richtig reinarbeiten. Das fängt mit diesen Busproblemen an und geht mit Fehlerverarbeitung weiter (was tun, wenn der Slave nicht korrekt antwortet oder unsinnig stretcht usw). Dabei drängt mich in meinem neuen Projekt die Zeit. Aber ok, nochmals danke für den Link, ich werde das erstmal in Stufen mit geringem Aufwand verbessern - 3k3 oder bei mehr Slaves weniger. Dann natürlich ein Kabel, bei dem die beiden Leitungen nicht nebeneinander liegen, vielleicht find ich eins mit getrennt geschirmten Adern (mein Leitungssponsor ist sehr entgegenkommend). Und dann mal die alte und die neue Leitung am DSO ansehen und vergleichen.

Hilft dir zwar nicht weiter, aber ..... Probleme mit I²C hatte ich nur ein mal: Das war ein Display mit I²C und einem angegebenen Innen-R der Eingänge von 600-1000 Ohm. Bei sowas tut man sich dann mit "normal" bemessenen PullUps schwer und ich hab auch in diesem Fall mehr als 100kBit nicht geschafft. Zum Glück hat dieses Display auch SPI (DOG-XL).

Zitat:

---

Zitat von Crazy Harry

Hilft dir zwar nicht weiter, aber ...

---

Hilft mir doch, danke! Im Moment gehts nämlich nicht wirklich weiter. Aber der Reihe nach.

An beiden Platinen - RNControl und RN MotorControl - die 10k ausgelötet und durch 2k7 ersetzt. Happy und übermütig gleich ISP mit 800k angefangen. Ging nicht. Mehrere Tests brachten:
o Senden geht bis etwa 400 k recht ordentlich (fünf Motordaten: Aktualisierungscode, Richtung1-vor/zurück, PWM1, Richtung2-vor/zurück, PWM2).
o Rücklesen (oder empfangen?) geht bei 200 k gerade noch - manchmal, nicht immer (Eine initialisierte Ziffernfolge im Slave vom Master überschreiben und zurücklesen, mit geänderten Daten überschreiben und wieder zurücklesen). Ob die I2C-Kommunikation beim Senden, Lesen oder Empfangen hängen bleibt weiß ich (noch) nicht.

Eigentlich geht es zwischen diesen beiden Platinen mit dem 55cm Flachband (RN-Definition-Belegung = zwischen SCL und SDA liegt ein GND-Strängelchen) richtig ordentlich nur mit 100 kHz. Ok, ich werde mal ne Weile damit leben, sonst läuft mir die Zeit weg.

Zitat:

---

Zitat von oberallgeier

Hilft mir doch, danke! ... Eigentlich geht ... nur mit 100 kHz ...

---

Und bei den vielen Tests der letzten Tage war wohl der eine oder andere seltene Fall dabei, dass sich der Master auch bei 100 kHz aufgehängt hat - oder vom Slave aufgehängt wurde.

Codeschnippsel vom Master - Lesen I2C-Buffer

Code:

---

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
//      Lesen vom Slave    ##### mit Änderung/Zusatz
  if(!(i2c_start(SLAVE_MoCo+I2C_WRITE))) //Slave bereit zum schreiben/lesen?
  {                                    //
// - - - - - - - - - - - - - - - - - - - - - - - - - -
//      Musterzeile vom RN Wissen
//  i2c_write(0x00); //Buffer Startadresse zum Auslesen
//  i2c_rep_start(SLAVE_ADRESSE+I2C_READ); //Lesen beginnen
// - - - - - - - - - - - - - - - - - - - - - - - - - -
    i2cdmy = i2c_write(0x00);          // Buffer Startadresse 0 zum Auslesen
          i2c_stop();                  //
    i2cdmy = i2c_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen
////i2cdmy = i2c_rep_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen
    btst1  = i2c_read (ACK);            // 1. von 5 Bytes lesen...

---

Kann das an den Interrupt(s) liegen? Der Master (mega1284) hat einen Timer-Interrupt, 50µs von TIMER2 COMPA, der Slave (mega328) hat ebenfalls Timer-Interrupt, 50µs von TIMER2 COMPA, dazu werden kommen zwei extINT0 und ~1 von den Encodern, evtl. noch andere Interrupts. Der TIMER2 COMPA ist mit Vector 8 resp. 10 relativ hoch priorisiert, die extINT mit 2 bzw. 3 sehr hoch - dagegen ist der TWI mit vector 25 resp. 27 weit unten. Nun soll natürlich eine IRS immer warten, bis die laufende fertig ist - ich lasse keine nestet Interrupts zu - aber

es könnte Zeitverschiebungen in der I2C - Kommunikation geben. Macht das etwas? Könnte das der Fehler sein?

Was ist denn hier los? NIX????

Hallo oberallgeier,

natürlich kann es an den Interrupts liegen.

------------- Halber - BLÖDSINN -------------------------------------------------
\/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/
Also als erstes: Die Fleurylib arbeitet NICHT mit Interrupts. Deine Ansatz mit dem INT-Vektor ist hier somit komplett vergeblich. Aber leider kommt es somit noch schlimmer.
Wenn nun die Fleurylib-Software ackert und das Timing durch NOP's oder Loop's erzeugt wird, dann jagen deine doch recht häufigen 50µs-Timer einiges an Zeit durcheinander. Zumindest deutet da vieles drauf hin.
/\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\
------------- Halber - BLÖDSINN -------------------------------------------------
Das da oben war nicht ganz richtig.

- Auf der Master-Seite wird nicht mit Interrupts gearbeitet.
Timing-Loops oder NOPs werden hier allerdings auch nicht benutzt. Die Lib arbeitet sauber mit den Statuswerten der I2C-Hardware. Somit läuft die Wartezeit ausserhalb der I2C-Hardware und darf entsprechend auch durch Interrupts unterbrochen werden. Die Hardware sollte dann aber ohne Probleme die Daten transportieren!

- Auf der Slave-Seite allerdings komplett im Interrupt.
Hier könnte die Fragestellung zur Priorität von oberallgeier also doch noch wichtig werden!
------------- Halber - BLÖDSINN - nachgearbeitet ende ---------------------------

Du solltest mal eine Abschätzung machen wie lange deine Interruptfunktion denn so benötigt.
Ein Ansatz zur Lösung könnte folgendermaßen aussehen:
- Am Ende der INT-Funktion setzt du einen Merker auf TRUE
- In deinem Hauptprogramm rufst du NUR dann eine I2C-Funktion auf, wenn der Merker gesetzt ist.
- Den Merker dann in dem if sofort zurücksetzten, damit eine weitere Main-Loop keine 2.tes I2C-Funktion aufruft.
- Main ackert weiter und bekommt nach dem Timer-Interrupt-Merker=TRUE wieder die Erlaubnis ein wenig Fleurylib-Zeit zu verbrennen.

Die Idee ist, dass du innerhalb der Fleurylib-Funktionen für die nächste Zeit nicht gestört wirst wenn die aufgerufene Fleurylib-Funktion selbst weniger als 50µs benötigt. Die Zeit kannst du ja selber mal nachrechen.
Wenn dein Rechen zu dem Schluss kommt, dass die Fleurylib-Funktion länger dauert, kannst du mein Geschreibsel sofort in die Tonne treten, da dann das Prinzip nicht mehr funktioniert.

Hier hätte ich aber auch noch einen Link zu einem Leidensgenossen von dir. Eventuell nützt es was: http://www.elektronik-projekt.de/thread.php?threadid=3197

Gruß Sternthaler

Zitat:

---

Zitat von Sternthaler

Was ist denn hier los? NIX???? ... Die Fleurylib arbeitet NICHT ...

---

Danke erstmal für Deine freundliche Unterstützung und Deine Sorge.

Nix los? Na ja, es war die letzten Tage gigantisch sonniges Herbstwetter - oberhalb von 1200 MSL. Da rufen die Berge und die Kletterwände; Fliegen geht nicht, weil ALLE Landeplätze im Nebel liegen :-/ . Beispiel: Verschnaufpause knapp unter 2000 MSL mit freiem Oberkörper . . . auch geklettert wird derzeit öfters ohne Hemd. Aber Deine Frage zielt anderswo hin. Da ist auch nicht wenig los.

Servoplatine und -routine müssen noch werden. Die Routine hatte Probleme gemacht (weil ich mich eigensinnig wie immer auf ein bestimmtes Konzept versteif(t)e). Mittlerweile läuft die 10-Servo-Routine störungsfrei am Breadboard-m328-20Mhz. Was heißt störungsfrei? Gestern Nacht, eher heute, habe ich durch die fliegende und daneben gesteckte Verdrahtung zwei Billigservos gebraten. Richtig verdrahtet liefs dann wieder. Und ich bin richtig stolz darauf, zehn Servos (na ja, auf den meisten Kanälen läuft derzeit nur der Oskar) mit unterschiedlichen Geschwindigkeiten und unterschiedlichen Start- und Zielpunkten (zeitlich und örtlich) mit einer selbstgebauten Routine ansteuern zu können. Die Routine braucht noch einen Feinschliff z.B. für den spätere I²C-Datenaustausch, das Abfangen von Fehlern etc. Bekanntlich frisst so etwas die meiste Zeit.

Das mechanische Konzept des gesamten Projektchens macht auch Arbeit - ausser einem DINA0 mit etlichen Strichen, viel zu wenigen, steht noch nix.

Dazu kommen noch Nebenarbeiten durch ein Sonderangebot von Motoren, die ich für einen Hilfsantrieb einsetzen werde.

Schließlich zum I²C. Unser freundlicher Mathefreakkollege aus unseren gemeinsamen Navigationsdiskussionstagen unterstützt mich dabei. Da ich aber derzeit nur zwei endgültig einzusetzende Platinen habe, später werden es mehr, warte ich derzeit, bis ich a) die I²C-Geschichte des Kollegen halbwegs verstehe, b) mehr endgültige Platinen mit einer endgültigen Kabelbaumlänge habe und c) die kollegialen low-level-Programme des Kollegen mit meinen bescheidenen C-Kenntnissen ins fertige Projekt einbinden kann. Linken von relokativen Compilaten konnte ich vor vielen Jahren zu meiner Fortranzeit. Davon ist aber i) nix mehr übrig und ii) passt es sowieso nicht.

Du siehst - kein Moos, trotzdem was loos.

Freundliche Grüße aus dem mittlerweile kühlen Allgäu wo wir ruhig auf Winterreifen dem wochenendlichen Schneechaos entgegenträumen.

Nachtrag zum Wetter. Stand ungefähr Di, 23.10, 0830: meine Terrasse auf 812m MSL hatte 5°C, Terrasse einer Berghütte am Nebelhorn auf 1934m MSL hatte 16°C - da war es aber drei Stunden früher (also NACHTS!) etwas wärmer.