> > > 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
Antwort schreiben
Antworten:
Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 12.07.2003 8:56)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 12.07.2003 23:01)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 13.07.2003 10:10)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 13:44)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 13.07.2003 20:02)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 23:40)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 14.07.2003 9:15)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 14.07.2003 12:54)Re: Evtl. Fehler im Modul eeprom.c2 (von André H. - 14.07.2003 15:48)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 15.07.2003 2:57)Re: Modul eeprom.c2 (von André H. - 15.07.2003 8:25)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 10:47)Re: Modul eeprom.c2 (von 89984984/8 - 7.04.2005 10:32)Re: Modul eeprom.c2 (von André H. - 15.07.2003 11:50)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 19:31)Re: Modul eeprom.c2 (von André H. - 15.07.2003 20:26)Re: Modul eeprom.c2 (von Rolf - 15.07.2003 22:48)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 0:43)Re: Modul eeprom.c2 (von André H. - 18.07.2003 18:19)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 18:35)Re: Modul eeprom.c2 (von André H. - 18.07.2003 19:24)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 21:38)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 22:53)Re: Modul eeprom.c2 (von Rolf - 18.07.2003 22:55)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 1:36)Re: Modul eeprom.c2 (von André H. - 19.07.2003 8:41)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 13:02)Re: Modul eeprom.c2 (von André H. - 22.07.2003 10:18)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 14:04)Re: Modul eeprom.c2 (von André H. - 22.07.2003 14:42)Re: Modul eeprom.c2 (von Rolf - 19.07.2003 16:39)Re: Modul eeprom.c2 (von André H. - 22.07.2003 10:24)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 11:26)Re: Modul eeprom.c2 (von André H. - 22.07.2003 14:13)Re: Modul eeprom.c2 (von Rolf - 22.07.2003 15:04)Re: Modul eeprom.c2 (von André H. - 23.07.2003 16:42)Re: Modul eeprom.c2 (von Rolf - 23.07.2003 21:28)Re: Modul eeprom.c2 (von Rolf - 23.07.2003 12:16)Re: Modul eeprom.c2 (von André H. - 23.07.2003 16:28)Re: Modul eeprom.c2 (von André H. - 18.07.2003 22:43)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 14.07.2003 0:29)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:16)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:12)Re: Evtl. Fehler im Modul eeprom.c2 (von Rolf - 13.07.2003 15:08)