|
 |
 |
 |
|
|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
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
|
|
|