> 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"
> 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.
Das liegt daran, daÃ? alle Daten, wenn sie nicht anders definiert sind, als 16Bit behandelt
werden (Byte/Int). Will man das Ganze als Long behandelt haben, dann muÃ? sich im Term
mindestens ein Long-Wert(Variable oder Konstante) befinden. Das gleiche gilt auch für float.
Bsp.
long= (int * int) + long
hier werden zwei Integer multipliziert. Da jedoch beides Integer sind, wird das Ergebnis
auch wieder als Integer behandelt. Erst mit der Addition eines Long-Wertes wird das Daten-Format
zu einem Long.
Daher besser:
long=int
long=(long*int)+long
Wenn man den Integer vorher in einer Longvariable speichert, wird die nachfolgende
Multiplikation im long-Wertebereich durchgeführt.
> 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. :-)
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)
> 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]);
}
> 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:
> ee1=0
> addr=16384
> If writebyte(ee1,addr,wert) doerror (geterr())
> If writebyte(ee1,addr,wert) doerror (geterr())
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
und es keine weiteren Angaben zu fehlern gibt. daher müsste man in etwa so schreiben:
If writebyte(ee1,addr,wert) doerror (Konstante_für_Write_Byte_Fehler);
> If writelong(ee1,addr,wert) doerror (geterr())
> If writestring(ee1,addr,wert) doerror (geterr())
> If writebyte(ee1,addr,wert) doerror (geterr())
> ....
> addr=16384
> If readbyte(ee1,addr,wert) doerror (geterr())
> If readbyte(ee1,addr,wert) doerror (geterr())
> If readlong(ee1,addr,wert) doerror (geterr())
> If readstring(ee1,addr,wert) doerror (geterr())
> If readbyte(ee1,addr,wert) doerror (geterr())
>
> Auffallen solte bei dem Beispiel vor allem, das keine Adressen gezählt werden.
> Die doerror wäre eine vom Programmierer zugenerierende Fehlerfunktion in der er bestimmt, was im
> Fehlerfall geschehen soll. Mir ist dazu (so meine ich wenigstens) letztens aufgefallen, das wenn man in einer
> Funktion ein Funkionsparameter überschreibt, der nach oben weiter gereicht wird, unabhängig vom returnwert.
> Also so etwa:
>
> //programmstart
> a=0
> test()
> //a ist jetzt 100 obwohl die Funktion nichts zurück gibt.
>
> funktion test (int a)
> {
> a=100
> }
Nein, das geht so nicht. in der Funktion test greifst Du auf die lokale Variable a,
welche mit int a in der Funktion als übergebener Parameter definiert ist.
Nach dem Ende der Funktion auf a zugreifen zu können, mu�t Du diesen Wert entweder
zurückgeben, oder die Globale-Variable aufrufen.
Au�erdem führt Dein Aufruf von test zu einem Compilierfehler, da Du keinen �bergabeparameter
angegeben hast.
Bsp.:
Modulname sei "xy"
int a; // Globale Variable
funktion test (int a)
{
xy.a=100
}
thread main
{
a=0;
test(irgendein_Wert):
...
}
Hier wird der Wert 100 in die Globale Variable a des Moduls xy geschrieben.
Das hat auf die Lokale Variable test.a keinen einfluÃ?.
Es sind zwei komplett verschiedene Variablen, mit dem Unterschied, daÃ? test.a
nur während des Funktionsaufrufs existiert. (Ist im Handbuch auf Seite 54ff gut erklärt)
> 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.
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
> Wenn das ginge, hätte man im Fehlerfall auch die aktuelle Schreibposition, es müste jedoch für die
> Fehlerauswertung für jeden Schreibvorgang aber auch die Adresse mitgezählt werden. Verzichtet man auf
> addr als Fehlerlokalisierung und schreibt am schluÃ? einfach nur z.B. bei writestr addr=addr+32
Wie gesagt, das sind zwei komplett verschiedene Variablen. Es wird hier nur der Wert
der Variable übergeben. Mitzählen mu� man immer.
daher hatte ich auch erst immer die Anzahl der tatsächlich geschriebenen Bytes/Werte
zurückgeben wollen.
> 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)
> 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.)
So, jetzt muÃ? ich weg ...
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 - 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)