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.
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
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.
Ich weiß nicht, ob du von sternförmig das Gleiche Bild hast wie ich :)
1 | Sternförmig: |
2 | Slave1 |
3 | || |
4 | || |
5 | Slave4====Master====Slave2 |
6 | || |
7 | || |
8 | Slave3 |
9 | |
10 | Linienförmig: |
11 | |
12 | 2*10k===Slave1===Master===Slave2===Slave3==...==Slave4===2*10k |
13 | |
14 | (Master sitzt irgendwo in der Kette oder sogar an einem Ende.) |
mf
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
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
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.
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.