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:
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.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*
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
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.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.
MfG Benjamin Benz