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, > > > ??? 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. > > Ähh, Ich glaub Du hast nicht ganz verstanden, was ich gemeint habe, oder ich drücke > mich mal wieder unglücklich aus. :-) > Ich betrachte Strings nicht als Strings, sondern immer als Arrays mit fester Länge. > Bei der Programmierung gibt es bei mir deshalb kaum einen Unterschied zwischen einem > String und einem Byte-Array. > > Die Funktion readstr() gibt zurück, wieviele Zeichen der String enthält, und nicht, wieviele > Bytes gelesen wurden. Nur, wenn ein in das EEProm geschriebener String 0 Zeichen > enthält wird, wie bei der Fehlermeldung, 0 zurückgegeben. > > > > 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. > > Manche wollen eben mehr wissen. :-) > > > 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. > > So kompliziert ist das nicht: writestr() war erfolgreich, wenn 32 zurückgegeben wird. > Hier wird die Anzahl der geschriebenen Bytes zurückgegeben. > > > 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 > Falsch ! Hier wird 32 und nicht 7 zurückgegeben ! > > > readstring soll gleiche Adresse lesen und kriegt abcdefg in 32 Byte sowie in [31] als Länge 7. return 32 > Falsch ! Hier wird 7 und nicht 32 zurückgegeben ! > > > 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. > > Falsch, da writestr() nach erfolgreichen Schreiben immer 32 zurückgibt. > > > 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. > > Nicht unbeding. das schlimmste, das passieren könnte, wäre, daß der String mit einer > Länge von 255 ausgegeben wird. (Der Speicherbereich vom String + 223 Byte dahinter) > (Je nach dem, welchen Wert das 32.Byte hat oder ob zuerst eine Null kommt) > > > 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. > > Naja, wenn schon ein Fehler erkannt wurde, dann will man auch wissen, was passiert ist. :-) > > > 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... > > Häh ? > Warum in die Mitte des EEProms? Null ist und bleibt Null: 0 = 0x0000 = 0b0000000000000000 > > > 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 :-) > > Also, das mit dem INT-Bereich ist kein Problem ! Wofür sollten hier Offsets gut sein ? > Den Funktionen ist es egal, die Addresse einne negativen Wert annehmen, oder nicht. > Da gibt es keinerlei Fehlfunktionen. > Man kann auch ohne weiteres einen Long-Wert in einer Longvariable als Adresse übergeben. > Es werden hier die oberen 16 Bit abgeschnitten, und mit den unteren 16Bit gearbeitet. > Ich habe nur nie Long in den Funktionen in Betracht geuogen, da dies pure > Speicherverschwendung wäre. :-) > Als Bsp: > long addr; > addr=41254; // Das ist in HEX: 0x0000A126 > eeprom.writeint(0,addr,data); > Hier wird zwar aus 41254 die Zahl -24282, jedoch bleibt es bei 0xA126. > Da hier nirgends die Adresse in einer for-Schleife verwendet wird, kann es auch zu > keinen Problemen kommen. > Kurz: Der Bereich von 0 bis 65535 ist ohne weiteres möglich. > > MfG André H.
