Category: Embedded Systems

Experimente mit STM32 BluePill und libopencm3

Heute habe ich an einem Resturlaubstag mal ein bisschen mit meiner STM32 BluePill experimentiert.

Leider hat es einiges länger gedauert, als ich dachte.

Zunächst habe ich mir aktuelle Versionen von OpenOCD und den freien ST-Link Tools gebaut und installiert. Das funktionierte auch ohne Probleme.

Die ST-Link Tools bringen sogar eine GUI mit GTK3 mit. Leider kann das Tool nur Binärdateien auslesen und programmieren, aber es ist immerhin etwas bedienerfreundlicher als die Kommandozeilenvariante.

Danach habe ich mal die libopencm3 compiliert. Das ging auch gut, aber es gibt leider keine Installationsoption. Also muss man in die Projekte das jeweilige Verzeichnis entsprechend reinverdrahten.

Ich habe auch die offiziellen Beispiele mal übersetzt. Zumindest das Systicker Blink, USB HID und USB COM Port Beispiel für STM32L1 habe ich mit meiner BluePill zum Laufen bekommen.

Danach habe ich mir die Infrastruktur für eigene Projekte bauen wollen und bin beinahe gescheitert. Aus einigen Quellen musste ich mir Teile zusammenklauen, aber ich kann jetzt über CMake entsprechende Projekte aufsetzen, die die libopencm3 benutzen.

Das ganze habe ich im Visual Studio Code aufgesetzt und wollte dann die Debugerweiterung für Cortex-M benutzen und bin wieder gescheitert.

Nach langem Puzzeln habe ich gemerkt, daß mein gdb zu alt ist. Dann musste ich mir erstmal eine aktuelle Version bootstrappen.
Kurzentschlossen wollte ich die offizielle ARM Toolchain installieren, aber das waren 0,5GB Download. Das war mir doch zu riesig, also habe ich einen offiziellen gdb runtergeladen und mit einer kleinen Anleitung auch gebaut.

Mit dieser gdb Version konnte ich dann aber tatsächlich debuggen und mit .svd File auch die Peripherieregister anschauen.

Gelernte Punkte habe ich gleich mal in einer Wissenssammlung aufgeschrieben. Die werde ich vermutlich zukünftig noch erweitern und ggfs ergänzen.

Eigentlich wollte ich noch ein Beispiel mit Segger RTT ausprobieren, bin aber nicht mehr soweit gekommen.

STM32 “Blue pill” mit SEGGER Embedded Studio

Ich wollte mal SEGGER Embedded Studio ausprobieren, nachdem ich im Büro schon mit meinen Kollegen darüber gesprochen hatte.
Unter Linux stellt diese IDE auf jeden Fall eine gute Möglichkeit dar, für STM32 basierte Controller Software zu entwickeln, z.B. die “Blue Pill”.

Bislang habe ich nackte Makefiles und Eclipse probiert. Letzteres ist langsam und das Debuggen war damit nicht so gut verwendbar.

Die SEGGER IDE lies sich leicht installieren, die Installation benötigt leider root Rechte mit sudo, zumindest für udev Konfiguration für einen J-Link.
Wenn man das optional weglassen könnte, wäre das von Vorteil.

Die IDE präsentiert sich mit QT Oberfläche und ist flott und responsiv.

Positives:

  • gute Reaktionszeit
  • Debugger kann Controllerregister inklusive Peripherie darstellen
  • Debugger unterstützt SEGGER J-Link sowie GDB basiertes Debuggen mit OpenOCD
  • Installation nach /opt oder dgl möglich
  • bringt Compiler und Linker mit
  • Projektkonfigurator für Baremetal Devices
  • Plugins und Herstelersupport für definierte Controller und Familien nachinstallierbar
  • Crossplattform

Negatives:

  • kein Import von Makefileprojekten
  • Sortierung der Fenster und Reiter ist etwas unübersichtlich

Insgesamt aber besser als Eclipse und eine händische Umgebung.

Um via ST-Link v2 mit OpenOCD zu debuggen, habe ich mein Projekt im SEGGER Embedded Studio dann wie folgt konfiguriert:

  • “Debug > Debugger” auf “GDB Server” einstellen
  • “Debug > GDB Server für OpenOCD konfiguriert wie im Screenshot

[OpenOCD Konfiguration für die STM32 Blue Pill im SEGGER Embedded Studio]
OpenOCD Konfiguration für die STM32 Blue Pill im SEGGER Embedded Studio
Dann started OpenOCD automatisch im Hintergrund und man kann debuggen.

Ich bin bislang nur auf ein Problem gestossen, wenn ich die STM32 HAL für die Blue Pill benutzen möchte. Wenn ich das komplette .a File dazulinke, wird leider auch das komplette File eingebunden. Der GNU Linker im Makefile nimmt nur die Teile die nötig sind, da muss ich noch rausfinden, wie ich das SEGGER Embedded Studio dazu bekomme, nur das zu linken, was benötigt wird.

SNES2DB9 Arduino Prototyp

Seit ein paar Wochen arbeite ich an einem kleinen Mikrocontrollerprojekt.
Zum letzten Summer Games in Atzenhofen hatte ich für Janina vergessen, ein passendes Gamepad zum C64 mitzubringen. Mit einem klassischen Joystick kann sie nicht so recht zocken und bevorzugt Gamepads. Die Sega Pads funktionieren nur wackelig und teilweise und am C64 teils garnicht.

SNES2DB9 Arduino Prototyp am Atari STE
SNES2DB9 Arduino Prototyp am Atari STE

Zunächst wollte ich nur eine neue Leiterplatte entwerfen, mit der man ein USB Joypad auf den DB9 Joystickanschluß von Atari anpassen konnte. Das erschien mir ein wenig zu ambitioniert, also entschied ich mich, einen aktiven Konverter auf mit Arduino als Basis zu entwerfen. Ich entschied mich für die SNES Controller mit Schieberegister, da dies leicht abzufragen ist und die Handhabung der SNES Controller bei meiner Zielgruppe bekannt sind.

Heute habe ich meinen Prototypen dann mal am Atari STE ausprobiert, und ich muss sagen, es läuft. Es fehlen noch ein paar Feinheiten, Autofeuer, Springen mit Feuerknopf statt hoch, aber prinzipiell liest der Arduino den SNES Controller korrekt und mit ca 60Hz aus und bedient die Signalleitungen zum DB9 Joystickport entsprechend. Die Schaltung ist auch ziemlich einfach, mehr oder minder direkt verdrahtet, wobei ich dem Latch und Clock zum SNES Controller noch Pulldown, bzw Pullupwiderstände verpasst habe. Auch lassen sich Arduino und SNES Controller komplett über die 5V vom Joystickport versorgen.

Eine komplette Version mit eigenständigen Controller auf Basis eines ATTiny mit 14 Pin ist in Planung.

Quellcodes und Dokumentation werde ich recht bald bei Github unter MIT Lizenz verfügbar machen.

STM32 HAL Library für die “Blue pill”

Seit einiger Zeit kann man die sogenannte “Blue Pill” kaufen. Dies sind Mikrocontroller aus der STM32 Familie mit Cortex Kern, konkret STM32F103C8 mit Cortex M3, die auf einem schönen klassischen DIL-Träger aufgelötet sind mit Pinheader und Micro-USB zur Stromversorgung ausgerüstet sind. Dadurch passt alles in ein Steckbrett und kann auch als Arduino betrieben werden.

Ich habe mir ein paar Exemplare beschafft und möchte diese natürlich mehr oder minder “bare metal” benutzen, ähnlich wie ich das im Beruf auch tue. Dort arbeite ich seit gut 7 Jahren ebenfalls mit STM32 Controllern.

ST Microelectronics stellt eine recht gute Bibliothek zum Ansprechen der Controllerperipherie zur Verfügung. Damit man diese nicht immer mit jedem noch so kleinen Projekt von Null auf übersetzen muss, habe ich mir mit CMake ein kleines Framework geschrieben, welches die Library für den konkreten Controller der “Blue Pill” als Binary übersetzt.

Ausprobiert habe ich die Library noch nicht, aber es baut und linkt. Eigentlich müsste das schon reichen, das .a File wird im neuen Projekt referenziert und der Includepfade zu der Headern der HAL Library mitangegeben.

Der Anwender muss ggfs. die STM32 Header für den Controller in seinem Projekt referenzieren, denn einige Headerfiles der HAL Library ziehen die controllerspezifischen Header nochmal rein.

Näheres und technische Updates gibt es auf der Projektablage bei Github:
https://github.com/simonsunnyboy/stm32hal_bluepill

Ich habe den heute aktuellen Stand der HAL Library eingebunden, speziell den vom CubeMX angelegten, STM32Cube_FW_F1_V1.8.0.

Atari Joystick mit DB9 Anschluss an PC per USB anschliessen

Um klassische Joysticks nach Atari Standard mit DB9 Anschluß an moderne PCs anschließen zu können, benötigt man Adapter.
Solche gibt es als freie Designs zum Nachbauen, aber selten fertig zu kaufen. Sie enthalten meist einen kleinen Microcontroller, häufig AVR oder PIC, etwas “Hühnerfutter” drumrum und stellen PC seitig eine HID konforme Schnittstelle bereit.

Bei Ebay und anderen Shops tauchen ab und an fertig kaufbare Geräte auf. Diese braucht man in der Regel nur anschließen und gängige Betriebssysteme listen danach einen neuen Joystickanschluß auf.

Ich besitze aktuelle mehrere solcher Adapter. Bei einem konnte ich über eine in der Firmware hinterlegte URL auch eine Bezugsquelle in Kanada ausmachen. Zwar nicht die günstigste Variante, aber immerhin eine Möglichkeit, einen solchen Adapter zu beschaffen. Meinen hatte ich bei Ebay gefunden.

URL: http://www.retronicdesign.com/

Auszug aus meinem Linux Kernel Log beim Einstecken:

[ 5870.324066] usb 1-5.1.3: new low-speed USB device number 9 using xhci_hcd
[ 5870.453974] usb 1-5.1.3: New USB device found, idVendor=1781, idProduct=0a99
[ 5870.453980] usb 1-5.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5870.453982] usb 1-5.1.3: Product: Retro Joystick Adapter v2.0
[ 5870.453984] usb 1-5.1.3: Manufacturer: retronicdesign.com
[ 5870.453986] usb 1-5.1.3: SerialNumber: 3292
[ 5870.462639] input: retronicdesign.com Retro Joystick Adapter v2.0 as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.3/1-5.1.3:1.0/0003:1781:0A99.0008/input/input17
[ 5870.520437] hid-generic 0003:1781:0A99.0008: input,hidraw5: USB HID v1.01 Joystick [retronicdesign.com Retro Joystick Adapter v2.0] on usb-0000:00:14.0-5.1.3/input0

ATtiny85 per Drahtverhau ausgelesen

Ich habe heute mal endlich ein wenig in meiner Bastelkiste gewühlt. Bis heute war ich mir nicht sicher, ob man AVRs wirklich mit wenig Aufwand direkt im Steckbrett programmieren kann. Ich habe es einfach mal selbst ausprobiert und einen ATtiny85 mit ganzen 8 Pins mehr oder minder direkt mit meinem mySmartUSB light Programmiergerät verbunden.

Ich habe den 6 auf 10Pin Adapter missbraucht, um einfach Steckbrücken mit Buchsen auf die Pins zu stecken. Dabei habe ich mich an ein Schemabild aus dem Netz gehalten und dabei eine möglichst ähnliche Farbcodierung verwendet. Auf meinem Steckbrett musste ich dann nur die Buchsen auf Pins abbilden und gemäß Datenblatt die Pins am Microcontroller mit den jeweiligen Signalen verbinden.

Danach habe ich einfach mal per avrdude Inhalte gelesen und geschrieben. Flash und Fuses funktionierten prächtig, beim EEPROM hatte ich mein Problem. Eventuell kommt mir da die EESAVE Fuse ins Gehege. Ich plane am langen Wochenende (morgen habe ich Urlaub) ein Testprogramm für den ATtiny85 zu schreiben, bei dem ich mal im EEPROM per Programm schreibe und lese.

Insgesamt, ja, es funktioniert. Ich konnte den Chip im Steckbrett ohne spezielle Hardware auslesen und programmieren.

ATtiny85 mit fliegender Verdrahtung im Steckbrett
ATtiny85 mit fliegender Verdrahtung im Steckbrett

Arduino Sketch zum Auslesen des EEPROM Inhaltes

Um mein mySmartUSB light Programmiergerät zu verifizieren, habe ich folgenden Arduino Sketch ausprobiert. Der Arduino zeigt damit seinen EEPROM Inhalt in HEX Notation in der seriellen Konsole an.

/* Display EEPROM contents from Arduino UNO
 * (c) 2014 by Matthias Arndt
 */
#include <EEPROM.h>

void setup()
{
  uint16_t addr = 0;
  uint8_t c;
  uint8_t nl = 0;

  Serial.begin(9600);
  Serial.print("Arduino EEPROM contents:\n\n");

  while(addr < 1024)
  {
    c = (EEPROM.read(addr) & 0xFF);

    addr++;

    Serial.print(c, HEX);
    Serial.print(' ');

    if(nl < 31)
    {
      nl++;
    }
    else
    {
      Serial.print('\n');
      nl = 0;
    }

  }

}

void loop()
{
  for(;;);
}

mySmartUSB light – Programmiergerät für AVRs im USB Stick Format

mySmartUSB light - Programmiergerät für AVRs
mySmartUSB light - Programmiergerät für AVRs

Irgendwann im letzten Jahr stolperte ich beim Recherchieren über das mySmartUSB light Programmiergerät für AVRs. Laut der Dokumentation und Beschreibung sollte es problemlos auch unter Linux funktionieren.

Bei einem moderaten Preis um 20€ habe ich es mir dann als Ergänzung zu meinem ähnlich preiswerten Pollin Evaluationboard gekauft.

Das Gerät kommt als kleiner USB Stick daher, hat einen Anschluss für das 6polige ISP Kabel und kann kleinere Systeme auch problemlos über USB mit Saft versorgen.

Ausprobiert habe ich den Stick kurzerhand mit meinem Arduinoboard, allerdings nur lesend. Der Arduino bringt den 6poligen Sockel direkt mit, so daß das Programmiergerät direkt passt. Unter Linux wurde mir direkt ein neuer USB COM Port angezeigt und verfügbar gemacht.

Anschließend habe ich AVR8 Burn-O-Mat benutzt, avrdude auf STK500v2 Protokoll und die USB Schnittstelle eingestellt, und es hat auf Anhieb funktioniert, ich konnte den Flashinhalt des Arduinos direkt auslesen. Im Binärvergleich mit dem Arduinoprotokoll und dem Arduino direkt stimmt das FLASH überein, beim Auslesen des EEPROMs gab es Diskrepanzen, das neue Gerät zeigt ein leeres Eeprom, während mit dem Arduinoprotokoll Inhalte übertragen werden. Auch die Fuses konnte ich nur mit dem neuen Gerät und STK500V2 Protokoll korrekt auslesen. Da muss ich in jedem Fall mal mit einem leeren ATmega16 oder dgl experimentieren, vllt. hat das arduino Bootloaderprotokoll Besonderheiten oder meine avrdude Version ist zu alt.

Unter Windows muss man wohl erst einen USB Treiber installieren, aber ich gehe davon aus, daß das Gerät dort genauso und ohne Macken funktioniert.

Für 10polige Sockel gibt es wohl ein offizielles Adapterkabel, bzw ein Wechsler, der von 10 auf 6 und 6 auf 10 Pole umschaltet. Beide Formate sind in jedem Fall von Atmel standardisiert.

In jedem Fall für Embedded Entwickler, die AVRs per ISP programmieren, ein nützliches und preiswertes Gadget für den kleinen Erste Hilfe Koffer.

Mehr zum Gerät, u.a. Downloads unter http://shop.myavr.de/Topseller/mySmartUSB%20light.htm?sp=article.sp.php&artID=200006

AVR, JTAG and externel reset

Today at the office I learned a nice trick that might become handy for other AVR users.

A times a target system with AVR microcontroller exhibits an accessibility problem. The system features an ATmega644PA microcontroller unit which is debugged via JTAG interface. The board can only be flashed via JTAG if the external reset is triggered properly.

In an AVR Studio project the system can be told to enable the external reset over the wiring but access without the project over the Atmel JTAGICE MKII programmer fails. How to place the thing in reset condition so JTAG can take over?

The trick came from one of our electronics gurus who simply asked: “Can’t you short the reset and make it work?” We simply tried and yes this works. Ofcourse the flashed firmware does not boot if RESET is tied to GND but JTAG access works. The device can be flashed, fuses set and read and maybe debugging works too (we didn’t try that).

So basically if you try to access an AVR mcu with JTAG interface and no backup such as SPI, try tying the RESET line to GND. I simply made a little wire bridge shorting pins 6 (RESET) with 2 (GND) on the 10pin JTAG cable. I plug the main cable in the left socket on the programmer cable and put the bridge in the second socket whichs is probably wired in parallel. It worked well for us today!