Absender: Timo Sandmann
Datum: Do, 29.03.2007 20:38:53
In-reply-to:
<460BFC4D.5030809@xxxxxx>
References:
<460BFC4D.5030809@xxxxxx>
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?!
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.O
Gruß Timo