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è, > > > > 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" > > 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.... > > > > 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. > Dachte ich mir... na gut.. so gehts ja. > > > > 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. :-) > > LOL > > > 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) > > Hm.. kann der C164 das nicht? das ging ja schon auf dem 68000er... > Naja gut.. das scheint bei Intel und Derivaten so üblich zu sein... es bremst ja auch ungemein... > 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. > > > > 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: > > > > <font face="courier new" size=2>for i=0 ... x > > { > > eeprom.writestr(0,addr+(32*i)),String[i]); > > }</font> > > hmm... ich denke auch das man es rauslassen sollte... aber evtl. ist das was für die Tips&Tricks-Ecke > der Doku. > > > > 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: > > Ich weis nicht, wie ich auf das schmale Brett gekommen bin.... :-) > Die funktionen sind tatsächlich gekapselt und "Wasserdicht"... Die Ausnutzung des Seiteneffekts > wie früher unter C möglich und üblich geht nicht, weil eine Kopie des Wertes auf den Funktionsstack > geschrieben wird und nicht der Wert selbst oder dessen Adresse.. ich dachte ich hätte sowas gesehen > aber nach dem ich es mit einem kleinen Test ausprobiert habe, ist die Idee hinfällig.. zumindest was die > "Autoaddressierung" angeht. > > > 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... > > > Nein, das geht so nicht. in der Funktion test greifst Du auf die lokale Variable a, > > Ja.. wiegesagt... Seiteneffekte gehen so nicht... sehe ich ein. > > > > 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. > > Demnach werden Strings über referenzes (Adresspointer) adressiert, alles andere als Stackwert. > Dann hab ich das mit dem Seiteneffekt evtl. bei Stringvariablen gesehen.. na egal... > 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. > > > 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 > > 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. > > > > 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) > > Oder beim sequentiellen lesen, was häufiger vorkommen dürfte... in der Listenverarbeitung z.B. ... > > > > 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.) > > hab leider keins hier... > > > > > So, jetzt muß ich weg ... > > Ok.. ich warte auf Dein nächstes Posting... > Ich werde jetzt erst mal ein paar Sachen mit der neuen eeprom.c2 ausprobieren... > Testprogi.. für die Eeproms.... und Funktionstest für das Modul. > > Gruß Rolf
