c't Projekte - c't-Bot und c't-Sim - Mailinglisten
Absender: Timo Sandmann
Datum: Mi, 25.02.2009 01:29:14
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo,da es in letzter Zeit einige Updates im ct-Bot-Code gab, hier eine kleine Zusammenfassung und ein paar Erklärungen dazu:
- - Unterstützung für ATmega644PWird ein ATmega644 oder ATmega644P eingesetzt, unterstützt der Code jetzt auch eine Taktfrequenz von 20 MHz (in bot-local.h einstellen!). Größter Vorteil: Schnellere Kommunikation mit einer MMC / SD-Karte. Beim Steuercode bringt es nicht ganz so viel, weil recht häufig per delay() auf andere Komponenten gewartet wird.
- - Bugfix fuer map_get_ratio() und map_way_free(), Map-Visualisierung um Debug-Funktion zum Einzeichnen von Linien erweitert. Neu sind vor allem die Funktionen map_draw_line() und map_draw_rect(), wenn MAP_2_SIM_AVAILABLE an ist. Näheres in den Funktionsbeschreibungen in map.h/.c
- - Maustreiber überarbeitet, einheitliche Bezeichner MOUSE_ (statt MAUS_) eingeführt - - Pos-Store um pos_store_insert() ergänzt zum Einfügen von Daten vorne (Gegenteil zu push) - - Dokumentation zum Verhalten bot_drive_area() (Documentation/ drive_area.html)
- - Command-Code optimiert Daten werden direkt als Argumente übergeben (nicht mehr als Zeiger) - - Bugfix für HW-SPI und MOUSE_AVAILABLE (#180) siehe Ticket #180 - - SPI-Code unterstützt verschiedene Geschwindigkeiten- - Verhalten bei Abgründen korrigiert, werden auch wieder in die Map eingetragen Funktioniert auch wieder auf dem echten Bot, geänderte Verhaltensprioritäten
- - Map-2-Sim auch für den echten BotIst aber noch experimentell und die Anzeige besitzt derzeit eine recht große Verzögerung
- - Code in ct-bot.c aufgeräumt Hauptschleife ist wieder etwas übersichtlicher geworden- - Mini-OS (OS_AVAILABLE) verbessert, fest definiertes Zeitverhalten, Bot-Hauptschleife wird alle 10 ms durchlaufen, umfangreiche Debugmöglichkeiten ergänzt Sensorauswertung und Aufruf der Verhalten erfolgt jetzt auch beim echten Bot alle 10 ms, genau wie im Sim. Zu Debugzwecken lässt sich ausgeben, wann zu welchem Thread gewechselt wurde, außerdem ist es möglich die Stacks der Threads ausgeben zu lassen (very low level Debugging!)
- - Neues Verhalten bot_get_utilization() misst die CPU-Auslastung, während ein anderes Verhalten aktiv ist Das Verhalten wird mit der Priorität eines anderen Verhaltens aufgerufen (z.B. 150 für bot_turn) und wartet anschließend, bis dieses Verhalten aktiv wird. Dann misst es regelmäßig (standardmäßig alle 25 ms), wie groß die CPU-Auslastung ist und gibt diese Informationen nach Abschluss des zu überwachenden Verhaltens aus. Nur auf MCU, weil uninteressant für PC. Sehr nützlich um zu sehen, was man der Bot-CPU wann noch zumuten könnte.
- - Senden über UART flusht den Sendepuffer nicht mehr komplett, sondern wartet nur bis genug Platz für die zu sendenden Daten und schaltet während dessen auf einen anderen Thread um Vorteil: 1. Senden von wenig Daten wartet bei vollem Puffer nicht mehr, bis dieser komplett leer ist, was hier gar nicht erforderlich wäre. 2. Falls z.B. noch ein Map-Update aussteht, wird dieses während des Wartens fortgeführt.
- - Display mit CPU-Auslastung des Bots, zeigt auch UART-Auslastung anDer zugehörige Display-Screen heißt DISPLAY_OS_AVAILABLE. Es wird die CPU-Auslastung als Balken (jeweils ein Feld für 5 Prozentpunkte) und als Zahlenwert angezeigt. Dabei handelt es sich um die Durchschnittliche Auslastung der letzten 100 ms. Die UART-Auslastung zeigt an, zu wie viel Prozent des letzten Zeitfensters (100 ms) das UART aktiv war. Außerdem lassen sich auf diesem Display mit den Tasten 1 bis 3 die Stacks zur Anzeige an den Sim senden (s.o.). Taste 4 schaltet die Ausgabe der Threadwechsel an und aus (falls OS_KERNEL_LOG_AVAILABLE in include/os_thread.h an ist), Vorsicht viel Daten (200 bis 300 Zeilen pro Sekunde)!
Einige der beschriebenen Dinge sind im "Normalbetrieb" sicherlich nicht weiter interessant (insbesondere der ganze OS_-Debugging-Spaß), da dazu aber noch einiges an Dokumentation fehlt, habe ich das hier mal mit aufgeführt, vielleicht interessiert es den ein oder anderen ja doch.
Viel Spaß beim Testen. Grüße, Timo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkmkkNkACgkQDH/BX4067fKDBACfSvqGx1owPgNoMDeJxe+J6EUI T1QAoKuxrYA9g8Cl1gSIH55uRsm7zWgZ =n3L3 -----END PGP SIGNATURE-----