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. > > 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

Dateianhang: (.gif, .png., .jpg, .zip, .rar)

max. 256kB

max. 256kB