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é, > > > > Mit dem Überarbeiten des I²C-Capture wäre ja auch evtl. das Problem des Handlings mehrfacher > > > Eeprom-operationen im Zusammenhang mit Threads wie in der Ergänzung zum Bug beschrieben, > > > unter zu bringen. Sicheres Threading ist eine ganz schön komplizierte Angelegenheit... :-) > > > > > 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. 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
