RoboCup war mein Gateway Drug

Embedded ist überall

Embedded = Probleme in kleinen Lösungsraum

• Wenig RAM/Flash → plane Datenflüsse, statt “wir skalieren später”
• Echtzeit/IO → Nebenläufigkeit ist nicht optional
• Updates sind teuer → Debugbarkeit ist Teil des Produkts
• Hardware ist “API”, aber mit Lieferzeiten

Unser Mini-Labor: Blue Pill

Hello World ohne Display: Blinky

Mini-Glossar

• MCU: CPU + RAM/Flash + Peripherie auf einem Chip
• GPIO: Pin als Ein/Aus
• ADC: Spannung → Zahl
• PWM: “Analog tun” mit Digital-Pins (Duty Cycle)
• Interrupt: Hardware weckt Task
• HAL: Treiber-Schicht: “Pin A9” wird “LED”

Pinout

Analog vs. Digital

PWM: Zeit als Stellschraube

UART: Bits + Timing + Agreement

MCU: CPU + Peripherie + Bus

Das “Programm” ist nur ein Teil. Der Rest sind Timer, DMA, UART, ADC, GPIO, Interrupts.

Memory-Mapped IO

Bare Metal in Rust

no_std ist Absicht

#![no_std]
#![no_main]

use cortex_m_rt::entry;

#[entry]
fn main() -> ! {
    loop {
        // your code hits physics here
    }
}

• Kein OS → kein std
• verlinke nur, was du wirklich brauchst (core, optional alloc)
• “Komfort” kostet in Embedded oft: Flash, RAM, Determinismus

Ownership & Borrowing

der Compiler ist dein zweites Paar Augen

• Kein GC → trotzdem Memory Safety
• Werte werden besessen (move), nicht “irgendwo referenced”
• Du leihst Daten (borrow) statt sie “mal kurz zu teilen”
• Ergebnis: viele Fehler verhindert, bevor du überhaupt flashst

Ownership: Copy vs Borrow

let eins: i32 = 1;
let mut zwei: i32 = 2;

zwei = 3;              // ok: nur neue Zuweisung
let drei = eins;       // ok: Copy, eins bleibt gültig
let vier = &eins;      // ok: Borrow (immutable reference)

println!("{}", eins);  // ok: eins ist noch da
println!("{}", drei);  // ok
println!("{}", vier);  // ok: deref implizit bei Display

Der Debug-Loop muss banal sein

Weniger Handarbeit: Datasheet → SVD → API

Minimal bare-metal blinky

#![no_std]
#![no_main]

use cortex_m::asm::delay;
use cortex_m_rt::entry;
use panic_halt as _;
use stm32f1::stm32f103;

#[entry]
fn main() -> ! {
    let dp = stm32f103::Peripherals::take().unwrap();

    // Clock für GPIOC
    dp.RCC.apb2enr.modify(|r, w| unsafe {
        w.bits(r.bits() | (1 << 4))
    });

    // PC13 als Output Push-Pull @ 2 MHz
    dp.GPIOC.crh.modify(|r, w| unsafe {
        let mut bits = r.bits();
        bits &= !(0xF << 20);        // PC13-Feld (4 Bits) löschen
        bits |=  (0x2 << 20);        // MODE13=10, CNF13=00 setzen
        w.bits(bits)
    });

    const BLINK_DELAY_CYCLES: u32 = 2_000_000; // Cycles! not ms

    loop {
        // PC13 LOW (reset) -> LED oft AN
        dp.GPIOC.bsrr.write(|w| unsafe { w.bits(1 << (13 + 16)) });
        delay(BLINK_DELAY_CYCLES);

        // PC13 HIGH (set) -> LED AUS
        dp.GPIOC.bsrr.write(|w| unsafe { w.bits(1 << 13) });
        delay(BLINK_DELAY_CYCLES);
    }
}

Problem: Tasks nacheinander ausführen

#![no_std]
#![no_main]

use cortex_m_rt::entry;
use panic_halt as _;
use stm32f1xx_hal::{gpio::PinState, pac, prelude::*};

#[entry]
fn main() -> ! {
    let dp = pac::Peripherals::take().unwrap();
    let cp = cortex_m::Peripherals::take().unwrap();

    let mut flash = dp.FLASH.constrain();
    let rcc = dp.RCC.constrain();
    let clocks = rcc.cfgr.freeze(&mut flash.acr);
    let mut delay = cp.SYST.delay(&clocks);

    let mut gpioa = dp.GPIOA.split();
    let mut gpioc = dp.GPIOC.split();

    let mut led = gpioc.pc13.into_push_pull_output_with_state(&mut gpioc.crh, PinState::High);
    let button = gpioa.pa0.into_pull_up_input(&mut gpioa.crl);

    let mut wait_ms: u16 = 300;
    let mut was_up = true;

    loop {
        let _ = led.toggle();

        if was_up && button.is_low() {
            if wait_ms > 1 {
                wait_ms /= 2;
            }
            was_up = false;
        } else if button.is_high() {
            was_up = true;
        }

        delay.delay_ms(wait_ms);
    }
}

Async ist kein OS

Es ist ein fairer Scheduler

Embassy (embedded + async)

• Tasks sind statisch allokiert (kein Heap nötig)
• CPU schläft, wenn nix los ist (Interrupts wecken)
• Fairness: ein Task kann nicht “alles” belegen
• Du bekommst “blink + button + sensor” ohne Thread-Tetris

Embassy Async Beispiel

#![no_std]
#![no_main]

use core::sync::atomic::{AtomicU32, Ordering};
use embassy_executor::Spawner;
use embassy_stm32::{
    exti::ExtiInput,
    gpio::{Level, Output, Pull, Speed},
};
use embassy_time::Timer;
use panic_probe as _;

static BLINK_DELAY_MS: AtomicU32 = AtomicU32::new(3000);

#[embassy_executor::task]
async fn led_task(mut led: Output<'static, embassy_stm32::peripherals::PC13>) {
    loop {
        led.toggle();
        let d = BLINK_DELAY_MS.load(Ordering::Relaxed) as u64;
        Timer::after_millis(d).await;
    }
}

#[embassy_executor::task]
async fn button_task(mut button: ExtiInput<'static, embassy_stm32::peripherals::PA0>) {
    loop {
        button.wait_for_falling_edge().await;
        let d = (BLINK_DELAY_MS.load(Ordering::Relaxed) / 2);
        BLINK_DELAY_MS.store(d, Ordering::Relaxed);
        button.wait_for_rising_edge().await;
    }
}

#[embassy_executor::main]
async fn main(spawner: Spawner) -> ! {
    let p = embassy_stm32::init(Default::default());
    let led = Output::new(p.PC13, Level::High, Speed::Low);
    let button = ExtiInput::new(p.PA0, p.EXTI0, Pull::Up);

    spawner.spawn(led_task(led)).unwrap();
    spawner.spawn(button_task(button)).unwrap();

    core::future::pending::<()>().await;
    unreachable!()
}

Memory Safety ist Key-Faktor

Playbook: Erste Stunde Embedded Rust

1. Board + Debugger: Strom + SWD steht
2. Blinky: GPIO + Timer/Ticks
3. Logs an: RTT/defmt
4. Ein Input: Button oder ADC (Poti)
5. Ein Output: PWM (LED dimmen)
6. Dann erst: UART / I²C / SPI

Erst Feedback, dann Komplexität.

Decision Matrix: Rust vs C/C++ vs MicroPython

Zusammenfassend

Embedded mit Rust ist “weniger Stress”, nicht “weniger nah dran”

• Du arbeitest weiter mit Timern, Interrupts, Registern
• mit besseren Verträgen zwischen Modulen (Traits/HAL)
• Ziel: schneller iterieren, Fehler vornherein Verhindern

END OF BRIEFING

MAIL:
robert.jeutter@wieerwill.dev

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

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

WEB:
https://wieerwill.dev