## c't-Projekte - Mailinglisten

[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

### [ct-bot] EEPROM @ PC

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

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

`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

- Antworten:
  - Re: [ct-bot] EEPROM @ PC
    - 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
  - 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, Benjamin Benz
- Nächster (Datum): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Achim Pankalla
- Voriger (Thread): Re: [ct-bot] Re: Kalibrierung der Distanzsensren mittels EEPROM-Tabelle, Benjamin Benz
- Nächster (Thread): Re: [ct-bot] EEPROM @ PC, Achim Pankalla
- Indizes:
  - Datum
  - Thread