Absender: Achim Pankalla
Datum: Do, 29.03.2007 22:40:37
In-reply-to:
<03FA8E8E-224D-4E27-A1A6-2899A0C20B7B@xxxxxxxxxxxxxxx>
References:
<460BFC4D.5030809@xxxxxx> <03FA8E8E-224D-4E27-A1A6-2899A0C20B7B@xxxxxxxxxxxxxxx>
Timo Sandmann schrieb:
das macht mich ja auch stutzig, habe ganze zeit gesucht, worans liegen könnte, habe aber so nichts gefunden, vielleicht bin ich auch betriebsblind und kann es deshalb nicht finden. deshalb ja auch dieser hilferuf....Hi, Am 29.03.2007 um 19:50 schrieb Achim Pankalla:das problem muss im mouse kode des pc liegen, den ohne mouse-messung läuft der bot korrekt mit bot_turn im labyrinth. der reale bot muss auch korrekt arbeiten, da er ja nur 16bit uint's zu haben scheint.also das Problem mit bot_turn() kann ich so nicht nachvollziehen, außerdem rechnet das doch mit signed-ints?!
diese mail habe ich ganz übersehen :-[ . werde ich mir nochmal zur gemüte führen. danke für den hinweis...meine frage nun, woran scheiterts und wieso wurde uint16, im gegensatz zu int16, über den umweg eines define und typedef konstuiert?Das ist eine gute Frage, ich wäre ja prinzipiell für int8_t, uint8_t, int16_t, uint16_t usw. aus stdint.h, die sollten immer so groß sein wie erwartet. Ich habe allerdings keine Lust den kompletten Code darauf umzustellen... ;)Bei den eep-Dateien hatte ich eher das Problem mit dem Alignment, siehe eMail vom 9.3.2007, 17:44. Ebenso ist der erwartete Name der eeprom-Section wohl architekturabhängig, steht aber auch in der genannten eMail, am besten von vornherein berücksichtigen, dass man das an zentraler Stelle im Code anpassen kann.
Mit den dumps stimmt aber irgendwas nicht, da sind nicht nur nullen dazwischen: Mal sind in der .eeprom-Section 13 und mal 15 Bits gesetzt... o.OGruß Timo _______________________________________________ ct-bot-entwickler Mailingliste ct-bot-entwickler@xxxxxxxxxxxxxxxxx http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler