## c't-Projekte - Mailinglisten

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

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

> ``

`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.`

> ``

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

> ``

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

> ``

`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.`

>     MfG Benjamin Benz

> ``

- Referenzen:
  - [ct-bot] Kaibrierung
    - From: Carsten Giesen
  - [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle
    - From: Achim Pankalla
  - Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle
    - From: Timo Sandmann
  - Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle
    - From: Benjamin Benz

- Voriger (Datum): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Achim Pankalla
- Nächster (Datum): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Achim Pankalla
- Voriger (Thread): Re: [ct-bot] EEPROM @ PC, Benjamin Benz
- Nächster (Thread): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Achim Pankalla
- Indizes:
  - Datum
  - Thread