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.