Hallo, ich habe einen I2C Bus mit 1,4m länge. Das ganze wurde mit normaler Litze verdrahtet und läuft auch noch über eine Lüsterklemme. Abgeschlossen ist der Bus auf der einen Seite mit 5,6k auf der anderen Seite mit 33k. Als Busteilnehmer dienen 2 xmega 128 A1. Bustakt ist 5 Khz. Beide Prozessoren hängen an der gleichen Versorgung. So nun zu meinen Problem: Der Bus läuft nur durch Handauflegen oder Osziloskop anlegen und zwar egal an welcher Seite. Auf dem Oszilloskop sieht das Signal ordentlich aus. Akku oder Netzbetrieb machen da keinen Unterschied. Könntet ihr mir ggf einen Tip geben wie ich dem Problem weiter auf den Grund gehen kann? Gruß Peter
Hallo, das ging ja flott. @Troll Masseverbindung ist meiner Meinung nach ok. Sie ist allerdings auch 1,40m lang. Belasted wird sie mit maximal 100mA bei einem Querschnitt von 0,5qmm². Eingespeist wird in der Mitte. Die 2 Pullups habe ich versuchsweise eingebaut. @Michi Ich will das Problem einigermasen sicher lösen. Dazu Sollte ich wissen warum es nicht Funktioniert. Gruß Peter
Martin B. schrieb: > Es gibt von NXP den PCA0601, der ist genau für so was gemacht. 9601 natürlich. Treibt 4nF.
Peter schrieb: > So nun zu meinen Problem: > Der Bus läuft nur durch Handauflegen oder Osziloskop anlegen und zwar > egal an welcher Seite. Auf dem Oszilloskop sieht das Signal ordentlich > aus. Akku oder Netzbetrieb machen da keinen Unterschied. Könntet ihr mir > ggf einen Tip geben wie ich dem Problem weiter auf den Grund gehen kann? Das klingt nach einem Masse Problem oder (extrem selten) nach einer fehlenden kapazitiven Belastung. Warscheinlicher ist der Massefehler. Von daher also da alles checken. Ansonsten I2C so einsetzen wie er gedacht ist und das ist mit Sicherheit kein 1200mm ungeschirmtes (nein Schirmen bringt auch nix) Kabel.
Die Pullups sind zu groß! 3k3 bei 5V, das wäre der richtige Wert. 33k
oder auch 5k6 erzeugen doch viel zu flache Schaltflanken.
+5V
|
_
| | 3k3
220R |_| 220R
µC1 ----- | ----- µC2
SDA ---| |-----*----| |--- SDA
----- -----
GND -------------------------- GND
SCL ...
Es gibt allerdings auch Leute, die mit I²C einen Hausbus realisiert
haben.
Gruß
Carsten
Carsten Wille schrieb: > Es gibt allerdings auch Leute, die mit I²C einen Hausbus realisiert > haben. Gut, das geht vllt., wenn man kräftige Treiber/Tranceiver einsetzt und langsame Datenraten in Kauf nimmt. Allerdings ist I2C dafür nicht gedacht gewesen, hat keinerlei Vorkehrungen für fehlerhafte Bits auf den Leitungen und sollte eigentlich innerhalb eines Gerätes die Peripherieverdrahtung vereinfachen. Da es eine synchrone Übertragung ist, sind Laufzeiten und Flankensteilheiten nicht zu unterschätzende Probleme.
Mach die Pullups noch kleiner, für 5 Volt würde ich 1k8 empfehlen (am Master) und 220 in die Leitung(en) zu den Slaves.
Matthias Sch. schrieb: > Gut, das geht vllt., wenn man ... langsame Datenraten in Kauf nimmt. 5kHz ist bei 1,4m eine niedrige Datenrate. @Peter Wenn du ein Oszilloskop hast, dann häng das doch mal über einen 1MΩ Widerstand an den Bus und zeig die Signale, wie sie an den beiden Enden aussehen (Masseklemme bitte auch mit umhängen). Du kannst auch versuchsweise mal in die Masseleitung einen Widerstand reinklemmen und darüber ggf. fließende Masseströme messen.
tt2t schrieb: > Mach die Pullups noch kleiner, für 5 Volt würde ich 1k8 empfehlen (am > Master) und 220 in die Leitung(en) zu den Slaves. 1k8 ist zu wenig. Da stimmen durch die notwendigen Serienwiderstände von 220R die Pegel nicht mehr.
Angehängte Dateien:
Hallo, ich habe nochmal etwas gemessen/probiert: Bild 1 ist mit 1MOhm in Reihe mit den Tastköpfen gemssen. Dementsprechen verwaschen ist das Signal natürlich. Bei Weiß kam es zu keiner verbindung bei gelb habe ich den "Finger" draufgehalten und es kam zu einer Verbindung*. Bild 2 ist mit dirkt Angeschlossenen Köpfe. Auffällig ist dabei der eine kleine Einbruch dieser ist nach dem Paralellschalten von 1,8N zur Datenleitung nicht mehr da. Eine Verbindung* kommt damit auch ohne Tastköpfe. Woher könnte dieser Einbruch kommen? Könnte das der Grund sein? Gruß Peter *Als verbindungscheck schaut der Slave zur Zeit nur ob die Adresse(0x50) stimmt. Es werden sonst keine Daten Übertragen.
Michael schrieb: > Matthias Sch. schrieb: >> Gut, das geht vllt., wenn man ... langsame Datenraten in Kauf nimmt. > > 5kHz ist bei 1,4m eine niedrige Datenrate Das war nur als Kommentar zum Hausbus - nicht als Antwort auf das Problem des TO. @Peter: Was benutzt du als Master? Ist das die TWI Hardware oder machst du bitbanging? Ich frage deshalb, weil es mir die Datenwechsel verdammt knapp aussehen und nahezu zeitgleich mit dem SCL -> low kommen. Wenn auf SDA da nur eine kleine Speicherkapazität liegt, sieht der Slave evtl. den Datenwechsel noch in der High Phase von SCL und per Definition kann das ja nur eine Start- oder Stopbedingung sein. Damit gibt der Slave die Übertragung auf. Wenn es irgendwie möglich ist, entspanne das Timing ein wenig, indem du den Datenwechsel sicher im low Abschnitt von SCL machst. Dann sollten auch Kabelkapazität und -länge keine grosse Rolle spielen.
Der SDA geht aber schon irgendwann noch mal auf high-zurück, oder? Auf den Bildern ist der ja vor und nach der Übertragung low.
Angehängte Dateien:
-
100khz.gif
20 KB -
Zoom_5Khz.gif
20 KB
Hallo, danke für eure Hinweise. @Matthias Ich benutze das Hardware TWI von den XMegas und so wie es aussieht hat es einfach eine feste verzögerung eingebaut. Im Anhang ist einmal ein Screenshot von 100kHz Taktreate und einmal von 5kHz Taktrate sehr stark reingezoomt. Die Einbrüche kommen wohl durch das übersprechen der Leitungen. Die Tastköpfe scheinen das durch ihre Kapazität wohl grad so zu stabilisieren. Die Messungen im Anhang wurden ohne den Paralellen C bei SDA gemacht. @Jörg S. Am Anfang sind diese auf high. Danach gehen sie nicht mehr hoch. Sehr wahrscheinlich weil der Slave dauerhaft den Takt strecht. Das streching ist absicht da ich zu Zeit noch keine Daten verarbeite. Sehe ich das dann richtig das ich das Harware TWI im Prinzip für meine Anwendung in den Müll schmeisen kann und mir selber etwas TWI ähnliches Programmieren muss um das Timing etwas zu entspannen? Weil später sollen noch 2 weitere Module angeschlossen werden. Und so wie ich das sehe sind die fallende Taktflanken vom Takt einfach eine Ecke zu steil so das es zu dem übersprechen kommt was den Slave dann entsprechend verwirrt. Gibt es da ggf. Protokollvorschläge die ohne Änderung der Hardware auskommen? Gruß Peter
Du solltest als erstes probieren, den Strom durch den Bus zu erhöhen und die Leitungen gleichzeitg unempfindlicher zu machen, indem du kräftigere Pullups einsetzt. Lass den Strom in SCL und SDA ruhig auf 5mA ansteigen (pullups also ingesamt auf 660-750 Ohm) und schau, wie sich das auf Datensicherheit und Übersprechen auswirkt. Die Einbrüche auf SDA sind mit ziemlicher Sicherheit die Ursache für das Fehlverhalten. Ich habe mit den XMegas bisher das TWI Interface nicht benutzt, sondern benutze als externes EEPROM ein 93C46 per Bitbanging. Ein Projekt hier benutzt zwar das TWI Interface, allerdings auf einem Mega328 und die Leitungen sind nur 20cm lang. Sonst mache ich I2C immer manuell. Natürlich bleibt dir Bitbanging immer. Es ist nicht allzu schwer, wenn man einmal die Idee hinter dem Bus kapiert hat und die XMegas machens einem relativ leicht, an einzelnen Leitungen, egal welchen Ports, rumzumachen. Ob du nun alle Features inklusive Clockstretching implementierst, bleibt dir überlassen, ich habe immer fertige Slaves bedient, die davon keinen Gebrauch machten. Im Kern waren das 4 Routinen: StartCondition(), StopCondition(), boolean WriteByte(const byte), boolean ReadByte(byte), wobei ich das boolean als ACK interpretiere.
Matthias Sch. schrieb: > Du solltest als erstes probieren, den Strom durch den Bus zu erhöhen und > die Leitungen gleichzeitg unempfindlicher zu machen, indem du kräftigere > Pullups einsetzt. Lass den Strom in SCL und SDA ruhig auf 5mA ansteigen "Erlaubt" (laut Spec) sind allerdings nur 3mA
@ Peter (Gast) >es einfach eine feste verzögerung eingebaut. Im Anhang ist einmal ein >Screenshot von 100kHz Taktreate und einmal von 5kHz Taktrate sehr stark >reingezoomt. Aua! Da stimmt was nicht. Wenn es DERMASSEN Überprechen gibt, ist was faul! > Die Einbrüche kommen wohl durch das übersprechen der >Leitungen. Niemals. Nicht mal mit 1,5m verdrilltem Kabel kriegt man das hin. > Die Tastköpfe scheinen das durch ihre Kapazität wohl grad so >zu stabilisieren. Ja, sie verschleiern das Problem. >Sehe ich das dann richtig das ich das Harware TWI im Prinzip für meine >Anwendung in den Müll schmeisen kann Nein. > und mir selber etwas TWI ähnliches >Programmieren muss um das Timing etwas zu entspannen? Nein. > Weil später sollen >noch 2 weitere Module angeschlossen werden. Und so wie ich das sehe sind >die fallende Taktflanken vom Takt einfach eine Ecke zu steil so das es >zu dem übersprechen kommt was den Slave dann entsprechend verwirrt. Nein. DU hast wahrscheinlich ein Hardwareproblem. Das musst du finden und beheben. Siehe Fehlersuche. Ich tippe mal, dass die VCC-Verbindung, wo deine Pull-Ups dranhängen ein Problem hat. Wackelkontakt, kalte Lötstelle etc. Oder ein miese Masseverbindung. Probier es mal mit einer 10cm Verbindung, die sollte lehrbuchmäßige Signale erzeugen. >Gibt es da ggf. Protokollvorschläge die ohne Änderung der Hardware >auskommen? "Die schnellste und preiswerteste Art etwas zu tun, ist es gleich richtig zu tun".
Angehängte Dateien:
-
I2C_Crosstalk.png
7,9 KB
Falk Brunner schrieb: > Aua! Da stimmt was nicht. Wenn es DERMASSEN Überprechen gibt, ist was > faul! > >> Die Einbrüche kommen wohl durch das übersprechen der >>Leitungen. > > Niemals. Nicht mal mit 1,5m verdrilltem Kabel kriegt man das hin. @Falk Da muß ich dir widersprechen. Das Bild oben zeigt SDA, zusammen mit SCL über ca. 1m verdrillten Klingeldraht geführt. Peter schrieb: > Sehe ich das dann richtig das ich das Harware TWI im Prinzip für meine > Anwendung in den Müll schmeisen kann und mir selber etwas TWI ähnliches > Programmieren muss um das Timing etwas zu entspannen? Quatsch. In jedem DVI-Kabel ist ein I2C Bus, der geht leicht auch über 5m. In dem Aufbau, in dem das Bild oben entstanden ist, habe ich mit einem richtig belegten Kabel (Telefonleitung mit Sternvierer: SCL, GND, SDA, Vcc) 10m bei über 100kHz erreicht. MfG Klaus
Jörg S. schrieb: >> Du solltest als erstes probieren, den Strom durch den Bus zu erhöhen und >> die Leitungen gleichzeitg unempfindlicher zu machen, indem du kräftigere >> Pullups einsetzt. Lass den Strom in SCL und SDA ruhig auf 5mA ansteigen > "Erlaubt" (laut Spec) sind allerdings nur 3mA Stimmt natürlich - allerdings sind hier ja keine Standard I2C Kiesel verbaut, sondern 2 XMegas, für die die 5mA kein Problem darstellen. Natürlich sollte man bei der Verwendung von echten I2C Bausteinen dann auf 3mA zurückgehen.
Angehängte Dateien:
-
lang.gif
18 KB -
kurz.gif
18 KB -
spice_Leitung2.png
30 KB
Hallo, @Falk ich habe mal nachgemessen und Simuliert. Ich bin mir zu 90% sicher das es vom Kabel kommt. Die Messung "lang" wurde mit dem 1,2m langen Kabel gemacht. Messung Kurz wurde mit 10cm Kabel gemacht. Man muss allerdings beachten das auf den Platinen der I2C Bus auch nochmal jeweils eine länge von 16cm hat... . Außerdem habe ich das ganze mal noch Simuliert. Den Leitungsbelag habe ich mittels *1) auf 50pF/m abgeschätzt. Die Ergebnisse der Simulation stimmen grob mit den Messergebnissen überein. Alle Messung wurden mit einem 680 Ohm PullUp an SDA und 3k3 an SDC gemacht. Das entsprich einem Strom von knapp 5mA. Damit läuft es Momentan auch mit den Langen Leitungen. Wenn mehr Clients dazu kommen werde ich mal schauen ob ich ander Leitungen und/oder das Clocksignal durch einen Tiefpass etwas in der Anstiegszeit begrenze. Gruß Peter *1) http://de.wikipedia.org/wiki/Leitungsbel%C3%A4ge
Hallo, ich kann Klaus nur zustimmen. Bei mir ist ein I2C-BUS schon seit 10 Jahren im Einsatz der von einem Heizungsrechner im Keller sogar bis ins Obergeschoss per Telefonkabel, 4 x 0,6 mm (Volldraht), geht. Die Frequenz liegt so bei 10 KHz, die Pullups haben 2,2 K bei 5,0 V. SDA und SCL sind beim Slave jeweils mit 330 Ohm in Reihe angeschlossen, siehe Beitrag von Carsten Wille. Also bei 1,5 m darf es da noch keine Probleme geben. Gruss Klaus.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.