|
 |
 |
 |
|
|
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, 22.02.2007 00:47:38
In-reply-to:
<000001c755ed$468b68a0$fe78a8c0@mexpnew>
References:
<000001c755ed$468b68a0$fe78a8c0@mexpnew>
Am 21.02.2007 um 20:19 schrieb Frank Menzel:
Hallo Allerseits,
ich muß mich revidieren, das Verhalten läuft doch auf dem echten bot !
Da hatte ich letztens wohl zu viel auskommentiert:-( Also das
Verhalten
des bots geht dahin, dass er zu seinem definierten Zielpunkt (oder
eben
Ausgangspunkt) fahren will. Nur konnte ich meine Tests nicht
ausweiten,
ich muß erst eine geeignete Testumgebung dafür schaffen.
Aufgefallen ist
mir nur auf die Schnelle, dass er für den echten zu schnell fahren
will
und dass die links/ rechts Kommandos nicht schnell genug ausgeführt
werden, wodurch er zu viel Raum beansprucht. Ich habe sehr viel
auskommentieren müssen vom Code, damit er die 32K Grenze nicht sprengt
und ist nun knapp davor. Doch wie alles verkleinern ? Gibt's
vielleicht
eine Code-Optimierungsstufe auf höherem Level als jetzt ? Oder wie
könnte man allgemein Code, wie unten angesprochen, auf eine
Speicherkarte auslagern-würde das überhaupt gehen ? In den
Zusammenhang
die Frage: Im Zuge eines anderen Projektes bin ich auf einen
SMD-Schaltkreis Atmel Data Flash gestoßen. Wieso wurde bei unserem bot
eigentlich eine Speicherkarte verwendet (mit den Problemen der
diversen
verschiedenen Speicherkarten), hätte es ein solcher IC nicht besser
getan ?
Es ist übrigens nur eine echte verkette Liste, die logisch aber zwei
beherbergt. Und für MCU-Übersetzung muß die u.a. Zeile richtig
heißen (s
anstatt x): node_nextdest==NULL.
Gruß, Frank Menzel
Hallo,
also der Compiler sollte bereits mit -Os aufgerufen werden und er tut
sein bestes. Aber vieles kann der Compiler nicht so gut wissen wie
der Autor des Codes, darum macht es - besonders auf der AVR-Plattform
- durchaus Sinn, sich um die Optimierung auf Größe und
Geschwindigkeit selbst ein paar Gedanken zu machen. Bei vielen
mathematischen Operationen ist z.B. der Wertebereich eingeschränkt
und man kann mit uint anstatt mit int rechnen, oder mit 8 Bit anstatt
16 Bit oder gar 32 Bit. Besonders float-Operationen brauchen viel
Platz und viel Rechenzeit, hier kann man überlegen, ob man nicht mit
Ganzzahl-Operationen auskommt. Außerdem findet sich unter http://
www.atmel.com/dyn/resources/prod_documents/doc1497.pdf ein Dokument,
dass ein paar Aspekte zur Optimierung speziell für die AVRs
beschreibt. Wobei dort von einem anderen Compiler ausgegangen wird
(nicht gcc), aber das meiste trifft trotzdem zu.
Zur Speicherkarte: Programmcode auslagern funktioniert so ohne
weiteres nicht (außer man interpretiert z.B. ein Skript, das auf der
Karte liegt zur Laufzeit oder ähnliches). Ich meinte, dass man die
Speicherkarte als RAM-Erweiterung nutzen kann (und natürlich für
persistente Daten). Wie man relativ einfach und flexibel RAM
auslagern kann, findet sich im Bot-Projekt unter Documentation/mmc-
vm.html.
Warum Karte? Bei einem IC finde ich es immer so umständlich, das
kleine Ding in einen Cardreader am PC zu bekommen... Außerdem kann
man auf der Karte FAT-Dateien ablegen, einlesen, bearbeiten und
wieder auslesen, z.B. am PC.
Bei normalen verketteten Listen kommt man meist nur mit O(n) an die
Daten, deshalb meinte ich, man könnte eventuell mit einer anderen
Datenstruktur noch etwas mehr Performance herausholen, ist so
allgemein aber natürlich schlecht zu sagen, dafür muss man den Code
und was er tut besser kennen. ;)
Gruß Timo
|
|
|