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: 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



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