Absender: Timo Sandmann
Datum: Mi, 07.03.2007 13:33:55
In-reply-to:
<45EEAB88.1080901@xxxxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <A1E61AA9-0BF2-4A89-B255-27EDD9BDECD2@xxxxxxxxxxxxxxx> <45EEAB88.1080901@xxxxxxxx>
Hi, Am 07.03.2007 um 13:09 schrieb Benjamin Benz:
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.
klar, nur braucht man eine Lösung, die das auch vernünftig abdeckt und auf MCU nicht langsamer ist ;-)
Mir fällt da derzeit nix schlaues ein, aber das heißt nichts.
Ich denke z.B. auch, dass die Motorregelung auch laufen sollte, wenn man den Bot simuliert. Sonst bastelt man sichschnell was am PC zusammen, was in der realen Welt dann nie gehen wird. Lieber bekommt der Sim noch ein Modul, um die Sensor- und Aktuatorwertekünstlich zu verrauschen bzw. etwas mehr Physik zu verwenden.
Na ja, dann muss der Sim bei Full-Speed alle 6 ms eine Encoderflanke liefern und der Bot wesentlich öfter als in 6 ms Intervallen diese Daten abfragen, damit es genau genug ist. Klappt das performancetechnisch auf einem durchschnittlichen PC? Ich finde den Sim jetzt schon zu langsam...
Es gibt übrigens auch noch einen Vorteil der statischen EEPROM-Adressenzuordnung: Macht man das per gcc-Attribut, muss manaufpassen, 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.
Ich denke das EEPROM ist aber groß genug, so dass man da nicht optimieren muss. Wenn alle #ifdefs an sind, muss es ja auch reinpassen.
Gruß Timo