Das erste Projekt: “Blinky” auf dem STM32 Nucleo-Board

Das erste eigene Embedded-Projekt ist oft der Moment, in dem aus Theorie echte Praxis wird – und genau dafür ist ein Blinky auf dem STM32 Nucleo-Board ideal. Eine LED blinken zu lassen klingt banal, ist aber ein perfekter Einstieg, weil Sie dabei die komplette Toolchain einmal „durchlaufen“: Board anschließen, Debug-Schnittstelle nutzen, ein STM32-Projekt anlegen, Code kompilieren, Firmware flashen und anschließend im Debugger prüfen, ob Ihr Programm tatsächlich so läuft wie gedacht. Zusätzlich lernen Sie typische Begriffe kennen, die Ihnen später ständig begegnen: GPIO (General Purpose Input/Output), Takt/Delay, Debug-Session, Breakpoints, sowie die grundsätzliche Projektstruktur in STM32CubeIDE. Gerade mit einem STM32 Nucleo-Board haben Einsteiger einen großen Vorteil: Der ST-LINK-Debugger ist in der Regel bereits integriert, die Boards sind sehr gut dokumentiert, und viele Beispiele sind direkt verfügbar. In diesem Praxis-Tutorial bauen Sie Schritt für Schritt Ihr erstes „Blinky“-Projekt auf – so, dass es nicht nur funktioniert, sondern auch sauber aufgebaut ist und sich später problemlos erweitern lässt.

Was Sie für das Blinky-Projekt benötigen

Für den Start brauchen Sie erstaunlich wenig, wenn Sie bewusst auf ein typisches Nucleo-Setup setzen. Wichtig ist nicht, möglichst viel Zubehör zu sammeln, sondern eine stabile, reproduzierbare Umgebung zu schaffen.

• STM32 Nucleo-Board (beliebiges Modell, z. B. NUCLEO-F401RE, NUCLEO-L476RG oder ein ähnliches Board).
• USB-Kabel (möglichst hochwertig, Datenkabel – nicht nur Laden).
• Windows, macOS oder Linux – dieses Tutorial orientiert sich an STM32CubeIDE, unabhängig vom Betriebssystem.
• STM32CubeIDE als Entwicklungsumgebung.
• Optional: STM32CubeProgrammer als separates Flash-/Diagnose-Tool, hilfreich bei Debug-Verbindungsproblemen.

Offizielle Einstiegsseiten, falls Sie Board und Tools noch auswählen oder vergleichen möchten, sind die Übersicht zu STM32 Nucleo Boards sowie die Produktseite von STM32CubeIDE.

Board anschließen und Grundcheck: So vermeiden Sie typische Startprobleme

Bevor Sie überhaupt ein Projekt anlegen, sollten Sie das Board einmal sauber anschließen und prüfen, ob Ihr System es erkennt. Viele „mysteriöse“ Fehler sind in Wahrheit nur ein ungünstiges USB-Kabel, ein instabiler Hub oder ein Treiberproblem.

• Verbinden Sie das Nucleo-Board über den ST-LINK USB-Port (meist als ST-LINK beschriftet) mit Ihrem PC.
• Achten Sie darauf, dass das Board mit Strom versorgt wird (Status-LEDs sollten leuchten).
• Verwenden Sie nach Möglichkeit keinen passiven USB-Hub, sondern einen direkten Port am Rechner.

Unter Windows ist es sinnvoll, im Geräte-Manager zu prüfen, ob das ST-LINK-Gerät ohne Warnsymbol erscheint. Falls Treiber fehlen, stellt ST offizielle ST-LINK-USB-Treiber bereit: ST-LINK USB driver (STSW-LINK009).

Projektanlage in STM32CubeIDE: Der schnellste stabile Weg

Für das erste Blinky-Projekt gibt es mehrere Wege. Der pragmatischste für Einsteiger ist: Projekt anhand des Boards anlegen, damit Pinout, Takt und LED-Pins sofort korrekt vorbelegt sind. In STM32CubeIDE können Sie häufig nach Board-Namen suchen und das passende Nucleo-Modell auswählen.

• Starten Sie STM32CubeIDE und wählen Sie File > New > STM32 Project (oder eine vergleichbare Option).
• Wählen Sie den Reiter Board Selector und suchen Sie nach Ihrem Nucleo-Modell.
• Bestätigen Sie die Auswahl und legen Sie einen Projektnamen fest, z. B. Nucleo_Blinky.
• Wählen Sie einen Workspace-Pfad mit kurzen Ordnernamen (keine OneDrive-Synchronisation, keine sehr tiefen Verzeichnisse).

Beim ersten Anlegen kann STM32CubeIDE nach Einstellungen für Code-Generierung fragen (z. B. ob peripheriebezogene Initialisierung generiert werden soll). Für Einsteiger ist es sinnvoll, die Standardvorschläge zu übernehmen, weil sie einen sauberen Projektaufbau und eine stabile Startkonfiguration liefern.

Die Onboard-LED finden: Warum „LD2“ nicht immer gleich ist

Fast jedes Nucleo-Board hat eine Onboard-LED, häufig als LD2 beschriftet. Wichtig: Der konkrete GPIO-Pin hängt vom Board ab. Manche Nucleo-Boards nutzen z. B. PA5 (klassisch bei vielen Nucleo-64), andere nutzen einen anderen Pin. Statt zu raten, sollten Sie die LED-Zuordnung sauber nachsehen.

• Prüfen Sie das Board-User-Manual oder das Pinout-Diagramm des Boards.
• In STM32CubeIDE (bzw. der integrierten CubeMX-Ansicht) können Sie im Pinout die LED oft direkt erkennen.

Für Einsteiger ist es hilfreich, die offizielle Board-Seite zu öffnen und dort User Manual und Pinout zu nutzen. Starten Sie dazu über die Nucleo-Übersicht: Nucleo Boards – Dokumente und Ressourcen.

Variante 1: Blinky mit HAL (einfach und sehr verbreitet)

Die HAL (Hardware Abstraction Layer) ist für Einsteiger die komfortabelste Methode. Sie nutzen dabei eine klare API, die die Registerdetails kapselt. Das ist ideal, um schnell produktiv zu werden und die Toolchain zu verstehen.

GPIO als Output konfigurieren

Öffnen Sie in der Projektansicht die Konfigurationsoberfläche (CubeMX-Teil in STM32CubeIDE). Suchen Sie den Pin der Onboard-LED (z. B. PA5) und setzen Sie ihn auf GPIO_Output. Übliche Einstellungen:

• Mode: Output Push-Pull
• Pull-up/Pull-down: No Pull (in vielen Fällen)
• Speed: Low oder Medium (für LED reicht Low)

Speichern Sie die Konfiguration und lassen Sie den Code neu generieren, falls die IDE dazu auffordert. Danach existiert in Ihrem Projekt eine initialisierte GPIO-Konfiguration.

LED im Hauptprogramm toggeln

In STM32CubeIDE finden Sie üblicherweise eine Datei wie main.c mit einer Endlosschleife. Dort fügen Sie im „User Code“-Bereich die Toggle-Logik ein, damit Ihre Änderungen bei erneuter Code-Generierung nicht überschrieben werden. Typisches Prinzip:

• LED-Pin toggeln
• kurz warten
• wieder toggeln

Wenn Ihr Projekt HAL nutzt, sieht der Kern der Logik oft sinngemäß so aus: LED toggeln via HAL-Funktion und Verzögerung über eine Delay-Funktion. Der genaue Funktionsname und das Pin-Handle hängen von Ihrer Konfiguration ab. Achten Sie darauf, dass Sie ausschließlich in den vorgesehenen USER CODE-Bereichen arbeiten.

Variante 2: Blinky ohne Delay-„Magie“ (Timer-basiert, professioneller)

Viele erste Blinky-Beispiele arbeiten mit einer blockierenden Delay-Funktion. Das ist für den Einstieg in Ordnung, aber es ist gut zu verstehen, was dahinter passiert: Eine blockierende Verzögerung hält die CPU an und verhindert, dass Sie nebenbei andere Aufgaben erledigen. Für professionellere Firmware ist ein Timer- oder Interrupt-basiertes Konzept später meist sinnvoll.

Warum Timer-basierte Zeitsteuerung besser skaliert

• Nebenläufigkeit: Andere Aufgaben können laufen, während die Zeit „vergeht“.
• Determinismus: Zeitpunkte lassen sich präziser steuern, besonders bei vielen Tasks.
• Erweiterbarkeit: Aus Blinky wird später oft Sensor-Sampling, Kommunikation und Logging.

Wenn Sie später auf Timer umsteigen, ist ein guter Start, einen Periodic-Interrupt (z. B. 1 Hz) zu konfigurieren, der die LED toggelt, während die Hauptschleife frei bleibt. Für das erste Projekt reicht jedoch häufig die HAL-Variante, solange Sie den Unterschied im Hinterkopf behalten.

Build, Flash und Debug: So bringen Sie die Firmware aufs Board

Jetzt kommt der wichtigste Moment: Kompilieren, flashen, starten. Gehen Sie dabei systematisch vor, um Fehler schnell eingrenzen zu können.

• Klicken Sie auf Build (Hammer-Symbol) und prüfen Sie, ob der Build ohne Errors durchläuft.
• Starten Sie Debug (Käfer-Symbol), damit die IDE die Firmware automatisch auf das Board schreibt und eine Debug-Session startet.
• Wenn die IDE fragt, ob sie in die Debug-Perspektive wechseln soll, bestätigen Sie dies.

In einer typischen Debug-Session sehen Sie:

• Programmfluss im Quellcode
• Register- und Variablenansichten
• Breakpoints
• Peripherie-/SFR-Ansichten (je nach IDE-Konfiguration)

Breakpoints setzen: Der schnellste Realitätscheck

Setzen Sie einen Breakpoint in der Endlosschleife und starten Sie das Programm. Wenn der Breakpoint getroffen wird, wissen Sie: Flash, Reset, Start und Debug-Handshake funktionieren. Danach lassen Sie das Programm weiterlaufen („Resume“) und beobachten die LED. Dieser Schritt klingt klein, spart aber enorm Zeit, weil Sie sofort eine stabile Basis nachweisen.

Die Blinkfrequenz gezielt einstellen: Rechnen statt Raten

Für ein Blinky ist es hilfreich, die Blinkfrequenz bewusst zu wählen. Wenn Sie beispielsweise möchten, dass die LED genau einmal pro Sekunde umschaltet (also 0,5 Sekunden an, 0,5 Sekunden aus), können Sie die Periodendauer direkt ableiten. Für eine einfache, blockierende Delay-Variante gilt sinngemäß: Delay entspricht der gewünschten Zeit zwischen zwei Zustandswechseln.

Wenn Sie die Frequenz $f$ (in Hz) in eine Periodendauer $T$ (in Sekunden) umrechnen möchten, nutzen Sie:

$T=\frac{1}{f}$

Für eine LED, die einmal pro Sekunde ihren Zustand wechselt (Toggle), ist $f=1$ und damit $T=1$ Sekunde zwischen zwei Toggles. Wenn Sie hingegen „einmal pro Sekunde blinken“ als vollständigen Zyklus (an+aus) interpretieren, wäre die Toggle-Periode 0,5 Sekunden. Genau diese Klarheit hilft, Missverständnisse zu vermeiden.

Häufige Fehler beim ersten Blinky – und wie Sie sie schnell lösen

Wenn Blinky nicht funktioniert, ist die Ursache in der Praxis meist banal. Prüfen Sie zuerst die Grundlagen, bevor Sie tief in Code oder Peripherie abtauchen.

• Falscher LED-Pin: Das Board nutzt nicht den erwarteten Pin. Pinout/User Manual prüfen.
• GPIO nicht als Output konfiguriert: In der Konfiguration ist der Pin noch „Analog“ oder „Input“.
• Board am falschen USB-Port: Nicht der ST-LINK-Port, sondern ein anderer (bei manchen Boards gibt es mehrere).
• Treiber/Verbindung: ST-LINK wird nicht erkannt oder Debugger verliert die Verbindung. Kabel/Port wechseln, Treiber prüfen.
• Code überschrieben: Änderungen außerhalb der USER CODE-Bereiche wurden bei Code-Generierung ersetzt.
• Optimierungseffekte: Bei aggressiven Compiler-Optimierungen können Debug-Ansichten „komisch“ wirken. Für Einsteiger ist ein Debug-Build empfehlenswert.

Wenn Sie unabhängig von der IDE prüfen möchten, ob das Flashen funktioniert, ist STM32CubeProgrammer ein hilfreiches Zusatzwerkzeug: STM32CubeProgrammer.

Sauberer Projektaufbau: So bleibt Ihr Blinky später erweiterbar

Ein „Blinken“ ist schnell gebaut. Der professionelle Unterschied liegt darin, dass Ihr Projekt danach nicht zu einem unübersichtlichen Monolithen wird. Schon beim ersten Projekt können Sie einen kleinen Standard etablieren, der sich später bezahlt macht.

• Konstanten benennen: z. B. eine Variable für die Blinkzeit (in Millisekunden) statt „magischer Zahlen“.
• LED-Funktionen kapseln: z. B. Led_On(), Led_Off(), Led_Toggle() (auch wenn es nur ein Wrapper ist).
• USER CODE-Struktur: Änderungen konsequent in den vorgesehenen Bereichen halten.
• Versionskontrolle: Auch kleine Projekte profitieren von Git, spätestens wenn Sie experimentieren.

Nächste sinnvolle Schritte nach Blinky: Kleine Erweiterungen mit großem Lerneffekt

Wenn Blinky läuft, sind Sie bereit für kleine Erweiterungen, die jeweils einen neuen Aspekt der Embedded-Entwicklung abdecken, ohne Sie zu überfordern. Diese Schritte eignen sich hervorragend, um ein stabiles Fundament aufzubauen.

• Blinky mit Button: LED blinkt nur, wenn ein Taster gedrückt ist (GPIO Input, Pull-up/Pull-down, Debouncing).
• UART-Logging: Statusmeldungen über eine serielle Schnittstelle ausgeben (Baudrate, Terminal, Debug-Ausgaben).
• Timer-Interrupt statt Delay: LED toggelt im Interrupt, Hauptloop bleibt frei (Echtzeitprinzip verstehen).
• DMA-Grundidee: noch nicht zwingend, aber als Konzept früh wertvoll, wenn später Datenraten steigen.

Offizielle Ressourcen für Board, IDE und Einstieg

• STM32 Nucleo Boards: Übersicht, Dokumente, User Manuals
• STM32CubeIDE: Download, Dokumentation, Release Notes
• ST-LINK USB driver (Windows)
• STM32CubeProgrammer: Flashen und Diagnose

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.