## c't-Projekte - Mailinglisten

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

### Re: [ct-bot] EEPROM @ PC

Absender: Achim Pankalla
Datum: Mi, 11.04.2007 16:31:53
In-reply-to: <2A0C29E0-60B5-4AB3-8D92-286E59719C85@xxxxxxxxxxxxxxx>
References: <BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <A1E61AA9-0BF2-4A89-B255-27EDD9BDECD2@xxxxxxxxxxxxxxx> <45EEAB88.1080901@xxxxxxxx> <2F019FD4-6C76-47CB-9A35-3BA48E476E50@xxxxxxxxxxxxxxx> <461B959E.2080102@xxxxxx> <2A0C29E0-60B5-4AB3-8D92-286E59719C85@xxxxxxxxxxxxxxx>

    hallo timo,

`nur kurz ein paar bemerkungen/fragen zu deiner mail, danke vorab für die` `hinweise:`

    gruss
    achim

    Timo Sandmann schrieb:

>     Hi,

>     Am 10.04.2007 um 15:48 schrieb Achim Pankalla:

> >     hallo ct-bot'ler,

> > `anbei eine überarbeitete version meiner eeprom-simulation für den` `ct-bot unter ct-sim. es hat sich einiges getan, hier nur einige` `stichpunkte:`

> >     -auch block_read/write implementiert
> >     -eep datei wird erzeugt
> >     -tool für sim-eeprom patchen

> > `alles weiter findet ihr in der doku. die sollte man auch unbedingt` `lesen!`

> `erstmal danke an Achim, dass er sich der Sache angenommen und schon` `einiges implementiert hat! :)`

    danke! :-)

> `Ich habe das gerade mal ausprobiert (soweit möglich) und die Doku` `gelesen.` `1.) Leider lässt sich der Patch gegen das aktuelle CVS nicht komplett` `einspielen und zum manuellen Übernehmen der Codeteile fehlt mir die` `Zeit, sorry. Daher kann ich auch im Folgenden nur aufführen, was mir` `beim Lesen so auffiel.`

`tut mir leid, aber der patch wurde gestern von mir noch erfolgreich` `gegen ein gerade frisch geladenen cvs erfolgreich eingespielt! ich habe` `es gerade nochmal gegen ein frisches propiert, ohne probleme!`

    am welchen punkts hat es den geklemmt???

> `2.) Der Code compiliert für PC nicht, da die Datei` `"pc/eeprom-emu_pc.c" eine Headerdatei Namens "io.h" einzubinden` `versucht, auf meinem System gibt es aber keine "io.h" (jedenfalls` `nicht an der vorausgesetzten Stelle und die unter` `"/usr/include/architecture/i386" enthält andere Dinge als die` `geforderte "io.h". Ich habe mir sagen lassen, in der "io.h" stehen` `absolut-low-level-Funktionen, ich wäre sehr dafür, den Dateizugriff im` `kompletten Projekt einheitlich zu halten und auch für die` `EEPROM-Simulation ANSI C-Funktionen zu verwenden (open(), read(),` `write() entsprechen nicht dem ANSI C-Standard und sind z.B. unter` `Linux/Unix im Prinzip direkte System Calls). => z.B. mal bei` `pc/mmc-emu_pc.c vorbeischauen.`

    ok, war schon die ganze zeit so! ;-)   ich werde es aber ändern.

> `3.) Die Unterscheidung zwischen "Byte" und "Integer" bei load_ /` `store_parameter() finde ich persönlich unschön (ein Byte gilt` `eigentlich auch als Integer, das sei hier aber mal egal). Warum ruft` `eeprom_write_byte() nicht einfach einmal, eeprom_write_word() zweimal` `und eeprom_write_block() x-mal store_parameter(uint8* address, uint8` `data) auf?`

    verschiedene wege führen nach rom! ist eben so historisch gewachsen.

> `4.) Es wird scheinbar davon ausgegangen, dass das EEPROM immer 1 KB` `groß sei. Das sollte man aber mindestens irgendwo einstellen können,` `denn mein ATMega644 hat z.B. ein 2 KB großes EEPROM. Ich würde das` `lieber gar nicht künstlich beschränken / auf eine Größe festlegen,` `dann wäre es auch für ganz andere ATMegas verwendbar.`

    wird geändert!

> `5.) "#define EEPROM __attribute__ ((section (".eeprom")))"` `funktioniert so nicht auf allen Plattformen, siehe meine andere eMail` `dazu.`

`werde ich nochmal nachlesen, ist mir wohl im wust der infos entgangen.` `zur not darf ich sicher nachfragen.`

> `6.) Warum stehen denn in der HEADER(!)-Datei "eeprom_map.h"` `Initialisierungswerte (z.B. uint8 EEPROM ALIGNED err15=1;)?!?`

    weil dort die definition ist!?!

> `7.) "Leider arbeiten der gcc und er avr-gcc nicht identisch, so daß` `die Reihenfolge der Variablen in den eep Dateien von PC und MCU` `variiert." [Doku] - Das halte ich aber für ein Gerücht, man sollte` `wohl nur dieselbe gcc-Version für MCU und PC einsetzen... Dann kann` `man sich auch das "simeetool" sparen und direkt mit der eep-Datei` `arbeiten.`

`die gleichen versionen des compiler werden, wenn du es sagst, sicher den` `gleichen kode erzeugen. doch ich möchte mich hier nicht in abhängigkeit` `von compiler versionen begeben. ich denke nicht alle freunde des ct-bot` `sind so im thema wie du timo und so kann es leicht zu problemen kommen,` `die schwer zu entdecken sind. (zb schreibe ich in die doku, sim-eeprom` `und avr-eeprom sind gleich und dann hat jemand, so wie ich, nicht die` `gleichen compiler). niemand muss ja das tool benutzen. ;-)` `ein direktes arbeiten in der eep wäre ein möglichkeit, dann muss der` `kode aber noch geändert werden.`

> `8.) Absolute Pfade in der Konfigurationsdatei sind unschön, ich möchte` `das Projekt zu Testzwecken ganz gern mehrfach auf der Platte haben und` `dafür nicht immer irgendwelche Pfade anpassen müssen. Ich sehe aber` `auch keinen Grund, wofür man die Map-Datei des Linkers benötigt, die` `Sourcecode-Dateien werden MCU- und PC-Compiler ja in derselben` `Reihenfolge übergeben.`

`meints du die konfigurationsdatei des simeetool. dort kann man auch` `relative pfade eintragen. nach der cfg-datei sucht simeetool auch nur im` `aktuellen verzeichnis, man kann so auch mehrere cfgs anlegen.`

> `Das sind jetzt alles nur "negativ-Punkte", weil es eben nur das ist,` `was mir beim Doku-Lesen und schnellen Durchschauen so auffiel, testen` `kann ich es ja nicht richtig. Bitte nicht falsch verstehen,`

`was sollte ich bei hinweisen zu problemen falsch verstehen?? hinweise` `auf probleme/fehler können nicht negativ sein!`

> `das Ganze an sich ist natürlich eine gute Idee und dass es unter` `Windows funktioniert will ich auch nicht in Frage stellen.`

    danke! :-)

>     Aber plattformunabhängig sollte es schon sein.

    stimmt!

> > `nebenbei wurde noch die routine zum anzeigen der resets` `(TEST_AVAILABLE_COUNTER) entwanzt. ansonsten enthält dieser patch` `nur die eeprom-simulation und die anpassungen des vorhanden` `eeprom-kodes. die kalibrierroutine ist noch in arbeit.`

>     :-)

> > `an dieser stelle nochmal vielen dank an hr. benz und timo für die` `zahlreichen tipps und danke auch für die schnelle korrektur des` `typen-bug im pc von timo. funktioniert prima! ich hoffe sie findet` `bald eingang ins cvs.`

>     Ja ;-)

> > `da ich im moment nur unter win32 arbeite, wärs schön wenn jemand mit` `linux es mal testen könnte.`

> `Wie gesagt, der Patch geht so nicht (jedenfalls bei mir) und mit io.h` `ist das Ganze nicht ganz plattformunabhängig, daher kann ich es nicht` `weiter testen.`

>     Viele Grüße,
>     Timo
>     _______________________________________________
>     ct-bot-entwickler Mailingliste
>     ct-bot-entwickler@xxxxxxxxxxxxxxxxx
>     http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler

- Antworten:
  - Re: [ct-bot] EEPROM @ PC
    - From: Timo Sandmann

- 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
  - [ct-bot] EEPROM @ PC
    - From: Timo Sandmann
  - Re: [ct-bot] EEPROM @ PC
    - From: Achim Pankalla
  - Re: [ct-bot] EEPROM @ PC
    - From: Timo Sandmann

- Voriger (Datum): Re: [ct-bot] EEPROM @ PC, Timo Sandmann
- Nächster (Datum): Re: [ct-bot] EEPROM @ PC, Timo Sandmann
- Voriger (Thread): Re: [ct-bot] EEPROM @ PC, Timo Sandmann
- Nächster (Thread): Re: [ct-bot] EEPROM @ PC, Timo Sandmann
- Indizes:
  - Datum
  - Thread