EMBEDDED RUST · no_std → WASM

Ownership: the Compiler Catches It First

Understand ownership and moves by reading a real borrow-checker error and fixing it, so firmware that misuses a peripheral fails to build instead of misbehaving on the robot.

01Challenge

The Bench opens on firmware that tries to take the motors into their own variable. Press Compile & Run and it will not build. Read the compiler's message, fix the ownership mistake, and drive the rover to the pad.

Predict firstTwo variables try to own the same heap value in Rust. When is that error caught?

02Model

Every peripheral on a robot has exactly one owner: the motor driver, the timer, the pin. Two parts of a program fighting over the same one is a class of bug that ends careers in embedded work. Rust makes ownership a rule the compiler enforces. You take() the peripherals once as a value, and moving one out from behind a shared reference is simply not allowed. Here that rule shows its whole point: the firmware that grabs the motors the wrong way never runs, because it never compiles. The compiler caught the bug before the robot could.

03Guided practice

1. Read the error. Compile & Run first. You will see error[E0507]: cannot move out of p.motors. That is the borrow checker, not a crash. 2. Understand it. let motors = p.motors; tries to MOVE the motors out of a borrowed p. You are only borrowing p, so you cannot take its pieces away. 3. Fix it. Drop the intermediate variable and drive through the peripheral directly: p.motors.set(forward - turn, forward + turn); 4. Drive. Keep the proportional-ish forward and the 1.2 * bearing turn, and reach the pad.

04Feedback

PASS WHEN The firmware compiles as no_std and drives the rover within 0.2 m of the pad, with the ownership error resolved.

If your run fails, check:

Still failing to build with 'cannot move out of p.motors'? Don't copy the motors into a variable. Call `p.motors.set(...)` directly.
Builds now but the rover sits still. You removed the move but also the drive. Set the motors: `p.motors.set(forward - turn, forward + turn)`.
Rover veers away from the pad. The steering sign is flipped: bearing is + when the goal is LEFT, so use `forward - turn` on the left motor.

05Retrieve & space

Ownership: why can you not move `p.motors` out when you only hold `&mut Peripherals`? (you are borrowing p, not owning it).
What does `error[E0507]` tell you, and why is a compile error better than a runtime one on a robot?
How many owners does each peripheral have in Rust, and why does that matter for a motor driver?

06Mastery & project

Read and resolve a real borrow-checker error, then compile-and-run no_std firmware that drives the rover: ownership understood by using it.

The foundation of the course: every later firmware relies on owning the peripherals correctly.

← Rust for Physical AI Borrowing: Share Without Giving Away →

EMBEDDED RUST · no_std → WASM

Ownership: the Compiler Catches It First

Write no_std Rust against the rover HAL. It compiles to WASM and runs as the real control loop. This starter does not compile on purpose.

You read

You change

the firmware you write in the control loop

Fixed

the emulated chip, its peripherals, and the wiring