> 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....
Die Lösung ist "sauber". Und die Funktionen sind einheitlich. Nur gibt es eben kleine
feine Unterschiede.
Die Array-Lese-Funktionen(Arrays & String) müssen nicht in lasterr schreiben.
Was soll man da für Zusatzinformationen reinpacken, au�er die, die man schon
vom Rückgabewert erhält ?
lasterr ist nur für erweiterte Fehlermeldungen gedacht.
> Hm.. kann der C164 das nicht? das ging ja schon auf dem 68000er...
Der C164CI ist ein 16Bit-Controller !
Der Datenzugriff erfolgt immer 16-Bit-Weise. Darum darf hier niemals eine
ungerade Adresse zur Adressierung benutzt werden.
Der Ausnahmefall: Der Byteweise Zugriff (In ASM z.B. mit MOVB).
> Naja gut.. das scheint bei Intel und Derivaten so üblich zu sein... es bremst ja auch ungemein...
?? Warum sollte dies bremsen ?
> 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.
Ich sag ja nur, da� es zum guten Stil gehöre, und nicht verboten sei.
Wie jemand den Speicher nutzt, ist jedem selbst überlassen.
> > 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...
?? Es gibt, wie bei den Array-Lese-Funktionen keine relevanten Daten für die
erweiterte Fehlererkennung mit lasterr. Darum wird das nicht dort hineingeschrieben.
> Demnach werden Strings über referenzes (Adresspointer) adressiert, alles andere als Stackwert.
> Dann hab ich das mit dem Seiteneffekt evtl. bei Stringvariablen gesehen.. na egal...
Bei Strings und Arrays wird die RAM-Adresse auf den Stack geladen.
> 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.
Richtig. Hier gibt es einen Unterschied. Man kann z.B. keine Stringkonstanten einer
Funktion übergeben, da diese in einem anderem Segment stehen.
> 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.
Möglich wäre es, jedoch benötigt man dafür eigene Datentypen, was das Ganze dann sehr umständlich
und sogar langsam macht !
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 - 22.07.2003 14:04)Re: Modul eeprom.c2 (von André H. - 22.07.2003 14:42)