Tiny ASURO Library - Eine weitere Bibliothek für den ASURO

[markusj]

Hallo zusammen,

nach längerer Entwicklungsarbeit habe ich die erste Version meiner ASURO-Bibliothek fertiggestellt und veröffentlicht: Tiny ASURO Library

In vielen Punkten orientiert sich diese an der hier weiterentwickelten Bibliothek des DLR. Meine Bibliothek ist aber weniger umfangreich, außerdem wurde die Implementierung auf geringen Flash- und Stromverbrauch hin optimiert.

Die Bibliothek steht im Gegensatz zur "klassischen" Asurolib nicht unter der GPL-Lizenz. Stattdessen wurde die CDDL gewählt, da diese in meinen Augen das Werk jedes einzelnen stärker respektiert aber dennoch eine Weiterentwicklung der Bibliothek fördert.

Ich werde versuchen, in den nächsten Wochen einige meiner Optimierungen auch in die Asurolib einfließen zu lassen.

An dieser Stelle noch ein großes Dankeschön an (in alphabetischer Reihenfolge) Andun, Sternthaler und stochri. Deren Implementierung von GoTurn() konnte dank ihrer Einverständnis in die Bibliothek übernommen und dort weiterentwickelt werden.

Ich wünsche viel Spaß und freue mich über jede konstruktive Kritik,
Markus

Nachtrag: Vielleicht noch einige Anmerkungen zu einigen Features die "meine" Bibliothek auszeichnen:

• Quasi vollständig Interruptfest
• Encoderkompensierter Bewegungsmodus: Kompensation von (mechanischen) Abweichungen der beiden Antriebsseiten durch Encoderauswertung
• Es ist Keine Kalibrierung für die Odometrie-Auswertung mehr erforderlich (Flankenerkennung)!
• Eine "kugelsichere" ADC-Schnittstelle
• Durchgehende Verwendung von C99-Datentypen

[stochri]

Hallo Markus,

gute Arbeit.
>Durchgehende Verwendung von C99-Datentypen
Sehr löblich, es machen viele Mikrocontrollerprogrammierer noch den Fehler, allgemeine Datentypen wie "int" anstatt "int32_t" zu verwenden. Erst dadurch werden die Programme wirklich transportabel.
Gut finde ich auch die Trennung der asuro-lib in einzelne *.C Fiiles.

Was die Interrupts anbelangt, muss man sehen, wie es funktioniert. Am interessantesten ist die Frage, ob die Encoder jetzt ohne sich zu verzählen laufen.

Beste Grüße,
stochri

[Valen]

Was meinst du mit "kugelsichere ADC-Schnittstelle". Wahrscheinlich verstehe ich das nicht weil Deutsch nicht meiner Muttersprache ist.

[markusj]

Hallo zusammen,

@stochri: Danke, ich hatte bisher mit dem Encoder keine Probleme - weder bei GoTurn() wo der Encoder ja in einer Schleife gepollt wird und der AVR ansonsten schläft, noch bei meinen Anwendungen des encoderkompensierten Bewegungsmodus bei dem man sich selbst um das Pollen kümmern muss. Solange man es schafft EncoderPoll() mit ausreichend hoher Frequenz aufzurufen (hängt von der gewünschten Fahrtgeschwindigkeit ab), sollte sich die Auswertung nicht "verschlucken".

@Valen: Ist "bulletproof" besser?
Wird der ADC entsprechend der Dokumentation benutzt ist es unmöglich, sich in irgend einer Form ins Knie zu schießen. Wird eine AD-Wandlung in der Hauptschleife durch eine weitere Wandlung in einer ISR unterbrochen, hat dies keine negativen Folgen für die Hauptschleife, es wird sichergestellt dass diese ein Ergebnis ihres ADC-Kanals dennoch auslesen kann!

mfG
Markus

[radbruch]

Hallo

Was mich verwirrt: Was ist an diesem Ungetüm eigentlich tiny (winzig)?

Für mein Empfinden ist das alles viel zu kompliziert. Die urprüngliche Form der Lib mit nur zwei Dateien ist meiner Meinung nach die beste Basis für eigene asuro-Programme. Wenn man verfolgt, wie häufig das Kompilieren der asuro-Programme am falschen Einbinden der Lib scheitert, kann man sich ausmalen, wie das mit dieser TinyLib wird.

Lustig finde ich, dass die alten "Sünden" auch hier wieder auftauchen:

FWD für Forward und RWD für Rückwards?

Beim ersten Überfliegen der Funktionen ist mir dies aufgefallen:

ISR(TIMER2_OVF_vect)
{
    uint8_t temp_reg;

    asm volatile( // TCNT2 += 0x25;
            "in %[SUB_REG], %[TIMER_REG]            \n\t"
            "subi %[SUB_REG], %[OFFSET_2COMP]       \n\t"
            "out %[TIMER_REG], %[SUB_REG]"
            : /* Out-Operanden */
              [SUB_REG] "=&d" (temp_reg)
            : /* In-Operanden */
              [TIMER_REG] "I" (_SFR_IO_ADDR(TCNT2)),
              [OFFSET_2COMP] "M" (-37 + 256) // GCC mag -37 alleine nicht
    );

    tick36kHz++;

...
}

(aus time.c der TinyLib)

Das sieht im Orginal (die Version mit dem PWM-Timer2 nach Waste) so aus:

SIGNAL (SIG_OVERFLOW2)
{
	TCNT2 += 0x25;
	count36kHz ++;
...
}

(aus asuro.c)

Warum einfach, wenn es auch kompliziert geht?

Gruß

mic

[Valen]

@Valen: Ist "bulletproof" besser?
Wird der ADC entsprechend der Dokumentation benutzt ist es unmöglich, sich in irgend einer Form ins Knie zu schießen. Wird eine AD-Wandlung in der Hauptschleife durch eine weitere Wandlung in einer ISR unterbrochen, hat dies keine negativen Folgen für die Hauptschleife, es wird sichergestellt dass diese ein Ergebnis ihres ADC-Kanals dennoch auslesen kann!

mfG
Markus

Danke, ich verstehe es.

[markusj]

Hallo Radbruch,

haha, gute Argumentation *grins*. Zugegeben, einige Stellen im Quelltext sind ... heftig (ADC, lock.h) aber:
Die Bibliothek ist im Vergleich zur DLR/RN-Version Tiny in Punkto Umfang. (Und hoffentlich auch bezügl. der Codegröße).

Das Risiko einer Fehlbedienung halte ich bei beiden mitgelieferten Makefiles für relativ gering, es müssen nur zwei Konfigurationspunkte angepasst werden, egal ob die Bibliothek in Quelltext- oder Objectcodeform verwendet wird. Die Dokumentation diesbezüglich ist hoffentlich ausreichend eindeutig.

@FWD/BWD: Da hast du recht und es tut mir auch etwas weh, aber ich wollte die Kompatibilität zu anderen Bibliotheken erhalten. Evtl. baue ich in die nächste Version zusätzlich ein BWD ein (oder gibt es andere Vorschläge?)

@"Warum einfach, wenn es auch kompliziert geht?": Der "Hack" mit dem 36kHz-Tick basiert auf bestimmten Vorbedingungen/Annahmen darüber, wie der Quelltext umgesetzt wird. Ich wollte diese impliziten Annahmen vermeiden und zeigen, wie die Parameter zustande kommen und warum es so funktionieren kann.

Sofern es mein Zeitplan zulässt werde ich die Bibliothek in nächster Zeit um weitere Codebeispiele erweitern, in der Hoffnung dass das Ungetüm so weniger abschreckend wirkt
Danke für die Kritik!

mfG
Markus

[radbruch]

Hallo

"Danke für die Kritik!"

Ehrlich, es fällt mir nicht leicht hier zu kritisieren. Ich sehe natürlich auch die Arbeit und die Zeit die in dieser Lib steckt. Deshalb auch ein Dank zurück für die Lib und die Entgegennahme der Meinungen ;)

Mit ein paar Codebeispielen und etwas mehr Einarbeitungszeit sollte es mir vermutlich auch gelingen die Vorteile zu erkennen. Ich bin eben noch etwas verwirrt und habe mit der Nibobee-Lib, die ja auch in mehrere Teildateien zerlegt ist, keine guten Erfahrungen gemacht. Die war allerdings auch in C++ geschrieben...

Mit dem Testen siehts etwas mau aus, weil mein "asuro" ja nicht ganz hardwarekonform mit dem Orginal ist. Tasten und Motoransteuerung weicht etwas ab, aber die Sensorik ist nahezu identisch. Ist eine gute Übung für mich, weil ich nun auch ein aktuelles WinAVR installiert habe und gewillt bin, nun auch das AVR-Studio und das Notepad zu nutzen ;)

Gruß

mic

[markusj]

Hallo zusammen,

es gibt Neuigkeiten! Version 1.1.0 ist veröffentlicht bringt zwei Änderungen mit sich:
1. Als Alias zum sinnarmen RWD gibt es jetzt das Makro BWD (@radbruch so ok?).

2. Die Bibliothek bringt jetzt einen ASURO-kompatiblen Bootloader zur Verwendung mit "ASURO Flash" (dem Programm von Arexx/DLR) mit. Im Gegensatz zum Original ist der "Tiny ASURO Bootloader" Open-Source und um 50% kleiner. Vermutlich werden vor allem fortgeschrittenere Bastler mit eigenem Programmiergerät daran Interesse haben.

Wie immer: Viel Spaß beim Ausprobieren!

Zur Projektseite und zum Direktdownload

mfG
Markus

[Valen]

Naturlich war ich gleich neugierig wie das Bootloader geschrieben ist. Den AvrBuild.bat datei in dem tinyasuroboot ordner enthalt pfaden der nur stimmen für den Rechner der Person das es geschrieben hat.