www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik i2c Bus instabil


Autor: Alex M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

an meiner Dockstar betreibe ich einen i2c-tiny-usb. Dieser hat bis vor 
einigen Tagen noch ein einzelnes LCD Display und einen DS1621 
angesteuert.

Gestern habe ich dann mal angefangen, 4 weitere Sensoren anzubauen. Nun 
habe ich folgendes Problem:

Die Sensoren werden ab und zu unter Linux nicht gefunden (i2cdetect 0). 
Es fehlen immer nur einzelne Sensoren. Außerdem geht die Ausgabe von 
sensors immer wieder auf 0 Grad runter und springt dann wieder auf einen 
realistischen Wert.

Ich habe Cat5 Kabel für die Sensoren genommen und die Kabellängen sind:
4m
1m
2m
50cm

Das Entfernen von einzelnen Sensoren (besonders mit langen Kabeln) 
bringt keine Besserung. In der Originalschaltung werden 10k Widerstände 
als Pullups für die beiden Steuerleitungen genutzt. Ich habe diese nun 
mal gegen 1.8k Widerstände getauscht und gehofft, dass es besser wird, 
leider Fehlanzeige.

Kann mir jemand noch 1-2 Tipps geben, was ich noch machen kann um die 
Sensoren stabil anzubinden?

Danke schonmal!

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1/ Messen (Oszi), ob es wirklich ein Hardwareproblem ist. Dazu die 
Software so schreiben, dass zunächst nur ein Sensor angesprochen wird. 
Nach und nach weitere Sensoren dazu nehmen und noch mal messen.

2/ Schaltplan zeigen. Vielleicht fällt jemandem was auf. Z.B. 
unterdimensionierte Spannungsversorgung der Sensoren.

3/ Programm zeigen. Vielleicht fällt jemandem was auf. Z.B. zu schneller 
Wechsel der Sensoren.

Autor: Alex M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für die schnelle Antwort.

1, Leider kein Oszi vorhanden, also nicht messbar.
2, http://www.harbaum.org/till/i2c_tiny_usb/schematic.gif nur statt 10k 
Pullup 1.8k
3, Das Programm ist lm_sensors, welches unter Linux verfügbar ist.

Autor: Joachim K. (minifloat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex M. schrieb:
> Cat5 Kabel für die Sensoren genommen
Bedenke, dass I2C eigentlich für Geräteinterne Kommunikation gedacht 
ist.
vllt. kann man mit zwei RS485-Bustreibern eine Umsetzung auf eine 
Feldbustaugliche Signalisierung vornehmen.

50cm müssten aber dennoch gehen. Hast du beim Cat5 Kabel ein einziges 
verdrilltes Paar für SCL und SDA benutzt? Das macht dir mit der 
Kapazität zw. den Adern bestimmt probleme. Ich würde mal probieren, je 
SCL und SDA ein eigenes verdriltes paar zu geben und die nun unbenutzte 
Ader an Masse zu klemmen.

Alex M. schrieb:
> 10k Widerstände [...] mal gegen 1.8k Widerstände getauscht
Öhm, in der I2C Spec steht 4k7. Die würde ich bei solchen Kabellängen 
aber schon durch zwei 10k Pullups an beiden Enden ersetzen.
Oder du gehst mit der Taktfrequenz an SCL herunter, das machen vllt. 
nicht alle Busteilnehmer mit, aber man kann testen ob es sich um 
Kapazitive Einflüsse handelt.

mfg mf

Autor: Alex M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Idee mit den verdrillten Adern hatte ich auch schon, meinst du 
wirklich, dass da das Problem liegen könnte (SCL und SCA sind 
tatsächlich verdrillt)?

Die 10k Widerstände hatte ich bisher drinnen und nachdem ich im Internet 
mehrere Seiten gefunden habe, wo auch von 1.8k Widerständen die Rede 
war, habe ich die beiden mal ersetzt...

Könnte es bei der RS485 Lösung Probleme mit dem Linux-Tool geben oder 
läuft das unsichtbar für dieses ab?

Autor: Joachim K. (minifloat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verdrillte Adern Frage: Ja.

Mit den 10k meinte ich, an jedem Ende des Busses einen hinzutun und 
nicht Sternförmig zu verdrahten.

Die RS485-Lösung deswegen, damit man ein Differentielles Signal hat, das 
man leichter über verdrillte Adern bekommt. Dazu sind pro Teilnehmer 2 
von diesen Transceivern nötig(SN75176, MAX485 etc.).

SCL gibt man beim Master auf einen Hardwire auf "Senden", bei Slaves auf 
"Empfangen" verdrahteten Transceiver. Jetzt kann man den Clock als 
Differentielles Signal übertragen.

SDA kommt entsprechend verschaltet an Transmit Enable und Data out des 
Transceivers, sodass jedenfalls zurücklesen aus dem Bus wie auch Senden 
möglich sind. Data In muss dazu Hardwire auf GND gelegt sein.

Ziel von meiner Idee ist es, i2c auf differentielle Signale aufzubohren.
Die Sache wäre also transparent, ja.

An beide Enden des Busses setzt man Abschlusswiderstände in Höhe des 
Wellenwiderstandes des Kabels(100Ω).

mfg mf

Autor: Joachim K. (minifloat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also meine obige Idee basiert für SDA darauf, dass viele Leute diese 
485-Bustreiber für CAN-Bus(die sache mit den Dominanten und rezessiven 
Bits ähnlich wie beim ACKing beim i2c) Mißbrauchen. Es gibt von den 
Herstellern dieser Treiber-ICs sogar AppNotes dazu.


Man könnte auch einen USB-CDC-Serial-Adapter aus dem Tiny machen, dann 
einen RS485 Transceiver da dran knallen, und jedem Sensor ebenfalls 
einen Tiny und einen RS485 Transceiver spendieren. Du Pustest dann 
einfach Seriell durch deine Bude :D

mfg mf

Autor: Spaßfaktor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vergiss diese RS485 Treiber für I2C !

es gibt spezielle Leitungs-Treiber für I2C : P82B96

http://www.nxp.com/documents/data_sheet/P82B96.pdf

100 Meter und mehr funktionieren damit problemlos :-)

>> Bedenke, dass I2C eigentlich für Geräteinterne Kommunikation gedacht ist.

Und ... es war einmal ... es wurde aber auch weiterentwickelt ... auf 
der Seite von NXP gibt es eine menge AppNotes über und mit I2C.

Autor: Horst Hahn (horha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Hier im Forum gab es einen Beitrag, da ist er ja:
Beitrag "Re: I²C ist durch äusere Einflüsse unstabil. Was kann man dagegen machen?" von Peter Danegger
....
Kabel: paarweise verdrillt
Paar 1: VCC + SDA
Paar 2: GND + SCL
...
Hat dort sehr weitergeholfen

Autor: Alex M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal Jo für die ausführliche  Erklärung. Leider ist mein 
Sensorensystem sternförmig, ich müsste also an so ziemlich jeden Sensor 
einen CAN Umwandler bauen, das wird mir zu teuer.

@Spassfaktor: Klar kann man Buffer oder Extender nehmen, da habe ich 
dann aber auch das Problem, dass ich mehrere brauche. Bei i2c hat mir 
hauptsächlich die günstige Umsetzung gefallen ;)

@Horst: Das werde ich gleich mal probieren, danke für den Tipp, den 
Thread muss ich wohl übersehen haben. Da ich ja noch genug Adern frei 
habe, werde ich direkt mal noch den Rat aus dem Artikel zu i2c befolgen 
und die Stromversorgung etwas vergrößern.

Autor: Joachim K. (minifloat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Spaßfaktor schrieb:
> vergiss diese RS485 Treiber für I2C !
>
> es gibt spezielle Leitungs-Treiber für I2C : P82B96

Danke Spaßfaktor, Ich hätte ja das problem, dass man am SDA-Pin des 
Masters und aller Slaves die Datenflussrichtung bestimmen müsste.
mfg mf

Autor: Alex M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, kurzer Zwischenbericht:

Ich habe am 4m Kabel nun mal die Adern getauscht und noch 2 10K 
Widerstände am Sensor angebracht, es sieht schon wesentlich besser aus 
als vorher!

Autor: spess53 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Siehe Anhang.

MfG Spess

Autor: Alex M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, halt ein Extender, brauch ich halt zwei pro Sensor :(

Autor: weinbauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I²C möglichst nicht sternförmig sondern schön liner von Teilnehmer zu 
Teilnehmer ziehen, dann an beiden Enden Pullups dran, 2x 10K sind ok,
den Busteilnehmern je einen großen Elko und nen kleinen 100nF 
Stützkondensator spendieren und die Kiste läuft.
Hab selber ein Netz in genannter Form laufen, geht problemlos.
Ach so, den Bustakt auch nicht zu hoch ansetzen.
Bei mir läufts mit 4-adrigem Telephonkabel über ~40m.

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo K. schrieb:
> Öhm, in der I2C Spec steht 4k7.

Ich kann den Wert in der Spec so nicht finden - der ist eher im Bereich 
des maximalen Wertes. Der Wert sollte in der Anwendung so niedrig wie 
möglich sein; die angeschlossenen Devices geben doch sicherlich im 
Datenblatt an, welchen Strom sie maximal sinken können. Laut NXP-Spec 
sei das mindestens ein Wert von 3mA. Für ein 5V-System sind deine 1.8k 
dann durchaus richtig.

Autor: Alex M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da leider mein Master mitten in der Wohnung steht, führt nichts an einem 
sternförmigen System vorbei. Nach der Änderung der Kabelverdrillung und 
zusätzlichen 10k Widerständen direkt an den Sensoren läuft das ganze 
jetzt aber wunderbar. Ich werde mri Montag mal noch ein längeres 
Netzwerkkabel besorgen und mal testen, ob jetzt auch noch größere 
Distanzen überbrückbar sind.

Autor: Joachim K. (minifloat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht, ob du von sternförmig das Gleiche Bild hast wie ich :)
Sternförmig:
          Slave1
            ||
            ||
Slave4====Master====Slave2
            ||
            ||
          Slave3

Linienförmig:

2*10k===Slave1===Master===Slave2===Slave3==...==Slave4===2*10k

(Master sitzt irgendwo in der Kette oder sogar an einem Ende.)
mf

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
I2C ist sehr robust.

Aber 400kHz Takt sollte man nur dann benutzen, wenn sich alle ICs auf 
der selben Platine befinden.
Ansonsten nur max 100kHz einstellen.

Jedem Sensor sein 100nF Stützkondi sollte klar sein.

Die Pullups so klein wie möglich, also 1,8k oder 2,2k ist ein optimaler 
Wert.

Die Adreßeingänge sollte man immer beschalten (GND oder VCC).

Hast Du verdrillte Leitungen, dann nie SDA, SCL auf ein Paar legen.
1.Paar: SDA + GND
2.Paar: SCL + GND
3.Paar: VCC
4.Paar, Schirm: GND
Alle GND auf beiden Seiten, den Schirm nur auf der Master-Seite 
anschließen.


Peter

Autor: Horst Hahn (horha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@peda:
Da bin ich jetzt erstaunt:
Beitrag "Re: I²C ist durch äusere Einflüsse unstabil. Was kann man dagegen machen?"
Kabel: paarweise verdrillt
Paar 1: VCC + SDA
Paar 2: GND + SCL

und jetzt alles parallel zu GND
1.Paar: SDA + GND
2.Paar: SCL + GND

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst Hahn schrieb:
> Da bin ich jetzt erstaunt:

VCC ist signalmäßig kalt, ist also egal, ob VCC oder GND.
Bei nem 4-paarigem Kabel kann man VCC ein eigenes Paar gönnen.


Peter

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Problem von per Software implementiertem I2C ist die hohe 
Flankensteilheit der stromstarken Pintreiber im H=>L Übergang, die dank 
fehlendem adäquatem Abschluss zu entsprechend deutlichen und evtl. 
störenden Reflektionen führen kann. Fertige I2C/TWI-Funktionsmodule in 
Mikrocontrollern begrenzen daher üblicherweise diese Flanken (ATmega: 
slew rate limited output drivers).

Die TWI-Module enthalten auch eine Störunterdrückung an den 
entsprechenden Eingängen, die dem hier verwendeten Tiny ebenfalls fehlt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.