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é, > > > 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
