Absender: Benjamin Benz
Datum: Mi, 07.03.2007 13:09:46
In-reply-to:
<A1E61AA9-0BF2-4A89-B255-27EDD9BDECD2@xxxxxxxxxxxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <A1E61AA9-0BF2-4A89-B255-27EDD9BDECD2@xxxxxxxxxxxxxxx>
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 > 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. > 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 -- Benjamin Benz Heise Zeitschriften Verlag Redaktion c't eMail: bbe@xxxxxxxx WWW : http://www.heise.de Heise Zeitschriften Verlag GmbH & Co. KG Registergericht: Amtsgericht Hannover HRA 26709 Persönlich haftende Gesellschafterin: Heise Zeitschriften Verlag Geschäftsführung GmbH Registergericht: Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise, Steven P. Steinkraus, Dr. Alfons Schräder