> Jetzt wird der Thread langsam richtig lang. :-)
Ja .. aber wir bewegen ja auch was.. das finde ich dann schon ok. Von mir aus kannst Du auch einen
neuen anfangen wenn Du Sorge wegen der Threadlänge hast. Ich passe mich da an.
> > Das stimmt aber im Fehlerfall gibt die Funktion ohne if len < 1 return 0; den falschen Wert zurück.
> > Das aufrufende Programm meint dann, es wäre alles ok. Auf der i2c-Seite ist es das auch.
>
> Ã?hh, return 0 heiÃ?t hier immer, daÃ? nichts OK ist bzw. daÃ? 0 Werte geschrieben wurden.
Ups... kann sein.. ja..
> > Entweder man macht es bei allen array-Funktionen rein und der Treiber prüft len oder man macht es bei
> > allen raus und sagt, der Treiber ist nicht für Fehlaufrufe zuständig. Das ist eine Definitionssache...
> > komfortabeler wäre mit Prüfung.. ein bischen schneller ohne.
>
> Es ist jetzt in allen Array-Funktionen drin.
> Die Array-Schreib-Funktionen geben immer zurück, wieviele Werte(nicht Bytes) geschrieben wurden.
(Wichtig für die Doku später!)
Ich denke, der ganze Thread hier enthält wichtige Infos dazu.
> > hm..das wäre dann sowas wie eine imlizite len-Funktion in readstr...
> Ist es, ja. Ich hatte hier aber auch return -1 zurück schreiben können.
> Aber die Definition von "True" ist nunmal: x!=0 :-)
> Das einzige Problem tritt auf, wenn man einen String mit der Länge 0 aus dem EEProm liest. :-)
> (seeeeeehr unwahrscheinlich)
??? Ich glaub, Du schmeist da jetzt string und array durcheinander.
Eine Stringarrayfunktion gibts ja noch nicht..*grübel* braucht man sowas? Eigentlich ja.
Nur bei Arrays wird len angegeben. Strings werden im Ganzen gelesen.
Ein Lesen von einem String mit der Länge 0 führt zu einem Lesen von 32 Byte.
Das Lesen von einem Array mit der Länge 0 wird nun einheitlich als Fehler abgebrochen.
Das ist ja die if len < 1 return 0; - Geschichte. Ich sehe das Problem also nicht.
> > Macht es dann nicht Sinn, in writestr ein return len s; statt dem return i; zu machen?
> > Weil wie gesagt.. i ist immer 31 und dann nicht die tatsächliche Stringlänge.
> > Ausserdem... len s und s[31] müsten ja dann immer das gleiche Ergebnis haben... ist das so?
> > Dann könnte man ja auch in writestr ein return s[31]; statt len einsetzen... macht die Funktionen konsistenter.
>
> Nein, es mach Sinn. Es wird die Länge der tatsächlich geschriebenen Bytes zurückgegeben.
> Ist diese nicht 32, gab's einen Fehler. Dieser könnte z.B. beim Pagewrite passieren,
> wenn das EEProm beim Adressieren für die nächste Page nicht mehr reagiert.
> Genauso ist der Rückgabewert für alle anderen Array-Schreib-Funktionen wichtig.
> Bsp.: String schreiben ab Addr. 60
> Es werden 4 Byte geschrieben, dann wg. Pagewechsel neu adressiert.
> EEProm reagiert nicht. Ergo: es wird nicht 32, sondern 4 zurückgegeben.
�hem.. da sehe ich allerdings noch dringend Klärungsbedarf... Ich will Dich ja nicht nerven aber...
Ich halte es für unnötig verkomplizierend, wenn unterschiedliche Funktionen bei ähnlichen Störungen
unterschiedlicher Werte zurück geben. Das macht die Angelegenheit schwierig, Errorhandler in der Anwendung
zu schreiben und führt zu Mi�verständnissen. Deshalb habe ich u.a. auch darauf gepocht, das die Funktionen
möglichst alle nur True oder False zurück geben. Das Grundsätzlich.
writestring hat den klaren Auftrag, ein String ins eeprom zu schreiben. Es kann erst mal nur nur Erfolg oder
Fehlschlag geben (je nach dem wie das eeprom reagiert). Wenn man für Fehlschalg einen Wert definiert,der sonst
nicht vorkommen kann, hat man bei Erfolg die Möglichkeit einen weiteren Informellen Wert zu übergeben.
(oder man zieht das ganze anders rum auf... Erfolg gleich einmaliger Wert, Fehlschlag = info.)
Einen Teilwert zurück zu geben klingt nach fuzzylogik und macht beim Schreiben von Strings kaum Sinn,
wie ich finde. So viel zur Theorie... readstring lässt sich ähnlich definieren.
Ich will das an einem Beispiel zeigen.
writestring soll abcdefg ins eeprom schreiben. Es schreibt 32 Byte incl. [31] als Länge 7. return 7
readstring soll gleiche Adresse lesen und kriegt abcdefg in 32 Byte sowie in [31] als Länge 7. return 32
Soweit alles ok. Wir löschen alle zellen mit 0xff oder 0x00.. egal.
Jetzt bricht aber writestr bei der wiederholung nach dem 4 Byte ab.
writestring soll abcdefg ins eeprom schreiben. Es schreibt 4 Byte. return 4 (es wird kein Byte 31 geschrieben)
Da kein Defaultfehlerwert kommt, müste ich vor dem Schreiben erst mit len() gucken wie viel Byte der String hat
und das dann nachher mit dem Ergebnis von writestring vergleichen.
lese ich das letzte ungeprüft mit readstr, kriege ich abcdxxxxxxxxxxx ohne Längenangabe.
Jedes Programm, das damit arbeiten will, geht damit zwangsläufig in Fehlerzustände.
Deshalb mu� meines erachtens im Fehlerfall immer ein -1 zurück gehen, auch wenn ein Teilstring geschreiben
werden konnte. Wenn man dann als Goodie im Erfolgsfall die Anzahl Zeichen zurück gibt (implizites Len() )
ist das ok da die niemals -1 sein können. Ein fehlerhaft geschriebener Teilstring wäre später im Programmlauf
wertlos. Ã?berleg Dir das doch noch mal bitte, vieleicht kannst Du Dich dem Standpunkt anschlieÃ?en.
>
> > Ok.. ich denke auch, das es schnell geht.
>
> Die Long-Array-Funktionen sind drin.
Prima.
> Diese 1MBit EEProms gibt es bereits. Jedoch ist die Adressierung wieder völlig anders.
> Darum wäre es hierfür besser, wie für die 2kBit EEProms (eeprom2k), ein eigenes Modul
> zuschreiben.(z.B. eeprom1M.c2)
> Jedoch wird das 1Mbit-EEprom nicht so leicht erhätlilich sein. Auch der Preis wird höher sein.
> AuÃ?erdem gibt's ja noch das CC2Net-RAM-Device mit bis zu 4 MBit. :-)
> (Und evtl. auch irgendwann ein CC2Net-Flash od. RAM-Device mit 8MBit.)
hm.. da hab ich noch kein �berblick.. Was aber in jedem Fall in die Doku müste wenn Du bei INT-Addressierung
bleibst, ist die Geschichte mit Vorzeichen und Int als Adressen... weil's ja keine unsigned INT's sind.
Die Adresse 0 schreibt ja mitten in das eeprom... und Adressen über 32768 sind logisch negativ... damit läst
sich sehr schlecht rechnen... die Leute mit 24c512er Bausteinen haben es mit INT nicht einfach, 64K
anzusprechen... Deswegen dachte ich an Long-Adressen, man könnte das mit Offsets in den Funktionen so
korrigieren, das der normale Programmierer / Anwender der Module einen "virtuellen Adressraum von 64 K hat.
Physikalisch würden auf dem i2c natürlich weiter INT's als Adressen geschrieben.
Mit steigender Verbreitung der 24c512er Bausteine wird das Problem drängender... sehe ich so...
Aber wie gesagt.. das ist eher erst mal nur was für die Doku. Sonst wirds zu kompliziert :-)
GruÃ? Rolf
Antwort schreiben
Antworten:
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)