Rust on Robots

interaktiver Workshop von „Rust fühlt sich neu an“ zu „LED blinkt auf STM32“

• Level: Anfänger mit Programmiererfahrung
• Bring-your-laptop - Wir flashen echte Board(s)
• Vorab: RustUp installieren! -> https://rustup.rs

Was ihr nachher könnt

• Rust Toolchain installieren und verifizieren
• Ein kleines Desktop-Programm bauen
• Ein no_std-Firmware-Projekt flashen und Logs sehen
• “Rust auf MCU” mental einordnen

Robotik ist Embedded

und Embedded bestraft uns sofort

• Viele Fehler sind nicht “Logik”, sondern Speicher & Nebenwirkungen
• Debug-Zeit frisst Projektzeit (gerade im Schulkontext)
• Ziel heute: robuster werden, ohne „RTOS + C++-Template-Magie“

Memory-Safety lohnt sich – aber nicht gratis

• weniger UAF/BOF-Klassen → weniger „Geisterbugs“
• Rust verschiebt Fehler nach links (Compile-Time statt Feldtest)
• Aber: Tooling + Denkmodell brauchen Einstieg (heute)

Rust ist kein Zauberstab

• Compile-Zeiten können nerven (vor allem mit vielen Dependencies)
• Embedded ist „weniger bequem“: kein std, keine Files, kein Netzwerk
• Unsafe existiert weiterhin (aber: eingrenzbar und reviewbar)

Workshop-Route (~90 Min)

1. Setup & Repo-Smoketest (~15–20m)
2. Rust-Grundprinzipien über Übungen (~20m)
3. Mini-Desktop-Programm: Cargo-Flow + Result (~15m)
4. MCU: no_std + Flash + Logs (~20–30m)

Mini-Glossar

• rustup: Toolchain-Manager (stable/nightly, targets)
• cargo: Build/Test/Run/Package
• crate: Rust-Paket (lib oder bin)
• Ownership/Borrow: Regeln für Speicherzugriff
• no_std: kein OS-Standard-Lib; bare metal
• HAL / embedded-hal: Hardware-Abstraktion-Layer/Traits

Evidence: rustup ist der „kleinste gemeinsame Nenner“

Heute nutzen wir rustup, weil es plattformübergreifend stabil ist.

Setup: Was wir brauchen

• Rust stable via rustup (einheitliche Toolchain)
• Git Repo
• Für MCU: probe-rs

Übung 0a: Toolchain verifizieren

• rustc --version
• cargo --version
• rustup show
• cargo new hello && cargo run
• Ziel: Jeder hat einen grünen Build.

Übung 0b: probe-rs Tools installieren

probe.rs

• Linux/macOS: Installer-Skript (prebuilt) ausführen
• Windows: PowerShell Installer (prebuilt) ausführen
• Check: cargo embed --version und probe-rs --version

Übung 0c: Repo holen & Smoketest

Repo klonen (oder ZIP) und in Projektordner wechseln

git clone https://git.wieerwill.dev/wieerwill/didakta-rust-workshop

Rust in 10 Minuten: Die 3 Regeln, die alles erklären

• Werte haben einen Owner (und eine Lebensdauer)
• Borrowing: viele const &T oder genau ein &mut T
• Result<T, E> ist normal - Fehler sind ein Datentyp
• Aber: Der Compiler ist streng damit ihr später schneller seid

Evidence: Ownership

Die Ownership-Kapitel sind die beste „einmal sauber“-Referenz.

Übung 1: Rustlings Sprint

• Rustlings starten, erste Übungen lösen (compile → fix → repeat)
• Fokus heute: Ownership/Borrow + Result
• Ziel: Fehlermeldungen lesen wie Unit-Tests (nicht wie Gegner)

Übung 2: Mini-Desktop-Programm

• Input: „Sensor-Log“ (Text) → parse → aggregieren
• Ausgabe: Mittelwerte/Min/Max + einfache Warnschwellen
• 1–2 Tests schreiben (damit Refactoring safe bleibt)
• Ziel: Cargo-Loop sitzt: test → run → fix

Bridge: Jetzt drehen wir std ab

• Cargo bleibt (build/test/run)
• Rust bleibt (Ownership/Result/Types)
• Weg sind OS-Services: Files/Netz/Threads
• Dafür kommt Hardware rein: GPIO/Timer/Interrupts

Evidence: Embedded Rust Book – Einstieg in no_std

Das Embedded Rust Book erklärt no_std, Tooling und Cortex-M Basics.

no_std in einem Satz

• Firmware ist ein „Binary“, aber ohne OS-Standardbibliothek
• Hardwarezugriff passiert über HALs (GPIO/Timer/UART/…)
• Viele Projekte teilen Traits über embedded-hal
• Aber: Debugging muss geplant sein (RTT/defmt hilft)

Evidence: embedded-hal 1.0 ist ein Stabilitäts-Signal

embedded-hal 1.0: gemeinsame Traits → weniger Wildwuchs zwischen HALs.

Übung 3: Flash-Pipeline

• Board per USB verbinden (ST-LINK / CMSIS-DAP / etc.)
• probe-rs list → sieht der Rechner den Probe?
• probe-rs info -> können wir das Board auslesen?
• cargo embed → build → flash → reset → RTT
• Ziel: LED blinkt + wir sehen Logs.

Evidence: cargo-embed = flash + RTT + optional GDB

cargo-embed beschreibt den Ablauf (build → detect → flash → RTT → gdb).

Übung 4: Embassy Blinky (async embedded)

• Beispiel-Firmware bauen (aus Repo: „blinky“)
• Zwei Tasks: LED-Timer + (optional) Button-Input
• Ziel: „Multitasking“ ohne Threads/Stacks pro Task

Evidence: Embassy Runtime – warum async hier Sinn macht

Embassy erklärt: kein Heap nötig, Tasks statisch, CPU kann schlafen.

Debug-Ausgabe, die im Workshop wirklich funktioniert

• RTT statt UART: weniger Verkabelung, schneller Start
• defmt: Strings nicht im Flash → kleinere Firmware
• Logs wie „printf“, aber embedded-freundlicher
• Aber: Tooling muss zusammenpassen (Printer/Runner)

Evidence: defmt Printers (host-seitig)

defmt braucht einen Host-Printer (z.B. probe-run) zur Ausgabe.

Case Study: OpenTitan – Rust ist „allowed“ in echten Secure-Stacks

• Device-SW darf C/ASM/Rust sein
• Host-Tools explizit C++ oder Rust
• Tradeoff: Integration + Toolchains sind Teil der Arbeit

Evidence: OpenTitan benennt Rust explizit als Sprache

OpenTitan Doku: Device Software (C/ASM/Rust) und Host Software (C++/Rust).

Messe-Realität: Netz ist unzuverlässig → wir arbeiten offline-first

• Dependencies vorab „ziehen“ (oder vendoren)
• Builds mit --offline müssen möglich sein
• Wir haben „Plan B“: vorbereitete Artefakte/ZIPs
• Aber: ihr nehmt das Setup danach mit nach Hause

Evidence: cargo vendor / offline-Modus ist dokumentiert

cargo vendor + offline Flags sind Teil der offiziellen Cargo-Doku.

Wenn Flashing nicht geht: 5 Quick Fixes

• USB-Kabel tauschen (ja, wirklich) + anderen Port testen
• Probe sichtbar? probe-rs list → sonst Treiber/Permissions
• Chip-Name stimmt? (Runner / Embed.toml / Feature)
• Reset/Boot-Pins prüfen (manche Boards brauchen Boot0 low)
• Pairing: eine Maschine flashen, andere schaut zu/editiert

Evidence: ST-LINK Treiber ist der häufigste Windows-Blocker

STMicroelectronics stellt ST-LINK USB Treiber als Download bereit.

Playbook: Rust auf Robotern einführen

• 1. Toolchain standardisieren (rustup, formatter, clippy)
• 2. Kleines Modul wählen (klarer Input/Output, testbar)
• 3. FFI/Boundary bewusst setzen (Rust innen, C außen – oder umgekehrt)
• 4. Embedded: Logging/Debug zuerst (RTT/defmt), dann Features
• 5. Erst danach: async/Embassy/Performance-Tuning

Decision Matrix

• Rust lohnt sich, wenn: Memory-Safety wichtig + Tests/Reviews ernst gemeint
• Rust lohnt sich, wenn: ihr klare Modulgrenzen habt (Schnittstellen!)
• Rust lohnt sich weniger, wenn: extrem kleines MCU + kaum Flash/RAM + Deadline hart
• Rust lohnt sich weniger, wenn: Toolchain/Drivers nicht kontrollierbar (Schul-IT)
• Aber: „Rust nur am Host“ (Tools/CI) ist oft ein sehr guter Start

Deep Dive: Unsafe & FFI

• Unsafe ist erlaubt, aber: lokal + reviewbar halten
• Typischer Einsatz: Registerzugriff, HAL-Interna, C-Interop
• Pattern: safe API außen, unsafe innen – mit Tests/Assertions
• Aber: unsafe ist kein „Escape“ für Architekturprobleme

Deep Dive: Safety-Critical Rust

wenn Regeln & Audits zählen

Ferrocene als Beispiel: qualifizierte Toolchain für Safety/Mission-Critical.

Wrap-up: Was heute passiert ist

• Rust-Grundprinzipien an echten Compiler-Fehlern gelernt
• Cargo-Workflow geübt (run/test, reproducible builds)
• MCU geflasht + Logs gesehen (RTT/defmt)
• Klarheit gewonnen: Rust ist Werkzeug – mit Kosten & Nutzen

Mehr?!

• Rust Book + Rustlings (Sprache festigen)
• Embedded Rust Book + Discovery (bare metal verstehen)
• Embassy Book (async sauber einsetzen)
• probe-rs Docs (Runner/Embed.toml/Debug)
• Community: Embedded WG Ressourcen + RoboCup Kontexte

END OF BRIEFING

MAIL:
robert.jeutter@wieerwill.dev

MASTODON:
https://chaos.social/@wieerwill

LINKEDIN:
https://www.linkedin.com/in/wieerwill

WEB:
https://wieerwill.dev