> ??? 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.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
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)