Zweiter Test mit ARM-Board

Hier der zweite Test mit dem frisch gelöteten ARM-Board mit dem STM32F4 STMicroelectronics und dem komplett neu geschriebenen Code. Die Software läuft hier komplett auf dem Roboter unter Linux, so wie er später selbstständig „durch die Gegend“ fahren soll:

 

Heute über 47 commits!

Es geht voran um die Tests zusammen mit dem neuen ARM-Board und der vorhandenen direcs-Software laufen zufriedenstellend. Wie es aussieht, wird der Roboter einwandfrei erkannt und auch das „Lesen“ der Sensorwerte (A/D-Wandler bzw. Akkuüberwachung) funktionieren wie gewünscht.

Für die Ansteuerung der RGB-LEDs wurde eine komplett neue Klasse erstellt um die alten Servo-Funktionen nicht mehr zu nutzen. Hier ein Überblick über die Änderungen allein von heute:

 direcs-avrsim/src/simulationThread.cpp |    4 +
 direcs-avrsim/src/simulationThread.h   |    1 +
 direcs/bin/direcs.ini                  |   18 ++
 direcs/src/circuit.cpp                 |   15 +-
 direcs/src/circuit.h                   |    2 +
 direcs/src/direcs.cpp                  |  317 +++++++++++++++++---------------
 direcs/src/direcs.h                    |   21 ++-
 direcs/src/direcsSerial.cpp            |   21 ++-
 direcs/src/direcsSerial.h              |    8 +-
 direcs/src/gui.h                       |   12 +-
 direcs/src/inifile.cpp                 |    6 -
 direcs/src/interfaceAvr.cpp            |   31 ++--
 direcs/src/interfaceAvr.h              |   16 +-
 direcs/src/motor.cpp                   |   85 +++++----
 direcs/src/motor.h                     |   13 ++
 direcs/src/rgbLed.cpp                  |  183 ++++++++++++++++++
 direcs/src/rgbLed.h                    |  138 ++++++++++++++
 direcs/src/sensorThread.cpp            |   56 +++---
 direcs/src/sensorThread.h              |    8 +-
 direcs/src/servo.cpp                   |    9 +-
 direcs/src/servo.h                     |    1 +
 direcs/src/src.pro                     |    4 +-
 test/src/test.cpp                      |  166 +----------------
 test/src/test.h                        |   24 +--
 24 files changed, 711 insertions(+), 448 deletions(-)
 create mode 100644 direcs/src/rgbLed.cpp
 create mode 100644 direcs/src/rgbLed.h

Erster Test mit ARM-Board

Hier nun endlich der erste große Test mit dem frisch gelöteten ARM-Board mit dem STM32F4 STMicroelectronics und dem komplett neu geschriebenen Code. Es ist eigentlich selbsterklärend:

Nicht im Video gezeigt ist das Abfragen der Werte der A/D-Wandler. Hier werden die beiden Akku-Spannungen überwacht, also die 12 und die 24 Volt. Die Abfrage erfolgt wie im Video zum Beispiel mit dem Befehl *s7# (Sensor 7). Die Antwort lautet dann z.B. *4095* bei einem vollen Akku (13,2 Volt). Nett, oder?

 

Letzter Schritt vor Atmel-Austausch?

Nachdem nun bereits PWM sicher auf dem Atmel-Nachfolger STM32F4 funktioniert, wurde als nächstes der AD-Wandler implementiert. Hier galt es den Spannungsteiler anzupassen, damit das STM-Board nicht mehr als 3,3 Volt an den Eingangs-Pins erhält – und natürlich überhaupt den Code für den AD-Wandler für den ARM-Prozessor zu implentieren. Eine Besonderheit dabei ist DMA (Direct Memory Access).

Der STM32F4-Prozessort unterstützt mehrere DMA-Streams mit jeweils mehren Kanälen. Das bedeutet, man gibt in seinem Sourcecode unter anderem eine Speicheradresse innerhalb der CPU an, die sozusagen direkt mit dem Inhalt einer Variable verbunden wird. Das heißt, man aktiviert zum Programmstart einmalig die AD-Wandlung die danach kontienuierlich im Hintergrund läuft, ohne Interrupt, while-loops oder ähnliches. Der aktuelle Wert der Analog-Digital-Wandlung liegt jederzeit abrufbereit in der gewünschten Variable. Und durch DMA auch noch ohne die CPU zu belasten! Man kann sich an dieser Stelle durchaus fragen, warum Leute noch Atmel-Prozessoren verwerden…

Ach so, die Wandlung wird auf dem Roboter benötigt, um die Akku-Spannungen zu überwachen. Das heißt, die 24 Volt und die 12 Volt gehen „in den Spannungsteiler hinein“ und landen dann zum Messen am Pin des STM42F4-AD-Wandlers.

Hier wie immer die Fotos der Tests. Als erstes das übliche Steckbrett mit einer der zu überwachenden Spannungen (hier 24 Volt):

Hier das „Ergebnis“ wie es „in den Port“ des AD-Wandlers rein geht (wie gesagt, nicht mehr als 3,3 Volt!):

 
In diesem Bild sieht man, dass es 2,85 Volt für den AD-Wandler ergibt. Hintergrund ist, dass zwei 12 Volt-Blei-Gel-Akkus eine Spannung >24 Volt aufweisen. Darum wurde der Spannungsteiler so gewählt, dass maximal 25 Volt am Eingang anliegen, welches im Programm dann dem Dezimalwert 4095 entspricht.

Als letztes noch die verwendete Schaltung (leider etwas unscharf) mit Z-Diode zum Schutz des Ports:

Test der RGB-LEDs mittels PWM

 Nachdem die Motoren des Roboters erfolgreich mit dem noch recht neuen STM-Board über PWM angesteuert wurden, musste nun noch ein Test mit den RGB-LEDs erfolgen. Hier war nicht die Frage, ob PWM funktioniert, sondern viel mehr, ob die 3,3 Volt Pegel einwandfrei mit den Optokopplern funktionieren. Die Optokoppler sind nämlich hier nötig, da die RGB-LED-Streifen mit 12 Volt angesteuert werden. Das Ergebis war aber erfreulich:

  

Übrigens die im Bild verwendeten Kabel zum Verbinden des STM-Boards habe ich bei Watterott bestellt.

Und wen es interessiert, wie die LED-Streifen angesteuert werden:

Motortest mit STM-Board über die serielle Schnittstelle

 Mittlerweile wurde der Sourcecode vervollständigt, um alle vier Motoren per PWM und mit den jeweiligen Portbits anzusteuern. Hierzu die Fotos wo die Ansteuerung über den seriellen Port erfolgt:

Hier im linken Bild rechts unten sieht man die (rote) Platine, welche die USB-Verbindung zum steuernden Rechner darstellt. Von hier aus werden (gerade in einem Terminal-Programm) die seriellen Befehle gesendet. Das USB-Kabel am STM-Baord dient nur zur Stromversorgung (und zum Flashen):

   

PWM Ergänzung

 Hier noch ein paar ergänzende Fotos zum hier beschriebenen PWM-Test mit dem STM32F4 DISCOVERY Board:

    

Kleiner Tipp noch für das Testen: Es schadet nicht, die verschiedenen Spannungen an den Kabeln zu beschriften.

 

Abschließend möchte ich hier noch ergänzen, dass es mir nicht gelungen ist, die Timer 1 und Timer 8 (TIM1 & TIM8) sowie die Timer 9 bis 14 bei gleichem Sourcecode dazu zu bewegen, die gleiche PWM-Frequenz auszugeben. Aus einem mir noch nicht klaren Grund, waren diese Timmer immer doppelt so schnell. Es funktionierte nur mit den „General-purpose timers (TIM2 to TIM5)“ einwandfrei. Die erste Vermutung, dass es teils 32-Bit- und teils 16-Bit-Timer bestätigte sich nicht. Wenn jemand einen Tipp hat, gerne als Kommentar hinterlassen!

Erste Tests mit dem STM-Board und dem Roboter

 Die Arbeit mit dem STM-Board macht Fortschritte: Beim letzten Update wurde der Code für das ARM-Board derart aktualisiert, dass 2 Bits als Ausgänge definiert wurden. Diese wurden in fliegender Verdrahtung mit einander verbunden, so dass die Eingänge des Motorcontrol-Boards direkt am STM32F4-Board angeschlossen wurden. Interessant ist hierbei, dass das Motor-Board – entgegen den 3,3 Volt des STM-Boards –  5 Volt-Logik aufweist. Das geht jedoch in dieser Richtung, da die 3,3 Volt (HIGH) am Ausgang auch als HIGH vom Motorcontroll-Board akzeptiert werden weil sie innerhalb der Spezifikation liegen. Und so sieht das Ganze dann aus:

Nun wurde das das STM-Board per USB mit dem MacBook verbunden, ein Terminal-Programm gestartet, welches Befehle an das STM-Board sendet:

   

 

 
Und: Es fuktioniert! Der Motor 1 dreht in beide Richtungen entsprechend der seriellen Befehle – wie zuvor mit dem Atmel-Board. Und im Sourcecode wurden lediglich die neuen ARM-Ports angegeben und die Befehle zum Bit-Setzen und -Löschen angepasst. Als nächstes muss geprüft werden, wie bei dem ARM-Board PWM funktioniert, damit z.B. die Motorgeschwindigkeit Richtung Motorcontrol-Board „gesendet“ werden kann.
 
Das Gute an dem Motorcontrolboard: Die benötigte PWM-Spannung Vpwh kommt hier ebenfalls mit 3,3 Volt klar (min. 3,25 Volt). Die Versorgungsspannung des verwendeten Motortreiber ICs VNH2SP30-E benötigt jedoch mindestens 5,5 Volt und maximal 16 Volt – aber diese stehen auf dem Bot ja ohne weiteres zur Verfügung.

Neues STM32F4 Discovery Board

Wie auch in der aktuellen Ausgabe meines Robotik-Podcasts Robotiklabor berichtet, gibt es mit dem derzeitigen Atmel-Board ja immer Probleme mit der Kommunikation über die serielle Schnittstelle, genauer, dem USB-Port. Um hier auch einmal neue Wege zu gehen, wurde mir das STM32F4 Board von STMicroelectronics empfohlen.

Bestellt wurde es vorgestern bei Watterott für schlappe 16,66 EUR zzgl. Versand – kaum vergleichbar mit dem derzeitigen Atmel 2560-Board, welches ca. 60 EUR kostete. Nach etwas Ärger mit DHL erreichte mich das Board glücklicherweise dann doch bereits heute, so dass ich hier schon einmal ein erstes Video zeigen möchte:

STM-Board – Erster Test

Hier noch ein Auszug der STMicroelectronics-Seite mit den Hauptmerkmalen des Boards:

  • STM32F407VGT6 microcontroller featuring 32-bit ARM Cortex-M4F core, 1 MB Flash, 192 KB RAM in an LQFP100 package
  • On-board ST-LINK/V2 with selection mode switch to use the kit as a standalone ST-LINK/V2 (with SWD connector for programming and debugging)
  • Board power supply: through USB bus or from an external 5 V supply voltage
  • External application power supply: 3 V and 5 V
  • LIS302DL, ST MEMS motion sensor, 3-axis digital output accelerometer
  • MP45DT02, ST MEMS audio sensor, omni-directional digital microphone
  • CS43L22, audio DAC with integrated class D speaker driver
  • Eight LEDs:
    • LD1 (red/green) for USB communication
    • LD2 (red) for 3.3 V power on
    • Four user LEDs, LD3 (orange), LD4 (green), LD5 (red) and LD6 (blue)
    • 2 USB OTG LEDs LD7 (green) VBus and LD8 (red) over-current
  • Two push buttons (user and reset)
  • USB OTG FS with micro-AB connector
  • Extension header for all LQFP100 I/Os for quick connection to prototyping board and easy probing

Und noch ein paar Fotos: