Serielle Übertragungen vom STM-Board zum Computer über USB

Es geht voran mit dem STM32F4-Discovery Board!

Um es vorweg zu nehmen: Die folgende serielle Übertragung geschieht nicht über die bereits auf dem STM-Board verbauten USB-Ports. Nach Studium diverser Threads im Internet erwarb ich ein neues IC, welches in der Lage ist, den seriellen Port des ARM-Prozessors (USART) in einen USB-Port zu wandeln. 

Das Ganze ist auf einem sogenannten Breakout-Board von Sparkfun gleich praktisch fertig verlötet, man muss nur noch Stiftleisten hinzufügen. Zum Einsatz kommt hier der Baustein FTDI232R, der keine weiteren Bauteile mehr benötigt und auch gleich mit den 3,3 Volt Logiklevel des STM-Boards klar kommt. Entgegen dem Datenblatt von FTDI müssen bei der Verbindung zwischen dem Breakoutboard drei Leitungen verlötet werden: TX mit RX und RX mit TX und natürlich die gemeinsame Masse, GND. Wer will könnte auch noch gleich zwei Hardware flow control Leitungen mit anschließen – beide Boards unterstützen dieses. So sieht die Testverbindung dann mit den Steckern aus:

 

Hier das Breakout-Board mit dem FTDI-Chip und der USB-Buchse (rechts, mit oranger Schutzfolie) noch einmal im Detail:

  

Und so wird das Ganze dann zum Testen angeschlossen: Das schwarze USB-Kabel, welches zum STM-Board führt, dient hier nur zum flashen des selbigen und zur Stromversorgung. Das transparente USB-Kabel, welches zum FTDI-Board geht, ist das Kabel, welches dann zum PC oder Mac geht. Wird dieses dann angeschlossen, erscheint z.B. unter Linux und Mac OS X ein Device namens /dev/tty.xxxxx bzw. /dev/ttyUSBx. Beim Mac enthält „xxxxx“ gleich eine einmalige Seriennummer. Bestellt hattee ich das Board übrigens bei Watterott (ca. 14 EUR).

  

Hier sind beide Boards dann mal zum Testen am „PC“ des Roboters angeschlossen:

 

Später sollen dann die Daten vom PC des Roboters zum STM-Board (über den FTDI-Chip) und zurück fließen. Diese Aufgabe übernimmt derzeitnoch ein Atmel-Board mit einem Atmega 2560. Tipp: Auf dem STM-Board gibt es diverse USART, wovon aber einige bereits z.B. durch den vorhandenen USB-Port belegt sind! Ich habe mich daher für den noch freien USART2 entschieden.

 

Montage des Commel Pico ITX Boards, der Festplatte und der WLAN-Antenne

Nachdem das neue Pico-ITX Board von Commel; das 170G nun "verkabelt" wurde,

   

ging es an die Montage des Boards auf dem Roboter. Verbaut wurde es an die gleiche Stelle, an der zuvor der fit-PC2 war:

   

Hierzu wurde es wie bewährt auf die Profilschienen geschraubt:

  

Wie man an den Detailfotos sieht, wird das Board mit Kunststoffmuttern und -unterlegschreiben auf den Distanzbolzen festgehalten, damit hier keine besonderen Masseschleifen o.ä. entstehen. Das Kabel rechts im Bild mit den freien Kontakten am Pfostenstecker geht übrigens zum Ein-Aus-Schalter auf dem Bedienpanel:

   

Um nun die 2,5" Festplatte zu befestigen, bedurfte es Distanzbolzen mit sehr kurzem Gewinde. Diese wurden kurzerhand mit einer Schleifmaschine gekürzt. Tipp dazu: Vor dem Kürzen eine passende Mutter auf das Gewinde schrauben, damit man hinterher ggf. die verbleibenden Grate leichter beim Lösen der Mutter "wegdreht" [And always wear safety glasses!]:

    

Und nun die Montage der Festplatte und ein paar verschiedene Blickwinkel:

          

Nun noch die WLAN-Antenne montiert, die übrigens samt mini-PCI-Karte noch aus dem defekten fit-PC2 stammt:

    

Und noch mal im Ganzen fotografiert:

  

 

Und nun am Roboter montiert:

         

Ein abschließender Test durfte nicht fehlen:

     

PS.: Die Kabel am Mainboard sind natürlich erst provisorisch und müssen noch "verlegt" werden. Und ja, der rote Text im letzten Foto zeigt leider noch eine Fehlermeldung vom Laserscanner. Irgendwie bringt dieser unter Linux – aber nur unter Linux – noch Fehlermeldungen und bricht dann ab. Da ist noch Forschungsarbeit zu leisten.

Fotos vom neuen Commel Pico ITX Board

Hier ein paar aktuelle Fotos vom neuen ein Pico-ITX Board von Commel; das 170G, welches das neue "Herz" des Roboters direcs1 werden soll. Erste Tests liefen bereits erfolgreich, ein Debian brachte alle Treiber out-of-the-box mit, so dass auch die KDE ebenfalls korrekt mit passendem Grafikkartentreiber lief. Aber hier nun erstmal die Fotos:

      

Hier noch einmal im Größenvergleich mit dem defekten fit-PC2:

    

Hier liegt neben dem neuen Pico-ITX-Board die "alte" Mini-PCI-WLAN-Karte aus dem fit-PC2:

 

Und so sieht das ganze verkabelt und angeschlossen aus – mehr Kabel als Board  :

   

3D-Kompass-Modul-Verbindung wird geprüft und in GUI angezeigt

Beim Testen des Atmelboards außerhalb des Roboter fiel auf, dass es manchmal bei der seriellen Übertragung nach einiger Zeit timeouts gab. Die Ursache lag im Atmelcode für den Micromag 3D-Kompass. Dieser initialisiert beim ersten Start des Atmels das SPI / I²C Protokoll. Danach fragt das direcs-Hauptprogramm den Atmel nach den Kompassdaten. Ist das Kompassmodul aber nun gar nicht mit dem Atmelboard verbunden, so kommt es zu den timeouts, da im SPI-Code auf bestimmte Bitzustände gewartet wird.

Um dieses zu verhindern und hiermit auch eine weitere Sicherheit einzubauen, wird nun beim Abfragen der Kompasswerte jedesmal geprüft, ob ein bestimmtes Portbit gesetzt ist. Dieses Portbit ist durch einen 100k-Widerstand am Atmelboard standardmäßig auf Masse gezogen. Wird das Kompassmodul nun per Falchbandkabel angesteckt, wird diese Leitung vom Kompassmodul aus auf 5V "hoch gezogen". 

Bei der Initialisierung des Atmelboards bzw. der Prüfung ob der Roboter eingeschaltet ist im direcs-Hauptprogramm, wird nun auch zusätzlich abgefragt, ob das Kompassmodul verbunden ist. Dieses wird auch in der GUI grafisch mit einer weiteren LED (rechts oben im Bild) angezeigt.

Atmel-Board gar nicht verbunden (Kompass damit natürlich auch nicht):

Atmel-Board verbunden, Kompassmodul nicht angeschlossen:

Atmel-Board verbunden, Kompassmodul ebenfalls angeschlossen: