| Re: Modul eeprom.c2 Kategorie: I²C-Bus (von André H. - 22.07.2003 14:42) | |
|
Als Antwort auf Re: Modul eeprom.c2 von Rolf - 22.07.2003 14:04
| |
|
Hallo Rolf, > ... 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. �hh, es werden doch alle Fehler abgefangen. Wenn man die Rückgabewerte aller Funktionen (au�er readbyte,-int,-long) auf True oder False prüft, wei� man, sofort, ob es einen Fehler gab. In lasterr stehen optional nur weitere Fehlermeldungen. Nur bei readbyte,-int und -long wird lasterr für die Fehlererkennung benötigt, da dies schlie�lich nicht über den Rückgabewert der Funktion selbst möglich ist. > 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) ) Nö, nur indirekt. Das ist eher dem EEProm zu verdanken, da dieses zum Schreiben eben mehr Zeit benötigt. > Andrè, der 68000 _IST_ ein 16 Bit controller und er kann sogar 32 Bit Datenregister verarbeiten... Ups, kleine Verwechlung. :-) > «eeprom.c2» > Naja.. nur funktionieren mu� es dann mit ungraden Adressen schon.... sonst hat der User eben nicht die Wahl. Funktioniert ja auch. > > ?? 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. Warum, die Schreibfunktionen geben doch alle ein True oder False zurück, ob der Vorgang durchgeführt werden konnte. Aus lasterr bekommst Du nicht mehr Infos. Jedoch habe ich als Kompromi� in writebyte lasterr schreiben lassen. Aber schlauer wird man dann aus lasterr nicht. :-) > > 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... �hh, nicht ganz: Der Fehlerkommt eher wegen der Optimierfunktion des Compilers zustande. (wie schon im anderen Thread geschrieben) Wenn Du z.B. zwei Konstanten const a=24; const b=-14; hast, und diese so verwendest x=a+b;, dann macht der Compiler daraus x=10;. Bei Fehler mit dem Vergleich gibt's bei dieser Optimierung einen Fehler, und der Compiler steigt aus. > Also das mit dem "langsam" scheint ja nen echtes Trauma für Dich zu sein... *grins* In der Tat, das ist es. In Projekten mit über 100kB Sourcecode benötigt man jede ms. Darum werde ich einiges vermehrt in ASM programmieren. 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: | |