c't

c't-Projekte - Mailinglisten


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

Re: [ct-bot] EEPROM @ PC

Absender: Timo Sandmann
Datum: Mi, 11.04.2007 01:17:34
In-reply-to: <461B959E.2080102@xxxxxx>
References: <BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <A1E61AA9-0BF2-4A89-B255-27EDD9BDECD2@xxxxxxxxxxxxxxx> <45EEAB88.1080901@xxxxxxxx> <2F019FD4-6C76-47CB-9A35-3BA48E476E50@xxxxxxxxxxxxxxx> <461B959E.2080102@xxxxxx>


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

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. 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. 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? 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. 5.) "#define EEPROM __attribute__ ((section (".eeprom")))" funktioniert so nicht auf allen Plattformen, siehe meine andere eMail dazu. 6.) Warum stehen denn in der HEADER(!)-Datei "eeprom_map.h" Initialisierungswerte (z.B. uint8 EEPROM ALIGNED err15=1;)?!? 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. 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.

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, das Ganze an sich ist natürlich eine gute Idee und dass es unter Windows funktioniert will ich auch nicht in Frage stellen. Aber plattformunabhängig sollte es schon sein.

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