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