| Re: Evtl. Fehler im Modul eeprom.c2 Kategorie: I²C-Bus (von Rolf - 11.07.2003 22:42) | |
|
Als Antwort auf Re: Evtl. Fehler im Modul eeprom.c2 von Rolf - 11.07.2003 21:25
| |
|
> Hallo André, �h.. ich mu� mich schon wieder korrigieren. write() und read() geben an die aufrufende Funktion True oder False zurück. Der Rest innerhalb der Auswertung der Kapselfunktionen bleibt aber als Fehlerquelle bestehen. Gru� Rolf > Das haben wir der Abfrage in write() und read() mit: > if i>=100 return 0; > zu verdanken. Ich frage mich jedoch, ob im Fall von Hardwarefehlfunktionen (wie in diesem Fall) > einfach kommentarlos abgebrochen werden darf. 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... > > kriege ich also nie mit, ob der Wert geschrieben wurde oder ob per Timeout abgebrochen wurde. > 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. > Eine zentrale Fehlerroutine mit der vorbestimmbaren Option Break/Continue wäre auch denkbar und evtl. besser. > 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. Wenn ich mir eine Heizungsteuerung > vorstelle wo das Schreiben und Lesen von Daten von einem °%-Zufallsfaktor abhängt, wird mir anders :-) :-) ... warm! > > 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 > > 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. > Ich möchte Dich bitten, das Eeprom-Modul und Abhängige bald zu überarbeiten... :-) > > Gru� Rolf > | |
Antwort schreiben Antworten: | |