> > Was mir beim kurzen durchlesen aufgefallen ist, Du benutzt read() teilweise mit Fehlerprüfung, Teilweise ohne.
> > Hat das nen Grund? Ich meine ausser das das Modul nochnicht fertig ist?
> > Einmal so:
> > if read(eepromaddr,addr)
> > und einmal die neue Version:
> > if not read(eepromaddr,addr){lasterr=0x000200000000;return 0;}
>
> Das ist schnell erklärt:
> Einerseits verwende ich die erste Variante bei Funktionen allen Funktionen mit
> eigenstäddigen Rückgabewerten (Arrays/String):
> "Wenn Lesevorgang erfolgreich eingeleitet, dann lesen"
> Andererseits bei den Funktionen ohne möglichen Rückgabewert des Status:
> "Wenn Lesevorgang nicht erfolgreich eingeleitet, dann errorcode setzen und Funtion verlassen"
Das finde ich aber keine saubere Lösung denn dann mu� ich wieder unteschiedliche Fehlerprüfungen
vorsehen. Irgendwie kannst Du dich nicht mit dem Gedanken anfreunden, die Funktionen zu vereinheitlichen...
Es wäre nicht mal ein Laufzeitproblem da Fehler ja eigentlich nur selten bis garnicht auftreten dürften.
Unterschiedliche Fehlerabfragen machen zudem Programm unübersichtlich... denk auch mal an die,
die diese Funktionen verwenden werden... Je schwieriger und differenzierter die Anwendung um so
fehlerträchtiger ist der Einsatz. Mach doch bitte alle Fehlerfälle mit der neuen Funktion....
> > Bei den Longarrays verarbeitest Du die Longs in zwei Schritten als geteilte INTs mit shl 16
> > Lässt sich das nicht ... anders... bzw. kürzer regeln?
> > Oder gibt das Probleme wegen 16 Bit bei shl... ? ich weis es jetzt nicht genau...
>
> Richtig, es würde sonst zu Problemen kommen.
Dachte ich mir... na gut.. so gehts ja.
> > Ansonsten hast Du scheinbar alle Macken beseitigt, die noch so gefunden hatte.
> > in writeintarray den Pagebreak hast Du gefixt.. der //kommentar kann da jetzt raus...
> > von wegen gerade Adressen... das ist erledigt :-)
>
> Kommentare kommen erst zum SchluÃ? dran. :-)
LOL
> Allerdings gehört es zum guten Stil, wenn man gerade Adresen benutzt.
> Beim C164 darf man nicht auf die Idee kommen, bei Integer- oder gar Longzugriffen
> eine ungerade Adresse anzusprechen. Das endet immer mit einem "ILL INA".
> (Illegal Instruction Access)
Hm.. kann der C164 das nicht? das ging ja schon auf dem 68000er...
Naja gut.. das scheint bei Intel und Derivaten so üblich zu sein... es bremst ja auch ungemein...
Allerdings kann Deine Aussage nur für den operativen Speicher in der CC2 zutreffen da der Zugriff
bei externen eeproms sequenziell ist....immer... auch wenn nur ein Byte gelesen wird. Von da her ist das
also egal mit den Adressen weil das eeprom sowas wie ein Speichermedium und kein Hauptspeicher ist.
Ungerade Adressen sind also definitiv kein Problem im Eeprom wenn der Pagebreak ok ist.
> > Wenn ich noch was für die Wunschliste äussern darf, wäre eine Stringarray-Funktion nicht schlecht.
> > Dann sind bis auf Float alle Datentypen drin. Aber wie gesagt.... Wunschliste... das Longarray war wichtiger.
>
> Na ja, ich könnte es noch hinzufügen, aber das la� ich erstmal.
> Ich glaub, die Anwendung von Stringarrays ist eher etwas selten.
> Im Zweifelsfall kann man sich selber eine keine Routine schreiben:
>
> for i=0 ... x
> {
> eeprom.writestr(0,addr+(32*i)),String[i]);
> }
hmm... ich denke auch das man es rauslassen sollte... aber evtl. ist das was für die Tips&Tricks-Ecke
der Doku.
> > Noch ne Idee... ich gebe zu, ich kann sie erst morgen prüfen... aber ich meine, sowas gesehen zu haben.
> > Meine "Zielvorstellung" eines Programmes mit eeprom-Funktion (ins Unreine geschrieben) ist etwa so:
Ich weis nicht, wie ich auf das schmale Brett gekommen bin.... :-)
Die funktionen sind tatsächlich gekapselt und "Wasserdicht"... Die Ausnutzung des Seiteneffekts
wie früher unter C möglich und üblich geht nicht, weil eine Kopie des Wertes auf den Funktionsstack
geschrieben wird und nicht der Wert selbst oder dessen Adresse.. ich dachte ich hätte sowas gesehen
aber nach dem ich es mit einem kleinen Test ausprobiert habe, ist die Idee hinfällig.. zumindest was die
"Autoaddressierung" angeht.
> Beachte, daÃ? bei writebyte() im Fehlerfall lasterr nicht geschrieben wird und
> geterr() auch keinen Fehler anzeigt, da writebyte nur true oder false zurückgeben kann
Pffff..... irgendwie müssen wir das doch mal grade ziehen können...
> Nein, das geht so nicht. in der Funktion test greifst Du auf die lokale Variable a,
Ja.. wiegesagt... Seiteneffekte gehen so nicht... sehe ich ein.
> > Wenn das so stimmt - und ich vermute das es so stimmt sonst könntest Du z.B. eigentlich keine Strings in
> > readstr zurück geben - dann müste für mein Beispiel oben der Parameter epromaddr nicht verändert werden
> > und in addr müste die Menge der geschriebenen/gelesenen Bytes plus aktuelle Adresse eingetragen werden.
>
> Darum betrachte ich Strings als Arrays. :-)
> Man muÃ? hier unterscheiden:
> Einzelwerte, wie byte, int, long und float, werden als Wert einer Funktion übergeben.
> Diese stehen dann in einer eigenen lokalen Variable zur Verfügung und haben nichts mehr
> mit der "Quellvariable" zu tun.
Demnach werden Strings über referenzes (Adresspointer) adressiert, alles andere als Stackwert.
Dann hab ich das mit dem Seiteneffekt evtl. bei Stringvariablen gesehen.. na egal...
Es dürften dann auch noch ein Unterschied zwischen Lauzeitstrings und Stringconstanten geben
da letzteres ja im Flash landet und nicht im Betrieb überschrieben werden kann.
> Bei Strings, Arrays und eigenen Datentypen wird hier allerdings die Adresse des RAMs
> übergeben, an welcher sich das Array befindet.(Alle 3 Datentypen sind prinzipiell Arrays)
> Darum ist ein "übergebenes" Array immer direkt änderbar.
> Wenn man z.B.
> byte x[16];
> function a()
> {
> x[3]=124;
> }
> schreibt, wäre das gleichbedeutend mit
>
> byte x[16];
> function a(byte y[])
> {
> y[3]=124;
> }
> thread xy
> {
> a(x);
> }
> Der Unterschied ist nur, daÃ? man mit function a(y[]) flexibel ist, und
> jedes beliebige byte-Array (und Strings! = Bytearray) übergeben kann
Wäre es dann möglich, die Parameter für readbyte, readint und read long (die drei Problemfunktionen)
auch als arrays auszulegen? Dann wäre zwar a=readbyte(); nicht möglich
aber ein readbyte(a) müste doch gehen. So hatte ich das mal vor und deswegen wollte ich mal
neue 3 Funktionen einbringen (getabyte , getaint, getalong) die das jetzige Verhalten haben sollten.
Man kann das definieren.. getax ist Funktionen mit Rückgabe, readx sind Unterprogramme die nur Fehlerwerte
returnen und die gelesenen/geschriebenen Werte per "call by reference/array" übergeben.
Das würde einige konzeptionelle Probleme entschärfen.
> > Der Vorteil dieser Idee ist vor allem, das man sich als Programmierer nicht mehr überlegen mu�, wie lang
> > den nun die Typen beim Schreiben sind, da am SchluÃ? jeweils sozusagen schon die neue Startposition
> > für das nächste Schreiben übergeben würde.
>
> So einfach machen wir es den Leuten nicht. :-)
> Man mu� hier selbst mitzählen. Au�erdem hätte dies nur Vorteile beim sequentiellen
> Schreiben. (z.B. Datenlogger)
Oder beim sequentiellen lesen, was häufiger vorkommen dürfte... in der Listenverarbeitung z.B. ...
> > Ich hoffe, mein eeprom geht mir dabei nicht flöten.
>
> Kommt darauf an, wie of Du auf eine Speicherzelle schreiben willst. :-)
> Ab 100.000 Schreibzyklen wird es kritisch. :-)
> (Ich benutze zum Testen immer nur ein günstiges 24C64.)
hab leider keins hier...
>
> So, jetzt muÃ? ich weg ...
Ok.. ich warte auf Dein nächstes Posting...
Ich werde jetzt erst mal ein paar Sachen mit der neuen eeprom.c2 ausprobieren...
Testprogi.. für die Eeproms.... und Funktionstest für das Modul.
GruÃ? Rolf
Antwort schreiben
Antworten:
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)