michael-fauth.de

Entwicklungsarbeiten im Berech eingebetteter Systeme geraten meistens schnell ins Stocken sobald Probleme mit externer Peripherie auftreten. In diesen Fällen hilft das Debugging des Mikrocontrollers/Prozessors nur bedingt, denn oft sind die Probleme elektronischer Natur und können mit dem Debugger nicht oder nur schwer gefunden werden. Solche Probleme können von einer unsauberen Versorgungsspannung, über falsch dimensionierte Pullup Widerstände, bis hin zu kalten Lötstellen reichen.

In all diesen Fällen ist es extrem hilfreich ein Oszilloskop zur Verfügung zu haben. Da mein altes, analoges Oszilloskop in der Vergangenheit vermehrt für Frust gesorgt hat, musst endlich ein neues, digitales Speicheroszilloskop her.

Da mittlerweile die Portierung auf den STM32 abgeschlossen ist, war zeitgleich auch eine neue Benutzeroberfläche fällig. Wie anhand der Bilder unschwer zu erkennen ist, läuft die Software jetzt unter Windows. Als Entwicklungsumgebung kommt Visual Studio 2010, und als Sprache C# zum Einsatz. Man verzeihe mir die lustige Sprachmischung, ich kann mich oft einfach nicht zwischen Deutscher und Englischer Namensgebung entscheiden :D

Hier ein paar Eindrücke der neuen Software, deren Umfang jedoch noch recht bescheiden ist.

Die Kommunikation erfolgt über einfache ASCII Befehle wie sie unten in der Console beispielhaft zu erkennen sind. Das vereinfacht das Debuging enorm, da jeder Befehl zumindest für mich weitgehend selbsterklärend ist. Die Software setzt jeden Befehl lediglich in eine passende ASCII Repräsentation um, die gesamten Berechnungen finden dann lokal im Bot statt.

Pünktlich zu den Semesterferien gibt es mal wieder etwas neues zu berichten. Der Bot ist nun in der Lage, einen geneigten Untergrund zu erkennen, und dabei den Körper immer horizontal, bzw. in einer beliebigen Lage zu halten. Da Bilder, bzw. ein Video ja bekanntlich mehr sagen als 1000 Worte, werde ich mich an dieser Stelle kurz fassen ;)

Leider hat sich in letzter Zeit immer mehr herausgestellt, dass die Lösung mit dem IGEPv2 einige Probleme mit sich bringt. In erster Linie bereitet die Anbindung an den CAN Bus Schwierigkeiten. Den Flaschenhals stellt hierbei die Verbindung des IGEPv2 mit dem CAN Adapter dar. Diese Schlüsselstelle läuft über einen UART und ein selbst entwickeltes Protokoll. Leider macht es sowohl auf der Seite des Linux Boards, als auch auf dem CAN Adapter große Probleme, die harten Ansprüche an das Timing einzuhalten. Gleichzeitig verfügt der CAN Adapter mit seinem Mega8 nur über begrenzen Speicher, was die Pufferung der CAN und der UART Kommunikation extrem erschwert.

Des weiteren habe ich diverse Probleme mit der Linux Programmierung, bisher habe ich zum erstellen der Grafischen Benutzeroberfläche das GTK Toolkit verwendet. Anfangs war dies ideal, da ich schnell zu recht guten Ergebnissen gekommen bin. Eine ansprechende Visualisierung von Messwerten hat sich aber beispielsweise als extrem aufwändig erwiesen. Somit ist auch hier ein wechsel der Umgebung naheliegend.

Auch kann ich zwischenzeitlich die Hardware Anforderungen der IK recht gut abschätzen, und habe mich daher für eine Betriebssystemlose Controller Lösung entschieden. Diese hat den großen Vorteil, das ich sowohl Hard- als auch Software von Grund auf selbst entwickeln kann, und somit alles selbst in der Hand habe ohne mich beispielsweise auf seltsame Linux-UART Bibliotheken verlassen zu müssen und bei der Fehlersuche zu verzweifeln.