>
> > ??? 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.
Also mir ist das schon klar... nur für das aufrufende Programm sieht das unterschiedlich aus...
Ich hab das schon verstanden....
> 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.
Siehst Du.. dieses Hickhack entsteht nur, weil eben die Stringfunktionen mit ihren Rückgaben
aus der Rolle fallen. Der beste Grund, das gerade zu ziehen.
> > 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. :-)
Das sollen sie auch... aber z.B. mit zusätzlichen (eigenen) Funktionen.
Sinn und Zweck eines Treibermoduls ist die möglichst einfache und universelle Handhabung von
Systemresourcen. Das Prüfen, wie viele Zeichen im Fehlerfall geschrieben wurden, gehört eindeutig in einen
Errorhandler, der die Basisfunktionen aufruft und ggf. zusätzliche Dinge unternimmt. Im Fehlerfall
würde man z.b. auf den fehlerhaften String mit readbyte zugreifen um die Bytes des Strings zu lesen
anstatt sie mit readstr einlesen zu wollen - mit einem Ergebnis was das Betriebssystem nicht mal verarbeiten
könnte da byte 31 fehlt. Es wäre wirklich besser, readstr und writestr umzustellen.
> > 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.
Gut.... und wie prüft das Aufrufende Programm das? Etwa so?
"if writestring() == 32"
Du selbst hast mir doch den Tip gegeben, das
"if writestring()"
schneller in der Abarbeitung ist, weil der Vergleich entfällt.
Das geht aber nur, wenn passende return-Werte übergeben werden.
Jetzt packe ich Dich bei Deinen eigenen Hörnern....!
writestr mu� daher im Erfolgsfall -1 oder TRUE zurück geben.
writestr mu� daher im Fehlerfall 0 oder FALSE zurück geben.
(Sprachgebrauch.. die Funktion war false oder true... falsch oder richtig)
Wenn sie False war, müste ein Errorhandler das schecken.. in anderen Sytemen
wird typischer Weise dann lasterror() aufgerufen. Und das müste z.B. 4 aus unserem
Beispiel zurück geben.
Die Geschichte mit dem impliziten len() ist zwar nett aber es führt zu Durcheinander.
Das was Du in der Funktion einsparst, muÃ? vor der Funktion mit Aufwand erkauft werden.
> > 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 !
Ok...
writestring soll abcdefg ins eeprom schreiben. Es schreibt 32 Byte incl. [31] als Länge 7. return 32
und im Fehlerfall die Menge an geschriebenen Bytes... und 0/FALSE wenn eeprom nicht reagiert...
Ein -1/TRUE gibt es aber niemals zurück.... man müste also auf 32 und nicht auf True prüfen.
Um dies zu machen... und um im nächsten Schritt darauf reagieren zu können wäre ein Aufruf so nur
wie folgt möglich:
a=writestr();
If a != 32
dann Fehlerbehandlung mit a als Merker
// a war 32.. OK weiter
Wesentlich besser wäre
if ! writestr()
Fehlerbehandlung mit den Parametern aus writestr()
// OK weiter
Das hier geht auch....
if writestr()
// OK weiter
Fehlerbehandlung mit den Parametern aus writestr()
So.. und das geht nur, wenn sich die Stringfunktionen so wie die anderen Geänderten verhalten.
Ggf kann man ja für "Fehlerbehandlung mit den Parametern aus writestr()" noch eine extra Funktion bauen.
> > 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 !
Ok..
Aber da siehst genaus so aus... siehe writestr
> > 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.
Gut... ich prüfe also auf 32 als Rückgabewert... hatten wir ja schon oben...
Ich gehe aber hier von einem fehlerhaften Schreibversuch aus...
writestring soll abcdefg ins eeprom schreiben. Es schreibt 4 Byte. return 4 (es wird kein Byte 31 geschrieben)
> > 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)
�h.. und was sagt das OS zu einem String mit 255 Byte Länge?
Schlieslich müste es das z.B. bei der nächsten Verwendung auf den Stack schreiben... oder
im RAM-Speicher adressieren. Da kommt alles Mögliche bei raus.... und mich würde nicht
wundern, wenn die CC2 deshalb abstürzt. Das ist kein sauberer Programmierstiel!
Ein String der "je nach dem" die CC2 Platt macht, ist nicht Verarbeitungsfähig. Basta!
> > 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. :-)
Da hab ich ja nichts gegen aber Du versuchst die Stringfunktionen als eierlegende Wollmilchsau
zu schreiben... das geht nun mal nicht! Du könntest Dich in der Errorfunktion austoben.. aber nur da...
> > 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
�h.. sorry ..das stimmt... 0 scheibt an den Anfang... da haste natürlich recht.. mein Denkfehler...
> > 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.
Fehlfunktionen nicht... aber es rechnet sich schlecht damit... zumindest überschlagsweise im Kopf...
Adresse 48248+16 in scheibweise für Int-Adressierung? Da brech ich mir einen dran ab...
> 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.
Ich sag ja... möglich schon.... aber nur über solche Wege...
Versuch mal eine lineare for/next-Schleife aufzubauen (also ohne Sprung und nicht 2) die die ganzen 64 KB
von 0 bis 64K überstreicht und ohne eine Konvertierung von Long nach Int vorzunehmen... Und wenn doch nur
mit Long, dann hat sich auch das Speichersparargument erledigt :-) Das Konvertieren kostet auch wieder
zusätzliche Rechenzeit... Hätte die CC2 den Datentyp unsigned int, wäre das alles kein Problem...
Aber ich hab zu dem Thema schon ne Idee... mal gucken... :-)
Hast Du Gelegenheit, mir noch mal die neue Fassung von eeprom.c2 zu schicken? Ich will ja nicht drängeln... :-)
GruÃ? Rolf
Antwort schreiben
Antworten:
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)