STM32 mit QtCreator

[Matthias W. (mathew5392)]

Guten Tag

Im Rahmen meines Studiums habe ich eine Einführung in die 
Programmiersprache C erhalten. Bisher habe ich ausschliesslich "Desktop" 
Anwendungen programmiert.

Dies mit folgender Umgebung:
- Debian GNU/Linux 9 (stretch)
  - GNOME v 3.22.2
- Qt 5.7.1 (x86_64-little_endian-lp64 shared (dynamic)
- GCC

Damit war ich sehr glücklich. Nun haben wir mit der Programmierung von 
Mikrocontrollern begonnen. Dies unter dem wohl bekannten W****** 
Betriebssystem und der IDE KEIL uVision5. Leider entspricht diese IDE 
gar nicht meinen Wünschen und ich würde gerne weiter mit QtCreator 
programmieren.

Deshalb habe ich mich auf die Suche nach passenden Lösungen gemacht.
Nach einiger Zeit konnte ich das Nucelo F446re Board mit Hilfe des 
folgenden Beitrages programmieren und debuggen:
http://brightened.ir/post/deploy-stm32-on-qtcreator/

Leider setzt diese Lösung auf die Verwendung des "Hall-Wizzards" 
STM32CubeMX. Da wir aber in der Vorlesung die "stm standard peripheral 
library" verwenden nützt mir die beschriebene Lösung nur wenig. (Und ja 
ich weiss, dass die SPL keine Unterstützung für die neueren Controller 
bietet)

Deshalb frage ich mich ob es nicht möglich ist ein leeres QtCreator 
Projekt zu erstellen, natürlich mit den geeigneten 
Build-Konfigurationen, um mit Hilfe von qMake ein Makefile zu erzeugen. 
Und die SPL als #include dem Projekt hinzu zu fügen.

Hat jemand von Euch Erfahrungen in der Verwendung von QtCreator mit 
STM32 Controllern? Ich bin froh um jeden Input.

Vielen Dank für Eure Anregungen
Beste Grüsse
Matthias

[Markus F. (mfro)]

QtCreator kann prima mit externen Makefiles umgehen.

Einfach das Projekt soweit bringen, dass es mit "make" auf der 
Kommandozeile compilierbar wird (brauchst Du ja nur einmal zu machen, 
das Makefile lässt sich für neue Projekte ja ganz einfach kopieren und 
anpassen).

Ich arbeite so (sehr zufrieden) seit Jahren mit Kinetissen und anderen.

Auf die Weise bist Du von der IDE unabhängig und hast Projekte, die sich 
z.B. auch auf einem Headless-Server oder Mac OS X problemlos bauen 
lassen (natürlich brauchst Du da die arm-none-eabi Toolchain, aber auch 
die ist verfügbar).

[Matthias W. (mathew5392)]

Hallo Markus

Danke für deine rasche Antwort.
Was du beschrieben hast, mache ich mehr oder weniger bereits mit der 
Erwähnten Methode über CubeMX und der arm-none-eabi Toolchain. Wie du 
beschrieben hast, ist es allerdings notwendig das Makefile für jede 
Erweiterung durch .c/.h Files zu erweitern/anzupassen.
Da Qt für die Erstellung des Makefiles bereits ein nützliches Tool 
bietet, frage ich mich ob die ganze "Projektverwaltung" nicht über das 
Qt eigene .pro File möglich ist.

[Markus F. (mfro)]

Hallo Matthias,

auch das geht: hier gibt's ein Beispiel (nicht von mir), wie man das für 
AVR macht: Beitrag "Qt Creator IDE für AVR Entwicklung nutzen"

[Christopher J. (christopher_j23)]

Hallo Matthias,

ich benutze selber auch QT-Creator mit ganz normalen Makefiles und zwar 
mit verschiedenen Architekturen, also nicht nur STM32 bzw. ARM sondern 
z.B. auch ESP32. Funktioniert soweit alles prima. Wenn du ein normales 
Makefile nutzt musst du auch nicht jede Datei einzeln zu einem Projekt 
hinzufügen. ST macht das lediglich so bei deren generierten Makefiles, 
weil sie es halt ohnehin aus einem Template generieren. Von Hand will 
man das natürlich nicht machen aber es geht auch komfortabler.

Als Beispiel mal angenommen du hast folgende Verzeichnisstruktur:

.
├── foo
│   ├── bar
│   │   ├── bar_src1.c
│   │   └── bar_src2.c
│   ├── baz
│   │   ├── baz_src1.c
│   │   ├── baz_src2.c
│   │   └── baz_src3.c
│   ├── foo_src1.c
│   └── foo_src2.c
└── Makefile

Jetzt gibt es verschiedene Möglichkeiten.

Die Variante die du meinst ist wohl

C_SRC = foo/foo_src1.c foo/bar/bar_src1.c foo/bar/bar_src2.c foo/baz/baz_src1.c etc

Das ist natürlich viel zu viel unnötiges Geschreibsel und geht einfacher 
mit Wildcards, z.B.

z.B.

FOO_SRC = $(wildcard foo/*.c)
# i.e. FOO_SRC = foo/foo_src1.c foo/foo_src2.c

BAR_SRC = $(wildcard foo/bar/*.c)
# i.e. BAR_SRC = foo/bar/bar_sr1.c foo/bar/bar_src2.c

BAZ_SRC = $(wildcard foo/baz/*.c)
# i.e. BAZ_SRC = foo/baz/baz_src1.c foo/baz/baz_src2.c foo/baz/baz_src3.c

C_SRC = $(FOO_SRC) $(BAR_SRC) $(BAZ_SRC)

Aber auch das ist noch zu viel und geht viel eleganter mit $(foreach), 
z.B.

C_SRC_DIRS = foo foo/bar foo/baz
C_SRC = $(foreach $(DIR), $(C_SRC_DIRS), $(wildcard $(DIR)/*.c))
# für die Beschreibung von $(foreach) siehe unten den Link zum Make-Manual

Mit Wildcards kann man übrigens auch auf Verzeichnisse matchen, d.h.

SUBDIRS = $(wildcard */) # ist in diesem Falle nur foo
SUBSUBDIRS = $(wildcard */*/) # ist in diesem Falle foo/bar und foo/baz
# SUBSUBDIRS würde aber nicht foo/baz/bazinga enthalten, falls baz einen solchen Unterordner hätte.

Darüber hinaus kann man mit $(shell find ...) so ziemlich alles finden, 
was es auf einem Rechner gibt. Mal angenommen man möchte den Ordner foo 
und alle seine Unterordner, dann kann man statt

C_SRC_DIRS = foo foo/bar foo/baz foo/baz/bazinga

auch einfach folgendes schreiben.

C_SRC_DIRS = $(shell find foo -type d)

Bei find kann man auch noch mit -mindepth und -maxdepth arbeiten, z.B. 
wäre das folgende äquivalent zu dem Beispiel oben mit $(wildcard)
SUBDIRS = $(shell find . -maxdepth 1 -type d) # in diesem Falle nur foo
SUBSUBDIRS = $(shell find . -mindepth 2 -maxdepth 2 -type d) # = foo/bar 
foo/baz

Eine sehr gute Übersicht mit kurzen und knackigen Beispielen hat meiner 
Meinung nach das alte(!) Make-Manual 
ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_8.html

Auch wenn ich davon ausgehe, dass du die Grundlagen von Make kennst, 
möchte ich hier mal noch auf zwei Makefile-Tutorials hinweisen, die mir 
selber den Einstieg sehr erleichtert haben:
http://www.jfranken.de/homepages/johannes/vortraege/make_inhalt.de.html
http://www.ijon.de/comp/tutorials/makefile.html

[Markus F. (mfro)]

Das Makefile die Quelldateien selbst einsammeln lassen kann man machen, 
ich halte es allerdings nicht für eine gute Idee. Vielleicht liegt das 
aber auch an meinem eher "kreativen" (man könnte auch sagen: 
schlampigen) Arbeitsstil.

Ich will eben gerade nicht, dass das Makefile "jeden Müll" compiliert, 
der im src Directory gerade so rumliegt, sondern nur das, was ich 
explizit dazupacken will. Die dafür notwendige zusätzliche Schreibarbeit 
nehme ich gerne in Kauf.

P.S.: dein C_SRC_DIRS kannst Du durch eine VPATH-Pfadliste ersetzen. So 
faul bin ich dann doch auch wieder ;)

[Christopher J. (christopher_j23)]

Die Brootforce-Methode halte ich auch für eine ganz schlechte Idee :D
Natürlich verliert man bei Wildcards etwas an Granularität aber mir ging 
es nur darum zu zeigen, dass man auch ordnerweise Dateien hinzufügen 
kann und da nicht jede einzelne Datei von Hand reintippen muss.
Das könnte man Beispielsweise für den SPL-Ordner so machen. Was nicht 
benutzt wird sollte man mit --gc-sections beim Linken sowieso 
rausschmeißen. Wenn man qmake benutzt müsste man ja z.B. auch alle nicht 
benutzten SPL-Dateien aus dem Projekt entfernen (und ggf. wieder 
hinzufügen wenn man sie dann doch braucht) damit diese nicht bei jedem 
Rebuild wieder neu kompiliert werden.