> 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.
Wir sehen diese Geschichte offensichtlich unterschiedlich und kommen uns auch nicht näher.
Für mich ist eine Treiberbiblithek mit unterschidlichen Fehlerauswertungen, unterschidlichen
Rückgabeparametern und teilweise nicht abgefangenen Fehlern eben unvollkommen.
Du magst die Geschichte anders sehen und die "feinen Unterschiede" für richtig halten.
Für mich ist JEDER "feine Unterschied" und jeder nicht abgefangener Fehler (da wo z.B. read oder write
ohne Fehlerauswertung ausgeführt wird) eine potentielle, vermeidbare Fehlerquelle.
Das Lesen und Schreiben von je 32K dauert mit den Funktionen ca 45 Sek. (15 Sek. lesen, 30 Sek. schreiben,
beides jeweils mit der intarrayfunktion aus 2.4b, die 15 Sek. die write mehr braucht, haben wir dem sleep
zu verdanken (sleep 1 wie von Dir vorgegeben) )
Da wäre es Laufzeittechnisch relativ egal wenn Fehler besser weil präziser abgefangen werden!
>
> > Hm.. kann der C164 das nicht? das ging ja schon auf dem 68000er...
> Der C164CI ist ein 16Bit-Controller !
Andrè, der 68000 _IST_ ein 16 Bit controller und er kann sogar 32 Bit Datenregister verarbeiten...
> 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).
Und er kann Speicherzugriffe auf ungrade Adressen, egal in welcher Stückelung.
> > Naja gut.. das scheint bei Intel und Derivaten so üblich zu sein... es bremst ja auch ungemein...
> ?? Warum sollte dies bremsen ?
Ich bezog mich auf dem 68000er...
Speicherzugriffe auf ungrade Adressen führen beim 68000 zu zusätzlichen Leseoperationen auf dem Bus.
(Es sei denn, man verwendet den 68008, einem 68000 mit 8 Bit Datenbus.... de liest sowieso mehr...)
Du bist mal wieder auf "Anti"-Kurs...
> > 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.
Naja.. nur funktionieren muÃ? es dann mit ungraden Adressen schon.... sonst hat der User eben nicht die Wahl.
> > > 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.
Das mag sein.. das ist aber kein Grund, die Fehlerbehandlung in dem Fall anders zu machen als sonst wo.
> > 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.
Sag ich ja. Sozusagen ... :-)
> > 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.
�h... ggf. ist das auch der Grund für die "Fehler" beim vergleichen von 2 Constanten...
es stehen ja beide in Flasch und die CPU müste ein Vergleich mit 2 Werten im Flash machen,
was aber sozusagen auch 2 Adresspointer für das Flasch erfordert. Die CC2 bzw. das OS wird aber nur einen
nutzen weshalb das dann irgendwas aber nichts Sinnvolles gibt.
Vermute ich mal so... aus dem �rmel geschüttelt...
> > 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 !
>
Also das mit dem "langsam" scheint ja nen echtes Trauma für Dich zu sein... *grins*
GruÃ? Rolf
Antwort schreiben
Antworten:
Re: Modul eeprom.c2 (von André H. - 22.07.2003 14:42)