Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > > 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 > >
