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