Für dieses Forum muß Javascript im Browser aktiviert werden!
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 Andrè, > > 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
