> > Ein sicheres Threading ist auch jetzt ohne weiteres gewährleistet.
> > Du kannst von jedem Thread auf die EEProms zugreifen, ohne daÃ? etwas passiert.
>
> Das haben wir der Abfrage in write() und read() mit:
> if i>=100 return 0;
> zu verdanken.
Falsch!
Threading-sicher wird das Ganze durch das Capture.
Die Schleife ist nur dafür da, da das EEProm einige Zeit benötigt,
die mit einem Schreibvorgang zwischengepufferten Daten zu schreiben.
In dieser Zeit reagiert das EEProm nicht. Jedoch dauert dies normal nie länger
als 10ms. Das Timeout beträgt insgesamt ca. 120ms.(Bei Multithreding mit hohen Prios auch mehr)
> Ich frage mich jedoch, ob im Fall von Hardwarefehlfunktionen (wie in diesem Fall)
> einfach kommentarlos abgebrochen werden darf.
Welche Fehlfunktion ??!
Wenn das EEProm nach 120ms nicht reagiert ist es entweder Defekt, oder es gibt auf
dem Bus einen Kurzschlu�/Störung(lange Leitung).
Das sind die einzigen, aber auch wirklich einzigen beiden Fälle, bei denen mit
return 0 abgebrochen wird.
> Es wäre in diesem Zusammenhang WICHTIG,
> den Rückgabewert der Funtion zu prüfen, nur da read und write gekapselte Funtionen sind und die
> Rückgabewerte nicht an das aufrufene Programm (mich) gehen, Beispiel:
>
> function writeint(byte eepromaddr,int addr, int data)
> {
> capture i2c.flag;
> write(eepromaddr,addr); //<----- keine Verarbeitung des Rückgabewertes
> i2c.write((data & 0xFF00) shr 8);//<----- Wird auch ausgeführt wenn write fehlschlug
> i2c.write(data & 0x00FF);//<----- Wird auch ausgeführt wenn write fehlschlug
> i2c.stop();//<----- Wird auch ausgeführt wenn write fehlschlug
> release;
> } //<----- Der Thread bekommt nichts vom Problem mit! ein "return wert_aus_write;" fehlt für meine Begriffe.
> //<----- Da hat's gerade ne Katastrophe auf dem i2c-Bus gegeben und der Thread freut sich das er wieder dran ist...
Falsch ! Warum sollte es hier eine Katastrophe auf dem Bus geben ?!?
Es wird eine ganz normale I²C-Bus-Operation ausgefürht:
start+busaddr(in Funktion write)
2 Byte schreiben (2 Datenbytes)
stop
Hier gerät wirklich nichts durcheinander, au�er, da� die Daten nicht in das
EEProm geschrieben wurden, weil dieses nicht reagiert.
Es wird jedoch bei der �berarbeitung des Moduls eine Rückgabe von Fehlermeldungen
geben, zumindest bei den Schreibfunktionen. Bei den Lesefunktionen wird das schwer.
> kriege ich also nie mit, ob der Wert geschrieben wurde oder ob per Timeout abgebrochen wurde.
Wie gesagt. Der Timeout greift nur, bei den beiden o.g. Möglichkeiten.
> In dem Fall müste entweder mit einem quit 63; und einer Fehlermelung auf dem Display auf den Hardwarefehler
> aufmerksam gemacht werden oder aber ich als Programm mu� die Möglichkeit bekommen, auf Erfolg zu prüfen.
Die einzig sichere Prüfung, ob ein Wert geschrieben wurde, ist, da� man diesen zurückliest.
Die Speicherzellen in einem EEProm halten schlieÃ?lich auch nicht ewig. :-)
Wenn diese defekt sind, bekommst Du dies nur durch ein Zurücklesen heraus.
> Eine zentrale Fehlerroutine mit der vorbestimmbaren Option Break/Continue wäre auch denkbar und evtl. besser.
Sorry, soetwas ist in C2 nicht möglich, und in Multithreadsystemen sehr schwer zu handeln.
> Das macht die Funktionen zwar etwas Aufwendiger aber auch Sicherer. Das trift für eine ganze Reihe von (älteren)
> Funktionen des CC2 zu und für mein Emfpinden gehört das dringend gefixt.
Was z.B. ?
> Wenn ich mir eine Heizungsteuerung
> vorstelle wo das Schreiben und Lesen von Daten von einem °%-Zufallsfaktor abhängt, wird mir anders :-) :-) ... warm!
Wie gesagt, das hat nichts mit Zufall zu tun.
Ich arbeite wirklich sehr viel mit I²C und habe z.B. noch nie das Problem gehabt, da�
Daten nicht ins EEProm geschrieben werden konnten.
> Ausserdem wird hier im Beispiel ggf. zwar der Adressierungsversuch abgebrochen "if i>=100 return 0;"
> aber dann munter mit
> i2c.write((data & 0xFF00) shr 8);
> i2c.write(data & 0x00FF);
> i2c.stop();
> weiter gearbeitet... eigentlich müste dies geprüft werden denn sonnst passiert sonst was auf dem i2c-Bus..
> nur nicht das Richtige. Das gilt auch für alle anderen Kapselfunktionen aus eeprom.c2
Falsch!
Auf dem Bus passiert garnichts, Da ein ordenlichen I²C-Start gesendet wurde; eben nur
mit folgenden Bytes für die sich kein Baustein "angesprochen fühlt".
> Davon kann immerhin die Zuverlässigkeit des Gesamtsystems abhängig sein, das aktuelle eeprom.c2 würde ich
> daher nicht als im Threading Sicher bezeichnen weil der Fehlerfall bisher im Modul ganze 2 mal schlicht ignoriert
> wird. Die Auswirkungen auf andere i2c-Bausteine aus dem Fehlerfall kann ich nicht abschätzen.
Wie gesagt, es gibt hier keinerlei Auswirkungen auf andere Bus-Bausteine.
Es wird weder etwas gestört oder durcheinandergebracht, noch ein falscher Baustein angesprochen.
Das kannst Du mir galuben. Ich kenne den I²C-Bus in und auswendig.
Und was soll das mit dem Thema Threading-Sicher zu tun haben ?
Threading sicher hei�t nur, da� nicht einer oder mehrere Thread in die Ausführung
eines Threads eingreifen können, während dieser z.B. auf dem I²C-Bus zugreift.
Und das ist hier 100%ig durch das capture/release gewährleistet.
> Ich möchte Dich bitten, das Eeprom-Modul und Abhängige bald zu überarbeiten... :-)
Das kann noch einige Zeit dauern, da andere Module eine höhere Priorität besitzen.
Am EEProm-Modul ist das einzige was passieren könnte, da� einmal Daten im Falle
eines defekten EEProms oder einer von au�en verursachten Störung nicht geschrieben
werden könnten.(sehr unwahrscheinlich)
MfG André H.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 12.07.2003 0:53)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 12.07.2003 8:56)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 12.07.2003 23:01)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 13.07.2003 10:10)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 13:44)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 13.07.2003 20:02)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 23:40)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 14.07.2003 9:15)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 14.07.2003 12:54)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 14.07.2003 15:48)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 15.07.2003 2:57)Re: Modul eeprom.c2 (von André H. - 15.07.2003 8:25)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 10:47)Re: Modul eeprom.c2 (von 89984984/8 - 7.04.2005 10:32)Re: Modul eeprom.c2 (von André H. - 15.07.2003 11:50)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 19:31)Re: Modul eeprom.c2 (von André H. - 15.07.2003 20:26)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 22:48)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 0:43)Re: Modul eeprom.c2 (von André H. - 18.07.2003 18:19)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 18:35)Re: Modul eeprom.c2 (von André H. - 18.07.2003 19:24)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 21:38)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 22:53)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 22:55)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 1:36)Re: Modul eeprom.c2 (von André H. - 19.07.2003 8:41)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 13:02)Re: Modul eeprom.c2 (von André H. - 22.07.2003 10:18)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 14:04)Re: Modul eeprom.c2 (von André H. - 22.07.2003 14:42)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 16:39)Re: Modul eeprom.c2 (von André H. - 22.07.2003 10:24)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 11:26)Re: Modul eeprom.c2 (von André H. - 22.07.2003 14:13)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 15:04)Re: Modul eeprom.c2 (von André H. - 23.07.2003 16:42)Re: Modul eeprom.c2 (von Rolf - 23.07.2003 21:28)Re: Modul eeprom.c2 (von Rolf - 23.07.2003 12:16)Re: Modul eeprom.c2 (von André H. - 23.07.2003 16:28)Re: Modul eeprom.c2 (von André H. - 18.07.2003 22:43)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 14.07.2003 0:29)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:16)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:12)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:08)