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 23:32:20
In-reply-to: <461CF140.4080503@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>


Hallo zusammen,

Am 11.04.2007 um 16:31 schrieb Achim Pankalla:

hallo timo,
nur kurz ein paar bemerkungen/fragen zu deiner mail, danke vorab für die hinweise:
gruss
achim

tut mir leid, aber der patch wurde gestern von mir noch erfolgreich gegen ein gerade frisch geladenen cvs erfolgreich eingespielt! ich habe es gerade nochmal gegen ein frisches propiert, ohne probleme!
am welchen punkts hat es den geklemmt???

keine Ahnung, Eclipse hat alle geänderten (also nicht neuen) Dateien mit einem roten ! versehen und sie dann nicht gepatcht. "Manuell" per Konsole ging's jetzt aber, wenn Eclipse das nur bei mir nicht macht, ist es ja egal.

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?
verschiedene wege führen nach rom! ist eben so historisch gewachsen.

ach so

5.) "#define EEPROM __attribute__ ((section (".eeprom")))" funktioniert so nicht auf allen Plattformen, siehe meine andere eMail dazu.
werde ich nochmal nachlesen, ist mir wohl im wust der infos entgangen. zur not darf ich sicher nachfragen.

sicher

6.) Warum stehen denn in der HEADER(!)-Datei "eeprom_map.h" Initialisierungswerte (z.B. uint8 EEPROM ALIGNED err15=1;)?!?
weil dort die definition ist!?!

und wenn die Headerdatei in mehreren Dateien eingebunden wird, ist es doppelt definiert (und initialisiert)? Ich meine, der Grundgedanke von Headerdateien war anders ;-) So oder so, niemand möchte an den EEPROM-Treibern etwas ändern müssen, wenn er bot_turn() neue Default- Werte verpassen will.

die gleichen versionen des compiler werden, wenn du es sagst, sicher den gleichen kode erzeugen. doch ich möchte mich hier nicht in abhängigkeit von compiler versionen begeben. ich denke nicht alle freunde des ct-bot sind so im thema wie du timo und so kann es leicht zu problemen kommen, die schwer zu entdecken sind. (zb schreibe ich in die doku, sim-eeprom und avr-eeprom sind gleich und dann hat jemand, so wie ich, nicht die gleichen compiler). niemand muss ja das tool benutzen. ;-) ein direktes arbeiten in der eep wäre ein möglichkeit, dann muss der kode aber noch geändert werden.

Hm, ich dachte, das direkte Verwenden der eep-Datei sei der Witz an der Sache? Wäre jedenfalls schön, wenn das ginge.

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.
meints du die konfigurationsdatei des simeetool. dort kann man auch relative pfade eintragen. nach der cfg-datei sucht simeetool auch nur im aktuellen verzeichnis, man kann so auch mehrere cfgs anlegen.

Ach so, in der Doku steht es halt immer mit absoluten Pfaden. Aber dann ist das ja schon erledigt.

Viele Grüße,
Timo