neue Asuro Lib V2.70 (Release Candidate 3)

[damaltor]

was muss ich machen, wenn ich kein winavr benutze? bin linux-user und kompiliere den mit kate geschriebenen qullcode mit avr-gcc. wohin müssen die dateien dann kopiert werden? die .h bleibt vermutlich da wo sie immer war, aber die .a datei?

[Thowil]

was muss ich machen, wenn ich kein winavr benutze? bin linux-user und kompiliere den mit kate geschriebenen qullcode mit avr-gcc. wohin müssen die dateien dann kopiert werden? die .h bleibt vermutlich da wo sie immer war, aber die .a datei?

Entweder du schiebst die Dateien in die include bzw. lib-Verzeichnisse deiner avr-gcc-Installation (bei mir zb. zu finden unter /usr/local/avr/avr/) oder aber du gibst im makefile deines aktuellen Programms einfach -I/pfad/zu/asuro.h in den CFLAGS und -L/pfad/zu/libasuro.a in den LFLAGS an. In beiden Fällen genügt dann im Programmkopf ein #include <asuro.h> und alles sollte klappen.

btw: Solltest du die lib neu übersetzen wollen, muss noch schnell in deren makefile CC auf avr-gcc gesetzt werden, ebenfalls empfehlen kann ich -Os statt O2 .

Was die userspezifischen Konstanten angeht, so ist ein Block von #defines (entweder in der asuro.h oder in einer weiteren Datei) sicher eine gute Idee, allerdings leuchtet mir im Moment nicht ein, warum man das ganze in eine Struktur packen sollte. Mit dem RAM-Verlust erkauft man sich doch auf diese Art eigentlich nur den "Luxus", dass jemand, der sich die lib besorgt diese nicht selbst compilen muss (so denn libasuro.a im Package erhalten bleibt). Irgendwie erscheint es mir gerade einfacher, schnell nach einmaligem anpassen der config make aufzurufen (evtl auch direkt mit nem install) und dafür auf die Struktur zu verzichten...

[damaltor]

Perfekt, vielen Dank. bis jetzt scheints zu funktionieren =)

[m.a.r.v.i.n]

Hi,

oh ja, die Linux-User hätte ich fast vergessen.

ebenfalls empfehlen kann ich -Os statt O2

Stimmt, das spart ebenfalls noch ein paar Bytes ein.

Was die userspezifischen Konstanten angeht, so ist ein Block von #defines (entweder in der asuro.h oder in einer weiteren Datei) sicher eine gute Idee, allerdings leuchtet mir im Moment nicht ein, warum man das ganze in eine Struktur packen sollte. Mit dem RAM-Verlust erkauft man sich doch auf diese Art eigentlich nur den "Luxus", dass jemand, der sich die lib besorgt diese nicht selbst compilen muss (so denn libasuro.a im Package erhalten bleibt). Irgendwie erscheint es mir gerade einfacher, schnell nach einmaligem anpassen der config make aufzurufen (evtl auch direkt mit nem install) und dafür auf die Struktur zu verzichten...

Deswegen wollen wir das ja hier auch erst diskutieren, bevor wir irgendetwas festklopfen. Klar, wäre es einfacher und Ressourcen sparender direkt mit den Defines zu arbeiten. Dann muß halt jeder User die Lib selbst übersetzen, wenn er die Werte ändert.

Im Hinterkopf hatte ich aber auch noch ein Kalibrierprogramm, das diese Werte weitestgehend automatisch ermittelt und dem Nutzer dann Vorschläge macht, welche Werte er nehmen soll. Oder noch komfortabler, die Werte gleich in den EEPROM Bereich schreibt, um sie dann beim Programmstart von dort auszulesen.

[damaltor]

klar, der eeprom wäre hierfür gut zu nutzen. ausserdem ist er einfach und unkompliziert anzusprechen. die init-funktion würde dann wahrscheinlich gleich die entsprechenden werte abfragen, oder eben die entsprechende funktion die die werte benötigt. an sich: tolle idee, aber:
-> 99% der neuen user, die sich blind die neue lib runterladen werden sich wundern dass "es nicht geht", da sie das kalibrierungsprogramm noch nicht ausgeführt haben und deshalb in jeder zelle des eeprom "." steht. und dann hier einen thread nach dem anderen eröffnen =)
-> ich benutze den eeprom in einigen meiner programme. damit gehöre ich zwar nicht zur masse der user (vermute ich mal) aber es wird bestimmt einige geben. die müssten dann entsprechende änderungen vornehmen, und wahrscheinlich wäre der eeprom dann auch für eigene Projekte mit vorsicht zu geniessen. sowie man (auch aus versehen) in eine falsche zelle schreibt, gehen alle anderen programme nicht mehr. und dann darauf zu kommen dass man das kalibrierungs programm wieder mal ausführen muss... ich glaub ich würde ewig suchen.
-> wären dann alle diese variablen in den ram geladen, wäre dieser wahrscheinlich auch recht schnell sehr voll - 1 kilobyte ist nicht sehr viel, und diesen mit variablen zu füllen, die während des ganzen programms konstant bleiben wäre unnötig. man könnte das ganze über eine funktion regeln, die den eeprom liest und den wert zurückgibt, und diese funktion dann an jeder stelle wo ein wert gebraucht wird einsetzen, aber das würde dann recht stark auf kosten der performance gehen.

darum bin ihc für ein kalibrierungsprogramm, welches werte zurückgibt die man dann entsprechend eintragen muss. am besten mit einer absolut idiotensicheren anleitung, was wie wo hingeschrieben werden muss und was dann passieren muss. das spart viel unnötige fragerei und hält den eeprom frei und den ram noch dazu.

[stochri]

-> 99% der neuen user, die sich blind die neue lib runterladen werden sich wundern dass "es nicht geht", da sie das kalibrierungsprogramm noch nicht ausgeführt haben und deshalb in jeder zelle des eeprom "." steht. und dann hier einen thread nach dem anderen eröffnen =)

Das Problem liese sich umgehen, wenn im EEPROM nach einer Magic-Number gesucht wird und falls diese nicht vorhanden ist, Default-ASURO Werte verwendet - oder die Kallibrierroutinen automatisch gestartet werden.

Was mir da eher Sorgen macht, ist dass die Einbindung der EEPROM-Routinen wieder eine ganze Menge Programmspeicher fressen könnte.

Gruss,
stochri

[radbruch]

Hallo

Ich lese zwar nicht richtig mit, aber für die myasuro-Daten bei meinen eigenen Progs plane ich ein Kalibrierungsproggi das nach Abschluss die Ergebnisse als Textdatei zum Terminal sendet. Dort kopiere ich dann die Daten und speichere sie als Datei die ich dann zusätzlich zur Standart-Lib einbinden möchte.

Gruß

mic

[damaltor]

das wäre eigentlich das einfachste, eine komplett ausformulierte datei, die nur noch gespeichert werden muss.

allerdings würde wenn beim übertragen ein einziges byte fehlt oder fehlerhaft übertragen wird, die ganza ktion für die katz sein.

das problem mit der magic number zu lösen ist fein, und auch die eeprom-routinen sind nicht sehr komplex. es werden zum schreiben (wenn ich mich recht erinnere) 3 register geschrieben, und zum lesen wird ein register geschrieben und einer gelesen. kein problem also. allerdings immer noch komplexer und speicherintensiver als konstante werte, die durch zB kalibrierungen fest mit einkompiliert werden. ich denke eher an den ram, der nämlich schon recht gut gefüllt werden dürfte mit daten, die konstant sind - und meiner meinung nach auch so behandelt werden sollten. konstanten werden vor dem kompilieren festgelegt und dann mit kompiliert. dann lieber eine möglichkeit mithilfe der kalibrierung werte zu ermitteln und diese dann zu speichern, und sich dann nicht mehr drum scheren zu müssen ob der eeprom nun bereits gefüllt ist, ob man mit den eigenen daten den wichtigen daten ins gehege kommt (davor schützt auch eine magic numer nicht, da müssten wir schon mit checksums o-Ä. anfangen) und dann einfach wie gewohnt weiterarbeiten.

[m.a.r.v.i.n]

Hi,

OK. Damit ist wohl entschieden, die Defines direkt zu verwenden, und nicht über zusätzliche Variablen.

Vielen Dank für die konstruktiven Beiträge. Weiter so.

[Sternthaler]

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.