|
 |
 |
 |
|
|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
Absender: Timo Sandmann
Datum: Sa, 10.03.2007 16:40:05
In-reply-to:
<45F2B74F.8090706@xxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <45EF385C.3080609@xxxxxx> <A2ED0A68-A8F1-438A-B1E3-18033ED489E3@xxxxxxxxxxxxxxx> <45F135B9.5030203@xxxxxx> <45F13A91.6090904@xxxxxxxx> <D053B7F5-6BDD-4052-B45F-28FCF0EF45F8@xxxxxxxxxxxxxxx> <45F2B74F.8090706@xxxxxx>
Hi,
Am 10.03.2007 um 14:49 schrieb Achim Pankalla:
kann das in zukunft nicht probleme geben? bot_turn fragt im moment
ab, ob ein wert von 0xff (leeres eeprom) vorliegt und initialisiert
dann seine variablen.
nun ja, wenn überall im EEPROM 0xFF steht, ist das bereits eine
saubere Initialisierung. Leider kann man davon im Allgemeinen nicht
ausgehen (außer man löscht das EEPROM regelmäßig, das möchte ich z.B.
aber nicht tun). Was ist, wenn nun aber 0xFE im EEPROM steht, wo
bot_turn() seine Daten ablegt? Dann beträgt die Drehwinkelkorrektur
plötzlich 254 Grad, nur mal als Beispiel.
Ich bin außerdem der Meinung, dass man im Code (so weit es denn
möglich ist), keine Abfragen auf Spezialfälle (z.B. ein leeres
EEPROM) einbauen, sondern stattdessen lieber dafür sorgen sollte,
dass die verwendeten Daten korrekt initialisiert sind und die
Behandlung des Allgemeinfalls ausreicht. Meistens macht das den Code
übersichtlicher, weniger fehleranfällig und schneller. Das kann man
natürlich auch anders sehen, darum geht's mir hier auch nicht, nur
sollte es meines Erachtens möglich sein, eine Initialisierung vor der
Laufzeit verwenden zu *können*, so wie es die Adressvergabe beim
EEPROM durch den gcc ja auch macht. An welcher Stelle man das Ganze
dann wie implementiert (bei der Kalibrierung der Distanzsensoren z.B.
wäre es wohl eher unsinnig), kann man dann von Fall zu Fall entscheiden.
Siehe dazu auch die eMail von gestern zum EEPROM-per-gcc-am-PC-Thema.
wenn ich aber immer, für ein verhalten oder eine systemfunktion,
die eep datei nachschieben muss, so mach ich doch damit
irgendwelche parameter, die der bot während seiner laufzeit
erstellt hat (zb die werte von bot_turn, oder auch andere werte,
die in zukunft dort abgelegt werden) platt.. durch ein
nachträglichen aufspielen eines eeprom abzuges, zum
wiederherstellen seiner parameter, wären aber wieder die
initialisierungen des compiler futsch.
Ich würde auch die eep-Datei nicht immer übertragen. Das ist übrigens
der Grund, warum ich das EEPROM nicht wirklich benutzt habe, bevor es
den Bootloader gab, denn vor jedem Flashen die Parameter auslesen und
hinterher neu übertragen zu müssen, fand ich sehr unpraktisch. Dass
nach dem Übertragen die Initialisierungen überschrieben sind, ist
aber ja Absicht, denn die Werte, die der Bot selbst schreibt, sollten
Vorrang haben.
wäre es nicht dann sinnvoller, das jede routine die das eeprom
nutzt selbst checken muss, ob ihre bereiche sinnvoll belegt sind
oder das sie jedenfalls daran nicht scheitern darf?
S.o. Ich denke außerdem, dass es im Allgemeinen schwierig ist zu
entscheiden, wann ein Wert "sinnvoll belegt" ist und wann nicht.
Gruß Timo
|
|
|