|
 |
 |
 |
|
|
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: Achim Pankalla
Datum: Sa, 30.06.2007 15:53:30
In-reply-to:
<6566D2F2-ADE4-4656-86C0-6533B3462B64@xxxxxxxxxxxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <45EF385C.3080609@xxxxxx> <A2ED0A68-A8F1-438A-B1E3-18033ED489E3@xxxxxxxxxxxxxxx> <45F135B9.5030203@xxxxxx> <45F13A91.6090904@xxxxxxxx> <D053B7F5-6BDD-4052-B45F-28FCF0EF45F8@xxxxxxxxxxxxxxx> <45F2B74F.8090706@xxxxxx> <38A4BFD9-CA32-436A-9A1E-B4E6E0652A5D@xxxxxxxxxxxxxxx> <463E0782.1050406@xxxxxx> <0FBD95CF-DA3B-461B-B12B-9FDCD84984D2@xxxxxxxxxxxxxxx> <463F3E0A.7020605@xxxxxx> <8D5B90F4-74FD-45D4-B5B8-DDCAC0B81932@xxxxxxxxxxxxxxx> <464092F7.30605@xxxxxx> <465DB1F9.5030404@xxxxxx> <CF925D4D-FD5A-4581-8480-1C5D35EFEDC9@xxxxxxxxxxxxxxx> <4663027F.4040301@xxxxxx> <F71477F0-03AD-4F06-87E3-AC5DA5BFD1B2@xxxxxxxxxxxxxxx> <466D6849.1020109@xxxxxx> <46756694.9010906@xxxxxx> <6566D2F2-ADE4-4656-86C0-6533B3462B64@xxxxxxxxxxxxxxx>
Timo Sandmann schrieb:
Hallo,
Am 17.06.2007 um 18:51 schrieb Achim Pankalla:
hallo,
wie angekündigt nun eine neue version von der eeprom-emulation. sie
benötigt kein linker-script mehr und auch keine zusätzlichen tools,
nur die schon mitgelieferten. compiler und linker versionen sollten
keine rolle spielen.
unter w32 geht alles wunderbar, erfahrung unter linux und macos
fehlen noch, da wäre ich noch für infos dankbar.
alles weitere findet ihr in der docu.
der patch enthält die eeprom-emulation und einige anpassungen an den
restlichen kode, weil bisher kein eeprom unter dem pc da war.
getestet habe ich es mit bot_turn und der sensor-kalibrierung.
viel spass damit
achim pankalla
der Patch ist jetzt im devel-Zweig des SVN. Eine kleine Änderung habe
ich noch vorgenommen: Im PC-Modus (Standard, wenn man nichts weiter
konfiguriert), werden beim Anlegen der EEPROM-Datei die Werte
eingetragen, die im Code als Initialisierung stehen, so dass auch ohne
weitere Schritte der PC-Bot im Sim funktioniert, wenn man einfach nur
den Code aus dem SVN holt (würde nur ein leeres EEPROM angelegt,
müsste man für alles, das Daten aus dem EEPROM braucht, also z.B.
Distanzsensoren oder bot_turn(), erst Kalibrierungen vornehmen).
danke! das ist wirklich eine sinnvolle änderung.
Außerdem sind noch zwei Punkte "offen":
1.) Ein Byte aus dem emulierten EEPROM lesen dauert bei der aktuellen
Implementierung (je nach Betriebssystem) zwischen 16 und 30 µsec,
einen Block von x Bytes zu lesen dauert sogar x-mal so lange. Das
ließe sich noch deutlich beschleunigen. Auch wenn der Sim sicherlich
mehr CPU-Zeit verbraucht als der PC-Bot - in jedem Bot-Zyklus werden
allein für die Distanzsensoren bis zu 24 Bytes aus dem EEPROM gelesen
und die Verzögerung auf Grund des langsamen Zugriffs sollten man IMHO
vermeiden. Hier wäre eine kleine Überarbeitung wünschenswert.
lässt sich sicher machen, werde mir mal einige spotane ideen durch den
kopf gehen lassen, priorität hat für mich erstmal punkt 2)
2.) Der MCU-Modus funktioniert (bisher) weder unter Linux noch unter
Mac OS X (Windows habe ich nicht testen können).
windows geht, habe es wie erwähnt mit der neuen routine für die
distanzsensoren und bot_turn getestet. für weitere tests unter windows
und hinweise bin ich natürlich dankbar.
Das Problem ist, dass die für den Post-Build-Step vorgesehen Befehle
auf den beiden Plattformen andere Ergebnisse liefern (getestet mit gcc
4.0 und 4.2 sowie binutils 2.17). Folgende Varianten produzieren bei
mir eine brauchbare map-Datei, die allerdings vom EEPROM-Code so nicht
korrekt geparsed wird:
Linux:
objdump -t -j .eeprom -C ct-Bot.elf | grep "g" > eeprom_pc.map
führt zu folgender map-Datei (der Übersichtlichkeit halber nach
Adressen umsortiert und unnötigen Leerzeichen entfernt):
080530ee g O .eeprom 00000004 pwmSlow
080530f2 g O .eeprom 0000001c sensDistDataL
0805310e g O .eeprom 0000001c sensDistDataR
0805312a g O .eeprom 00000001 sensDistOffset
0805312b g O .eeprom 00000001 resetsEEPROM
0805312c g O .eeprom 00000028 eefat
08053154 g O .eeprom 00000001 err15
08053155 g O .eeprom 00000001 err45
08053156 g O .eeprom 00000001 err_big
Mac OS X:
objdump -t -j LC_SEGMENT..s2eeprom. -C ct-Bot.elf | grep "g" >
eeprom_pc.map
führt zu dieser map-Datei (der Übersichtlichkeit halber nach Adressen
umsortiert und unnötigen Leerzeichen entfernt):
00012000 g LC_SEGMENT..s2eeprom. pwmSlow
00012004 g LC_SEGMENT..s2eeprom. sensDistDataL
00012020 g LC_SEGMENT..s2eeprom. sensDistDataR
0001203c g LC_SEGMENT..s2eeprom. sensDistOffset
0001203d g LC_SEGMENT..s2eeprom. resetsEEPROM
0001203e g LC_SEGMENT..s2eeprom. eefat
00012066 g LC_SEGMENT..s2eeprom. err15
00012067 g LC_SEGMENT..s2eeprom. err45
00012068 g LC_SEGMENT..s2eeprom. err_big
Wenn der map-Parser (auch?) dieses Format interpretieren könnte, ginge
der MCU-Modus plattformübergreifend und wir hätten eine Lösung, die
wirklich alles abdeckt.
das ist mein ziel!!! bitte sende mir doch an meine email adresse die
kompletten ausgaben von linux (objdump -t -j .eeprom -C ct-Bot.elf) und
mac os x (objdump -t -j LC_SEGMENT..s2eeprom. -C ct-Bot.elf), am besten
als anhänge gezipt. damit ich sie unverfälscht erhalte.
was mich bei dem mac ausgaben irretiert ist die tatsache, das die
variablen dort in der section .s2eeprom sind. sie sollten eigentlich in
.eeprom liegen. das lässt sich sicher noch klären...
nett wären auch von beiden die ausgaben von objdump -h ct-bot.elf
besten dank im vorraus.
gruss
achim
Siehe auch
http://www.heise.de/ct/projekte/machmit/ctbot/ticket/88#comment:6
Viele Grüße,
Timo
_______________________________________________
ct-bot-entwickler Mailingliste
ct-bot-entwickler@xxxxxxxxxxxxxxxxx
http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler
|
|
|