|
 |
 |
 |
|
|
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: Do, 12.04.2007 21:12:56
In-reply-to:
<461E6580.3020808@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> <2A0C29E0-60B5-4AB3-8D92-286E59719C85@xxxxxxxxxxxxxxx> <461CF140.4080503@xxxxxx> <1697D7D6-AB69-4775-926C-ED9B84B4289A@xxxxxxxxxxxxxxx> <461E6580.3020808@xxxxxx>
Nabend,
Am 12.04.2007 um 18:59 schrieb Achim Pankalla:
du hast recht timo. so ganz richtig ist das nicht mit der header-
datei. die alternative wäre eine eigene c-datei. ich möchte aber
die definitionen in einer datei halten. damit immer alle variablen
definiert werden, egal ob bestimmte code zeile, aufgrund von
define's nicht übersetzt werden und auch damit man eine übersicht
behält.
Jetzt muss die Datei "eeprom_map.h" genau(!) einmal per #include
eingebunden werden, zurzeit geschieht das in ct-Bot.c (obwohl ct-
Bot.c das EEPROM gar nicht benutzt). Schreibt man in irgendeine
andere Datei "#include eeprom_map.h", dann compiliert der Code nicht
mehr (logischer Weise). Das widerspricht meines Erachtens dem
Gedanken von Headerdateien und den Codinprinzipien in C.
Außerdem würde ich mir wünschen, die Init-EEPROM-Daten für bot_turn()
in behaviour_turn.c finden zu können und nicht in einer Datei in
include/eeprom_map.h, die ausschließlich in ct-Bot.c eingebunden
wird. Wie gesagt, meine persönliche Sichtweise.
ich glaube wir reden (schreiben) da etwas aneinander vorbei. ich
versuch mal meine idee (irrwitzigen gedanken ;-) ) klarer
auszudrücken:
es gibt die datei eeprom.bin, die ja automatisch von meinen
routinen erstellt wird, wenn sie noch nicht vorhanden ist. diese
ist für mich das eeprom, das während aller aufrufe des ct-sim werte
speichert, so auch die werte für die (sorry) sensorkalibrierung,
die man mit den kalibriermenue (einmal) erzeugt. bei jeden start
des ct-sim sind diese werte, wie beim realen bot, wieder zugreifbar.
Ich fände es schön, wenn man ein EEPROM-Abbild vom Bot direkt im Sim
verwenden könnte und andersrum. Ohne ein Konvertierungstool und ohne
noch eine Map-Datei des Linkers zur Hand haben zu müssen, die zur
Compilezeit einmal erstellt wurde. Dazu muss meines Erachtens im
Wesentlichen nur eine Bedingung erfüllt sein, nämlich die Gleichheit
der Speicheradressen jeweiliger "EEPROM-Variablen". Und ich sehe
keinen Grund, warum das nicht machbar sein sollte, ein und derselbe
Compiler arbeitet ja immer gleich (bei gleichem Sourcecode).
die objcopy-tools erzeugen die eep-datei, die die initialisierungen
für die variablen enthalten. diese inits kann man mit den simeetool
in das simulierte eeprom übertragen. benutze ich aber direkt die
eep datei als simuliertes eeprom, so sind meine kalibrierwerte
futsch, weil überschrieben, oder ich müsste sie als initialisierung
in den kode schreiben (bzw irgendwie eintragen, hex-editor).
deshalb habe ich auch simeetool erstellt , damit kannst du nur die
nötigen initialsierung in das sim-eeprom eintragen und da fand ich
das praktisch, wenn man das über die variablennamen machen kann.
deshalb die map-dateien.
Die Sache mit den Init-Werten ist mit erfüllter obiger Bedingung auch
gleich mit erledigt. Natürlich soll das EEPROM des Sims nicht in der
Datei mit den Initialisierungen rumschreiben, ich meinte nur, es
sollte exakt dasselbe Dateiformat (mit gleichen Adressen) sein. Dann
kann ich die von objcopy erstellte ct-Bot.eep in eeprom-emu.eep
umbenennen, die der Sim benutzt, wenn ich die Init-Werte haben
möchte. Möchte ich als Init den Inhalt des Bot-EEPROMs, nehme ich die
eep-Datei, die ich per avrdude ausgelesen habe usw.
deshalb möchte ich auch immer alle variablen definiert habe und in
einer datei haben. beispiel es gibt ein verhalten, das daten
ermittelt und im eeprom ablegt. nun deaktiviere ich dies verhalten,
um etwas anderes zu machen. werden diese variablen nun beim
compilieren nicht mehr definiert, so bekommen andere diese
speicheradressen und meine eventuell mühsam erstellten werte sind
weg. (wenn ich sie nicht sichere)
erweiterungen von simeetool, wie adressangabe statt variablenname
etc. sind schon geplannt
Na ja, es gibt ja immer jeweils mindestens ein Verhalten, das eine
"EEPROM-Variable" benutzt, sonst bräuchte man sie nicht. Folglich
kann dieses Verhalten auch für die korrekte Definition (außerhalb von
#ifdefs) sorgen. Nun kann es ja trotzdem eine zentrale Stelle
(Headerdatei) geben, wo die Variablen zusätzlich deklariert sind,
erstens zur Übersicht und zweitens, falls ein anderer Codeteil
dieselbe EEPROM-Variable benutzen möchte (man nehme z.B. mal an, der
Sensordaten-Screen soll die im EEPROM von bot_turn() abgelegten
Drehfehler anzeigen, das geht dann, indem ich dort einfach "#include
eeprom_map.h" mache (wie es an tausend anderen Stellen auch gemacht
wird) und ohne so einen "extern-Missbrauch").
im prinzip müsste man jetzt schon die eep-datei als eeprom benutzen
können, wenn man binary statt ihex format benutzt. werde ich mal
verifizieren die tage und abchecken, ob das ohne weiteres geht.
Das Format ist mir eigentlich egal, ihex ist halt für Menschen
leichter les- und änderbar.
Nochmal kurz ein bemerkung zu den gleichen code mit den compilern.
wie siehst eigentlich mit den mac-bestitzern aus. ich kann mich
schwach erinnern das dort nun auch das entwicklungstool läuft.
erzeugt der compiler, bei gleicher version auch gleiche eeprom
belegung?
Ja.
ganz gleiche eeproms erzeugen anscheinend auch gleiche versionen
nicht.da ohne aligned in der eeprom-sections füllbyte eingefügt
werden beim pc.
Ja, aber ich dachte, das Thema sei jetzt ausgiebig genug durchgekaut
worden... Ein "aligned (1)" löst das Problem ja bekanntlich.
Gruß Timo
|
|
|