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!
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.
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.
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
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?
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
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
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.
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.
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
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!
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.
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.
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.
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
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
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.
