Hi Leute,

Um eventuelle Probleme mit den Speicherpositionen im EEPROM zu umgehen, könnte man folgendermassen vorgehen:
Ist der Wert in der myasuro.h z.B. mit 0 definiert, soll es bedeuten, dass der Wert im EEPROM vorhanden ist und von dort, aus einer noch zu definierenden Adresse, geholt werden muss. Oder es würde bedeuten, dass eben ein in der Init()-Funktion hinterlegter Defaultwert (define) benutzt wird.
Ist aber etwas in der Datei definiert, dann wird erst gar nicht im EEPROM, oder im Init()-Default, nachgeschaut. -> Friss oder Stirb, aber eben ohne Probleme mit den Adressen im EEPROM.


Der Speicherplatzverbrauch im RAM ist, so wie m.a.r.v.i.n schon geschieben hat, zwar vorhanden, aber bis jetzt sieht es so aus, als ob alle Parameter, bis auf einen, als Byte abgelegt werden können. (Der eine wäre ein int, also 2 Byte)
Die bis jetzt vorgeschlagene Parameteranzahl würde also zu einem 'Verbrauch' von 8 Byte betragen. Da ich mir noch einen weiteren Parameter wünsche, wären es dann 9 Byte.
Ich halte dies für einen angemessenen 'Preis', die Lib doch allgemein zu halten.
Ausserdem hat es stochri schon angesprochen: Eine Lese-Funktion für das EEPROM mag noch so klein sein, aber sie belegt auf alle Fälle einiges an Speicher, den wir ja mit dem Gedanken einer Lib eben sparen wollen. (OK, OK, RAM und ROM sind was anderes.)


Die Befürchtung, dass neue Asuro-Besitzer, nicht mit der Lib, bzw. einer myasuro.h, klarkommen werden, kann ich verstehen. Hier ist eben eine gute Unterstützung durch eine möglichst 'wasserdichte' readme.txt zu gewährleisten. Ich würde diese erste Hilfe auch nicht in der HTML-Doku sehen, da man diese ja erst finden und 'starten' muss. (Auch der Weg zur HTML-Doku darf dann natürlich in dieser readme.txt stehen)


Dann tauchte noch die Frage auf, warum eine eigene Datenstruktur 'angedacht' ist. Erstens steht dies nicht fest, ist ja schliesslich unser aller LIB, und auf der anderen Seite findet man solche Variablen einfach besser im Source wieder, wenn man nach dem Strukturnamen suchen kann. Bis jetzt ziehen sich die hier angedachten Variablen durch die Sourcen asuro.c, encoder.c, switches.c und für die Variablendefinition globals.c. Da diese Variablen ja global gültig sein sollen/müssen, ist es ein Ansatz über den Strukturnamen zu sehen wozu sie denn überhaupt gehören. Meines Wissens nach benötigt dies weder mehr Speicherplatz noch Rechenzeit um auf eine Struktur zuzugreifen.


Da ich gerade beim schreiben noch von damaltor 'überholt' wurde, hier auch noch mein Senf zu den Kalibrierungsroutinen.
Grundsätzlich bin ich da absolut für. Aber genau hier muss eben auch an die Anfänger gedacht werden. Wie soll man vermitteln, dass man vor dem Gebrauch der Lib erst noch ein/einige Programm/e auf den Asuro laden muss; diese nach einer Bedienungsanleitung (lesst ihr die immer?) ablaufen lassen muss; eine Terminalemulation gerade auf Empfang steht um da ein paar Bytes in einer Datei natürlich an einer bestimmten Stelle zu speichern.
Tschuldigung, dass ich hier etwas 'ätzend' schreibe, bitte keinesfalls so verstehen, aber ich bin schon der Meinung, dass man versuchen muss eben beide Typen von Usern glücklich zu machen.
Anfänger bekommt eine für ihn editierbare Datei myasuro.h. (plus readme)
Profi kann immer noch die Lib selber umbauen und machen was er will um die Parameter zu erhalten. (Gute, schöne, schnelle, sparsame und natürlich alle glücklichmachende Lösungen unbedingt hier im Thread posten)

Schön, dass hier so viel los ist.