EMBEDDED RUST · no_std → WASM

Borrowing: Share Without Giving Away

Use shared and mutable references to pass the peripherals into helper functions without moving them, the everyday tool for structuring firmware into readable pieces.

01Challenge

A helper named navigate() wants to do the driving, but it asks for the peripherals by value, which would move them away from control() for good. The build fails. Change how navigate borrows so both functions can use the peripherals, and reach the pad.

02Model

You will not write one giant control() forever. Real firmware splits into functions: navigate, sense, report. Each needs access to the peripherals, but if a function takes them by value it consumes them, and the caller is left with nothing. Borrowing is the answer. A mutable reference, &mut Peripherals, lends the peripherals to a function for the length of the call and takes them back when it returns. One lender, one borrower at a time, checked at compile time. It is how Rust lets many parts of a program share hardware safely with no locks and no runtime cost.

03Guided practice

1. Read the error. navigate(p) passes a &mut Peripherals where the function wants an owned Peripherals: error[E0308]: mismatched types. 2. Fix the signature. Change fn navigate(p: Peripherals) to fn navigate(p: &mut Peripherals). Now it borrows. 3. The body already works. p.goal.distance(), p.motors.set(...), p.led.set(...) all work through the reference. 4. Drive. control() calls navigate(p) and the rover reaches the pad.

04Feedback

PASS WHEN The firmware compiles with navigate() borrowing the peripherals by mutable reference, and the rover reaches the pad.

If your run fails, check:

Build fails with 'mismatched types: expected Peripherals, found &mut Peripherals'. Change navigate's parameter to `p: &mut Peripherals`.
Still failing after editing the call instead of the signature. Fix the function's parameter type, not the `navigate(p)` line.
Compiles but the rover sits still: check that navigate() actually calls `p.motors.set(...)`.

05Retrieve & space

What is the difference between `Peripherals` and `&mut Peripherals` as a function parameter? (owning/consuming vs borrowing).
Why does borrowing let both control() and navigate() use the peripherals when moving would not?
How long does a `&mut` borrow last, and when do the peripherals return to the caller? (for the call; on return).

06Mastery & project

Structure firmware into functions that borrow the peripherals rather than consume them: the reference model that scales past one function.

The pattern every multi-function firmware in this course and in real embedded projects uses to share hardware safely.

← Ownership: the Compiler Catches It First Option: No Null, No Silent Bug →

EMBEDDED RUST · no_std → WASM

Borrowing: Share Without Giving Away

Split firmware into functions with borrowing. The starter does not compile until navigate() borrows instead of consuming.

You read

You change

the firmware you write in the control loop

Fixed

the emulated chip, its peripherals, and the wiring