STM32 C Programmierung Tutorial (Buch)

O je, Diller... da schreibt mal wieder einer zu allererst sowas:
" 1. IDE, Programmer & Eval-Boards"

Wenn ich so eine Herangehensweise sehe (zuerst ne IDE, dann ein 
Evalboard mit ST-Link drauf, dann der Rest der Welt), dann dreht sich 
mir der Magen herum.

Nein, solche Herangehensweise ist so ziemlich das Verkehrteste, wenn man 
etwas lernen will. Aber danach hast du "ich" ja garnicht gefragt, 
sondern:

Ich schrieb:
> ... Tutorial/Buch zur STM32 Programmierung in C

OK, wenn du also nur lernen willst, wie man die STM32 mit einer in C 
geschriebenenen Firmware versieht, dann kannst du dir die o.g. Seite 
durchlesen und am besten ausdrucken. Dann exakt 1:1 nachmachen und 
fertig.

Aber wenn du etwas lernen willst und eigene Fähigkeiten entwickeln, dann 
gehe lieber ganz anders heran:

- Zu allererst solltest du dich damit abfinden, englische Texte zu 
lesen. Es gibt fast nichts anderes. Ist eben so, also klag nicht drüber

- Dann sollest du mal querbeet diverse C-Quellen und was einfaches an 
C-Tutorials dir anschauen und dir dabei C beibringen. Da wirst du als 
erstes genug Frust kriegen. Zum einen wegen der Sprache als solcher, zum 
anderen wegen der ganz häufig miserabel geschriebenen Quellen, wo sich 
viele darin üben, möglichst "genial", also unverständlich oder maßlos 
über-verkompliziert und newdenglish zu schreiben.

- Selber solltest du beim Schreiben deiner Quellen von allem 
Schnickschnack absehen, den du nicht UNBEDINGT benötigst. Also schreib 
du lieber bieder und auch ne Zeile mehr, das ist auf lange Sicht besser 
weil klarer.

Negativbeispiel der klassischen Art gefällig:
 while(*d++=*s++);
Man kann sowas auch ausführlich hinschreiben und den Compiler die 
Optimierung machen lassen.

- Dann solltest du dir die Manuals und die Referenzmanuals zu 
verschiedenen Chips aus der Arm/Cortex-Klasse anschauen. Und zwar von 
Chips verschiedener Hersteller, nicht bloß von ST. Lies dir auch mal die 
Referenzmanuals zu den verschiedenen CPU-Varianten (Cortex M0, M0+, M3, 
M4F) durch. Bei alledem brauchst du nicht jede einzelne Zeile auswendig 
zu lernen, hier geht es erstmal nur um den Überblick und den Eindruck, 
den du von CPU und dem anderen Zeugs auf dem Chip gewinnst. Es geht aber 
auch darum, einen Eindruck von den Manuals als solchen zu gewinnen. 
Nicht jeder mag jeden Stil. Ich z.B. habe sehr etwas gegen die Manuals 
von Freescale, die gehen mir auf den Keks. Aber das muß jeder selbst für 
sich entscheiden.

- Dann besorgst du dir ein Minimalboard für den Chip, den du dir 
inzwischen ausgesucht hast. Sowas wie die billigen Bluepill- Brettln aus 
China sind da erstmal am besten. Es ist fast nix drauf, was dich 
ansonsten bei all den Evaluation-Boards stören würde, du kommst an fast 
alle Pins heran und es ist auch noch billig. Aber guck lieber mal über'n 
Tellerrand, so z.B. bei NXP (LPCxxxx), Nuvoton und wenn du willst auch 
Texas und Atmel und Freescale (via NXP). Merke dir dabei, daß STM32 
nicht das Maß aller Dinge sind, insbesondere stört mich bei denen, daß 
die Peripherie immer noch ziemlich weitgehend nur 16 bittig ist. Da sind 
andere viel besser.

- Dann installierst du dir erstmal eine Toolchain deiner Wahl. Wer mit 
Linux lebt, der nimmt den Gcc, wer Windows hat, hat die Wahl zwischen 
Keil, IAR und Gcc. Vom Keil und vom IAR gibt es frei benutzbare 
Bastlerversionen, die bis zu 32K Code können. Laß dich davon nicht 
abschrecken, es gibt ne Menge Chips, wo garnicht mehr Flash drauf ist 
und mit der Codequalität vom Keil kommt der Gcc nicht mit.

- So, und dann lerne erstmal, deinen 
Compiler+Assembler+Linker+Fromelf+Programmiertool zu Fuß aufzurufen, 
also von der Kommandozeile. Nicht verständnislos gucken, das ist wichtig 
um es können zu können und eben nicht vom Gewurschtel einer IDE 
sklavisch abhängig zu sein. Wer das kann und sich gegebenenfalls ne 
kleine .bat oder ein Script selber schreiben kann, der kann dann auch ne 
IDE benutzen und selbige wieder wegschmeißen, wenn sie ihm in die quere 
kommt, ohne dann aufgeschmissen zu sein.

Und nochwas: Am lautesten schreien viele Leute nach dem Debugger. 
Insbesondere diejenigen, die nicht gründlich denken und ihren Code 
sauber strukturieren können oder wollen. Ich halte den Debugger für 
zweitrangig, das Verstehen der Hardware und das "biedere" Formulieren 
der Programmquellen ist viel wichtiger. Dann kommt man übrigens bei 
vielen Chips auch mit dem dort eingebauten residenten Bootlader aus und 
benötigt dafür eben kein besonderes Debug-Geschirre wie diversen -Link's 
(JLink, STLink, LpcLink oder weiß der Geier-Link). Und wenn schon, dann 
ist der JLink noch immer das Maß der Dinge.

W.S.

Da du schon Vorkenntnisse hast brauchst du meiner meinung nach nicht 
mehr als eine kleine Einstiegshilfe und die Datenblätter des 
Herstellers.

Schau mal: http://stefanfrings.de/stm32/index.html

> Ich halte den Debugger für zweitrangig, das Verstehen der Hardware
> und das "biedere" Formulieren der Programmquellen ist viel wichtiger.

Dito. Wobei der Debugger bei STM32 (im Gegensatz zu AVR) fast verschenkt 
wird.

Es wäre vielleicht auch ganz hilfreich, die Programmiersprache C erstmal 
auf einem PC ganz ohne Mikrocontroller zu lernen. Dazu könntest du QT 
Creator herunterladen und einfach loslegen. Tutorials dazu gibt's ja 
genug.

Die Anleitungen von Diller beziehen sich auf die veraltete und schon 
lange nicht mehr gepflegte Standard Peripheral Library. Aktuell ist aber 
die Cube HAL. Ich würde zum Lernen aber erstmal auf solche 
Abtraktions-Libraries verzichten, und wirklich mit Datenblatt und 
Registern auf Bit-Ebene arbeiten. Das ist am Ende meiner Meinung nach 
kaum schwerer, als durch die HAL durchzusteigen.

Hier ist auch was: 
https://www.amazon.de/Joseph-Yiu/e/B001IQWINC/ref=dp_byline_cont_book_1

Eins der Bücher gibt's kostenlos hier: 
https://www.eecs.umich.edu/courses/eecs373/labs/refs/M3%20Guide.pdf

Der Mann beschreibt allerdings nur den ARM Kern. Mit dem Buch alleine 
kann man noch nichts anfangen. Ich kann es allerdings als Begleitlektüre 
zur Doku von STM sehr empfehlen.

> da kommt es auf ein paar Takte wirklich nicht mehr an

Richtig. Aber es kommt darauf an, die Dokumentation der HAL zu lesen und 
zu verstehen.

Ich persönlich beschäftige mich lieber zuerst mit dem Datenblatt des µC 
und dem Reference Manual der Serie.

Aber das ist Geschmackssache.

W.S. schrieb:
> - So, und dann lerne erstmal, deinen
> Compiler+Assembler+Linker+Fromelf+Programmiertool zu Fuß aufzurufen,
> also von der Kommandozeile. Nicht verständnislos gucken, das ist wichtig
> um es können zu können und eben nicht vom Gewurschtel einer IDE
> sklavisch abhängig zu sein. Wer das kann und sich gegebenenfalls ne
> kleine .bat oder ein Script selber schreiben kann, der kann dann auch ne
> IDE benutzen und selbige wieder wegschmeißen, wenn sie ihm in die quere
> kommt, ohne dann aufgeschmissen zu sein.

Prinzipiell stimme ich Dir zu, dass das nützliche Kenntnisse sind, auf 
die leider zu wenig wert gelegt wird. Allerdings halte ich es für gewagt 
das alles gleich am Anfang zu lernen. Da kann schnell die Lust vergehen.

Marc V. schrieb:
> HAL macht das alles per Mausclick und zwar ohne Fehler.

Aktuelles Cube für STM32F407VG => USB Audio Device in Cube 
zusammenklicken.
Fehler. Der Code Generator vergisst ein oder (|) bei der Initialisierung 
der Clocks. Soviel zu "ohne Fehler"...

Marc V. schrieb:
> Arbeiten auf Bitebene ist erstens für normale Programmierer unnötig
>  und zweitens ist das bestimmt schwerer und die Möglichkeit einen Fehler
>  zu machen oder etwas wichtiges zu vergessen (Clock einschalten z.B.)
>  ist ungefähr 1:100.

Das würde ich nicht sagen. Gerade am Anfang kann es sinnvoll sein, recht 
tief anzusetzen. Man muss sein Linkerskript ja nicht gleich am Anfang 
selbst schreiben. Aber die Peripherie der STMs ist in der Regel recht 
ausführlich im Reference Manual beschrieben. Da er bereits AVRs 
programmiert hat, sollte er also mit Datenblättern zurechtkommen.

Ich würde am Anfang, wenn STM, auf ein STM32F4 discovery setzen. Da ist 
einige Hardware drauf, um einfache Anfänge zu starten und es sind noch 
genug Pins herausgeführt, um eigene Hardware anschließen zu können. 
Programmer/Debugger ist  on-board.
Für den STM32F407 gibt es ebenfalls noch das Clock Config Tool, das 
leider in Excel mit Macros geschrieben ist.

http://www.st.com/en/development-tools/stsw-stm32091.html

Das generiert registerbasierten Code, der leicht eingebunden werden 
kann.

> HAL macht das alles per Mausclick und zwar ohne Fehler.

Als ich Cube HAL vor ein paar Monaten zum ersten mal benutzte, hat er 
glatt die Clock Initialisierung so falsch gemacht, dass sich der µC 
dabei aufhängte. Da brauchte ich schon ganz zu Beginn Hilfe von den 
Profis. Und genau das war bei mir der Auslöser, es mal ohne HAL zu 
versuchen. Dabei bin ich bisher geblieben, außer wenn ich USB benutze. 
Das ist mir dann ohne fertige Libs doch eine Nummer zu hoch (noch).