neue Asuro Lib V2.70 (Release Candidate 3)

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

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

[Ronny10]

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)

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

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.

[stochri]

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

[Ronny10]

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

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

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.

[Sternthaler]

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.

[HermannSW]

Hi,

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 ...

[Sternthaler]

@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.

[stochri]

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

[Sternthaler]

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:


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.

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

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.

[Sternthaler]

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.

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

Hi,


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.


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.


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.


Mit den 4 Blanks zum Einrücken habe ich leichte Probleme
OK, 2 Blanks sollten auch reichen.


Funktionsnamen mit und ohne _-Zeichen im Namen.
Da stimme ich dir zu. Die Unterstriche fliegen also raus.


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.

[stochri]

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.


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

[Sternthaler]

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.


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.


... 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.)


da heb ich mal spontan die Hand.SUPER


OK, 2 Blanks sollten auch reichen. Einverstanden


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.
v.i.n"]Artistic StyleZiehe ich mir dann wohl auch mal.


.. die Lib 2-sprachig zu kommentieren (deutsch, englisch).Da werde ich mich auch mal dran versuchen.


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)


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.

[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).

@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.

[HermannSW]

Hi,

ich bin ein begeisterter Verwender der neuen Lib.

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:

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 ...)

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

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

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 (https://sourceforge.net/account/newuser_emailverify.php) anmelden, sind auch immer willkommen.

[HermannSW]

Hallo,

...
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:

...
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)

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

[Simsys]

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:


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

[Sternthaler]

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?

[stochri]

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

[Mooses78]

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

[Sternthaler]

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 ;-)



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.

[Simsys]

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 \


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

[Sternthaler]

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

[Mooses78]

Hallo Sternthaler

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

Dankeschön für die schnelle Antwort

Mooses

[Simsys]

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
/************************************************** **************************/
/*!
\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. (http://de.wikipedia.org/wiki/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

# 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

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

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.

[Danjo00]

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

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

Hi,



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.

[raid_ox]

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

[damaltor]

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.

[raid_ox]

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 :( .

[damaltor]

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.

[raid_ox]

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.

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

Hi,



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.

[HermannSW]

Hallo,

...
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".


..., 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.

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

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.



/* 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.



/*
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
* ...

[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.

[Sternthaler]

Ich sollte weniger, oder schneller, schreiben.
Hallo m.a.r.v.i.n

[radbruch]

Die Daten wären reines ascii und die Datei gegebenenfalls editierbar. Natürlich sollte die Lib mit Defaults laufen. Neulinge, die mit den Ergebnissen mit defaults nicht zufrieden sind, werden sicher auch in der Lage sein, die myasuro-Datei zu erzeugen. Und die Zufriedenen werden sich nicht dran stören.

Das Kalibrierungsproggi kann man bestimmt gut als erweitertes selftest unter die Leute bringen.

[damaltor]

ja das ist wahr, also ein kalibrierungsprogramm sollte möglich sein, und das halte ich auch für sehr sinnvoll. es müsste allerdings die datenübertragung möglichst sicher gestaltet werden, damit nicht aufgrund eines fehlerhaften bytes irgend ein mist übertragen wird und der dann in allen (!) programmen kompiliert wird. evtl sollte der nutzer zum abgleich den empfangenen wert nochmal eingeben oder so etwas.
braucht ein integer wirklich nur 2 bytes? wo steht, welchen typ die variable hat? signed oder unsigned? ich kenne mich mit speicherarchitekturen nicht besonders aus, es reicht gerade für ein paar grundsätzliche pointer und adressoperationen. ansonsten könnte man ja die letzten paar bytes des eeprom reservieren, beispielsweise alle über 500 oder alle über 480 oder so. allerdings sollte eine lib so knapp wie möglich sein und deshlab nicht immer auf den eeprom angewiesen sein. auch die wiederkehrenden eeprom lese aktionen machens nicht zwingend einfacher und auch wenn sie nur ein paar bytes belegen müssen die einfach nciht sein.
ich bleibe bei den defines =)
hier mal beispielcode zum schreiben eines bytes in den eeprom (übergeben werden die adresse (ein wert zwischen 0 und 511 bzw 0 und 0x1F) und die daten (ein char)

void EEPROM_write(unsigned int uiAddress, unsigned char ucData)
{
/* Wait for completion of previous write */
while(EECR & (1<<EEWE))
;
/* Set up address and data registers */
EEAR = uiAddress;
EEDR = ucData;
/* Write logical one to EEMWE */
EECR |= (1<<EEMWE);
/* Start eeprom write by setting EEWE */
EECR |= (1<<EEWE);
}

und zum lesen muss nur die adresse übergeben werden:

unsigned char EEPROM_read(unsigned int uiAddress)
{
/* Wait for completion of previous write */
while(EECR & (1<<EEWE))
;
/* Set up address register */
EEAR = uiAddress;
/* Start eeprom read by writing EERE */
EECR |= (1<<EERE);
/* Return data from data register */
return EEDR;
}

Diese funktionen sind direkt aus dem datenblatt genommen, ich vermute deshalb dass sie so minimalistisch wie möglich sind. aber eben trotzdem eigentlich unnötig.

[Sternthaler]

@radbruch
Das mit den Möglichkeiten eines Kalibrierungsprogramms sehe ich ja auch als sehr gute Idee, um seinen eigenen Asuro möglichst perfekt einzustellen.
Ich wollte hier darauf hinweisen, dass es wichtig ist, jetzt schon mal über die Technik zum Einbinden von 'externen' Konfig-Daten nachzudenken. (Hätte ich ja auch schon füher schreiben können. ](*,) )


ABER VIEL WICHTIGER zum aktuellen Release Candidate 2.

In der Doku zur Funktion EncoderStart() in encoder.c habe ich als Fehler beschrieben, dass die Funktion nicht geeignet ist die Rad-Encoder-Automatik wieder zu starten nach einem EncoderStop().
DAS DORT VON MIR ALS FEHLER BESCHRIEBEN VERHALTEN STIMMT SO NICHT.
stochri hat (natürlich) alles richtig gemacht, da er in EncoderInit() den ADC-Wandler im sogenannten 'free running'-Mode startet. Damit ist es eben doch Möglich die Automatik zu stoppen und mit EncoderStart() wieder zu starten. Tut mir Leid, Doku wird korrigiert.

[damaltor]

Na das klingt doch gut...

mehr ideen morgen, ab ins bett jetzt kinder =)

[Sternthaler]

@damaltor (ich werde immer erst um diese Zeit wach)
int ist tatsächlich nicht immer 2 Byte groß. Die tatsächliche Größe hängt vom verwendeten Rechner/CPU (evl. Compiler) ab.
Aus diesem Grund gibt es auch noch eine andere Variante um integer-Variablen zu definieren. Da werden dann z.B. die Typen uint32_t oder int16_t benutzt.
Das u bedeutet dann, dass der Wert als unsingned zu interpretieren ist, und die Zahl gibt die BIT-Anzahl an.
Diese Typen sind in der Include-Datei [AVR-Installation]\avr\include\inttypes.h definiert und stellen auf jedem System sicher, dass die Variablen tatsächlich immer die Größe haben, die der Programmierer haben möchte.
Bei dem unsigned ändert sich auf keinen Fall etwas an der BIT-Anzahl. Du kannst in einer mit 'unsigned char' oder eben mit uint8_t Zahlen zwischen 0 und 255 in den 8 Bits speichern. Wird die Variable als 'char' oder int8_t definiert, ändert sich der Bereich zu -128 bis +127.
Komisch: Eigendlich kannst du in beiden Typen doch immer nur 8 Bits an- bzw. ausgeknipst setzen. Wo kommt also das Vorzeichen mal her und dann doch wieder ohne Vorzeichen.
--> Das Höchstwertige Bit wird bei den signed-Werten einfach mal so als Vorzeichen INTERPRETIERT (0=Plus; 1=Minus und dann kommt da noch bei den negativen Zahlen das 2'er-Komplement hinzu. Bitte weiter fragen bei Bedarf.)
Bei den UNsigned-Werten wird das höchste Bit als weiteres Bit für den Zahlenwert benutzt.


P.S.: Danke für deine Code-Stücke für das EEPROM.

[damaltor]

also dass das von der architektur abhängt, das hab ich schonmal gehört, und das zweierkomplement kenne ich auch. so ganz grob weiss ich wie das aussehen muss, aber beispielsweise wird bei float-zahlen doch auch das vorzeichen als eigenes bit gespeichert (0=+,1=-), dann der exponent + BIAS, dann die normierte mantisse ohne 1. irgendwo muss doch vermerkt werden, ob ein wert nun unsigned ist oder nicht, ansonsten wüsste ja niemand ob man 11111111 nun als 255 oder asl -127 ausgeben / rechnen sollte... aber naja. auf die paar bytes kann man zwar wahrscheinlich verzichten, das ist schon wahr. aber ich denk dann immer, man müsste nicht drauf verzichten, schliesslich könnten die werte genausogut einmal definiert werden und dann verwendet werden. schliesslich wurde ja auhc die lib zerlegt, um immer mal einige bytes der nicht benötigten funktionen sparen zu können.

[_HP_]

Hallo Lib-Entwickler,

nachdem ich mich eine Weile mit der Frage herumgeschlagen hatte, warum es eine myasuro.h Datei gibt, diese aber nirgends verwendet wird, habe ich in diesem Thread den Grund gefunden. Es wäre wünschenswert, wenn der Hinweis, das diese Werte noch keine Bedeutung habe auch im Kommentar der Datei selbst stehen würde.

Und was mir noch aufgefallen ist: Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgens WARUM?! Könntet Ihr mir das bitte erklären und dann auch in die Doku einfließen lassen. Das wäre Klasse.

Zur Diskussion um die ASURO-spezifischen Werte: Ich bin auch dafür, diese von jedem Nutzer selbst ermiteln zu lassen - und zwar mit gut dokumentierten Testprogrammen. Das fördert das Verständnis über die Sensorproblematik erheblich, und wenn es dann klappt, dann weiß man auch warum...

Sonst aber ein großes Lob für die viele Arbeit, die Ihr Euch gemacht habt. Wenn ich darf - würde ich gern an einer Weiterentwicklung der Lib mitarbeiten...

Gruss,

_HP_

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

Hi _HP_,



nachdem ich mich eine Weile mit der Frage herumgeschlagen hatte, warum es eine myasuro.h Datei gibt, diese aber nirgends verwendet wird, habe ich in diesem Thread den Grund gefunden. Es wäre wünschenswert, wenn der Hinweis, das diese Werte noch keine Bedeutung habe auch im Kommentar der Datei selbst stehen würde.


Im aktuellen Entwicklungsstand werden die Defines bereits verwendet. Ich denke, dass dieses Wochenende eine weitere Release veröffentlicht wird.



Und was mir noch aufgefallen ist: Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgens WARUM?! Könntet Ihr mir das bitte erklären und dann auch in die Doku einfließen lassen. Das wäre Klasse.


Gute Frage. Diese Änderung wurde schon vor geraumer Zeit gemacht. Wenn ich mich recht erinnere, im Zusammenhang mit dem Umbau der IR Schnittstelle zur Hinderniserkennung. Mehr weis ich leider auch nicht.



Zur Diskussion um die ASURO-spezifischen Werte: Ich bin auch dafür, diese von jedem Nutzer selbst ermiteln zu lassen - und zwar mit gut dokumentierten Testprogrammen. Das fördert das Verständnis über die Sensorproblematik erheblich, und wenn es dann klappt, dann weiß man auch warum...


An den Testprogrammen hapert es derzeit noch.



Sonst aber ein großes Lob für die viele Arbeit, die Ihr Euch gemacht habt. Wenn ich darf - würde ich gern an einer Weiterentwicklung der Lib mitarbeiten...


Mitarbeiter sind immer herzlich willkommen. Dazu müßtest du dich als Entwickler bei Sourceforge anmelden und mir deinen Entwicklernamen per PN zukommen lassen. Dann kann ich dich als Entwickler zur Asuro Lib eintragen.

[Sternthaler]

Und was mir noch aufgefallen ist: Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgens WARUM?! Könntet Ihr mir das bitte erklären und dann auch in die Doku einfließen lassen. Das wäre Klasse.

Doch, es gibt folgenden Kommentar in der Doku: (Im Source asuro.c zur Funktion Init() geschrieben.)

Hinweis zur 36 kHz-Frequenz vom Timer 2
Genau diese Frequenz wird von dem Empfaengerbaustein benoetigt und kann
deshalb nicht geaendert werden.
In der urspruenglichen, vom Hersteller ausgelieferten LIB, war diese
Frequenz allerdings auf 72 kHz eingestellt. Durch eine geschickte
Umkonfigurierung durch waste konnte diese aber halbiert werden.
Sinnvoll ist dies, da der durch diesen Timer2 auch ausgeloesste Timer-
Interrupt dann nur noch die Haelfte an Rechenzeit in Anspruch nimmt.


Uff, da bin ich aber froh, dass das schon erledigt ist.

Was gemacht wurde, ist wie angedeutet etwas 'tricki':
Anstatt den Timer so zu programmieren, dass die HARDWARE bis zu dem vorgegeben Wert zählt, den Interrupt auslößt und dann den Zähler wieder initialisiert, wurde es so programmiert, dass in der Interrupt-Funktion zum Timer das Register TCNT2 um Hex 25 erhöht wird. Damit wird erreicht, dass das Taktverhältnis (An-/Aus-Zeit vom Port-Pin zur IR-Kommunikation) 50% bleibt. Ausserdem ist das Verhalten zum Wecheln genau dieses Port-Pins geändert worden.

Unterm Strich ist das Ausgangssignal am Port-Pin gleich geblieben. Nur wird, wie beschrieben, der Interrupt nur noch halb so oft aufgerufen.
That's all, ich hoffe das hilft.

[_HP_]

Danke m.a.r.v.i.n und sternthaler für die schnelle Antwort. Ich konnte leider erst jetzt reagieren, da ich meinen Laptop erst einmal retten mußte, aber das ist jetzt geschafft. Einen Accout bei Sourceforge habe ich angelegt und m.a.r.v.i.n eine Mail zukommen lassen - es kann also losgehen. Ich freue mich schon...

Gruß,

_HP_

[HermannSW]

Hallo,

die auf UartPutc() basierenden Funktionen void PrintInt (int wert)
void PrintLong (long wert)
void SerPrint (unsigned char *data)
void UartPutc (unsigned char zeichen)funktionieren gut, wenn man sie separat von der IR-Kollisionsvermeidung einsetzt.

Die IR-Kollisionsvermeideung (IRCollisionTest/test.c.) funktioniert gut (IR-Hindernisvermeideung, IR-Höhenmesser, ...), wenn man sie separat von auf UartPutc() basierenden Funktionen einsetzt.

Frage:
Gibt es "magic_1" und "magic_2", damit folgender Code funktioniert?

...
Init();

DDRD |= (1 << DDD1); // Port D1 als Ausgang
PORTD &= ~(1 << PD1); // PD1 auf LOW
OCR2 = 0xF7; // Pulsbreite 8

while (1)
{
"magic_1"

if (PIND & (1 << PD0))
StatusLED(GREEN);
else
StatusLED(RED);

"magic_2"

SerPrint(something);
}
...

[damaltor]

Was meinst du mit "seperat"? nicht im gleichen programm? oder die funktionen nur ausführen, wenn die IR-kollisionserkennung gerade abgeschaltet ist?

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

Hallo Hermann,

wie wäre es damit:

"magic_1"


USRB = 0; // UART TX disable
OCR2 = 0xF7; // Pulsbreite 8


"magic_2"


OCR2 = 0x91; // Pulsbreite fuer 36kHz

[HermannSW]

Hallo m.a.r.v.i.n.,

Hallo Hermann,

wie wäre es damit:

"magic_1"


USRB = 0; // UART TX disable
OCR2 = 0xF7; // Pulsbreite 8


"magic_2"


OCR2 = 0x91; // Pulsbreite fuer 36kHz
den Beitrag hatte ich bisher irgendwie nicht gesehen -- werde es gleich im Zug mal ausprobieren!

[HermannSW]

Hallo Librarians!

Könntet Ihr euch vorstellen, folgenden Abschnitt am Ende von asuro.h reinzunehmen:

#ifdef REVERSE_DIR

#undef FWD
#define FWD (1 << PB4) /*!< Motor vorwaerts */
#undef RWD
#define RWD (1 << PB5) /*!< Motor rueckwaerts */

#endif


#ifdef UPSIDE_DOWN

#undef FWD
#define FWD (1 << PB4) /*!< Motor vorwaerts */
#undef RWD
#define RWD (1 << PB5) /*!< Motor rueckwaerts */

#undef LEFT
#define LEFT 1
#undef RIGHT
#define RIGHT 0

#undef LEFT_DIR
#define LEFT_DIR (1 << PB4) | (1 << PB5) /*!< PB4, PB5 Ports fuer Drehrichtung rechter Motor */
#undef RIGHT_DIR
#define RIGHT_DIR (1 << PD4) | (1 << PD5) /*!< PD4, PD5 Ports fuer Drehrichtung linker Motor */

#undef IR_RIGHT
#define IR_RIGHT (1 << MUX0) | (1 << MUX1) /*!< ADC3 A/D Wandler Port fuer Linienfolger Fototransistor links */
#undef IR_LEFT
#define IR_LEFT (1 << MUX1) /*!< ADC2 A/D Wandler Port fuer Linienfolger Fototransistor rechts */

#undef WHEEL_RIGHT
#define WHEEL_RIGHT (1 << MUX0) /*!< ADC1 A/D Wandler Port fuer Odometrie Sensor links*/
#undef WHEEL_LEFT
#define WHEEL_LEFT 0 /*!< ADC0 A/D Wandler Port fuer Odometrie Sensor rechts */

#define BackLED(l,r) BackLED(r,l)
#define MotorDir(l,r) MotorDir(r,l)
#define MotorDir(l,r) MotorDir(r,l)
#define MotorSpeed(l,r) MotorSpeed(r,l)
#define SetMotorPower(l,r) SetMotorPower(r,l)

#endif

Der erste Abschnitt mit REVERSE_DIR ist in folgendem Beitrag besprochen:
https://www.roboternetz.de/phpBB2/viewtopic.php?p=267410#267410

Der Abschnitt mit UPSIDE_DOWN in in diesem Beitrag:
https://www.roboternetz.de/phpBB2/viewtopic.php?p=267146#267146

REVERSE_DIR ermöglicht es, ein "normales" Programm für einen Asuro zu übersetzten, der beide Motoren falsch hermum angeschlossen hat (z.B. weil einer der beiden nur rückwärts dreht, wie aktuell bei mir).

UPSIDE_DOWN ermöglicht es, einen "falsch herum" fahrenden Asuro ohne Änderungen mit "normalen" Programmen ansteuern zu können.

Wenn ja, dann müßte allerdings noch $(DEFS) in die ersten Zeilen von CFLAGS in allen Makefiles eingefügt werden

...
CFLAGS = -g $(DEFS) -O$(OPT) -I../../lib/inc\
...

damit "make DEFS=-DUPSIDE_DOWN" bzw. "make DEFS=-DREVERSE_DIR" den Rest erledigt!

Cool finde ich die Makrovertauschungen (z.B. BackLED) am Ende der Einfügung ...

[_HP_]

Hi HermannSW,

erst einmal: Ich bin beeindruckt davon, was Du hardwaretechnisch alles angestellt hast - und noch mehr, wie Du das alles unter Einbeziehung Deiner zwei Kinder auf die Reihe bekommst!!!!

Trotzdem würde ich die von Dir vorgeschlagenen Änderungen nicht in die reguläre Lib aufnehmen. Sie sind einfach zu speziell und machen sie für Leute, die neu dazukommen schwer nachvollziehbar. Leider mußt Du dann jedesmal die Lib anpassen, wenn es eine neue Version gibt, aber das geht anderen bestimmt auch so, die Änderungen wollen, die die Lib eben nicht erfüllt.

Sorry...

Aber ich bin natürlich nur ein kleines Licht hier und meine Meinung ist nicht die ausschlaggebene. Wenn die anderen Entwickler meinen, diese Änderung sollte Eingang in die Lib finden...

Gruß,

Helmut

[stochri]

Trotzdem würde ich die von Dir vorgeschlagenen Änderungen nicht in die reguläre Lib aufnehmen.

Ich möchte mich dieser Meinung anschließen. Die größten Probleme bei Betriebssystemen, Programmen und Videorecordern hat man dadurch, dass es zuviele Schalter gibt, an denen man drehen kann.

Variabilität erhöht die Komplexität

Gruss,
stochri

[radbruch]

Hallo


Der 72kHz - Timer wurde auf 36kHz geändert. Leider steht nirgends WARUM?!
Ich hab mal gelesen, die Verringerung der Frequenz sollte die Anzahl der Interrupts verringern um dem Hauptprogramm mehr Rechenzeit zu gönnen.(Ohne Gewähr)

Gruß

mic

[HermannSW]

Hallo,

Trotzdem würde ich die von Dir vorgeschlagenen Änderungen nicht in die reguläre Lib aufnehmen. Sie sind einfach zu speziell und machen sie für Leute, die neu dazukommen schwer nachvollziehbar.
Ich möchte mich dieser Meinung anschließen. Die größten Probleme bei Betriebssystemen, Programmen und Videorecordern hat man dadurch, dass es zuviele Schalter gibt, an denen man drehen kann.
Ihr habt beide Recht, das war wohl ein Schnellschuß von mir, ist ok, wenn das nicht in die Lib kommt. Wenn jemand solche Probleme hat, wird er ja über die Forensuche auch hier fündig werden ...


Leider musst Du dann jedesmal die Lib anpassen, wenn es eine neue Version gibt, aber das geht anderen bestimmt auch so, die Änderungen wollen, die die Lib eben nicht erfüllt. Ist schon ok, ist ja nur einmalig das Reinkopieren in asuro.h.

Letztes Mal hatte ich mehr Glück, PrintLong() hat ja bereits seinen Weg in die Lib gefunden.

Noch eine Frage hinterher:
Unter "9.2.12. unsigned char PollSwitch(void)" werden im Handbuch die Taster K1-K6 benannt.
Wie wäre es denn mit Konstanten K1-K6 im Abschnitt Makrodefinitionen von asuro.h?

[raid_ox]

Hi Alle,

Ich bin endlich wieder dabei, nach lange pause aus Roboternetz.

Habt ihr schon Ideen, was in der nächsten Version kommen wird?

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

Hi,

die AsuroLib V2.7.0rc3 wurde heute released. Diesmal auch als Setup Programm für Windows mit Installation/Deinstallation Routinen.
Näheres siehe erstes Post in diesem Thread.
Download unter http://sourceforge.net/projects/asuro

[stochri]

Hallo Marvin,

der Dank der ASURO-Community ist euch gewiss! Vielen Dank also.

Was mir aufgefallen ist: die Funktionen Go() und Turn() sind nirgends zu finden. Weder in der Hilfe, noch als source-Code. Allerdings werden die beiden Funktionenn in den Beispielen noch benutzt.

Es wäre meiner Meinung nach auch sehr nützlich, wenn sich im obersten Verzeichnis die Datei "index.html" oder ein Link darauf befinden würde. Es ist relativ schwierig, besonders falls man noch Anfänger ist, den Startpunkt für die Doku im doc-Verzeichnis zu finden.

Beste Grüße,
stochri

[damaltor]

wurden die nicht mal umbenannt....?

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

Hi,

Die Go und Turn Funktion befindet sich im File encoder.c.
Schaut man sich die Doku zur asuro.h an findet man dort alle Funktionen.
Ebenso gibt es einen alphabetischen Index unter Dateielemente.

Vielleicht wird die Übersicht besser, wenn man die Beispielprogramme aus der Doku herausläßt oder in eine extra Doku verlagert.

Die Idee mit einer index.html direkt im obersten Verzeichnis ist gut.
Dann könnte man von dort auf die Lib Doku, die Beispiel Doku etc. verlinken.
Bei der Installation über die AsuroLib-vXXX-Setup.exe werden allerdings auch eine Programmgruppe mit Links auf die Doku angelegt.

[HermannSW]

Hallo,

Bei der Installation über die AsuroLib-vXXX-Setup.exe werden allerdings auch eine Programmgruppe mit Links auf die Doku angelegt.... wenn es denn klappt ...

Habe gerade AsuroLib-v270rc3-Setup.exe ausgeführt (bisher habe ich immer die Lib entzipped), und erhalte als Fehlermeldung:
"WinAVR is not installed"

Wie stellt die Setuproutine denn fest, daß WinAVR nicht installiert ist?
[Ist bei mir in c:\WinAVR vorhanden, allerdings nach einer Neuinstallation nur dorthin verschoben.]
Sollten irgendwelche Environmentvariablen gesetzt sein?
Oder klappt das nicht mit der [uralten :)] WinAVR-Version von der Asuro-Original-CD?

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

Hallo Hermann,


Habe gerade AsuroLib-v270rc3-Setup.exe ausgeführt (bisher habe ich immer die Lib entzipped), und erhalte als Fehlermeldung:
"WinAVR is not installed"


interessant, das Setup Programm überprüft den Registry Key


HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\WinAVR

Wenn der Registry Key nicht existiert, gibt es die obige Fehlermeldung.
Trotzdem ist bei dir fast alles richtig installiert:
* die libasuro.a muß nur noch ins WinAVR\avr\lib Verzeichnis kopiert werden
* das Makefile muß nicht angepaßt, da c:\WinAVR die Voreinstellung ist.

Es sollte in deinem Fall genügen im lib-Verzeichnis

make install
aufzurufen, um die libasuro.a ins WinAVR/avr/lib/ Verzeichnis zu kopieren.

Ich werde wohl die Install Routine noch um eine Suche nach Verzeichnis Funktion erweitern müssen. Oder mir fällt eine andere Lösung ein, die ohne kopieren der Lib auskommt.

[damaltor]

vielleicht kann man ja eine möglichkeit in das installationsprogramm einbauen, sowas wie

"winavr wurde nicht gefunden. installation aubbrechen oder winavr verzeichnis manuell wählen?"

und dann muss man eine datei aus dem winavr verzeichnis auswählen, damit währe der pfad ja definiert.

[stochri]

Die Go und Turn Funktion befindet sich im File encoder.c.

Ach da sind die Funktionen. Ich habe sie vergeblich bei motor.c gesucht, das erschien mir am logischsten.

Aber mal was anderes:
Wenn man ein Projekt mit AVR-Studio und der neuen Lib anlegt, sollte man die vorkompilierten Libs bei AVR-STudio einbinden können. Wenn man jetzt das Projekt speichert, sollte doch alles korrekt und portabel ohne Installation sein, oder?
Zur Not müsste man jedem Projekt halt die ganze Lib mitgeben. Mach ja nichts, 80KB overhead kann man sich bei den heutigen Festplattengrößen ja locker leisten und es besteht nicht immer die Gefahr, dass man die falsche Version der LIB hat.

Gruss,
stochri

[adrisch]

Eine kleine Frage:
Wäre es theoretisch denkbar, dass man das ganze noch mit dem Programmers Notepad programmiert? Ich verwende zwar auch dass AVR-Studio, aber für mein Programm (siehe Beitrag: Asuro Entwicklungsumgebung in C) greife ich dennoch teilweise auf die Funktionsweise des Programmers Notepad zurück.

[HermannSW]

Hallo m.a.r.v.i.n,

...
interessant, das Setup Programm überprüft den Registry Key


HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\WinAVR
der ist bei mir jetzt natürlich nicht (mehr) gesetzt.


Es sollte in deinem Fall genügen im lib-Verzeichnis

make install
aufzurufen, um die libasuro.a ins WinAVR/avr/lib/ Verzeichnis zu kopieren.Hat gestern bereits geklappt.

Die neue Lib habe ich für einige Programme bzgl. der Größe der erzeugten .hex-Dateien untersucht, keines ist größer geworden, und viele wurden kleiner. Besonders für das EEPROM_dump.hex, siehe in diesem Thread
https://www.roboternetz.de/phpBB2/viewtopic.php?t=29635
reduzierte sich die Anzahl der zu Flashenden pages von 27 auf 17 durch einfaches NeuÜbersetzen.

Kanst Du als Lib-Entwickler bitte nochmal der Frage in diesem Thread nachgehen?


Vielleicht wäre es auch sinnvoll dieses oder ein anders EEPROM_dump als Example in einer späteren Version der Asurolib zu haben -- der Zugriff auf das EEPROM ist im Moment Asurolib-mäßig noch gar nicht abgedeckt, und die 512 bytes EEPROM könnten für viele Programme aufgrund der beschränkten RAMsize ganz nützlich sein ...

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

Hallo,



Wenn man ein Projekt mit AVR-Studio und der neuen Lib anlegt, sollte man die vorkompilierten Libs bei AVR-STudio einbinden können. Wenn man jetzt das Projekt speichert, sollte doch alles korrekt und portabel ohne Installation sein, oder?

Das ist soweit richtig. Ich habe selbst ein paar Beispiele mit AVR-Studio ausprobiert. Leider sind diese .aps Files nicht portierbar, weil Pfadangaben absolut sind. Sonst hätte ich die Projektfiles miteingepackt.
Wenn die libasuro.a im WinAVR lib-Verzeichnis steht, sollte sie als verfügbar angezeigt und eingebunden werden können.

@adrisch PN funktioniert ohne Probleme, da lediglich die Makefiles geändert sind.

Für alle anderen IDEs wie z.B. KamAVR, die scheinbar kein Einbinden von Libs unterstützen, bleibt immer noch der Weg, statt der libasuro.a die Sourcefiles zu Fuß einzubinden.



Vielleicht wäre es auch sinnvoll dieses oder ein anders EEPROM_dump als Example in einer späteren Version der Asurolib zu haben -- der Zugriff auf das EEPROM ist im Moment Asurolib-mäßig noch gar nicht abgedeckt, und die 512 bytes EEPROM könnten für viele Programme aufgrund der beschränkten RAMsize ganz nützlich sein

Na klar, wird gemacht.

[stochri]

Leider sind diese .aps Files nicht portierbar, weil Pfadangaben absolut sind. Sonst hätte ich die Projektfiles miteingepackt.

Falls ich mich nicht täusche, sind die aps-Files protierbar, wenn alle Dateien in einem Verzeichnis liegen.
Ich kann mein Ordner mit den Programmen verschieben und AVR-Studio findtet wieder alle zugehörigen Dateien.

Gruss,
stochri

[HermannSW]

Hi,

ich würde gern libasuro.a exakt nachbilden, und bin dabei auf ein paar Problemchen gestoßen:
Bei "make all" kommt bei mir für jedes .o-file die Meldung:

cc1.exe: warning: `dwarf-2': unknown or unsupported -g option
Ich benutze noch den Win-AVR-Compiler von der CD, und würde jetzt doch gerne umsteigen wollen ...
Welche Compilerversion habt Ihr für den Build benutzt?

Nach Ersetzen von -gdwarf-2 durch -g im Makefile gibt es genau eine Warning bei "make all":

avr-gcc.exe -mmcu=atmega8 -W -Os -I./inc -MD -MP -MT encoder.o -MF dep/encoder.
o.d -c encoder.c
encoder.c: In function `Go':
encoder.c:130: warning: comparison between signed and unsigned
Solle tot_count nicht auch einen unsigned type haben?

Im Command prompt funktioniert nach erfolgreichem make all ein make clean nicht:

C:\ASURO_src\AsuroLib\lib>make clean
dep/adc.o.d:1: *** multiple target patterns. Stop.
Erst nach manuellem Löschen aller Dateien in dep geht´s wieder ...

Dasgleiche gilt für make install nach erfolgreichem make all:

C:\ASURO_src\AsuroLib\lib>make install
dep/adc.o.d:1: *** multiple target patterns. Stop.
Auch hier geht´s wieder nach manuellem Löschen aller Dateien in dep ...

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

Hi,


Falls ich mich nicht täusche, sind die aps-Files protierbar, wenn alle Dateien in einem Verzeichnis liegen.
Ich kann mein Ordner mit den Programmen verschieben und AVR-Studio findtet wieder alle zugehörigen Dateien.


Ja, du hast recht. Pfadangaben stehen zwar absolut im Projektfile, aber nach Verschieben der Dateien findet AVR Studio trotzdem alles.

Übrigends, die einfachste Methode, um ein bestehendes ASRUO Projekt ins AVR Studio zu migrieren ist die Verwendung des bestehenden Makefiles.
Einfach unter Projekt | Configuration Options | General
"Use external makefile anklicken. Das entsprechende Makefile auswählen. Fertig. Alle Einstellungen werden dann gefunden, auch die Asuro Lib.

Zum Problem mit dem Finden der WinAVR Installation:
Es geht auch ohne Kopieren in den WinAVR Lib Ordner. Beim Stöbern in der GCC Doku fand ich den entscheidenen Tip.



LDFLAGS += -L../../lib
LDFLAGS += -lm
LDFLAGS += -lasuro


lediglich eine Zeile im Makefile dazugefügt und der Linker sucht auch in anderen Verzeichnissen nach Librarys.



Welche Compilerversion habt Ihr für den Build benutzt?


Ich benutze die WinAVR Version 20060421. Von der aktuellen 20070122 habe ich einiges negatives gehört. Deshalb werde ich vorerst auch nicht umsteigen. Komisch die Warnung wg. signed und unsigned Vergleich gibt es mit dieser Version nicht. Das sollte man natürlich trotzdem korrigieren.

[adrisch]

kann man das ganze jetzt mit programmers notepad programmieren oder nicht?

[damaltor]

ich denke schon, steht da nicht was etwas weiter oben im thread...?

[bloodyDragon]

Ich hätte eine frage zum releas candidate 2
( könnte auch auf candidate 3 zutreffen )


StartSwitch();
while(1) {
PrintInt(switched);
if(switched) { // Tastendruck

t1 = PollSwitch();
t2 = PollSwitch();
switched = FALSE;
PrintInt(t1);
PrintInt(switched);
SerPrint ("\n\r");
}
}

in diese wird nur einmal hineingesprungen ?

und wenn ich in der schleife ein StartSwitch mache dann wird immer hineingesprungen...

ich erlese es aus der doku nicht was ich falsch mache ?

[Sternthaler]

Hier hast du aber einen etwas andern Code als unter Programmier Fragen (https://www.roboternetz.de/phpBB2/viewtopic.php?p=274260#274260)

[inka]

hi allerseits,
offensichtlich ganz toll, was Ihr hier geleistet habt. Nur ich als anfänger habe verständigungsprobleme mit der einführung und verwendung der neuen lib/lib´s(?).
Es wurde auf die dokumentation zu RC3 hingewiesen, sicher, dort sind erklärungen zu den funktionen, den code kann man sich anschauen, anwendungs-beispiele auch. So weit so gut...

Zu installation steht in der dokumentation folgendes:
---------------------------------------------
Installation der Asuro Library
Zur Installation der Asuro Lib kopiert man das File /lib/libasuro.a in das c:/WinAVR/avr/lib Verzeichnis. Das File /lib/inc/asuro.h kopiert man in das c:/WinAVR/avr/include Verzeichnis.
----------------------------------------------
ist das wirklich alles? Was ist mit all den *.c files?
weitere fragen:

die asuro.c 2.6.1 wurde nun offensichtlich in viele kleinere lib´s aufgeteilt. Nach funktionen, ok, so weit verstanden...

Muss ich alle diese *.c dateien includen bzw. als sourcefiles in avr-studio hinzufügen?

Oder reicht es im avr-studio das verzeichnis in dem alle diese *.c datein sind hinzuzufügen und avr sucht beim kompilieren alle diese files durch ob die darin enthaltenen funktionen mit übersetzt werden?


Momentan ist es ein RC3, wann ist mit einer endgültigen freigabe zu rechnen? Ist zu freigabe mit großen änderungen zu rechnen?

entschuldigung, wenn ich die antworten auf meine fragen irgendwo übersehen haben sollte...

[damaltor]

ich denke, so resige änderungen wirds ncht mehr geben.

die .c dateien müssen auch mit kopiert werden.

hinzufügen oder includieren brauchst du sie glaube ich nicht, sondern das passiert durch die .a-datei (sofern ich das richtig kapiert habe)

[Sternthaler]

Hallo inka, (auch damaltor),

NEIN, die C-Dateien brauchen nicht irgendwohin kopiert zu werden!

Es ist ausreichend, wenn die Entwicklungsumgebung weiss wo die LIB ist. Da die LIB die Datei Datei libasuro.a IST, und sie in das Standard-Verzeichnis für Library's von euch kopiert werde soll, findet sie eigendlich jede Umgebung ganz alleine.

Hier noch ein Tipp:
Wo eigendlich ist das LIB-Verzeichnis?

inka hat oben als Muster c:/WinAVR/avr/lib angegeben. Das müsste für die meisten auch OK sein.
Ich selber installiere alle Programme immer an einer anderen Stelle, dann ist der Pfad zur LIB aber auch anders. Bei mir heist es dann C:\Programme\Meine\Prog\AVR-Win\avr\lib.

Wichtig: Wenn ihr nicht sicher seid, wo das Lib-Verzeichnis ist, sucht einfach nach "ranlib.exe", bei mir kommt dann C:\Programme\Meine\Prog\AVR-Win\avr\bin. Jetzt seid ihr sehr dicht bei dem Lib-Verzeichnis.
(Upss, hoffe, dass das hilft)

Hier noch mal eine weitere KurzInfo (oben schon erwähnt):
- alte, original-Datei asuro.c zerlegt in viel *.c-Dateien
- alle *.c-Dateien werden zu *.o übersetzt.
- alle *.o-Dateien werden in der asuro.a NUR zusammengefasst.
---> Alles was notwendig ist, ist IN der asuro.a-Datei.

Die 'blöde' asuro.h ist nur dafür da, damit der Compiler weiss, dass es das Zeug überhaupt gibt. (Natürlich auch für die dort definierten #define-Zeilen)

[inka]

hi Sternthaler,
werden die neuen *.c dateien auch auf netzwerklaufwerken gesucht (und gefunden?), muss ich den pfad dahin nicht angeben?

[inka]

hier ein versuch, wie es eben nicht geht :-( :

ich habe die lib mit hilfe der setup.exe in das netzwerkverzeichnis Y:\georg\hobby\roboter\asuro\_asuro_lib\2_7_rc3\As uroLib installiert. Die installation verlief problemlos...
beim compilieren kommen diese meldungen:

rm -rf herman_sw_linie.o herman_sw_linie.elf dep/* herman_sw_linie.hex herman_sw_linie.eep
Build succeeded with 0 Warnings...
avr-gcc.exe -I"Y:\georg\hobby\roboter\asuro\_asuro_lib\2_7_rc2\li b\lib\inc" -I"Y:\georg\hobby\roboter\asuro\_asuro_lib\2_7_rc3\As uroLib\lib" -mmcu=atmega8 -Wall -gdwarf-2 -DF_CPU=8000000UL -Os -fsigned-char -MD -MP -MT herman_sw_linie.o -MF dep/herman_s
w_linie.o.d -c ../hermann_sw_linie/herman_sw_linie.c

avr-gcc.exe -mmcu=atmega8 herman_sw_linie.o -o herman_sw_linie.elf
herman_sw_linie.o: In function `RaceStart':
../hermann_sw_linie/herman_sw_linie.c:100: undefined reference to `PollSwitch'
../hermann_sw_linie/herman_sw_linie.c:101: undefined reference to `PollSwitch'
../hermann_sw_linie/herman_sw_linie.c:111: undefined reference to `StatusLED'
../hermann_sw_linie/herman_sw_linie.c:114: undefined reference to `Msleep'
../hermann_sw_linie/herman_sw_linie.c:117: undefined reference to `StatusLED'
../hermann_sw_linie/herman_sw_linie.c:118: undefined reference to `BackLED'
../hermann_sw_linie/herman_sw_linie.c:122: undefined reference to `PollSwitch'
../hermann_sw_linie/herman_sw_linie.c:123: undefined reference to `PollSwitch'
../hermann_sw_linie/herman_sw_linie.c:131: undefined reference to `Msleep'
../hermann_sw_linie/herman_sw_linie.c:134: undefined reference to `BackLED'
herman_sw_linie.o: In function `main':
../hermann_sw_linie/herman_sw_linie.c:47: undefined reference to `Init'
../hermann_sw_linie/herman_sw_linie.c:51: undefined reference to `FrontLED'
../hermann_sw_linie/herman_sw_linie.c:52: undefined reference to `MotorDir'
../hermann_sw_linie/herman_sw_linie.c:53: undefined reference to `MotorSpeed'
../hermann_sw_linie/herman_sw_linie.c:57: undefined reference to `LineData'
../hermann_sw_linie/herman_sw_linie.c:67: undefined reference to `BackLED'
../hermann_sw_linie/herman_sw_linie.c:76: undefined reference to `BackLED'
make: *** [herman_sw_linie.elf] Error 1
Build failed with 17 errors and 0 warnings...

ich habe in avr noch die folgenden verzeichnise mit angegen:
Y:\georg\hobby\roboter\asuro\_asuro_lib\2_7_rc3\As uroLib\lib\ (da sind die *.c dateien)
und
Y:\georg\hobby\roboter\asuro\_asuro_lib\2_7_rc3\As uroLib\lib\inc\ (da ist die asuro.h z.b.)

- die vom avr mit "undefined reference to " gemeldeten befehle sind doch schon mit der lib 2.6.1 gelaufen, oder? Sind die in der 2.7 nicht mehr drin?

[inka]

deshalb habe ich mit der 2.7. lib weiter experimentiert:

- alle neuen *.c als sourcefiles dazu-addiert/als sourcefiles hinzugefügt
- das verzeichnis mit den *.h dateien in den project einstellungen hinzugefügt

das kompilieren verlief ohne fehlermeldung, das hexfile hat allerdings nicht weniger als die 42 ursprünglichen pages sondern 69!

Hat man damit eines der angestrebten ziele verfehlt? Oder mache ich etwas falsch?

[damaltor]

das prinzip der geteilten lib ist, dass nur die funktionen die gebraucht werden auch kompiliert werden. wenn aber alle dateien zugefügt wurden, dann werden auch alle kompiliert, und das programm ist riesig...

[inka]

muss ich dann entscheiden welche *.c notwendig ist? Für einen anfänger schwierig - da war die asuro.c als ganzes einfacher :-(

[damaltor]

nein. du musst nur die .h datei includieren. durch diese wird dann in der .a datei geschaut welche .c dateien benötgt werden (bzw. .o-dateien). theoretisch sollte das alles sien.

[HermannSW]

Hallo m.a.r.v.i.n,

Hallo Hermann,

wie wäre es damit:

"magic_1"


USRB = 0; // UART TX disable
OCR2 = 0xF7; // Pulsbreite 8


"magic_2"


OCR2 = 0x91; // Pulsbreite fuer 36kHz
da das Programm examples/IRCollisionTest der Asuro Library v270rc3 nicht funktioniert, habe ich mich an Dein Posting erinnert und endlich Deinen Vorschlag mit folgendem Programm getestet:
#include "asuro.h"

char *msgG="GREEN\r\n";
char *msgR="RED\r\n";
char *something=NULL;

int main(void)
{
Init();

DDRD |= (1 << DDD1); // Port D1 als Ausgang
PORTD &= ~(1 << PD1); // PD1 auf LOW
OCR2 = 0xF7; // Pulsbreite 8

while (1)
{
// "magic_1"
UCSRB = 0; // UART TX disable
OCR2 = 0xF7; // Pulsbreite 8

if (PIND & (1 << PD0))
{ StatusLED(GREEN); something=msgG; }
else
{ StatusLED(RED); something=msgR; }

// "magic_2"
OCR2 = 0x91; // Pulsbreite fuer 36kHz

SerPrint(something);

// Msleep(50);
}

return 0;
}
Leider funktioniert es nicht richtig: ohne SerPrint() ist der LED-Output OK mit SerPrint() ohne Msleep() gibt's nur GREEN, unabhängig vom Abstand mit SerPrint() und Msleep(50) gibt es ab und zu sogar "Audio" (bell character), und folgenden Output:
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
GREEN
REEN
GREEN
FREEN
GREEN
GREEN
GREEN
GREEN
FREEN
...Wieso kommt RED so selten, obwohl ich den Abstand auch klein und groß gemacht habe?
Und vor allem, wieso wird nicht RED in einer Zeile geschrieben, sondern REEN, FREEN, ...?

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

Hallo Hermann,

ich hatte es mit dem folgendem Programm probiert.
Hier erfolgt eine serielle Ausgabe allerdings nur, wenn eine Taste gedrückt wurde.


int main(void)
{

unsigned char sw;

Init();

DDRD |= (1 << DDD1); // Port D1 als Ausgang
PORTD &= ~(1 << PD1); // PD1 auf LOW
ocr2 = 0xFE;
while (1)
{
UCSRB = 0;
OCR2 = ocr2;

if (PIND & (1 << PD0))
StatusLED(GREEN);
else
StatusLED(RED);

sw = PollSwitch();
if (sw & 0x01)
ocr2 = 0xFE; //Pulsbreite 1
if (sw & 0x02)
ocr2 = 0xFD; //Pulsbreite 2
if (sw & 0x04)
ocr2 = 0xFB; //Pulsbreite 4
if (sw & 0x08)
ocr2 = 0xF7; //Pulsbreite 8
if (sw & 0x10)
ocr2 = 0xEF; //Pulsbreite 16
if (sw & 0x20)
ocr2 = 0x90; //Pulsbreite 110

if (sw)
{
OCR2 = 0x91;
PrintInt(sw);
SerPrint(" ");
PrintInt(ocr2);
SerPrint("\r\n");
}
// Msleep(100);
}
return 0;
}


Mit deinem Programm bekomme ich dasselbe Ergebnis wie du. Merkwürdig. :-k

[HermannSW]

Hi,

Hallo Hermann,

ich hatte es mit dem folgendem Programm probiert.
Hier erfolgt eine serielle Ausgabe allerdings nur, wenn eine Taste gedrückt wurde.nach Hinzufügen der beiden Zeilen

#include "asuro.h"
static unsigned char ocr2 = 0x91;konnte ich Dein Programm kompilieren und flashen -- bei mir kommt aber Schrott, wenn nichts gedrückt wurde, und ich sitze hier extra schon im Dunkeln ...

NÈ™5bÉÂ&NÈ™5ÉÂ&NÈ™5ÉÂÉÂÉÂÄÉÂ54
bÉÂÉÂNÈ™5bÉÂ&NÈ™5ÀÉÂ&FH™5ÉÂÉÂÉÂDÉÂÉÂÉÂNÈ™5bÉÂNÈ™5ÉÂ&NÈ™5bÉÂ&NÈ™528
254
028 254
128 254
128 25428 254
128 254
128 254
!28 254028 254
128 254
128 254
128128 254
128 254
128 254
028 254 28 254
128 254
128 2128 254
128 25bÉÃNÈ™5ÉÂ&NÈ™5ÉÂBÉÂ`ÉÂÉÂÀÉÂÉÂÀÉÂNH™5@ÉÂ&NÈ™5DÉÂ&NÈ™5ÉÂÉÂ@ÉÂÄ
ÉÂÉÂNÈ™5ÉÂNÈ™5@ÉÂ&NÈ™5ÉÂ&NÈ™5ÉÂ@ÉÂÉÂÉÂ`ÉÂNÈ™5@ÉÂNH™5ÉÂ&NÈ™5ÉÂÉÂÄÉÂ
ÉÂÉÂNÈ™5@ÉÂNÈ™5ÉÂNÈ™5ÀÉÂÉÂÉÂÉÂ@ÉÂNÈ™5ÄÉ NÈ™5@ÉÂ&NÈ™5ÉÂÉÂÉÂÉÂÉÂ@
ÉÂNÈ™5ÉÂ&NÈ™5@ÉÂNÈ™5@ÉÂÉÂ@ÉÂÉÂÉÂNÈ™5ÉÂ&NÈ™5@ÉÂ&NÈ™5bÉÂÉÂ@ÉÂÉÃ@ÉÂN
È™5ÉÂNÈ™5`ÉÂNÈ™5ÀÉÂNÈ™5@ÉÂÉÂÉÂÉÂ54



Mit deinem Programm bekomme ich dasselbe Ergebnis wie du. Merkwürdig. :-kIrgendwie überlagern sich die Ausgaben von RED und GREEN -- kann der Asuro etwa parallele IO-Threads? ... :)

Übrigens:
Gerade vor zwei Stunden habe ich endlich den von Dir empfohlenen Compiler WinAVR-20060421 installiert, damit klappt endlich auch das -gdwarf-2 als Compiler-Option in den Makefiles!

[M1.R]

Hallo,

ich versuche, die lib 2.7 zu installieren.
Ich kapiers nicht. - Vielleicht kann mir jemand weiterhelfen.

"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."

Das habe ich gemacht.

"Um die Lib neu zu übersetzen startet man den Make Prozess im Verzeichnis lib mit:
make clean
make all "

Wie ist das gemeint? Mit Programmers Notepad ? Welche Datei muss ich denn dann öffnen?

Wo muss denn das lib Verzeichnis hin? Da wo auch mein AVR Projekt liegt? Oder sollen alle Dateien aus dem 2.7-lib-Verzeichnis in das schon vorhandene WinAVR\avr\lib Verzeichnis?

Gruss
M.

[Bääääär]

um make clean und make all auszuführen machst du eine Textdatei und schreibst diese 2 befehle in je eine Zeile. dann speicherst du das ganze mit der Dateiendung *.bat ab und führst es im entsprechenden Ordner aus.

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

Hi,

du brauchst lediglich die Batch-Datei 'make-lib.bat' im Lib Verzeichnis ausführen (Doppelklick). Dann wird die Lib neu übersetzt und die neu erzeugte libasuro.a wird in das WinAVR Lib Verzeichnis kopiert.

Die restlichen Dateien brauchen nicht kopiert werden.

[ehenkes]

Ich habe da mal ein paar Fragen:
1) Sehe ich das richtig, dass die Datei asuro.c nicht in der statischen Bibliothek libasuro.a integriert ist?

OBJECTS = globals.o adc.o encoder.o encoder_low.o i2c.o leds.o lcd.o motor.o motor_low.o print.o rc5.o sound.o switches.o time.o uart.o version.o
2) Warum nicht?
3) Erwartet das Makefile in Programmer's Notepad asuro.h in C:\ASURO_SRC\AsuroLib\lib oder in C:\ASURO_SRC\AsuroLib\lib\inc ?

-I../../lib/inc\
VPATH=../../lib
DIRINC = .

[M1.R]

Hi,

du brauchst lediglich die Batch-Datei 'make-lib.bat' im Lib Verzeichnis ausführen (Doppelklick). Dann wird die Lib neu übersetzt und die neu erzeugte libasuro.a wird in das WinAVR Lib Verzeichnis kopiert.


Hallo m.a.r.v.i.n,
habe ich gemacht - die Datei ist auch vorhanden.

Trotzdem gibts noch Fehler (siehe Anhang).

Gruss M.

[stochri]

Hallo M.

hier (https://www.roboternetz.de/phpBB2/viewtopic.php?p=272559) befindet sich ein AVR-Studio-Projket, in dem alle Pfade richtig gesetzt sein sollten. Damit müsste es gehen.

Gruss,
stochri

[M1.R]

Hallo stochri,

bei deiner Methode werden ja alle Dateien kompiliert.

=> Fehler: c:\winavr\bin\..\lib\gcc\avr\4.1.1\..\..\..\..\avr \bin\ld.exe: region text is full (asuroLib27RC3test.elf section .text)
make: *** [asuroLib27RC3test.elf] Error 1
Build failed with 1 errors and 0 warnings...

Er macht also gar keine .hex - Datei, weil die zu gross würde.

Ich wollte die Lib 2.7 aus dem Grund verwenden, weil ich dachte, dass damit nur die wirklich benötigten Funktionen eingebunden werden und ich dann mein"Riesenprogramm" noch erweitern kann.

Ich könnte jetzt natürlich alle nicht benötigten Dateien rausschmeißen.
Es fällt mir nur etwas schwer zu entscheiden, welche das sind.

Gruss
M.

[stochri]

Alle "nicht benötigten" Dateien rausschmeisen ist wohl die beste Lösung. Mich wundert, dass bei Dir "text region full" erscheint, bei mir hat er das Zip-File in der Form wie in dem Therad gepostet, compiliert. Alternativ kannst Du andere Compiler-Optionen ausprobieren:

z.B. Os

dann wird weniger Speicher verbraucht.

[M1.R]

Hallo stochri,
mit deinen example - Dateien klappts bei mir auch.
Ich habe aber stattdessen meine eigene 19 KB grosse datei eingefügt.
Mit 0s kompiliert er zwar, aber das hex-file wird 17 KB gross!

Gruss
M.

[Sternthaler]

Hallo zusammen.
Da es ja doch immer wieder neue Hilferuf zur Installation und Inbetriebnahme der Asuro-LIB gibt, habe ich mal einen eigenen Thread für eine 'hoffentlich komplette Übersicht' angelegt.
Ihr findet dies unter So wird die Asuro-LIB installiert und in Betrieb genommen (https://www.roboternetz.de/phpBB2/viewtopic.php?p=306481)

Vorsicht: es geht da bei 'Adam und Eva' los. ;-)

[RobotNeu]

1.Frage :- Was bedeutet das 'L' hier
#define MY_GO_ENC_COUNT_VALUE 19363L

2.Frage :- In dem Beispiel Program in Motortest/test.c habe ich eine Variable Namens 'WheelSpeed[2]' gesehen. Ich glaube, dass dieser Wert nie gesetzt wird und folglich wird der ASURO immer schneller fahren (halt bis zu max. Geschwindigkeit und dann konstant, aber nicht um 150). Zumindest habe ich nicht gefunden, wo dieser Wert gesetzt wird. Auch beim ausdrücken dieser Wert wird nur eine '0' für beide WheelSpeed links und rechts ausgegeben. Der Asuro fährt aber.

könnte mir da jemand weiterhelfen?

[hai1991]

hallo robotneu

1:
das L zwingt den compiler, den wert als long zu verwenden.
im gegensatz zu einer variable ist dies bei einem define ansonsten nicht deklariert.

2.
kann ich dir leider auch nicht weiter helfen
jedoch vermute ich, dass diese variable irgend wo anders in der lib geändert wird. ist jedoch nur eine vermutung