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è, > > > > > 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. > > Richtig... Softwareseitig.. da stimme ich Dir ja auch voll und ganz zu. > Die Threads können sich aber nicht auf den Erfolg einer Datenoperation verlassen... > und das kann durchaus systembedingte Probleme erzeugen. Glaub mir das einfach... > > > 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) > > Das habe ich begriffen. > > > > Ich frage mich jedoch, ob im Fall von Hardwarefehlfunktionen (wie in diesem Fall) > > > einfach kommentarlos abgebrochen werden darf. > > Welche Fehlfunktion ??! > > Na zum Beispiel fehlerhaft arbeitende Eeproms. Oder ein Fehler auf dem i2c-Bus. Oder ein fehlendes i=0; > > > 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. > > Nana... einen weiteren hast Du selbst heute noch gefixt. :-) > Aud das zu häufige beschreiben kann ein eeprom plätten..... obwol ich nicht weis, wie es sich dann > auf dem i2c-Bus verhält. Ggf. würde das nicht mal beim Adressieren auffallen. > Ich halte es jedenfalls für ein Unding, das Treibersoftware (und das ist eeprom.c2 nun mal) gnadenlos > über ein offensichtlichen Fehler des eeprom-i2c-Systems hinwegschaut als wenn nichts gewesen wäre. > > > > 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 ?!? > > Häng Dich doch bitte nicht an dem Wort Katastrophe auf... > Eine fehlgeschlagene Schreiboperation ist eine fehlgeschlagene Schreiboperation! > Da diskutiere ich auch nicht länger drüber... wenn PC-Treiber so geschrieben wären, > würdest Du Dein PC nicht mal booten können. > > > 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. > > Das sehe ich ein. Nur wenn Ausgaben auf dem i2c laufen und der Bus nicht ok ist, > könnte es dann nicht doch zu Fehlern in anderen i2c-Bauteilen kommen? > > > Es wird jedoch bei der Überarbeitung des Moduls eine Rückgabe von Fehlermeldungen > > geben, zumindest bei den Schreibfunktionen. Bei den Lesefunktionen wird das schwer. > > Hab ich gemerkt.. 3 Funktionen sind problematisch.... readbyte,readint und readlong > > > > 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. > > Da hast Du wiederum ultimativ Recht. :-) > > > Die Speicherzellen in einem EEProm halten schließlich auch nicht ewig. :-) > > Wenn diese defekt sind, bekommst Du dies nur durch ein Zurücklesen heraus. > > Wie ich bereits vermutete... > > > > 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. ? > > Na das worüber wir die ganze Zeit sprechen... ich denke mir, das aber auch andere Module solche Probleme haben. > > > > 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. > > Ich will Dir Deine Erfahrung auch nicht absprechen... ich würde mich selbst eher als Laie bezeichnen. > Zumindest was den I2C und die CC2 angeht. > > > > 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". > > Wie gesagt, wenn der Bus nicht ok ist, kann das im Extremfall doch zu Fehlern führen. > Behaupte ich einfach mal so.... sonst dürfte es tatsächlich keinen Einfluß haben. > > > > 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. > > Auch hier möchte ich Deine Erfahrung nicht anzweifeln. > > > 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) > > Die Wahrscheinlichkeit führ Fehler steigt mit der Leitungslänge des Busses.... > mehr brauche ich dazu doch nicht zu sagen oder? > > Ich sag Dir auch was.. ich programmiere schon seit Jahren auf Linux in C und ich weis auch > wovon ich rede.. so von wegen Multithreading, Multitasking, Seiteneffekte. Ich kenne zwar den i2c-Bus > nicht so genau aber wenn Dir einer helfen will, dann hau dem nicht auf die Finger. > So... und damit tun wir jetzt mal Butter bei die Fische! Hier kommt das von mir eben überarbeitete > Listing von eeprom.c2 Sehe es bitte als Vorschlag. Ich denke mir, das Du noch eigene Ideen dazu hast. > > /******************************************************************/ > /* Treiberbibliothek für EEPROM 24C32 bis 24C512 */ > /* */ > /* Author : André Helbig (andre.h@cc2net.de) */ > /* Version : 2.3 */ > /* Datum : 7. Juli 2002 */ > /* Geändert : 12. Januar 2003 */ > /* Getestet : ja */ > /* Benötigt : i2c.c2 ab V1.1 */ > /******************************************************************/ > /* Geändert : Rolf Diesing, bezüglich Rückgabewerte V2.3a1 */ > /* Überarbeitete Version zur Diskussion im Forum www.cc2net.de */ > /* Funktionsrückgabe TRUE bei Erfolg und FALSE bei Fehler. Die */ > /* Ausname: readbyte,readint,readlong geben den gelesenen Wert */ > /* Ersatz: getbyte,getint,getlong */ > /******************************************************************/ > /******************************************************************/ > /* eepromadr = 0 bis 7 */ > /******************************************************************/ > > const Pagewrite=128;//in Byte; siehe EEProm-Datenblatt > const FALSE = 0; > const TRUE = -1; > > /**Schreibzugriff einleiten****************************************/ > function write(byte eepromaddr,int addr) returns int > { > byte i; > i=0; > eepromaddr= 160 or (eepromaddr shl 1); > loop > { > if i2c.start(eepromaddr) break; > if i>=100 return FALSE; > i=i+1; > sleep 1; > } > i2c.write(addr shr 8); > i2c.write(addr); > return TRUE; > } > > /**einzelnes byte schreiben****************************************/ > function writebyte(byte eepromaddr,int addr, byte data) returns int > { > int i; > capture i2c.flag; > if write(eepromaddr,addr) == TRUE > { > i2c.write(data); > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > /**einzelnes Integer schreiben*************************************/ > function writeint(byte eepromaddr,int addr, int data) returns int > { > int i; > capture i2c.flag; > if write(eepromaddr,addr) == TRUE > { > i2c.write((data & 0xFF00) shr 8); > i2c.write(data & 0x00FF); > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > /**einzelnes long schreiben****************************************/ > function writelong(byte eepromaddr, int addr, long data) returns int > { > int i; > capture i2c.flag; > if write(eepromaddr,addr) == TRUE > { > i2c.write((data & 0xFF000000) shr 24); > i2c.write((data & 0xFF0000) shr 16); > i2c.write((data & 0xFF00) shr 8); > i2c.write(data & 0xFF); > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > /**Byte-Array schreiben*******************************************/ > function writebytearray(byte eepromaddr,int addr, byte data[], int len) returns int > { > int i; > capture i2c.flag; > if write(eepromaddr,addr) == TRUE > { > for i=0 ... len-1 > { > if ((addr+i) % Pagewrite)==0 and i > {i2c.stop();//sleep 1; > write(eepromaddr,addr+i); > } > i2c.write(data[i]); > } > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > /**Integer-Array schreiben***************************************/ > function writeintarray(byte eepromaddr,int addr, int data[], int len) returns int > // Für "addr" sollten nur geradzahlige Werte übergeben werden !! > // ggf. durch Fehlerfallprüfung return FALSE; ->FIXME<- r.diesing > { > int i; > capture i2c.flag; > if write(eepromaddr,addr) == TRUE > { > for i=0 ... len-1 > { > if ((addr+i*2) % Pagewrite)==0 and i > {i2c.stop(); > write(eepromaddr,addr+i*2); > } > i2c.write((data[i] & 0xFF00) shr 8); > i2c.write(data[i] & 0x00FF); > } > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > /**String schreiben**********************************************/ > function writestr(byte eepromaddr,int addr, byte s[]) returns int > { > byte a; > int i; > capture i2c.flag; > if write(eepromaddr,addr) == TRUE > { > for a=0 ... 31 > { > if ((addr+a) % Pagewrite)==0 and a > {i2c.stop(); > write(eepromaddr,addr+a); > } > i2c.write(s[a]); > } > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > /**Lesezugriff einleiten*******************************************/ > function read(byte eepromaddr,int addr) returns int > {byte i; > i=0; > eepromaddr= 160 or (eepromaddr shl 1); > loop > { > if i2c.start(eepromaddr) break; > if i>=100 return FALSE; > i=i+1; > sleep 1; > } > i2c.write(addr shr 8); > i2c.write(addr); > i2c.start(eepromaddr or 1); > return TRUE; > } > > /**einzelnes byte lesen********************************************/ > function readbyte(byte eepromaddr,int addr) returns byte > { > byte data; > capture i2c.flag; > if read(eepromaddr,addr) == TRUE > { > data=i2c.readlast(); > i2c.stop(); > } > release; > return data; > } > > /**einzelnes Integer lesen*****************************************/ > function readint(byte eepromaddr,int addr) returns int > { > int data; > capture i2c.flag; > if read(eepromaddr,addr) == TRUE > { > data=i2c.read() shl 8; > data = addr or i2c.readlast(); > i2c.stop(); > } > release; > return data; > } > > /**einzelnes long lesen********************************************/ > function readlong(byte eepromaddr, int addr) returns long > { > long data; > capture i2c.flag; > if read(eepromaddr,addr) == TRUE > { > data = i2c.read() shl 8; > data = (data or i2c.read()) shl 8; > data = (data or i2c.read()) shl 8; > data = data or i2c.readlast(); > i2c.stop(); > } > release; > return data; > } > > /**Byte-Array lesen***********************************************/ > function readbytearray(byte eepromaddr,int addr, byte data[], int len) returns int > { > int i; > if len < 1 return FALSE; > capture i2c.flag; > if read(eepromaddr,addr) == TRUE > { > for i=0 ... len-2 > { > data[i] = i2c.read(); > } > data[len-1] = i2c.readlast(); > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > /**Integer-Array lesen*******************************************/ > function readintarray(byte eepromaddr,int addr, int data[], int len) returns int > { > int i; > if len < 1 return FALSE; > capture i2c.flag; > if read(eepromaddr,addr) == TRUE > { > for i=0 ... len-2 > { > data[i] = (i2c.read() shl 8) or i2c.read(); > } > data[len-1] = (i2c.read() shl 8) or i2c.readlast(); > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > /**String lesen**************************************************/ > function readstr(byte eepromaddr,int addr, byte s[]) returns int > { > byte a; > int i; > capture i2c.flag; > if read(eepromaddr,addr)== TRUE > { > for a=0 ... 30 > { > s[a] = i2c.read(); > } > s[31] = i2c.readlast(); > i2c.stop(); > i=TRUE; > } > else > i=FALSE; > release; > return i; > } > > > Gruß Rolf > >

Dateianhang: (.gif, .png., .jpg, .zip, .rar)

max. 256kB

max. 256kB