|
 |
 |
 |
|
|
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: Fr, 09.03.2007 11:24:08
In-reply-to:
<A2ED0A68-A8F1-438A-B1E3-18033ED489E3@xxxxxxxxxxxxxxx>
References:
<BCF016D5ED5AC34FBB655D109519ABCF083EBE@xxxxxxxxxxxxxxxxxxxx> <45ED3B46.4030400@xxxxxx> <45EF385C.3080609@xxxxxx> <A2ED0A68-A8F1-438A-B1E3-18033ED489E3@xxxxxxxxxxxxxxx>
hallo ct-bot'ler,
da sind ja einige tipps, hinweise und kritiken eingelaufen. das find ich
toll, hätte noch ein paar meinungen gewünscht!
vorweg, ich werde das erstellen der tabelle in ein verhalten
integrieren. ich kann die gründe zum grössten teil nachvollziehen und
ich denke, das es dann auch wieder im ct-sim funktioniert. (zumal man in
der neusten version den bot auch wieder positionieren kann, was ja ein
must have für das einmessen ist). ich denke der einzige wirkliche
kritikpunkt ist damit beseitigt. die anderen zahlreichen bemerkungen
sehe als anreiz für verbesserungen, aber nicht als punkte, die eine
aufnahme in den kode entgegenstehen oder habe ich da etwas übersehen hr.
benz?
herr benz schrieb bezüglich eeprom@pc:
Was meinen denn die anderen auf dieser Liste dazu?
Die Optionen sehen IMHO so aus:
1. manuelle Speicherzuteilung ==> code läuft auf PC und MCU identisch
2. automatische Speicherzuteilung per avr-gcc ==> Code läuft nicht
sinnvoll auf PC
3. evtl. kann man mit ein paar geschickten Makros die Speicherzuteilung
auf dem PC nachstellen?
Nach den von Ihnen genannten Pros würde ich (wenn jemand weiß wie) für
Version 3 oder sonst 1 plädieren.
ich würde auch lieber version 3 haben, aber mir ist noch nichts besseres eingefallen. meine bescheidene meinung dazu ist, da es ja auf eine emulation der avr-gcc fkt rausläuft, das man dann durchaus erst einmal eine version 1 implementieren kann. da sich an parameter und rückgabenwerte der fkt ja nichts ändern darf (der name ja eh nicht), kann man später, wenn jemand etwas besseres schafft, das ohne probleme übernehmen.
wichtig ist mir persönlich nur, das muss ja nicht für alle so sein ;-) , das das eeprom auf dem pc, wenns denn bei einer datei bleibt, im aufbau (selben adressen der variablen)zum bot identisch ist und möglichst als bin datei vorliegt. dann kann ich es weiter auf den bot übernehmen und via versa.
ein paar fragen /anmerkungen von timo möchte ich noch beantworten, aber
ich halte es kurz. man muss ja nicht jeder punkt kommentieren :-)
wer hat den bitte ein bot der genau 120mm meldet konstant und ohne
wackler. durch die kalibrierung ist so etwas möglich!
Ich. ... Wenn sein muss, kann ich gerne ein Video (nicht digital
nachbearbeitet...) machen.
danke timo, das ist nicht nötig. ich glaub dir das auch so. hast noch
etwas weiteres an der sensoransteuerung geändert, ausser die hw-patches
mit den kondensatoren??? das würde mich interessieren.
Huch, verstehe ich schon wieder nicht :-/ Ich vermute mal, es ist
gemeint, dass die Variablen auf beiden Systemen (PC und MCU) an
derselben Adresse (im Speicher ?) liegen? Ich sehe keinen Grund, warum
das der Fall sein müsste, einzig der Name muss eindeutig sein, das ist
er aber ja automatisch, wenn der Quellcode gleich ist. *ratlos*
doch, du verstehst mich doch. genau das meine ich, die variablen sollen
an der gleichen adresse liegen, so kann ich die daten mit ponyprog vom
bot holen und sie den ct-bot.exe im sim als eeprom unterschieben, ohne
sie vorher konvertieren zu müssen. (siehe auch oben)
In dieser Mail ging es mir jetzt in erster Linie um das Konzept, nicht
darum, dass mir die ein oder andere Codezeile nicht gefällt oder ich
behaupte, sie funktionierte nicht korrekt! Ist nur meine Meinung, die
uns vielleicht ein kleines Stückchen weiterbringen kann.
habe ich auch nicht so aufgefasst. ich habe ja auch nichts gegen das
verhaltens-framework, ich war nur der meinung, das die kalibrierroutine
dort nicht reinpasst. ok da bin ich jetzt eines besseren belehrt worden
:-) , das ist doch sinn dieses newsletters oder ?(siehe oben). nützlich
finde ich die routinen des patch trotzdem... ;-)
ich weiss noch nichts über den bootloader, da ich mich damit noch
nicht beschäftigt habe. wenn ich ihn benutze zum prg aufspielen, wird
dann auch das eeprom gelöscht??? ich spiele meine prg noch mit
ponyprog auf und muss dann mit write data (eeprom) nach dem prg auch
das eeprom neu aufspielen. das eeprom ziehe ich nach dem kalibrieren
natürlich ab (im bin format) und kann diese datei dann auch im
sim-bot benutzen. sie muss nur in dem pfad stehen, der in
parameter-low_pc.c steht.
Kann ich die EEPROM-Variablen im Code mit Initialisierungen versehen
und diese ins EEPROM übertragen (per Programmer)?
ich verstehe die frage nicht ganz. die initialisierung ist auch beim
mein patch wie gehabt. wenn im kode eine eeprom-variable erstellt wird,
werden deren werte im eeprom abgelegt. ich ziehe mir das eeprom erst
nach dem erstellen der stütztabellen im bin-format ab, dann kann ich sie
mit hex-editor bearbeiten oder sie im sim nutzen.
meine frage hast du aber nicht beantwortet. wird beim aufspielen eines
programmes mit den bootloader das eeprom gelöscht (wie es beim
aufspielen mit ponyprog ohne bootloader geschied)???
mit freundlichen grüssen
achim pankalla
.
|
|
|