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 Rolf, > > > > 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.
