Absender: Benjamin Benz
Datum: Fr, 13.04.2007 13:00:36
In-reply-to:
<39D8E34B-6A42-4407-8C2D-D927173F43C8@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> <461CF140.4080503@xxxxxx> <1697D7D6-AB69-4775-926C-ED9B84B4289A@xxxxxxxxxxxxxxx> <461E6580.3020808@xxxxxx> <39D8E34B-6A42-4407-8C2D-D927173F43C8@xxxxxxxxxxxxxxx>
Hallo, ich kann mich den Ausführungen von Timo nur anschließen. MfG Benjamin Benz Timo Sandmann wrote: > 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 > > > > _______________________________________________ > ct-bot-entwickler Mailingliste > ct-bot-entwickler@xxxxxxxxxxxxxxxxx > http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler > -- Benjamin Benz Heise Zeitschriften Verlag Redaktion c't eMail: bbe@xxxxxxxx WWW : http://www.heise.de Heise Zeitschriften Verlag GmbH & Co. KG Registergericht: Amtsgericht Hannover HRA 26709 Persönlich haftende Gesellschafterin: Heise Zeitschriften Verlag Geschäftsführung GmbH Registergericht: Amtsgericht Hannover, HRB 60405 Geschäftsführer: Ansgar Heise, Steven P. Steinkraus, Dr. Alfons Schräder