I2C Bus "störungssicher" machen

[Christoph2]

Hi,

danke für die vielen Antworten, erstmal noch ein paar Informationen: Die Stromversorgungskabeln für alle Verbrauer werden über 6,5m lange Kabeln von der Steuerung zum Terrarium geführt. Parallel dazu läuft ein CAT6 Kabel für den I2C Bus.
Bei den Stromversorungskabeln sind 3 Kabeln dabei, die 3,5A PWM modulierten Strom führen, zum dimmen der Lampen. Das hat erstmal garnicht funktioniert. Ich habe dann direkt an die Steuerung eine kleine Schaltung mit CAN Bustreibern gehängt, die den standard I2C Bus auf Differentielle Signalübertragung umwandelt. Direkt beim Terrarium wird es wieder zurückgewandelt.
Der Standard-I2C Bus ist jetzt nur noch auf der Hauptplatine (ca. 30cm) und im Terrarium zu den einzelnen Sensoren (ca. 1,5m geschirmte CAN Kabeln).

Ich glaube hardwaremäßig kann man nicht mehr viel verbessern ohne viel Geld zu investieren. Und selbst wenn ich es durch Hardwareverbesserungen zum Laufen bekomme kann ich nie sicher sein dass es ewig funktioniert, z.B. wenn ich noch ein zusätzliches PWM Kabel dazulege oder so...
Lieber wäre mir das eleminieren von den Endlosschleifen im Programm.

Mit 10kHz Busgeschwindigkeit funktioniert es ca. 10 Sekunden, mit 2kHz ca. 5 Minuten.
Das heißt bei 2kHz kommt durchschnittlich alle 5 Minuten ein "Fehler". Wenn ich den fehlerhaften Wert verwerfe, wird eben alle 5 Minuten ein Wert verworfen, das ist total egal.

Irgendwelche Sicherungen gegen Überflutung wird es auch noch geben, aber das ist ja nicht das einzige Problem, das war nur ein Beispiel. Ich kann die Steuerung ja nicht alle 5 Minute resetten...

@lorcan: Ich habe die i2c_read Befehle auf if-Abfragen umgeschrieben, jetzt mach der Controller aber überhaupt nichts mehr. Ich glaube es dauert einfach ein bischen bis das TWINT Bit rückgesetzt wird, und diese Zeit muss man abwarten. Wenn man es aber ohne Schleife macht, also nur mit if, dann fängt er an mit dem Empfangen, fragt aber sofort ab ob er schon fertig ist. Das ist er natürlich noch nicht, also gibt er den Fehlercode -1 zurück. Dann führt er den nächsten Befehl aus, z.B. das nächste i2c_write zur Abfrage des nächsten Sensors... Obwohl er den letzten Wert noch garnicht empfangen hat.

Vielleicht reicht es aber auch, eine gewisse Zeit zu warten, anstatt zu warten bis das TWINT Bit rückgesetzt wird?
Weiß jemand wie lange ungefähr, oder wie man das berechnen kann?

lg
Christoph

[Klebwax]

Bei den Stromversorungskabeln sind 3 Kabeln dabei, die 3,5A PWM modulierten Strom führen, zum dimmen der Lampen. Das hat erstmal garnicht funktioniert. Ich habe dann direkt an die Steuerung eine kleine Schaltung mit CAN Bustreibern gehängt, die den standard I2C Bus auf Differentielle Signalübertragung umwandelt. Direkt beim Terrarium wird es wieder zurückgewandelt.
Der Standard-I2C Bus ist jetzt nur noch auf der Hauptplatine (ca. 30cm) und im Terrarium zu den einzelnen Sensoren (ca. 1,5m geschirmte CAN Kabeln).

Du hast also gar keinen I2C Bus, sondern irgendetwas nicht näher beschriebenes anderes mit RS485 Pegeln. Bist du dir sicher, das das wirklich funktioniert?

Es ist ziemlich schwer, zielführende Ratschläge zum I2C Bus zu geben, wenn du gar keinen hast.

Das Grundproblem von I2C ist halt schon, dass er unsymmetrisch ist und eben auf solche Störungen anfällig

Das wäre ein Hinweis gewesen, passt aber nicht bei RS485 Pegeln.

Ich glaube auch nicht an direkte Störungen durch die PWM, die passt nicht zu Minuten. Da geht eher jede Übertragung in die Hose. Ich denke, die ganze Buswandlung funktioniert nicht zuverlässig, und die SCL Leitung hängt. Der Master, der eigentlich den Takt vorgibt, sieht das als Clock-Stretching und hängt dann auch.

Lieber wäre mir das eleminieren von den Endlosschleifen im Programm

Klingt gut, aber wenn dein Bus hängt und damit auch dein I2C Controler, hilft dir das hier nicht.

Ohne Tricks und voll in den Specs, reicht ein I2C Bus leicht 5m bei 400kHz. Eingestreute Störungen führen nicht zum Hängen sondern "nur" zu fehlerhaften Daten.

Die häufigsten Probleme entstehen durch "Verbesserungen" wie Pegelwandler oder Buswandler. Die Busleitungen sind nun mal Open Collector und nur nach Low getrieben, und das ist nicht einfach zu machen. Auch fertige Wandlerbausteine haben da ihre Einschränkungen, wie man in den Datenblättern lesen kann.

Das nächste Problem sind die Kabel. Weil bei anderen Übertragungen verdrillte Leitungen eingesetzt werden, wird das auch als gut für I2C angesehen, und dann SDA und SCL als Paar geführt. Die Wirkung ist dann ein quasi Kurzschluß zwischen beiden durch die Kabelkapazität. Da geht dann auch nichts mehr.

Da ich aber immer noch nicht weiß, wie lang dein Bus sein muß, jedenfalls ist er nicht kürzer als 30cm + 1,5m, kann ich dir schlecht einen Rat geben, dein Problem zu lösen.

MfG Klebwax

[lorcan]

Du must das ergebnis der Abfrage natuerlich weiterverwerten.
Dazu musst du erstmal ermitteln wie lange der Bus braucht bis das Signal ansteht.
Zu dieser ermittelten Zeit addierst du noch eine Reserve von 10%.
Wenn dann in dieser Wartezeit kein ACK empfangen wurde liegt ein Fehler vor und du solltest die Uebertragung wiederholen.
Zum Warten kannst du die Funktionen aus der Delay.h verwenden, allerdings ist der MCU dann blockiert, oder
einen Timer der einen Interrupt ausløst.
Viel Erfolg!

[crabtack]

Hallo!

Also der Watchdog wäre eine gute Lösung.
Immer, wenn er nicht im Programm testetet wird löst er nach einer einstellbaren zeit ein redet aus.
Sobald er dann hängen bleibt, wird er nach wenigen millisekunden resettet.
http://www.mikrocontroller.net/artic...rial:_Watchdog

Gruß
olaf

[lorcan]

Die Idee mit dem Watchdog ist in sofern schlecht, als dass die alten Einstellungen verloren gehen und damit immer noch keine Kommunikation gewaehrleistet ist.
Das heisst z.B. dass die Pumpe laeuft und kann nicht mehr erreicht werden.

[TheDarkRose]

Naja, durch was wird die Pumpe genau angesteuert?

[Besserwessi]

Der Watchdog timer ist im Prinzip schon richtig um einen hängenden µC wiederzubeleben - nur sollte das Programm im Prinzip auch ohne richtig laufen. Der
Watchdog ist mehr für den Fall das eventuell doch mal Fehler auftreten, die man bei der Fehlersuche nicht gefunden hat, weil sie so selten sind. Fehler die nach 5-10 minuten auftreten sollte man besser an der Ursache beheben. Es ist eine Frage des Programms ob der µC die Einstellungen vergisst, oder weiter lesen kann. Es fordert allerdings schon etwas mehr Aufwand als nur den WD zu aktivieren. Man kann testen ob der Reset vom WD ausgelöst wurde, und für den Fall die Variablen nicht neu initialisieren - dem C Compiler muss man dazu ggf. sagen das er die Variablen nicht automatisch alle 0 initialisieren soll.

Viel langsamer machen hilft nur begrenzt gegen Störungen, denn es verhindert nicht, das die Leitungen zusätzliche Pulse einfangen. Für einen richtigen I2C bus helfen sonst niederohmigere Pullups und ggf. auch zusätzliche RC Glieder und eventuell ein Kondensator gegen GND.

[Christoph2]

Hallo,

in den letzten Tagen hatte ich wenig Zeit, ich hab bis jetzt einfach mal bei allen I2C Befehlen (senden, empfangen, und initialisieren) statt der while Schleife ein _delay_ms(10) eingefügt, ohne irgendwas mit dem Oszi zu messen.

Es funktioniert bis jetzt sehr gut, die Steuerung läuft seit zwei Tagen durchgehend.

Sogar ohne Watchdog, aber den werde ich auch noch einbauen, vielleicht nächstes Wochenende...

Vielen Dank für die Hilfe!

lg
Christoph