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 :-)
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.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.
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 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)???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)?
mit freundlichen grüssen achim pankalla .