## c't-Projekte - Mailinglisten

[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

### Re: Fwd: Re[2]: [ct-bot] ct-Bot-Wettkämpfe

Absender: Benjamin Benz
Datum: Mi, 26.04.2006 12:17:47
In-reply-to: <444F37DB.6000007@xxxxxxxxxx>
References: <006901c668cf$6bf19030$2201a8c0@user08> <444F37DB.6000007@xxxxxxxxxx>

    Hallo,

    >> beigebracht wird, sollten weder Compiler- noch Linkeroptionen die
    >> Logik der
    >> Algorithmen beeinflussen. Ob der Linker nun frisch übersetzten Quellcode
    >> oder alte libs verwendet, sollte IMHO Einsteigern doch eigentlich
    >> ziemlich
    >> egal sein.
    >
    > Eben nicht. das eine Mal fängt man mit einem Haufen Quellcode an,
    > in dem man main() erstmal suchen muß, das andere Mal gibt es ein
    > paar Bibliotheken und Header, das erste Projekt kann aber leer sein.

    Nun, ganz sollte man vielleicht auch die begleitenden c't-Artikel nicht
    ausser acht lassen, denn dort finden sich genau die Hinweise, wo man am
    besten einsteigt.

    > Ein "int main(){ led(GREEN,ON); }" ließe sich dann flashen, und
    > würde einen wirklich einfachen Einstieg garantieren.
    das lässt es auch so. Es spricht nicht das geringste dagegen, in
    ct-Bot.c eine eigene neue Main-Routine zu schreiben, die genau so aussieht.

    > Zum einen finde ich das Framework nicht sehr modular (so sind z.B.
    > Maschinenkonstanten über etliche Headerfiles verstreut), zum anderen
    > soll eine Modularisierung dem Anfänger helfen und den Fortgeschrittenen
    > nicht hindern. Das momentane Framework bietet nur letzteres.

    Eben das ist modular. Wäre alles an einem Ort würde ich den Begriff
    monolithisch verwenden. Die Konstanten sind, wo auch immer möglich dort,
    wo sie thematisch dazugehören. Wer sich gerade mit den LEDs beschäftigt
    soll sich doch nicht durch Timer-Konstanten wühlen müssen. Wer an der
    PWM spielt, braucht nicht im gleichen File die Definitionen für die
    Sensorkalibration. Es gibt zu fast jedem Themenkomplex ein .c-File und
    den dazu passenden header (.h) hier die Liste:

    File		Inhalt

    mcu/ :
    adc.c       	Analog-Digitalkonverter
    display.c 	Display-Routinen
    ir-rc5.c	Low-Level dekodierung/Empfang von IR-Signalen
    motor-low.c  	PWM-Steuerung und Co
    sensor-low.c	Low-Level Abarbeitung der Sensoren
    srf10.c		Ansteuerung eines Ultraschall-Distanzsensors
    TWI_driver.c	Ansteuerung der I2C- (alias TWI-) Schnittstelle
    bot-2-pc.c  	Kommunikation mit dem PC per UART
    delay.c		Delay-Routinen
    ena.c		Ansteuerung der Sensor-Schalter
    led.c		Ansteuerung der LEDs
    mouse.c		Ansteuerung des Maussensors
    shift.c		Ansteuerung der Shift-Register
    timer-low.c	Timer
    uart.c		Low-Level-Routinen für die serielle Übertragung

    Bei Bedarf setze ich diese Liste auch gern mit den weiteren Files in den
    anderen Verzeichnissen fort.

    Ich denke, der Begriff Modular trifft hier zu. Wobei wie sicherlich
    nichts gegen konkrete Umbauvorschläge haben, wenn sie es modularer machen.

    > (das wäre ebenso ein Beispiel) dazuschreiben? Der erfahrenen Benutzer
    > hat dann das Framework, welches keine hartkodierten Werte benutzt,
    > sondern Konstanten/Funktionen bietet, der Anfänger kann direkt sein
    > 1001 benutzen, um erstmal mit der FB rumzuspielen. Beide benutzen
    > dann aber doch eine Funktion "uint16 remotecontrol(void)" einer Basis-
    > Bibliothek.

    Im derzeitigen Modell, bekommen aber doch alle alles. Der Einsteiger
    kann sofort loslegen und alles ignorieren. Der Erfahrene Coder kann auch
    tiefer einsteigen. Zwei getrennte Code-Basen machen die wartung viel
    komplexer und Binary-Libraries machen es IMHO auch nicht besser und
    machen 1. die Installation schwieriger und dürften in absehbarer Zeit
    für komplexe Versionsabhängigkeiten sorgen (siehe Linux). Derzeit kann
    man aus dem CVS eine Version holen und weiss, alles passt zusammen.

    > Nochmal: das sind nur Ideen, ob die Routine wirklich so heissen soll,
    > ob sie keinerlei Parameter kennt, ob es eine Routine für die RC5-Nutzdaten
    > und eine für die RC5-Adresse geben soll, das alles ist mir nicht wichtig,
    > nur eben die Idee, Einsteigern einen simplen Einstieg zu ermöglichen.
    gerade beim Verhaltensframework haben wir uns bemüht es auf einfache
    Nutzung für Anfänger zu optimieren (siehe Bsp. in meiner anderen Mail).
    der preis dafür ist allerdings ein etwas komplexeres Innenleben. Ich
    würde aber hier gerne nochmal ganz kurz für das Verhaltensframework
    werben, bzw. die dahinter stehenden Überlegungen darstellen:

    1. Es soll aller Low-Level-Kram im Hintergrund geschehen, damit dem User
    ganz einfach Sensorwerte und co zur Verfügung stehen, ohne dass er sich
    drum kümmern muss
    2. Es soll ohne komplexe Dinge wie Echtzeitbetriebssysteme auskommen
    3. Es soll möglich sein Straight-Forward-Code zu schreiben. d.h. um
    delays und Co muss man sich ebensowenig kümmern wie um PWM-Werte und
    Stromsparfunktionen der Sensoren
    4. Es soll möglich sein modulare Verhalten zu bauen, die man immer
    wieder verwenden kann.

    Und ich denke genau das tut es im Moment. Hier nochmal ein ganz kurzes
    Bsp. für ein Verhalten, dass den Bot Stoppt, wenn er vor einem Abgrund
    steht:

    void bot_avoid_border_behaviour(Behaviour_t *data){
      if (sensBorderL > BORDER_DANGEROUS)
        speedWishLeft=-BOT_SPEED_NORMAL;

      if (sensBorderR > BORDER_DANGEROUS)
        speedWishRight=-BOT_SPEED_NORMAL;
    }

    Könnte es sein, dass wir vielleicht eher ausführlichere Doku brauchen,
    als eine umdefinierte API? Ich finde den hier in der Liste gemachten
    Vorschlag dafür schon sehr gut und würde mich über weitere freuen. Dann
    können wir da vielleicht gemeinsam etwas auf die Beine Stellen. Ich
    würde mich freuen, wenn gerade die Kritiker, die sich ja damit
    beschäftigt haben uns konstruktive Vorschläge liefern, damit wir die
    Punkte, die uns bisher entgangen sind glatt schleifen können, denn ich
    denke unser Ziel ist identisch: Eine Codebasis zu schaffen, die für
    Anfänger und Profis passt.

    MfG Benjamin Benz
    --
    Benjamin Benz
    Heise Zeitschriften Verlag
    Redaktion c't
    eMail: bbe@xxxxxxxx
    WWW  : http://www.heise.de

- Antworten:
  - Re: Fwd: Re[2]: [ct-bot] ct-Bot-Wettkämpfe
    - From: Michail Brzitwa

- Referenzen:
  - RE: Fwd: Re[2]: [ct-bot] ct-Bot-Wettkämpfe
    - From: Timo Sandmann
  - Re: Fwd: Re[2]: [ct-bot] ct-Bot-Wettkämpfe
    - From: Michail Brzitwa

- Voriger (Datum): Re: Fwd: Re[2]: [ct-bot] ct-Bot-Wettkämpfe, Fabian Recktenwald
- Nächster (Datum): [ct-bot] Ponyprog2000, Daniel Morell
- Voriger (Thread): Re: Fwd: Re[2]: [ct-bot] ct-Bot-Wettkämpfe, Fabian Recktenwald
- Nächster (Thread): Re: Fwd: Re[2]: [ct-bot] ct-Bot-Wettkämpfe, Michail Brzitwa
- Indizes:
  - Datum
  - Thread