neue Asuro Lib V2.70 (Release Candidate 3)

Hallo Leutz,

es gibt mal wieder eine neue Version der Asuro Lib. Bevor diese bei Sourceforge erscheint, sollte erst mal eine kleine Betatest Phase hier im RN-Forum erfolgen.

Es gibt ein paar neue Funktionen und Verbesserungen (vielen Dank an stochri):

* SetMotorPower Funktion zum gleichzeitigen ändern von Geschwindigkeit und Richtung der Motoren.
* Sound Funktion zur Sounderzeugung mit den Motoren.
* SerPrint Funktion zur Ausgabe null-terminierter Strings.
* Go Funktion mit Distanzparameter in mm.

Eine Sache bei der Lib macht mir Sorge:

Der Code wird immer umfangreicher. Da immer alle Funktionen eines Sourcefiles mitübersetzt werden, egal ob sie aufgerufen werden oder nicht, wächst damit auch immer der erzeugte Programmcode. Da der Speicher auf dem mega8 knapp ist, wäre es vernünftiger alle Funktionen in separate Sourcefiles zu packen und daraus eine richtige Library zu erzeugen.

Kritik und Anmerkungen sind willkommen.

EDIT rc1:

Da es scheinbar keine Probleme mit der neuen Lib gibt, hier nun der 1. Release Candidate der Asuro Lib 2.70 zum Download.

Folgende Änderungen sind inzwischen eingeflossen:

* Die Asuro.c wurde aufgeteilt in eine Reihe von C-Files. Daraus wurde eine Objekt-Library erstellt.
* HTML Doku wurde aktualisiert. Jetzt wieder inkl. aller Beispiele.
* Es werden jetzt neue und alte AVR-LIBC Versionen automatisch erkannt. D.h. es gibt keine Warnungen mehr wegen obsolete Headerfile "signal.h"
* Funktionen mit Unterstrich in Funktionsnamen wurden umbenannt (Encoder_Init heißt jetzt EncoderInit)
* Kosmetik: Alle Tabs durch Spaces ersetzt. Klammersetzung nach ANSI Style.
* Die Lib Funktionen werden jetzt in den C-Files dokumentiert, nicht in der Asuro.h

EDIT rc2:
ab sofort steht nun der 2. Release Candidate der Asuro Lib 2.70 zum Download.

* Alle Funktionen sind nun komplett dokumentiert.
* eine Bugliste wurde hinzugefügt
* neue Funktion PrintLong zur Ausgabe von Long Variablen
* benutzerspezifische Header Datei myasuro.h. Dort werden Konstanten abgelegt, die sich von Asuro zu Asuro unterscheiden (z.B. der Korrektur Wert für die PollSwitch Funktion). Diese Werte werden allerdings noch nicht verwendet.

EDIT rc3:
ab sofort steht nun der 3. Release Candidate der Asuro Lib 2.70 zum Download. Erstmalig auch mit einem Setup Programm für Windows mit Installations/Deinstallations Routinen.

* I2C Funktionen. I2C Master Emulation (Autor raid_ox)
* LCD Funktionen. LCD Modul Anschluss ueber I2C Port Erweiterungs Chip PCF8574 (Autor raid_ox)
* RC5 Funktionen. Fernbedienung ueber RC5 kompatibel Fernbedienungen (Autor m.ar.v.i.n)
* SelfTest Demomode jetzt wieder mit IRDemo und RechteckDemo. Der Demomode startet, wenn nach dem Einschalten eine Taste länger gedrückt und dann losgelassen wurde.
* teilweise englische Dokumentation (Autoren: MadMan2k, m.ar.v.i.n, raid_ox)

Da die Files zu groß sind um sie hierzu posten, sind sie auf dem Sourceforge Server abgelegt.
http://sourceforge.net/projects/asuro

Da hast du Recht, eine Library wäre auf jeden Fall sinnvoll (ich arbeite seit ca. einem halben Jahr mit Libraries für den ASURO und den YETI). Als Beispiel, meine Batch-Datei zur Erzeugung meiner YETI Library. Wichtig ist, dass die Object-Datei (*.o), in der sich die main()-Funktion befindet, vorher aus dem Projektordner gelöscht wird. Zur Projekterzeugung benötigt man ja eine main(), da sonst der Compiler meckert, aber in der Library hat die main()-Funktion nichts zu suchen! Beim Erstellen einer Library muss sich jede Funktion in einer eigenen Source-Datei bzw. Object-Datei befinden, da sonst die anderen, nicht benötigten Funktionen, die sich evtl. in der Datei befinden, später in das Projekt mit eingebunden werden! Der Linker bindet immer alle Funktionen die sich in einer Object-Datei befinden mit in das Projekt ein, nicht nur die benötigte/n Funktion/en. Deshalb sollte jede Source-Datei, die für eine Library geschrieben wird, auch nur jeweils eine Funktion beinhalten damit später auch wirklich nur die benötigten Funktionen in das Projekt eingebunden werden!

REM
REM ************************************************** **
REM der Name der Library die erzeugt werden soll
REM hier libyeti.a (ACHTUNG! .a nicht vergessen)
REM ************************************************** **
SET LIBRARY=libyeti.a
REM
REM ************************************************** **
REM der Name der Datei in der sich die main()-Funktion
REM befindet hier yeti_lib.o (yeti_lib.c)
REM ************************************************** **
SET MAIN_FUNKTION=yeti_lib.o
REM
REM ************************************************** **
REM der Name der Dump-Datei für die *.o-Dateien
REM ************************************************** **
SET LIBRARY_DUMP=libyeti_obj.dump
REM
REM ************************************************** **
REM alte Library mit del löschen
REM ************************************************** **
del %LIBRARY%
REM
REM ************************************************** **
REM die Datei in der sich main() befindet löschen
REM
REM A C H T U N G !
REM
REM die Library darf keine main()-Funktion enthalten
REM ************************************************** **
del %MAIN_FUNKTION%
REM
REM ************************************************** **
REM diese Zeilen erzeugen die Library
REM Infos zu den Programmen (avr-*) in der Doku zu WINAVR
REM ************************************************** **
c:\Winavr\bin\avr-objdump -h *o > %LIBRARY_DUMP%
c:\Winavr\bin\avr-ar r %LIBRARY% *.o
c:\Winavr\bin\avr-ar t %LIBRARY%
REM
REM ************************************************** **

Gruß, Peter (Ronny10)

Hi,

Gestern habe ich die ersten Versuche mit einer Objektcode Library für den Asuro gemacht. Das ganze funktioniert, wie erhofft, wunderbar. Die Codegröße der Beispielprogramme sinkt damit drastisch, nachdem die asuro.c Datei in viele kleine Dateien aufgeteilt wurde und daraus eine Objektcode Library erzeugt wurde.

Das schöne daran ist, dass man nichts am bestehenden Quellcode ändern muß. Lediglich im Makefile muß statt der asuro.c die libasuro.a dazugelinkt werden. Nach ein paar Aufräumarbeiten werde ich die Lib heute abend dann zum Download freigeben.

Zu beachten ist aber, wie Ronny10 schrieb, dass man erst alle alten Objekt Files und Depencies Files löscht, bevor man ein bestehendes Projekt damit übersetzt. Nach Änderungen an der asuro.h bzw. den Library Sourcefiles muß die Library natürlich neu erstellt werden und in das avr lib Verzeichnis kopiert werden. Evtl. sollte man auch besser die asuro.h in das avr include Verzeichnis kopieren, damit man sich nicht durch inkompatible Versionen Compile Errors einhandelt. Dazu müßte dann aber doch der Quelltext geändert werden. Statt

#include "asuro.h"

müßte man dann

#include <asuro.h>

schreiben.

Hallo Marvin,
herzlichen Dank für Deinen Arbeitsaufwand. Mich würde mal interssieren, ob die neue Lib schon jemand ausprbiert hat.

Ich habe mir auch schon mal überlegt, die Funktionen der Asuro-Lib in verschiedene Dateien aufzuteilen, z.B. motor.c serial.c usw.
Man könnte dann auch ein AVR-Studio Projekt draus machen und die Sache wäre schön modular. Eventuell wäre es aber für Anfänger etwas komplizierter mit Programmers Notepad.

Soweit erst mal,
stochri

Im AVR-Studio wird im Projekt mit [Project] [Configuration Options] [Libraries] unter Library Directories und [Add] zuerst der Ordner in dem sich die ASURO-Library befindet ausgewählt. Danach wird die ASURO-Library, die jetzt im Fenster Available Link Objects: zusätzlich erscheint, selektiert (Name der Library angeklickt) und mit [Add Library-->] in das Projekt aufgenommen. Im Fenster Link with These Objects: muss dann der Name der ASURO-Library erscheinen! Zum Abschluss mit [OK] bestätigen und die Projekteinstellungen abspeichern.

Gruß, Peter

Hi,

wie versprochen folgt jetzt die Asuro Objekt Library ebenfalls als Betaversion. Vom Funktionsumfang entspricht sie der C-Library V2.70. An bestehenden Quellcode muß nichts geändert werden. Lediglich in den Makefiles muß folgende Zeile hinzugefügt werden.

LDFLAGS += -lasuro

Dazu ist es notwendig, die Objekt Library \lib\libasuro.a
in das WinAVR\avr\lib Verzeichnis zu kopieren.
Ebenso sollte man die Header-Datei \lib\inc\asuro.h in das WinAVR\avr\include Verzeichnis kopieren.

Muß man Anpassungen an den Lib Sourcefiles oder asuro.h vornehmen, muß anschließend die Lib neu erzeugt werden mit:

make clean
make all

Das kopieren nicht vergessen.

Es gibt weiterhin die Datei \lib\asuro.c . Diese beinhaltet aber nur noch die Interrupt Funktionen und die Init Funktion. Diese muß also wie bisher mitübersetzt werden. Die Beispiel Makefiles im Ordner examples sind bereits alle entsprechend aktualisiert.

EDIT:

Release Candidate 1 der Lib befindet sich am Thread Anfang.

Tolle Arbeit m.a.r.v.i.n,
schön sortierte/gruppierte Sourcen.

Ich hab noch keinen Test gemacht; bisher erst nur einmal in das ZIP geschaut.


Ist bestimmt noch nicht zu spät: Ein schönes neues Jahr euch allen.

Hi,

Zitat:

---

Zitat von m.a.r.v.i.n

Hi,

wie versprochen folgt jetzt die Asuro Objekt Library ebenfalls als Betaversion.
...

---

sieht gut aus, werde es gleich mal Testen!

Aber: die html-Doku ist größtenteils über Board gegangen :(, da ja nur asuro.c und asuro.h dokumentiert sind.
Für die finale Distribution bitte auch für die anderen .c-files die Doku erzeugen lassen ...

@HermannSW
Ja, da muss ich zustimmen, dass die Kommentare mager sind.
Leider ist das Original ja auch nicht besondes gut kommentiert, so dass man m.a.r.v.i.n hier bestimmt nicht den Schwarzen Peter zuschieben kann.

Da ich selber immer für viel und aussagekräftige Kommentare bin würde ich mir die Arbeit machen und Kommentare schreiben.

Wie ist es? Sollen wir das in Angriff nehmen?
Fragen dazu:
- Deutsch/Englisch (Ich wäre für Deutsch)
- Einrücktiefe (Ich bin für 3 Leerzeichen)
- Was oll in den Kopf?
- Funktionsname
- Funktionsbeschreibung
- In-Parameter mit Wertebereich/Funktion
- Out-Parameter (haben wir in der Lib nur wenige)
- Global beeinfluste Variablen
- Änderungsbeschreibung?
- Datum, Version, Autor, Beschreibung der Änderung

Und noch einige offene Punkte.
Du hast html-Doku angesprochen.
Da ich keine Ahnung habe, wie man die dann erzeugen könnte, müssten dann wohl noch Steuerelemente in den Kommentar geschrieben werden.
Wie geht das, was ist da notwendig?

Auf geht's, nehmen wir m.a.r.v.i.n's Muster und bauen um?
Sinnvoll, ist es bestimmt, wenn sich m.a.r.v.i.n hier mit Einklinken würde, da er ja schon so ein schönes Packet hat.

Zitat:

---

Da ich keine Ahnung habe, wie man die dann erzeugen könnte, müssten dann wohl noch Steuerelemente in den Kommentar geschrieben werden.

---

Hallo Sternthaler,

das geht automatisch mit Doxygen ( lohnt sich übrigens, sich das mal anzuschauen, habe ich auch erst vor kurzem kennengelernt ). Es müssen nur die Kommentare im Quelltetxt ein bestimmte Form haben. In der alten Lib waren die noch entsprechend formatiert, in der neuen LIB muss das wohl verloren gegangen sein.

Was die Sprache anbelangt: Deutsch wäre wohl für viele hier besser ( aber vielleicht kann man ja die englischen Kommentare, die es schon gibt, stehen lassen und zusätzlich auch einen deutschen Text hinzufügen ). Aber ich befürchte, dass das Einbinden der neuen Lib schon den ein oder anderen Neuling überfordert.

Gruss,
stochri

Zitat:

---

Zitat von stochri

schon den ein oder anderen Neuling überfordert.

---

Mhhmm, ich weiss nicht so recht. m.a.r.v.i.n hat die Datei install.txt angefangen und das ist ja schon ein funktionsfähiger Anfang.
OK, da kann man bestimmt noch dran arbeiten.
Wenn man aber davon ausgeht, dass bis jetzt ja noch nicht allzu viele Leute an der Lib mitgearbeitet haben und somit für die 'Endanwender' der Lib eigendlich nur noch das Kopieren an die richtige Stelle übrig bleibt, denke ich, dass doch auch Anfänger damit zurecht kommen werden.

Nun aber zu meinem ersten Muster aus der zerlegten m.a.r.v.i.n-Lib.
Als Anmerkung vorab:
Ich bin der Haarspalter und habe den angehängten Source nicht nur kommentiert (ganz bestimmt nicht im Sinne von Doxygen; den Hint von stochri habe ich jetzt gerade erst gelesen), sondern auch etwas umformatiert.
- Als erstes habe ich die TAB-Zeichen in BLANKS getauscht, so dass jeder beliebiege Editor einen einheitlich formatierten Text sehen kann.
- Dann habe ich vor die öffneden Klammern ( und [ immer ein Leerzeichen gesetzt.
- Alle Variablen und Funktionen habe ich 'besonders' eingerückt. Dazu folgendes Muster, warum ich das so gemacht habe:

Code:

---

volatile unsigned char  count36kHz;
static  unsigned char  global_daten1;
        unsigned long  global_daten2;
                  char  global_daten3 [100];


                  void  funktion (
        unsigned int  *data)
{
static  unsigned char  lokal_daten1;
        unsigned long  lokal_daten2;
                  char  lokal_daten3 [100];
}


static            int  *andere_funktion (
        unsigned int  *data,
                  char  steuerung)
{
static  unsigned char  lokal_daten1;
        unsigned long  lokal_daten2;
                  char  lokal_daten3 [100];
}

---

Und nun erst einmal die Datei adc.c als erster Versuch einer Kommentierung.

Hi,

Hilfe ist immer sehr willkommen. Gerade die Dokumentation ist derzeit sicher noch etwas dürftig. Dank einem Tool wie Doxygen läßt sich das aber hervoragend automatisieren und da die Dokumentation im Sourcecode mit drinsteht ist sie auch immer aktuell.

Was die Code Formatierung angeht, würde ich das lieber ebenfalls einem Tool überlassen. Dies wurde bisher absichtlich nicht gemacht. Das hat mit dem Versionsverwaltungssystem zu tun. Da beim änderen der Tabs in Spaces quasi jede Zeile geändert wird, würde auch die Versionsverwaltung jede Zeile als geändert betrachten. Man könnte nicht mehr unterscheiden, was jetzt wirkliche Codeändeungen waren.
Da mit der aufgesplitteten Lib sowieso alles neu wird, wäre jetzt der richtige Zeitpunkt, den Quellcode umzuformen. Ein entsprechendes Tool wäre z.B. Artistic Style. Damit lassen sich Quellfiles im nu umformatieren. Nicht nur Tabs und Spaces. Auch Einrückungen und Klammern kann man nach Belieben formatieren.

Als Coding-Styles würde ich vorschlagen:
* Ansi C Style für Klammern und Einrückungen
* Tabs mit 4 Spaces ersetzen.
* Funktionen und Variablen Namen und Definitionen in Englisch
* Kommentare in Deutsch

@sternthaler: bis auf die besonderen Einrückungen eine gute Idee. Ich glaube so etwas unterstützen die Quellcode Formatierer wohl nicht. Werde ich mir aber nochmal näher anschauen.

Die doxygen Kommentare sind auch in der neuen Lib noch vollständig drin. Ich habe nur aus Platzgründen die Examples weggelassen.

Hab mal doxygen gezogen und etwas damit rumgespielt.
Hätte mich gewundert, wenn ich in der kurzen Zeit etwas Vernünftiges hinbekommen hätte.

Was ich bisher verstanden habe:
Alle dokumentierenden Stellen der Lib sind wohl nur in der asuro.h.

Ich frage mich ob dies sinnvoll ist.
Ich für meinen Teil schaue mir gerne den Code an, um die Funktionalität zu verstehen. (Liegt wohl daran, dass bei uns in der Firma die Doku nicht unbedingt verläßlich ist. Psst, nicht weitersagen!) Somit habe ich den Hang dazu, möglichst viel Doku im Source unterzubringen. Somit wäre dies aus meiner Sicht die richtige Stelle.
Andererseits ist es natürlich nicht verkehrt nur eine Stelle für den Doku-Text zu haben.
Als Vorteil für eine Dokumentierung in den C-Sourcen sehe ich allerdings, dass einzelne Sourcen OHNE Änderung der asuro.h gemacht werden können. Somit können sich noch mehr Leute beteiligen; ihre Duku an der Sourcestelle hinterlegen, und man muss nicht darauf aufpassen, dass die asuro.h von mehreren Leuten 'zerlegt' wird.
Z.B.: könnte jemand eine neue Funktion, in eigenem C-Source, für die Lib erzeugen, seinen Kommentar dort hinterlegen und nach der Integration in der Lib ist das erledigt.

Wie wollen wir vorgehen?

Wer fühlt sich im Moment eigendlich als Master-of-Asuro-Lib und pflegt/verwaltet neue Stände? (m.a.r.v.i.n bitte die Hand hoch)

@m.a.r.v.i.n
Auf eine 'besondere' Formatierung kann ich in der Lib auf alle Fälle verzichten.
Mit den 4 Blanks zum Einrücken habe ich leichte Probleme, da es mir häufig am Ende der Zeile zu knapp für einen //-Komentar wird. (Ich sehe zu, dass meine Sourcen nie breiter als 80 Char werden (alter Tunix-VI-User).)

Zu den Funktionen habe ich noch eine Anmerkung:
Englisch ist OK, aber mittlerweile habe wir Funktionsnamen mit und ohne _-Zeichen im Namen. Klar, mit Doku findet man das schnell herraus, aber sollten wir da nicht auch einheitlich werden? Wie, ist mir eigendlich egal, aber ich würde die ursprüngliche Schreibweise ohne _ bevorzugen, da ich recht sicher bin, dass der von Arexx mitgelieferte Source keine _'e benutzt und somit nicht jeder seine Sourcen umschreiben müsste.

So, erst mal (fast) genug.
Von Source-Formatieren halte ich nicht allzu viel. In der Firma haben wir ca. 30 Individualisten zum Code erzeugen; ich muss auf den Output acht geben, und hab noch keinen Formatierer gefunden der 30 Leute unter einen Hut gebracht hat. Ich bin da aber Vorurteilsfrei, solange es nicht zu stark aus irgendeinem Ruder läuft.

Hi,

Zitat:

---

Alle dokumentierenden Stellen der Lib sind wohl nur in der asuro.h.
Ich frage mich ob dies sinnvoll ist.

---

Die asuro.h ist nun mal die Schnittstelle des Anwenders zur Lib. Es spricht natürlich nicht dagegen die Funktionen in den c-Files ebenfalls mit Doxygen zu kommentieren. Ich hatte bisher nur keine Zeit dafür. Doxygen macht aber auch jetzt schon aus den c-Files ordentliche HTML Seiten.

Zitat:

---

Wie wollen wir vorgehen?

---

Der gesamte Quellcode befindet sich im CVS auf dem Sourceforge Server. Wer mitarbeiten willl, meldet sich am einfachsten als Entwickler bei Sourceforge an. Eine kurze email oder PN an mich mit dem Entwicklernamen und er bekommt Schreibrechte.
Sehr viel mühsamer wäre es, die Änderungen per email zu verschicken, oder hier im Forum zu posten. Komplette Zip-Files dagegen lassen sich leichter einhäkeln.

Statt CVS wäre es vielleicht besser, gleich auf SVN umschwenken.

Zitat:

---

Wer fühlt sich im Moment eigendlich als Master-of-Asuro-Lib und pflegt/verwaltet neue Stände?

---

da heb ich mal spontan die Hand.

Zitat:

---

Mit den 4 Blanks zum Einrücken habe ich leichte Probleme

---

OK, 2 Blanks sollten auch reichen.

Zitat:

---

Funktionsnamen mit und ohne _-Zeichen im Namen.

---

Da stimme ich dir zu. Die Unterstriche fliegen also raus.

Zitat:

---

Von Source-Formatieren halte ich nicht allzu viel.

---

Ich habe mal probehalber Artistic Style über die Lib gejagt. Sieht alles ganz sauber aus. Einrückungen sind damit problemlos änderbar.

RN-User madman2k hat einige der Sachen die hier gesagt wurden, bereits in der Asuro Lib 3.0 bei gna.org umgesetzt. Leider ist diese Lib hier im Forum nicht gut angekommen. Zum einen wurden von ihm alle Kommentare ins englische übersetzt und einige Funktionen umbenamst.
Es wäre schade, wenn es zwei Libs gäbe, die sich in unterschiedliche Richtungen entwickelt. Vielleicht gelingt es, die Lib 2-sprachig zu kommentieren (deutsch, englisch). Mich erreichen zur Lib doch des öfteren Mails aus dem Ausland, die mit der deutschen Doku nichts anfangen können. Allerdings scheint doxygen mit so etwas überfordert zu sein.

Zitat:

---

Hätte mich gewundert, wenn ich in der kurzen Zeit etwas Vernünftiges hinbekommen hätte.
Was ich bisher verstanden habe:
Alle dokumentierenden Stellen der Lib sind wohl nur in der asuro.h.

---

Hallo Sternthaler,
vor kurzem habe ich Doxgen mal ausprobiert und fand es eigentlich nicht schlecht. Ich habe einfach meine Funktionsköpfe mit dem entsprechenden Syntax /// oder

/*!
* Diese Funktion macht ... blabla
*/

in den *.c Files versehen und Doxygen drüberlaufen lassen. Das Ergebnis war eine recht schöne Dokumentation. Ich finde es übrigens auch besser, die Kommentare in die *.c files anstatt getrennt in die Header-Datei zu schieben. Ist ja schließlich beim Sourcecode durchlesen wichtig.

Zitat:

---

RN-User madman2k hat einige der Sachen die hier gesagt wurden, bereits in der Asuro Lib 3.0 bei gna.org umgesetzt. Leider ist diese Lib hier im Forum nicht gut angekommen. Zum einen wurden von ihm alle Kommentare ins englische übersetzt und einige Funktionen umbenamst.

---

Die Lib 3.0 stört mich ziemlich. Ich finde es eine Unverschämtheit, dass madman2k einfach die Nicknames aus den Funktionsköpfen entfernt hat und damit nicht mehr nachvollziehbar ist, wer an welcher Funktion gearbeitet hat. Meiner Meinung nach sollte man es in der Lib vorschreiben, dass die Autoren die an den Funktionen gearbeitet haben, in den Funktionsköpfen genannt werden.

Eine Funktion fehlt meiner Meinung nach übrigens noch: Einen Teilkreis fahren zu können z.B. in der Art

GoArc( int radius, int winkel );

int radius in mm
winkel in -360° ... +360°

Damit könnte man dem ASURO zu etwas runderen Bewegungen verhelfen.

Ich weiss nicht wann ich dazu komme, aber es könnte noch eine ganze Weile dauern.


Gruss,
stochri

Zitat:

---

Zitat von m.a.r.v.i.n

Die asuro.h ist nun mal die Schnittstelle ...

---

Ich bin, so wie stochri, doch auch eher für ein umlegen der Kommentare.
Die Arbeit kann ich übernehmen und die bestehende Doku ersteinmal platt umschreiben in den von dir getrennten Sourcen. Ich habe den von dir gepostenen ZIP-Stand.

Zitat:

---

Zitat von m.a.r.v.i.n

Wer mitarbeiten willl, meldet sich am einfachsten als Entwickler bei Sourceforge an.

---

Werde ich heute Abend versuchen. Ich schicke dir dann gegen 2:30 eine Mail. Bitte um sofortige Antwort ;-)
Blöde ist nur, dass ich das zum ersten mal mache. Rechnet eher mit Fragen als einer gelungenen Anmeldung.

Zitat:

---

Zitat von m.a.r.v.i.n

... gleich auf SVN umschwenken.

---

Da bin ich dafür, da ich SVN so halbwegs kenne. (Hey, und ich bin nun nicht mehr Windoof 98-User auf dem ja kein SVN-Server läuft. Hab über Weihnachten doch mal das veralterte XP installiert. Vista kann warten.)

Zitat:

---

Zitat von m.a.r.v.i.n

da heb ich mal spontan die Hand.

---

SUPER

Zitat:

---

Zitat von m.a.r.v.i.n

OK, 2 Blanks sollten auch reichen.

---

Einverstanden

Zitat:

---

Zitat von m.a.r.v.i.n

Die Unterstriche fliegen also raus.

---

Kann ich im Zuge der Kommentar-Umlegung gleich mitmachen.
Ich hoffe, dass stochri dann nicht auch auf mich schimpfen wird.

Zitat:

---

Zitat von m.a.r.v.i.n

v.i.n"]Artistic Style

---

Ziehe ich mir dann wohl auch mal.

Zitat:

---

Zitat von m.a.r.v.i.n

.. die Lib 2-sprachig zu kommentieren (deutsch, englisch).

---

Da werde ich mich auch mal dran versuchen.

Zitat:

---

Zitat von stochri

und fand es eigentlich nicht schlecht.

---

Stimmt, ich war auch überrascht was man da so alles machen kann. Ich hatte nur noch nicht den rechten Überblick wo die doxygen-Kommentar in unserer Lib eigendlich herkamen, als ich die ersten Versuche machte und hab da etwas hinterhergesucht. Die Doku zu doxygen kann sich echt sehen lassen.

Wer weiß denn, wie man die, fast immer leeren, Unterverzeichnisse wegkonfiguriert, die unterhalb des Doku-Output-Verzeichnisses angelegt werden? (Zumindest bei mir)

Zitat:

---

Zitat von stochri

Ich finde es eine Unverschämtheit ...

---

Da kann ich nur zustimmen.
Inkompatibler Code und geänderte Funktionsnamen sind das eine, aber die Info, wer sich da so viel Mühe gegeben hat zu vernichten ist tatsächlich nicht so nett.


So, bevor ich nun aber anfange, da etwas 'in Echt' zu machen, werde ich folgendermassen vorgehen.
1. Anmelden bei Sourceforget.
2. Mail an m.a.r.v.i.n
3. 'Artistic Style' testen (der Einwand, dass dann jede Zeile als geändert moniert wird, ist dann ja nur einmal vorhanden.
4. Hier im Thread auf weitere Einwände / Ideen / Vorschläge WARTEN
5. Startschuss zur Änderung sollten wir hier noch abstimmen.


Mir fällt noch folgendes ein:
Wenn man über die Forenauswahl geht, hat Frank immer einen Thread a la "Globale Ankündigung:" oder "Ankündigungen: Wie sieht der Asuro aus" in die niemand etwas reinposten kann. Der steht auch noch immer schön oben in der Liste.
Sollten wir Frank nicht mal darauf ansprechen, evl. so einen Thread zu bekommen, in dem Links zu den 'irgendwo' gespeicherten Libs (alle Versionen?) zum Asuro zu finden sind.
Dann müssten wir nur 'irgendwie' doch Zugang zu dem Eintrag bekommen, wenn es denn mal eine neue Lib gibt.

Hi,

die Asuro Lib ist nochmals überarbeitet worden und befindet sich jetzt als Release Candidate 1 im 1. Post dieses Threads als Attachment. Die wichtigsten Änderungen sind bereits eingeflossen (Siehe 1. Posting). Dieser Stand wird dann auch demnächst im SVN auf Sourceforge eingecheckt. (Hab leider noch etwas Probleme mit meinem SVN Client, um über SSH auf Sourceforge zugreifen zu können).

@sternthaler. Leere Verzeichnisse bei der Doku Erstellung bekomme ich nicht.
Ich hab auch das doxyfile soweit geändert, das jetzt alle Pfadangaben relativ sind und dazu gibt es ein Batchfile zum Erstellen der HTML-Doku. Damit müßte es ohne Anpassung überall laufen.

Hi,

ich bin ein begeisterter Verwender der neuen Lib.

Zitat:

---

Zitat von m.a.r.v.i.n

Hi,

die Asuro Lib ist nochmals überarbeitet worden und befindet sich jetzt als Release Candidate 1 im 1. Post dieses Threads als Attachment. Die wichtigsten Änderungen sind bereits eingeflossen (Siehe 1. Posting). Dieser Stand wird dann auch demnächst im SVN auf Sourceforge eingecheckt. (Hab leider noch etwas Probleme mit meinem SVN Client, um über SSH auf Sourceforge zugreifen zu können).
...

---

Hier gibt es eine Bereichsüberschreitung für z.B. PrintInt(-12345) (abschließendes '\0'), sollte vor Distribution auf char text[7] geändert werden:

Code:

---

void PrintInt(int wert)
{
  char text[6];
  itoa(wert,text,10);
  SerPrint(text);
}

---

Ich verwende häufiger GetTime(), und da kommt ein long zurück.
Verwendung von sprintf() und SerPrint() kostet wegen sprintf() viel codesize.
Wie wäre es mit PrintLong() in der Lib? (ich bin mittels PrintLong() ganz von der Verwendung von sprintf() abgekommen ...)

Code:

---

void PrintLong(long wert)
{
  char text[12]; // '-'1234567891'\0'
  itol(wert,text,10);
  SerPrint(text);
}

---

Hallo Hermann,

danke für die Infos. Das wird noch in die neue Release einfließen.

Den aktuellen Stand der Dinge kann man sich online betrachten und downloaden im SVN Repository unter
http://asuro.svn.sourceforge.net/viewvc/asuro/trunk/

Falls noch wer Ideen und Anemrkungen hat immer her damit. Auch aktive Mitarbeiter, die sich bei Sourceforge anmelden, sind auch immer willkommen.

Hallo,

Zitat:

---

Zitat von m.a.r.v.i.n

...
Falls noch wer Ideen und Anemrkungen hat immer her damit.
...

---

mein Sohn und ich verwenden noch den Compiler von der Original-CD.

Die Idee, mittels #ifndef SIGNAL die verschiedenen Compiler-Versionen auseinanderzuhalten ist gut, und das #include <avr/signal.h> notwendig, aber leider nicht hinreichend.

Wir haben die neue Lib heute erstmals auf einen Rechner gespielt, und getan, was in install.txt stand. Ein anschließendes compilieren des IRCollisionTest lieferte:

Code:

---

...
avr-gcc -c -mmcu=atmega8 -I. -g -Os -I../../lib/inc -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-ahlms=test.lst test.c -o test.o
In file included from test.c:13:
../../lib/inc/asuro.h:291: error: parse error before "leftpwm"
../../lib/inc/asuro.h:291: warning: function declaration isn't a prototype
../../lib/inc/asuro.h:300: error: parse error before "freq"
../../lib/inc/asuro.h:300: warning: function declaration isn't a prototype
make: *** [test.o] Error 1

---

Z.B. ist der Typ int8_t nicht definiert.

Könnte die neue Lib vor Release so o.Ä. angepaßt werden? (bei uns hat das die Probleme beseitigt)

Code:

---

...
#ifndef SIGNAL
  #include <avr/signal.h>  // header file obsolete in actual avr-libc
  #include <inttypes.h>
#endif
...

---

Leute,

die Lib ist eine sehr schönes Werk - vielen Dank. Die Doxygen-Doku hat einen Fehler in motor.c:

Der Range von SetMotorPower() ist falsch beschrieben:

Zitat:

---

Setzt Motor Geschwindigkeit und Richtung (Autor: stochri)
Parameter:
leftpwm linker Motor (-rückwaerts, + vorwaerts) (Wertebereich -255...255)
rightpwm rechter Motor (-rückwaerts, + vorwaerts) (Wertebereich -255...255)

---

Richtig ist (wär hätte das gedacht) -128...127.

Simsys

Hallo Simsys,
erst einmal herzlich willkommen im Forum.
Schön, dass die Doku gelesen wird, und noch besser, das von dir eine Mitteilung zum Fehler kommt.

Du hast noch die Lib erwischt, zu der eine einheitliche Doku gerade angefangen wurde. Ich bin bisher noch nicht durch alle Sourcen gekommen um ein einheitliches Grundgerüst mit m.a.r.v.i.n zu veröffentlichen.
Habt alle bitte noch etwas Geduld.

Zu der Differenz zwischen Doku und Funktion sollten wir aber auf alle Fälle stochri befragen, denn er hat seine Funktion korrekt auf englisch kommentiert. Nur ist der Kommentar-Teil, der für die HTML-Doku benutzt wird falsch geschrieben worden.

An stochri die Frage:
Macht es tatsächlich Sinn für diese Motor-Funktion einen anderen Wertebereich beizubehalten, oder sollte man da eher einen anderen Variablentyp spendieren um bei den bekannten Werten bis 255 zu bleiben und die interne *2-Geschichte wieder entfernen?

Hallo Sternthaler,

den Wertereich -128 ... +127 habe ich aus Spargründen gewählt. Der 255er Bereich wäre natürlich angenehmer für die Programmierung, was aber sowohl Speicherplatz als auch Rechenzeit kostet, weil man ja die Variablen dann auf 16Bit erweitern muss.
Meiner Meinung nach reicht für eine feinfühlige Ansteuerung der Motoren der halbierte PWM-Wert auch aus.

Wenn Ihr es ändern wollt, könnt Ihr es ändern. Für die Programmierung wäre es von Vorteil, für den Platzbedarf von Nachteil Für mich stand die Entscheidung auch auf der Kippe. Ich habe die Routine für eines meiner Experimente mit maximaler Ausführungsgesschwindigkeit gebraucht.
Ich vermute auch, dass noch einige Routinen im Laufe der Zeit dazu kommen und dann wird man den Platz wohl benötigen wird.
Ein wenig Platzu könnte man auch sparen, wenn man die Routine in die Go- und Turn-Funktion einbaut.

Gruss,
stochri

Hi

Ich versuch grad die Interruptgesteuerte Odometrie zu versehen, aber so ganz steig ich nicht durch.

Meine Hauptfrage betrifft eigentlich die Variable toggle ind der Signal routine (den rest versteh ich noch so halbwegs)

Diese gibt ja an, ob jetzt gerade das rechte oder das linke Rad ausgelesen werden soll, richtig?
Da diese allerdings bei Aufruf der Funktion (also bei jedem interrupt ?) zu 0 initialisiert wird und erst am ende geXORt wird, ist mir ein Rätsel wie das funktioniert. Wo mach ich da grad nen Denkfehler?

Mit untertänigster Bitte um Erleuchtung ;-)

Mooses

Hallo Mooses78,
ist relativ einfach.

Es sieht tatsächlich so aus als ob die Variable immer mit FALSE initialisiert würde. Das Geheimnis ist das STATIC (natürlich klein geschrieben) vor ALLEN 3 Varaiblen:

static unsigned char tmp[2],flag[2],toggle=FALSE;

Solche, mit static erzeugten, Variablen werden GENAU EINMAL initialisiert und dann NIE wieder.
Das war's schon. C hat halt so seine Geheimnisse ;-)

Zitat:

---

Zitat von stochri

Wenn Ihr es ändern wollt, könnt Ihr es ändern.

---

OK, ich gebe dir Recht, dass das ganze Rechenzeit und Speicher kostet. Also bleibt es so und ich werden die Doku anpassen.

Oder gibt es sonst noch andere Vorschläge??

Meiner Meinung nach macht es nicht allzu viel Sinn, die Funktion MotorSpeed komplett durch die neue Funktion SetMotorPower zu ersetzen. Die original Funktion MotorSpeed ist (mittlerweile) eine inline-Funktion und benötigt dadurch nur extrem wenig Platz. Sie kann also aus Gründen der Kompatibilität ruhig drin bleiben.

Hallo,

die Doku ist inzwischen echt klasse. Eine Bitte für die Linux-Fans (ich bin einer): Die Verzeichnisse in Doxyfile sollten mit einem Slash (/) statt einem Backslash (\) getrennt sein (nicht aber das Zeilenende):

statt
examples\EncoderTest \
besser
examples/EncoderTest \

Code:

---

INPUT                  = ./ \
                        lib \
                        lib/inc \
                        examples/EncoderTest \
                        examples/FirstTry \
                        examples/IRCollisionTest \
                        examples/KollisionTest \
                        examples/LineTest \
                        examples/MotorTest \
                        examples/SelfTest \
                        examples/TasterTest

---

Doxygen generiert dann unter Windows immer noch tadelos die ganze Doku.

Gruß
Simsys

Das ist erledigt (für die nächste Version)

Hallo Sternthaler

tja, wie leicht mna so ein kleines static doch übersehen kann...

Dankeschön für die schnelle Antwort

Mooses

So, ich habe das Linien-Verfolgungs-Programm ein wenig bearbeitet:

- Auf das notwendigste reduziert
- Etwas verbessert (Dank an HermannSW!)
- Doxygen-Kompatibel kommentiert

Ich schlage vor, es statt des test.c in das Verzeichnis examples/LineTest aufzunehmen. Ich habe es in "ltest.c" umbenannt, da ich ansonsten Doxygen nicht überreden konnte die Kommentare anzuzeigen.

ltest.c

Code:

---

/****************************************************************************/
/*!
  \file    ltest.c

  \brief    Linienverfolgung

Enthält einen Algorithmus, der den Asuro Linien verfolgen lässt. Dazu wird die
LED vorne unten "FrontLED" eingeschaltet und das reflektierte Licht mittels der
beiden Empfangs-LEDs vorne unten ausgewertet.

Der Asuro regelt die Geradeausfahrt. Wenn er links neben die Linie kommt, so
bremst er das rechte Rad ab und umgekehrt. Wie stellt er fest, dass von der
Mitte abweicht? Er leuchtet den Untergrund an miss auf den Empfängern rechts
und links das reflektierte Licht. Befindet sich beispielsweise der linke
Empfänger über der hellen Linie, so wird dort mehr Licht reflektiert. Die
beiden Messwerte sind ungleich - der Asoro versucht sie wieder anzugleichen.

Regelungstechnisch gesehen handelt es sich um einen \htmlonly
I-Regler. \endhtmlonly
Solange Asuro eine Abweichung feststellt, wird er immer mehr dagegen angehen
bis die Abweichung wieder auf Null ist. Das Maß des Gegensteuerns ist nicht
abhängig von der Differenz der Helligkeiten sondern nur von der Zeit, wie
lange die Abweichung besteht.

**************************************************************************/

/**************************************************************************
*
* Original: File Name:  LineDemo.c by Jan Grewe
*          Copyright (c) 2003 DLR Robotics & Mechatronics
*
* Geändert: Simsys
*
***************************************************************************
*  This program is free software; you can redistribute it and/or modify  *
*  it under the terms of the GNU General Public License as published by  *
*  the Free Software Foundation; either version 2 of the License, or    *
*  any later version.                                                    *
***************************************************************************/

#include "asuro.h"

/*! Legt die höchste Geschwindigkeit der Motoren fest */
#define MAXSPEED 140
/*! Legt die niedrigste Geschwindigkeit der Motoren fest */
#define MINSPEED 30


/*! Geschwindigkeiten der beiden Motoren merken */
int speedLeft,speedRight;
/*! Speicherplatz für A/D-Wandlung reservieren */
unsigned int lineData[2];
/*! Helligkeitsdifferenz der Bauteile fest halten */
int ADOffset;

/*!
Die Linie befindet sich links von der Mitte, also müssen wir das linke Rad
bremsen damit sie wieder in die Mitte kommt.
*/
void LineLeft (void)
{
    speedLeft  -= 1;      /* links bremsen */
    if (speedLeft < MINSPEED)
        speedLeft = MINSPEED;
}

/*!
Die Linie befindet sich rechts von der Mitte, also müssen wir das rechte Rad
bremsen damit sie wieder in die Mitte kommt.
*/
void LineRight (void)
{
    speedRight  -= 1;    /* rechts bremsen */
    if (speedRight < MINSPEED)
        speedRight = MINSPEED;
}

int main(void)
{
    int i;
    unsigned char j;

    Init();                    // Initialisierung der Asuro Hardware
    FrontLED(ON);              // FrontLED ein

    for (j = 0; j < 0xFF; j++)  // Einlesen der beiden Empfangsdioden
        LineData(lineData);
                                // Differenz bestimmen und abspeichern
    ADOffset = lineData[LEFT] - lineData[RIGHT];
    speedLeft = speedRight = MAXSPEED;  // Speed einstellen
    StatusLED(GREEN);          // Anzeigen: alles, jetzt geht es los!

    while (1) {                // Endlosschleife
        LineData(lineData);    // Helligkeitswerte einlesen
        i = (lineData[LEFT] - lineData[RIGHT]) - ADOffset; // Helle Linie
//        i = (lineData[RIGHT] - lineData[LEFT]) + ADOffset; // Dunkle Linie
        if ( i > 4)
            LineLeft();        // Die Linie befindet sich links
        else {
            if ( i < -4)        // Die Linie befindet sich rechts
                LineRight();
            else
                speedLeft = speedRight = MAXSPEED;  // keine Differenz, gerade!
        }
        MotorSpeed(speedLeft,speedRight);          // Geschwindigkeiten setzen
    }
}

---

Nachfolgend auch noch das angepasste Makefile

Code:

---

# WinAVR Sample makefile written by Eric B. Weddington, J�g Wunsch, et al.
# Released to the Public Domain
# Please read the make user manual!
#
#
# On command line:
#
# make all = Make software.
#
# make clean = Clean out built project files.
#
# make coff = Convert ELF to AVR COFF (for use with AVR Studio 3.x or VMLAB).
#
# make extcoff = Convert ELF to AVR Extended COFF (for use with AVR Studio
#                4.07 or greater).
#
# make program = Download the hex file to the device, using avrdude.  Please
#                customize the avrdude settings below first!
#
# make filename.s = Just compile filename.c into the assembler code only
#
# To rebuild project do "make clean" then "make all".
#


# MCU name
MCU = atmega8

# Output format. (can be srec, ihex, binary)
FORMAT = ihex

# Target file name (without extension).
TARGET = ltest

# Optimization level, can be [0, 1, 2, 3, s]. 0 turns off optimization.
# (Note: 3 is not always the best optimization level. See avr-libc FAQ.)
OPT = s


# List C source files here. (C dependencies are automatically generated.)
SRC = $(TARGET).c

# If there is more than one source file, append them above, or adjust and
# uncomment the following:
SRC += asuro.c

# You can also wrap lines by appending a backslash to the end of the line:
#SRC += baz.c \
#xyzzy.c



# List Assembler source files here.
# Make them always end in a capital .S.  Files ending in a lowercase .s
# will not be considered source files but generated files (assembler
# output from the compiler), and will be deleted upon "make clean"!
# Even though the DOS/Win* filesystem matches both .s and .S the same,
# it will preserve the spelling of the filenames, and gcc itself does
# care about how the name is spelled on its command-line.
ASRC =




# Optional compiler flags.
#  -g:        generate debugging information (for GDB, or for COFF conversion)
#  -O*:      optimization level
#  -f...:    tuning, see gcc manual and avr-libc documentation
#  -Wall...:  warning level
#  -Wa,...:  tell GCC to pass this to the assembler.
#    -ahlms:  create assembler listing
CFLAGS = -g -O$(OPT) -I../../lib/inc\
        -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums \
        -Wall -Wstrict-prototypes \
        -Wa,-ahlms=$(<:.c=.lst)

VPATH=../../lib

# Optional assembler flags.
#  -Wa,...:  tell GCC to pass this to the assembler.
#  -ahlms:    create listing
#  -gstabs:  have the assembler create line number information; note that
#            for use in COFF files, additional information about filenames
#            and function names needs to be present in the assembler source
#            files -- see avr-libc docs [FIXME: not yet described there]
ASFLAGS = -Wa,-ahlms=$(<:.S=.lst),-gstabs



# Optional linker flags.
#  -Wl,...:  tell GCC to pass this to linker.
#  -Map:      create map file
#  --cref:    add cross reference to  map file
LDFLAGS = -Wl,-Map=$(TARGET).map,--cref



# Additional libraries
#
# Minimalistic printf version
#LDFLAGS += -Wl,-u,vfprintf -lprintf_min
#
# Floating point printf version (requires -lm below)
#LDFLAGS +=  -Wl,-u,vfprintf -lprintf_flt
#
# -lm = math library
LDFLAGS += -lm
LDFLAGS += -lasuro



# ---------------------------------------------------------------------------

# Define directories, if needed.
DIRAVR = c:/winavr
DIRAVRBIN = $(DIRAVR)/bin
DIRAVRUTILS = $(DIRAVR)/utils/bin
DIRINC = .
DIRLIB = $(DIRAVR)/avr/lib


# Define programs and commands.
SHELL = sh

CC = avr-gcc

OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
SIZE = avr-size

REMOVE = rm -f
COPY = cp

HEXSIZE = $(SIZE) --target=$(FORMAT) $(TARGET).hex
ELFSIZE = $(SIZE) -A $(TARGET).elf

FINISH = echo Errors: none
BEGIN = echo -------- begin --------
END = echo --------  end  --------




# Define all object files.
OBJ = $(SRC:.c=.o) $(ASRC:.S=.o)

# Define all listing files.
LST = $(ASRC:.S=.lst) $(SRC:.c=.lst)

# Combine all necessary flags and optional flags.
# Add target processor to flags.
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)



# Default target.
all: begin gccversion sizebefore $(TARGET).elf $(TARGET).hex $(TARGET).eep \
        $(TARGET).lss sizeafter finished end


# Eye candy.
# AVR Studio 3.x does not check make's exit code but relies on
# the following magic strings to be generated by the compile job.
begin:
        @$(BEGIN)

finished:
        @$(FINISH)

end:
        @$(END)


# Display size of file.
sizebefore:
        @if [ -f $(TARGET).elf ]; then echo Size before:; $(ELFSIZE);fi

sizeafter:
        @if [ -f $(TARGET).elf ]; then echo Size after:; $(ELFSIZE);fi



# Display compiler version information.
gccversion :
        $(CC) --version




# Convert ELF to COFF for use in debugging / simulating in
# AVR Studio or VMLAB.
COFFCONVERT=$(OBJCOPY) --debugging \
        --change-section-address .data-0x800000 \
        --change-section-address .bss-0x800000 \
        --change-section-address .noinit-0x800000 \
        --change-section-address .eeprom-0x810000


coff: $(TARGET).elf
        $(COFFCONVERT) -O coff-avr $< $(TARGET).cof


extcoff: $(TARGET).elf
        $(COFFCONVERT) -O coff-ext-avr $< $(TARGET).cof

# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
        $(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@

%.eep: %.elf
        -$(OBJCOPY) -j .eeprom --set-section-flags=.eeprom="alloc,load" \
        --change-section-lma .eeprom=0 -O $(FORMAT) $< $@

# Create extended listing file from ELF output file.
%.lss: %.elf
        $(OBJDUMP) -h -S $< > $@



# Link: create ELF output file from object files.
.SECONDARY : $(TARGET).elf
.PRECIOUS : $(OBJ)
%.elf: $(OBJ)
        $(CC) $(ALL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS)


# Compile: create object files from C source files.
%.o : %.c
        $(CC) -c $(ALL_CFLAGS) $< -o $@


# Compile: create assembler files from C source files.
%.s : %.c
        $(CC) -S $(ALL_CFLAGS) $< -o $@


# Assemble: create object files from assembler source files.
%.o : %.S
        $(CC) -c $(ALL_ASFLAGS) $< -o $@






# Target: clean project.
clean: begin clean_list finished end

clean_list :
        $(REMOVE) $(TARGET).hex
        $(REMOVE) $(TARGET).eep
        $(REMOVE) $(TARGET).obj
        $(REMOVE) $(TARGET).cof
        $(REMOVE) $(TARGET).elf
        $(REMOVE) $(TARGET).map
        $(REMOVE) $(TARGET).obj
        $(REMOVE) $(TARGET).a90
        $(REMOVE) $(TARGET).sym
        $(REMOVE) $(TARGET).lnk
        $(REMOVE) $(TARGET).lss
        $(REMOVE) $(OBJ)
        $(REMOVE) $(LST)
        $(REMOVE) $(SRC:.c=.s)
        $(REMOVE) $(SRC:.c=.d)


# Automatically generate C source code dependencies.
# (Code originally taken from the GNU make user manual and modified
# (See README.txt Credits).)
#
# Note that this will work with sh (bash) and sed that is shipped with WinAVR
# (see the SHELL variable defined above).
# This may not work with other shells or other seds.
#
%.d: %.c
        set -e; $(CC) -MM $(ALL_CFLAGS) $< \
        | sed 's,\(.*\)\.o[ :]*,\1.o \1.d : ,g' > $@; \
        [ -s $@ ] || rm -f $@


# Remove the '-' if you want to see the dependency files generated.
-include $(SRC:.c=.d)



# Listing of phony targets.
.PHONY : all begin finish end sizebefore sizeafter gccversion coff extcoff \
        clean clean_list program

---

Beste Grüße
Simsys

Hallo Simsys,

Klasse. Gut dokumentierte Beispielprogramme sind natürlich ebenfalls willkommen. Falls es sonst noch Beispielcode gibt, entweder etwas neues oder die Verbesserung der bestehenden Programme, immer her damit.

Hallo

Will jetzt auch die neue Lib verwenden nur leider blicke ich da nicht so ganz durch hab mir jetzt den ordner geladen, Dann habe ich das gemacht was im txt bei installer steht Zur Installation der Asuro Lib kopiert man das File \lib\libasuro.a
in das WinAVR\avr\lib Verzeichnis.
Das File \lib\inc\asuro.h kopiert man in das WinAVR\avr\include Verzeichnis.
wo ich jetzt nicht durchblicke ist das: Um die Lib neu zu übersetzen startet man den Make Prozess im Verzeichnis lib mit:
make clean
make all
wie muss man das machen??? muss ich die einzelden dateien auch im Winavr ordner kopieren? Bitte helf mir einer

Hi,

Zitat:

---

Zitat von Danjo00

wo ich jetzt nicht durchblicke ist das: Um die Lib neu zu übersetzen startet man den Make Prozess im Verzeichnis lib mit:
make clean
make all
wie muss man das machen??? muss ich die einzelden dateien auch im Winavr ordner kopieren? Bitte helf mir einer

---

Die Lib muß nur neu erzeugt werden, wenn an den Sourcefiles der LIB oder der asuro.h etwas geändert wurde.
Die Sourcefiles braucht man dazu nicht kopieren. Man öffnet eine DOS-Console (Eingabeaufforderung) und wechselt in das Verzeichnis, in die man die Lib installiert hat. Dort gibt man die beiden Befehlen ein:
make clean
make all
Dannach kopiert man die geänderte Lib libasuro.a in das WinAVR/lib Verzeichnis und evtl. die asuro.h in das WinAVR/include Verzeichnis.

Im nächsten Release Candidate wird es dafür ein Installtions Skript geben. Das wird dann einfacher.

Es wird außerdem noch folgende Änderung in der Lib geben:

Derzeit befinden sich im Sourcecode einige Konstanten oder feste Zahlenwerte, die von ASURO zu ASURO abweichen können. Diese werden aus der Lib entfernt und durch Variablen ersetzt. Diese Variabeln werden dann zur Laufzeit entweder mit Konstanten (aus einer Benutzerspezifischen Headerdatei), evtl. auch aus dem EEPROM oder halt mit Defaultwerten initialisiert.
Damit ist die Lib für alle ASUROs gleich und muß beim Anpassen dieser Werte nicht neu übersetzt werden.

Ich würde statt Batterie und OdometrieData, Battery und OdometryData schreiben :-k

Dann wäre das aber nicht mehr im Einklang mit der Anleitung, und ausserdem funktionieren dann alle älteren Programme, die mit der alten library erstelt worden nicht mehr bzw. lassen sich nicht mehr kompilieren.

Wird es wirklich nur die benutzte funktionen oder die benutzte c dateien kompiliert ???

Edit: ich hab versuch ein datei zu kompilieren. mit asurolib ist die hex file 6kb groß und mit meiner (eigenen) bibliothek 3kb. Es scheint dass es noch nicht optimal ist :( .

vor allem wenn man bedenkt dass der asuro nur etwa 7 kb speicher hat... wobie das, was am ende geflasht wird, etwak leiner ist als die hex-datei.

die lib von peter fleury braucht etwa 500 bytes.

Vielleicht sollen wir zusätzlich noch die asuro.h zerlegen. Außerdem könnte man auch noch print.c zerlegen, da diese datei so viel unnötige funktionen beinhaltet.

Hi,

Zitat:

---

Wird es wirklich nur die benutzte funktionen oder die benutzte c dateien kompiliert ???

---

wird eine Funktion aus einer c-Datei aufgerufen, werden auch alle anderen Funktionen aus der gleichen c-Datei mitgelinkt, leider.

Die asuro.h zu splitten bringt da gar nichts. Wenn schon, dann muß man die c-Files wie z.B. die print.c noch stärker splitten.

Hallo,

Zitat:

---

Zitat von m.a.r.v.i.n

...
wird eine Funktion aus einer c-Datei aufgerufen, werden auch alle anderen Funktionen aus der gleichen c-Datei mitgelinkt, leider.

---

muß heißen "aus der gleichen .o-Datei".

Zitat:

---

..., dann muß man die c-Files wie z.B. die print.c noch stärker splitten.

---

um die Dateien nicht beliebig zu zerkleinern, und damit auch den Überblick zu verlieren, könnte man die einzelnen Funktionen (in encoder.c gibt es sogar 6) mittels #ifdef/#endif's klammern.
Nun muß nur das Makefile angepaßt werden, um für jede einzelne Funktion (dieselbe) .c-Datei mit verschiedenen -Ddefine's in verschiedene .o-Dateien zu übersetzen (aus encoder.c würden dann 6 verschiedene .o-Dateien).
Dies hätte den gewünschten Vorteil (nur eine Funktion pro .o-Datei), ohne die Quelldatei-Struktur völlig über den Haufen zu werfen.

Hi,

Asuro Lib V2.70 Release Candidate 2 steht zum Download bereit (siehe 1. Posting). Auch die Doku dazu. Alle Funktionen sind jetzt vollständig dokumentiert und mit Beispiel Code versehen.

Aufregende neue Funktionen gibt es nicht. Zur Diskussion stellen möchten wir aber folgendes:

Derzeit befinden sich einige Zahlen (magic numbers) in der Lib, die sich leider von Asuro zu Asuro unterscheiden. Sowas sollte nicht in der Lib stehen. Deshalb der Vorschlag,
* diese Zahlen Konstanten aus der Lib zu entfernen,
* in eine Userspezifische Header-Datei packen,
* statt der Konstanten Variablen zu benutzen
* und diese Variablen zur Laufzeit mit den userspezifischen Konstanten zu laden.

OK, dadurch gehen erst mal wieder ein paar Bytes vom RAM verloren. Auch das laden der Variablen kostet Speicher. Dafür hat man dann aber eine Lib, die für alle Nutzer gleich ist. Bei einem Update gehen die Userspezifischen Werte nicht verloren. Evtl. könnte man diese Werte auch in den EEPROM des Asuros flashen und zur Laufzeit dann auslesen.

Wie das aussehen könnte, ist in der Datei myasuro.h zu sehen. Dort stehen diese Werte drin. Allerdings werden die Werte derzeit noch nicht verwendet.

Code:

---

/* Tastaturabfrage */
#define MY_SWITCH_VALUE          61L  /*!< Multiplikator fuer Tasterwerte */

/* Odoemtrie / Encoder */
#define MY_ODO_LIGHT_VALUE_L    160    /*!< Encoderschwellwert fuer Hell (linke Seite) */
#define MY_ODO_DARK_VALUE_L      140    /*!< Encoderschwellwert fuer Dunkel (linke Seite) */
#define MY_ODO_LIGHT_VALUE_R    160    /*!< Encoderschwellwert fuer Hell (rechte Seite) */
#define MY_ODO_DARK_VALUE_R      140    /*!< Encoderschwellwert fuer Dunkel (rechte Seite) */

/* Werte für 12 Segmente Encoder */
#define MY_GO_ENC_COUNT_VALUE  19363L  /*!< GO Funktion, Divisor fuer Entfernung  */
#define MY_TURN_ENC_COUNT_VALUE  177L  /*!< Turn Funktion, Mutiplikator fuer Winkel */

---

Dazu gibt es dann auch eine Struktur von Variablen. Dort werden dann die Werte zur Laufzeit eingetragen. (Dank an sternthaler)

Bitte stört euch nicht daran, das hier long Variablen verwendet werden. Das soll nur zur Übersicht dienen. In der nächsten Release werden die Variablen soweit möglich zusammengeschrumpft.

Code:

---

/*
  Aufbau der Datenstruktur fuer die Asuro-typischen Parameter die jeder User
  fuer seinen Asuro in der Datei myasuro.h selber aendern kann.
 */
typedef struct {
  /*! Faktor zur Berechnung der gedrueckten Tasten.\n
      Kann von jedem Asuro-Besitzer in myasuro.h angepasst werden.\n
      Der Originalwert ist \b 61L und koennten im Bereich zwischen ca. 58L und
      65L schwanken. Dieser Wert gleicht Toleranzen der Wiederstaende an den
      Tastern aus.
  */
            long  switch_value;
  /*! Wert, der in der Odometrie ueberschritten werden muss, um zum
      weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
      Automatik\n
      Kann von jedem Asuro-Besitzer in myasuro.h angepasst werden.\n
      Die Originalwerte (links, rechts) sind \b 160.
      Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
      Sie MUESSEN GROESSER als die Werte fuer odo_dark_value sein.
  */
  unsigned  int  odo_light_value[2];
  /*! Wert, der in der Odometrie unterschritten werden muss, um zum
      weiterzaehlen der Ticks in encoder[] zu fuehren bei aktivierter
      Automatik\n
      Kann von jedem Asuro-Besitzer in myasuro.h angepasst werden.\n
      Die Originalwerte (links, rechts) sind \b 140.
      Diese Werte sind sehr stark vom Umgebungslicht abhaengig.
      Sie MUESSEN KLEINER als die Werte fuer odo_dark_value sein.
  */
  unsigned  int  odo_dark_value[2];
  /*! Faktor zur Berechnung von Ticks um aus den in mm angegebenen Parameter
      umzurechnen.\n
      Kann von jedem Asuro-Besitzer in myasuro.h angepasst werden.\n
      Der Originalwert ist \b 19363L und ist von der Anzahl der schwarz/weiss
      Teilstuecke auf den Odometriescheiben abhaengig.\n
      Der Originalwert wurde durch stochri ermittelt.
  */
  unsigned  long  go_enc_count_value;
  /*! Faktor zur Berechnung von Ticks um aus den in Grad angegebenen Parameter
      umzurechnen.\n
      Kann von jedem Asuro-Besitzer in myasuro.h angepasst werden.\n
      Der Originalwert ist \b 177L und ist von der Anzahl der schwarz/weiss
      Teilstuecke auf den Odometriescheiben abhaengig.\n
      Der Originalwert wurde durch stochri ermittelt.
  */
            long  turn_enc_count_value;
} my_t;
extern volatile my_t my;

---

Ich denke was die Codegröße betrifft, sind wir auf dem richtigen Weg. Ein paar c-Files werden nocht gesplittet (motor.c encoder.c). Selbst der SelfTest Code ist inzwischen mit der neuen Lib nicht größer als mit der Original Lib (auch wenn ich die IRDemo und die RechteckDemo wieder dazu packe).

Hier noch ein Ausblick, was die die nächste Release enthalten wird:

* Verwendung der userspezifischen Werte. Beispiele, die diese Werte automatisch ermitteln können.
* I2C und LCD Library von raid_ox
* RC5 Decoder Funktion für Infrarot Fernbedienungen
* bessere und erweiterte Beispiele
* ...