c't

c't-Projekte - Mailinglisten


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

Re: [ct-bot] Code-Konfiguration [war: timer.h für ct-Bot.c]

Absender: Timo Sandmann
Datum: Di, 10.05.2011 01:31:41
In-reply-to: <1304846913.1833.29.camel@wbam-laptop>
References: <1304432598.1556.3.camel@wbam-desktop> <094DCFE5-4E6D-4947-B399-CC65624C29E2@xxxxxxxxxxxxxxx> <BANLkTi=-_TGYAs-1JAoZQRbkr0dDTZudoQ@xxxxxxxxxxxxxx> <76570.33339.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4DC3A0DC.8060309@xxxxxxxx> <941619.55637.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4DC3A8D0.4000906@xxxxxxxx> <BANLkTi=-V8BY8a8MD0e=sO19zboAvG4Wcw@xxxxxxxxxxxxxx> <4DC3D427.2030203@xxxxxxxx> <1304846913.1833.29.camel@wbam-laptop>


Am 08.05.2011 um 11:28 schrieb Simon Siemens:
> Ich finde es toll, dass ihr so offen für die Vorschläge und Bedürfnisse
> Anderer seid. Ein Code mit so vielen Konfigurationsparametern ist aber
> sehr schwer zu pflegen; ich beneide Timo nicht für seine Aufgabe ...
> tiefes Mitgefühl.

na ja, so viele Patches und Updates bekommen wir ja (leider) auch wieder nicht. Wenn ihr das Prozedere aber etwas vereinfachen möchtet, fügt den Patches doch auch einen entsprechenden Eintrag in Changelog.txt mit hinzu.

> Wir konfigurieren im Moment zwar den Code mit all den Schaltern, die uns
> zur Verfügung stehen; ich sehe aber nicht wirklich eine Notwendigkeit
> dafür. Ich könnte mir auch vorstellen, dass der Code in drei, vier oder
> fünf (aufeinander aufbauende) Teile gegliedert ist – dass es also nur
> drei bis fünf defines in ct-Bot.h gibt.

Man muss dabei aber auch bedenken, dass einige der Schalter echte Alternativen konfigurieren, also z.B. ob die Positionsdaten mit Hilfe der Radencoder _oder_ des Maussensors berechnet werden, oder wohin geloggt werden soll usw. Diese müssen also auf jeden Fall für den Benutzer konfigurierbar bleiben.
Ich denke, die Schalter
LOG_*, USE_MINILOG, CREATE_TRACEFILE_AVAILABLE, BOT_2_SIM_AVAILABLE, BOT_2_BOT_AVAILABLE, DISPLAY_REMOTE_AVAILABLE, MEASURE_MOUSE_AVAILABLE, MEASURE_COUPLED_AVAILABLE, MEASURE_POSITION_ERRORS_AVAILABLE, TEST_AVAILABLE_*,  MAP_AVAILABLE, MAP_2_SIM_AVAILABLE, SPEED_CONTROL_AVAILABLE, ADJUST_PID_PARAMS, SPEED_LOG_AVAILABLE, SPI_AVAILABLE, BOT_FS_AVAILABLE, EEPROM_EMU_AVAILABLE, BOOTLOADER_AVAILABLE
fallen in diese Gruppe. 

Weiterhin gibt es eine Gruppe von Schaltern, die sich auf die Konfiguration des Bots (der Hardware) beziehen und zu Optimierungszwecken aus- oder eingeschaltet werden können, das sind:
DISPLAY_AVAILABLE, MOUSE_AVAILABLE, BPS_AVAILABLE, SRF10_AVAILABLE, CMPS03_AVAILABLE, SP03_AVAILABLE, MMC_AVAILABLE
Hier kommt auch noch hinzu, dass einige Erweiterungen (SRF10, SP03) dankenswerter Weise von Benutzern eingereicht wurden - den entsprechenden Code können wir nicht testen, weil wir die zugehörige Hardware nicht haben. Daher sollten diese Schalter erhalten bleiben.

Die letzte Gruppe umfasst Schalter, die eigentlich immer an sein sollten, das sind alle Restlichen (falls ich jetzt auf die Schnelle keine vergessen habe):
LED_AVAILABLE, IR_AVAILABLE, RC5_AVAILABLE, KEYPAD_AVAILABLE, ADC_AVAILABLE, ENA_AVAILABLE, SHIFT_AVAILABLE, BEHAVIOUR_AVAILABLE, POS_STORE_AVAILABLE, OS_AVAILABLE
Trotzdem sollten wir auch diese Schalter nicht komplett entfernen, weil sie a) eine noch aggressivere Optimierung (auf eigene Gefahr sozusagen) ermöglichen und b) zu Debugging-Zwecken sehr hilfreich sein können.


Ein Vorschlag: Wir gliedern die Datei ct-Bot.h in drei Abschnitte, die den o.a. Gruppen entsprechen und verdeutlichen den Sinn der Gruppierung durch zusätzliche Kommentare. Technisch ändert sich dann erstmals nichts, es wird aber evtl. übersichtlicher und der Normalbenutzer muss weniger scrollen / Code lesen, um die üblichen Optionen zu konfigurieren. Außerdem wird dadurch deutlich, welche Schalter man üblicherweise anpassen muss / kann und welche im Normalfall unangetastet bleiben sollten. 

Grüße,
Timo