heise online · c't · iX · Technology Review · Telepolis · mobil · Security · Netze · heise open · heise resale · Autos · c't-TV · Jobs · Kiosk
Zum Inhalt
c't

c't Projekte - c't-Bot und c't-Sim - Mailinglisten

c't-Bot und c't-Sim


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

Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle

Absender: Achim Pankalla
Datum: Mi, 07.03.2007 23:51:23
In-reply-to: <45EEAB88.1080901@xxxxxxxx>
References: <BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <A1E61AA9-0BF2-4A89-B255-27EDD9BDECD2@xxxxxxxxxxxxxxx> <45EEAB88.1080901@xxxxxxxx>


Benjamin Benz schrieb:
Hallo,

ich schneide mal alle Teile weg, zu denne ich nichts zu sagen habe...

Das Kalibrieren sollte IMHO auf jeden Fall in ein Verhalten, das ist
keine Initialisierung, die zu Beginn von main() ausgeführt wird. An- und
abschaltbar per available_behaviours.h. Insbesondere eine
FB-Tastenzuordnung / RC5_Code Auswertung in oder von ct-Bot.c sowie
Displayausgaben dort sind IMHO unbedingt zu vermeiden.

*zustimmend nick*
es gibt keine tastenzuordnung in ctbot.c das geschied alles in calibrate_sonsors.c. warum ich immer noch der meinung bin, das kalibrieren kein verhalten sein sollte habe ich in der mail von 23:10 dargelegt. ich weiss ich scheinbar (aber nur scheinbar ;-) ) unbelehrbar. ich hatte schon an ein extra prg gedacht, das nur das kalibrieren erlaubt, dann kann man aber nicht so schön seine werte nach dem kalibrieren testen und man müsste danach ein neues bot-prg auf den bot bringen.
Zur EEPROM @ PC Diskussion: Ich denke, man sollte genau nachdenken, wo
man überhaupt ein emuliertes EEPROM auf dem PC braucht. Im Wesentlichen
sehe ich zwei Dinge bei solch einer Emulation: Zum Einen um Code am PC
testen / debuggen zu können (siehe MMC-Emulation am PC), das spielt aber
für das EEPROM IMHO nicht so eine große Rolle, denn man speichert /
liest einfach nur Bytes, Words oder kleinere Blöcke (das fehlt glaube
ich auch noch in der Patch-Lösung? Brauche ich unbedingt ;-)) und keine
das könnte man ja noch implementieren, würde die hlfe nicht ablehnen ;-)
großen Datenmengen.
Zum anderen, um denselben Code für MCU und PC zu haben. Hier macht das
schon Sinn, nur wo setzen wir letztlich das EEPROM ein? Die
Distanzsensorwerte im Sim sind immer identisch, hier könnte man die
Daten auch hardcoded in sensor_correction.h ablegen, so wie die
Maus-DPIs in bot-local.h. Ebenso verhält sich bot_turn() im Sim immer
gleich. Den FAT-Cache für die MMC braucht man am PC genauso wenig wie
die Daten der Motorregelung. Bleibt die Frage, was mehr Code ist, die
Emulation für den PC (inkl. der daraus resultierenden und in den eMails
zu diesem Thema genannten Einschränkungen) oder zweimal #ifdef.
Bitte nicht falsch verstehen, die Idee einer EEPROM-Emulation für den PC
ist super und wenn man eine einheitliche Schnittstelle für Verhalten /
Bot-Code hat, ist das ein eindeutiger Vorteil, man sollte dadurch nur
keine Nachteile schaffen, die man sonst nicht hätte.

Hier will ich eindeutig ein Lanze für die EEPROM@PC-Emulation brechen.
Gerade beim testen komplexer codes ist es praktisch, wenn soviel als
möglich identisch ist. Ich denke z.B. auch, dass die Motorregelung auch
laufen sollte, wenn man den Bot simuliert. Sonst bastelt man sich
schnell was am PC zusammen, was  in der realen Welt dann nie gehen wird.
Lieber bekommt der Sim noch ein Modul, um die Sensor- und Aktuatorwerte
künstlich zu verrauschen bzw. etwas mehr Physik zu verwenden.
danke :-) , kann ich nur zustimmen
Es gibt übrigens auch noch einen Vorteil der statischen
EEPROM-Adressenzuordnung: Macht man das per gcc-Attribut, muss man
aufpassen, dass der Code, der die Variablen deklariert (für MCU) *immer*
compiliert wird und nicht u.U. durch ein #ifdef ausgeschlossen wird,
dann ändert der Compiler nämlich alle Adressen und man bekommt Chaos /
überschreibt oder liest andere Werte.

Da hast Du recht, zumindest insofern man den statischen Aufbau nicht
auch per #ifdef macht. Das würde man aber unter Umständen wollen, weil
man sonst Teile seines EEPROMs opfert, die nie benutzt werden.
stimmt hr. benz, aber im moment ist die nutzung des eeprom eher mau oder? sollte einmal grössere datenmengen benötigt werden kann man ja abhängikeiten erzeugen und teile mit #ifdef machen. vorerst sind aber ca. 113 byte von 1024 verbraten.
MfG Benjamin Benz







Copyright © 2007 Heise Zeitschriften Verlag Kritik, Anregungen bitte an c't-WWW Datenschutzhinweis   Impressum