Wire Library hängt Arduino auf - Timeout (o.ä.) für fehlerhafte I2C Connection?

International Deutsch
#1

Hallo,

kann es sein, dass eine Fehlerhafte I2C Verbindung den Arduino "einfriert", z.B. wenn der I2C Slave während der Kommunikation aus schaltet (oder noch nicht eingeschaltet ist) oder die Verbindung gestört ist?

Gibt es da eine Option eines Timeouts oder eine ähnliche Fehlerbehandlung?

Habe nur ältere Einträge zu diesem Thema gefunden.

Hintergrund: Nutze Arduino Mega als Master mit std. Wire Lib. (IDE 1.6.5, Ubuntu) und eine DS3132 RTC als Slave. Die RTC wird nur eingeschaltet um die Zeit aus zu lesen. (Ob das ganze Sinn hat, sei gerne dahin gestellt, auch dass die Leitung nur wenige cm lang sein darf und Pull-Ups benötigt ist klar. Es geht mir rein um die Fehlerbehandlung im Code und ob es zu einem einfrieren kommen kann. ;) )

Vielen Dank.

#2

Gegenfrage: Wie hast du festgestellt, das der Arduino einfriert?

Ich setze seit längerem I2C mit diversen Sensoren oder RTC und der Standard Lib ein und habe dies bisher nicht feststellen können.

Allerdings wurde das System (Uno oder Pro Mini) nie sehr lange ohne die angeschlossenen (also kurze Zeit entfernt) Sensoren betrieben, so dass ich nicht sagen kann, ob ein Absturz doch nach längerer Zeit vorkommen kann.

#3

Habe primitiv aber umfänglich Serial-Debuged so in dieser Art:

#define SerialDebug(x); Serial.print(LINE);Serial.println(x);

und an etlichen Stellen im Code geschrieben. So konnte ich sehen, dass die letzte Ausgabe der Serial direkt nach dem Einschalten der I2C-Slave Power und vor dem ersten Lesebefehl des Slaves war.
(Zugegeben: Ich gebe der Power keine extra Zeit (delay) zum Einschwingen, dass kann natürlich eine Fehlerquelle sein! Aber meine Frage, ist Wire da robust gegen, oder kanns endlos werden? Störung auf Leitung kann ja immer mal sein) (Controller läuft gerde über Nacht zum Test mit 1ms Pause nach dem einschalten. Bisher kam Fehler schon nach 8-120min. RTC wird aber auch jede Sek. an, auslesen, aus)

Zusätzlich wird eine LED in jedem loop() durchlauf getoggelt. Die steht auch still. Der Code ist ansonsten in Tasks organisiert.

…hmm Du bringst mich auf die Idee… da könnte ich noch einen ext. Interrupt hinzufügen, der eine weietre LED toggelt und schauen ob er darauf noch reagiert oder total fest steht. Aber selbst wenn er den Interrupt noch bedient, bekomme ich ihn nicht mehr aus der vermutete I2C-Falle (Schleife) heraus, WENN ES DENN DIE IST! Will ich (noch) nichts unterstellen. Zu 99,9% sitzt der Fehler ja bekanntlich VOR dem Bildschirm :wink:

#4

Ok, soweit bin ich da noch nicht in die Tiefe gegangen.

Bei mir hat das bisher (wie beschrieben) immer sauber und ohne Hänger funktioniert. Der einzige Test war, mal die RTC oder einen Sensor für einige (ca. 15 Min.) rausgezogen. Dabei keinen Ausfall erhalten.

Ein Lux-Meter mit I2C und Pro Mini läuft jetzt seit gut einem 1/2 Jahr ohne Ausfall und eine Schaltuhr seit ca. 3 Monaten ebenso.

Aber warum schaltest du die RTC? Ich lass diese immer durchlaufen, der Stromverbrauch ist doch vernachlässigbar. :confused:

#5

Meine DS3231N RTC auf kleinem Board mit Backup-Batt von e-bucht auch China gönnt sich 7,3 -7,7mA. Das ist mir zu viel, zumal sie 990ms nix tut und nur 1% der Zeit aktiv sein muss.

Es sei angemerkt, dass ich auch meinen Arduino komplett schlafen lege im Low-Power-Mode um lange mit einer Batterie zu leben (nutze dafür auch eigenen Aufbau).

Habe es gerade mal provoziert und den Strom der RTC gänzlich geklaut, dann steht der Code still...

#6

Ups…

Habe es gerade mal provoziert und den Strom der RTC gänzlich geklaut, dann steht der Code still…

das sieht mir dann aber doch nach einem internen Problem aus.

Dieses konnte ich bei meinen Projekten nie beobachten. Hatte es gerade noch mit meiner “Entwicklungsschaltuhr” getestet. RTC abgezogen und die Uhr läuft munter weiter.

Allerdings werden meine Projekte bisher alle mit Netzteil betrieben, daher stört mich der Stromverbrauch nicht wirklich. Ist ebenso eine DS3231N.

Edit:
Fällt mir gerade ein, ist es eine Batterie oder Akku?

#7

Das war eine gute Idee mit dem Interrupt. Er reagiert noch auf den Interrupt, aber der Code steht ansonsten still.

Hin und wieder läuft der Code auch weiter, wenn ich die RTC weider anklemme, kommt scheinbar auf den richtigen/falschen moment drauf an.

Ok, ich kann als work arround mit nem delay(1) nach Power on warten bis Spannung ein geschwungen ist, UND zur Sicherheit Vor jeder I2c Datenübertragung mit digital read (oder sogar analog.read()) checken, dass die Power wirklich on ist.

Dennoch die Frage bleibt: Kann jemand etwas zur Robustheit/Fehlerverhalten der wire Library sagen? Kann man eine Art Time-out setzen?

Vielen Dank!

#8

Ok, da ich dir diese Frage nicht beantworten kann, werde ich mich jetzt schlafen legen. :sleeping: Gute Nacht.

P.S. Ist auf deiner RTC eine Batterie oder Akku?

#9

HotSystems: Ups... das sieht mir dann aber doch nach einem internen Problem aus.

Dieses konnte ich bei meinen Projekten nie beobachten. Hatte es gerade noch mit meiner "Entwicklungsschaltuhr" getestet. RTC abgezogen und die Uhr läuft munter weiter.

hmm.. Kann es aber ganz klar, wiederholend eingrenzen, die letzte Serielle Ausgabe kommt genau nach dem Power on und vor dem lesen der Uhrzeit oder Temperatur.

ABER, welche Library nutzt Du für die RTC? Ich nutze diese hier:https://github.com/JChristensen/DS3232RTC

Vielelicht hat es ja auch damit zu tun?? :o

HotSystems: Fällt mir gerade ein, ist es eine Batterie oder Akku?

Bei mir steck ich die selbst in den Halter der RTC, und ich habe ne Batterie drinne :)

#10

Ich glaube Du hast mir schon viel weiter geholfen! Werde mal eine andere Library testen, aber auch nicht mehr heute Abend/Morgen :sleeping:

#11

Ok, die Lib setze ich auch ein.

Was die Batterie betrifft, hast du denn auch eine originale Platine ähnlich dieser hier:

Wenn ja und du hast die nicht geändert, dann lies bitte folgenden Artikel:

http://arduino-hannover.de/tag/ds3231/

#12

Bingo! :o Klasse hinweise, vielen Dank! Das werd ich dann wohl mal schleunigst ändern müssen!! :fearful:

#13

Gerne, gute Nacht, bin weg...

#14

Danke Dir auch!

#15

Aber hat das nun was mit dem Aufhängen zu tun?

oder wie hast du das nun gelöst?

#16

Aber hat das nun was mit dem Aufhängen zu tun? Könnte höchstens sein, dass der Uhrenmodul seine I2C Funktion einstellt, wenn die CR Batterie auf 4,x V "geladen" ist. Die Uhr stellt dann fest, dass sie auf Batterie läuft, weil die normale Spannung zu wenig drüber liegt. Um Strom zu sparen, ignoriert sie den I2C Bus. Dann hängt es an der Library, ob sie Unsinn liefert oder Unsinn macht. Wire selbst hängt eigentlich nicht. (vgl. I2C Scanner)

#17

Also ich habe es mal mit einer 2. Hardware getestet bzw. bin noch dabei und es läuft stabiler. Es scheint aber mit dem ein und aus schlalten der rtc zu tun zu haben. Teste gerade auch den selben code aber mit dauer 5v an der rtc.

Die Dioden habe ich mal entfetnt an beiden rtcs da ich keine akkus drinn habe und bei eingeschalteter rtc die spannung an der batterie schon bei 4,6v lag.

Melde mich, wenn ich mehr weiß.

#18

jim_beam:
Also ich habe es mal mit einer 2. Hardware getestet bzw. bin noch dabei und es läuft stabiler. Es scheint aber mit dem ein und aus schlalten der rtc zu tun zu haben. Teste gerade auch den selben code aber mit dauer 5v an der rtc.

Die Dioden habe ich mal entfetnt an beiden rtcs da ich keine akkus drinn habe und bei eingeschalteter rtc die spannung an der batterie schon bei 4,6v lag.

Melde mich, wenn ich mehr weiß.

Ich befürchte, es hätte nicht lange gedauert und die Batterie wäre dir um die Ohren geflogen. :wink:

Durch das ein- und Ausschalten gelangen evtl. Impulse in den Arduino, die er nicht verkraftet.

#19

Häng doch mal einen Logiganalyser an den Bus. wenn er Low ist, trennst du ihn auf und schaust ob die RTC oder der Controller Low ist. dann weißt du, wo du ansetzen musst.

#20

Habe mal einige Messung gemacht mit 2 Aufbauten und der gleichen Software und mehrere Tage laufen lassen. (Nach dem Einschalten der RTC habe ich zur Sicherheit noch 100us und vor dem Ausschalten ebenfalls 100us delay eingefügt.) Dann habe ich über ca. 12h die Zeiten gemessen (bei beiden RTCs sind die Ladedioden abgetrennt, da kein Akku drin steckt):

Aufbau A) (Steckbrett): Hier wurde die RTC ständig (1x / sec) eingeschaltet, ausgelesen und ausgeschaltet. Zum erwarteten Synchronisationssignal wurde die RTC 10ms vorher eingeschaltet und danach wieder aus. Das hat ohne Probleme funktioniert, nachdem ich einen 100nF C in die VCC der RTC ergänzt hatte! Die 100us delays alleine halfen nicht. Konnte mir bei dem Aufbau die Spannung an der RTC leider noch nicht mit/ohne C ansehen. Aber es scheint mit der Versorgungsspannung der RTC zu tun zu haben. Mein Code selbst scheint nicht das Problem zu sein.

Nur warum bleibt der Code hängen, wenn die RTC nicht oder nicht richtig Antwortet da sie (offensichtlich) Versorgungsspannungsprobleme hatte?? Also doch die RTC-Library?

Laufzeit laut PC-Uhr: 12:12:30,991 Laufzeit laut RTC: 12:12:31,000 (ms werden von RTC nicht ausgegeben) Laufzeit laut millis(): 12:11:55,968 Laufzeit millisync(): 12:12:31,008 (basiert auf millis(), wurde aber alle 5s mit RTC Signal synchronisiert)

PC und RTC sind nahezu identisch, die millis() geht hoch gerechnet auf 24h 68,9s nach. Das entspricht 0,08% oder 797ppm. Für einen Datenlogger der Monate läuft schon doof, wenn (rechnerisch) nach 6 Monaten ca. 3,5h oder 12 Monaten fast 7h Versatz drin ist.

Aufbau B (Gehäuse): Hier lief die RTC nicht fehlerfrei, wenn sie ein- und aus geschaltet wird. Der Trick mit dem 100nF C hat hier nicht funktioniert, daher habe ich die RTC auf Dauer +5V geklemmt (muss unbedingt mal mit dem Osszi schauen). So lief sie zumindest mal auch mehrere Tage fehlerfrei durch. Die Zeitmessung hier:

Laufzeit laut PC-Uhr: 12:12:29,974 Laufzeit laut RTC: 12:12:30,000 (ms werden von RTC nicht ausgegeben) Laufzeit laut millis(): 12:12:19,440 Laufzeit millisync(): 12:12:29,999 (basiert auf millis(), wurde aber alle 5s mit RTC Signal synchronisiert)

Das sind 0,02% bzw. 240ppm Fehler oder 20sec/Tag, 20min/Monat 2h/Jahr, was schon viel besser und akzeptabel ist.

Besonders freue ich mich aber, dass das angedachte Prinzip, mit der RTC synchronisierte ms nutzen zu können anscheinend Funktioniert und gleichzeitig kann man Strom sparen indem die RTC 90% der Zeit aus bleibt (zumindest bei 1 von 2 Aufbauten). :)

PS: Wobei bei Verwendung eines Akkus in der RTC natürlich noch untersucht werden müsste, ob die RTC nicht doch einen mind. Anteil eingeschaltet bleiben sollte um den Ladezustand des RTC-Akkus zu waren. ;)