heise online | · | c't | · | iX | · | Technology Review | · | Telepolis | · | mobil | · | Security | · | Netze | · | heise open | · | heise resale | · | Autos | · | c't-TV | · | Jobs | · | Kiosk

Aktuelles Heft #### Support Hotline & FAQ Tipps & Tricks Treiber & BIOS Firmenkontakte #### Download Software zu c't Software-Verzeichnis c't-Projekte Testbilder & Vorlagen #### Service Tipp-Datenbank c't-CD-Register Internettarife Telefontarife Virenschutz #### Magazin Heftarchiv c't specials English Pages Benchmarks Red. Stuff Leserforum c't-Bildmotive URLs aus c't Schlagseite #### Aktionen Browsercheck Krypto-Kampagne Schulen ans Netz Netz gegen Kinderporno TV/Radio-Termine #### Info Abo & Heft Veranstaltungen Mediadaten Kontakt Impressum Kleinanzeigen und Veranstaltungen
| 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: 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
Antworten: [ct-bot] EEPROM @ PC From: Timo Sandmann Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle From: Achim Pankalla 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 Voriger (Datum): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Timo Sandmann Nächster (Datum): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Benjamin Benz Voriger (Thread): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Timo Sandmann Nächster (Thread): [ct-bot] EEPROM @ PC, Timo Sandmann Indizes: Datum Thread |

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