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