EMBEDDED RUST · no_std → WASM

One Source, Two Targets

Write the portable control core and understand the seam: the same control() that compiles to WebAssembly here also cross-compiles to a Cortex-M or RISC-V target, with only the HAL changing.

01Challenge

The firmware in this Bench compiles to WebAssembly and runs as the live control loop. Write the portable core so it drives the rover, and read how the identical source would target a real microcontroller with only the layer behind the peripherals swapped.

02Model

The code you are running is not a simulation of firmware; it is firmware, compiled to the wasm32 target and executed directly. The reason it also belongs on a chip is that Rust separates portable logic from hardware access. Your control() talks only to the HAL: p.goal, p.motors, p.led. Here the HAL is backed by calls into the browser. On a Cortex-M or RISC-V board, the same control() links against a HAL backed by real memory-mapped registers, and cross-compiles to that target unchanged. One source, two backends. The seam is the HAL, and that is the whole portability story: write the control logic once, port the thin layer beneath it.

03Guided practice

1. Write the core. let turn = 1.2 * bearing; and let forward = (0.9 * dist).min(0.6); then p.motors.set(forward - turn, forward + turn); 2. Note what it touches. Only the HAL, p.goal/p.motors/p.led. No browser, no board specifics leak in. 3. Understand the seam. Swap the HAL for a register-backed one and this exact function targets an MCU. The logic does not change. 4. Drive. Reach the pad; you have written the portable core that both targets share.

04Feedback

PASS WHEN The portable core drives the rover, and you can state what changes across targets (the HAL) and what does not (the control logic).

If your run fails, check:

Rover sits still: fill in the steering and forward, then `p.motors.set(forward - turn, forward + turn)`.
Veers away: left is `forward - turn`, right is `forward + turn`, with turn = `1.2 * bearing`.
Times out short of the pad: raise the forward toward `(0.9 * dist).min(0.6)` so it drives, not crawls.

05Retrieve & space

What is the only part of this firmware that differs between the browser and a real microcontroller? (the HAL backend).
Why can the same control() cross-compile to wasm32 and to a Cortex-M target unchanged? (it depends only on the HAL interface).
What target did your code compile to in this Bench, and what target would it link for on a board? (wasm32-unknown-unknown; e.g. thumbv7em / riscv32).

06Mastery & project

Write control logic that depends only on the HAL interface, so one Rust source is portable from the browser to bare metal by swapping the layer beneath it.

The seam that connects this course to the Silicon (RISC-V) work and to real embedded deployment: portable core, thin hardware layer.

GO FURTHER · THE LIVE PLAYGROUND

Drive the live rover in the Pilot ↗ — the same wasm target, running the rover you steer

← Traits: Reusable Control, Zero Cost Correct, and On Time →

EMBEDDED RUST · no_std → WASM

One Source, Two Targets

Write the portable control core. It compiles to WASM here and, unchanged, to a real MCU target behind a different HAL.

You read

You change

the firmware you write in the control loop

Fixed

the emulated chip, its peripherals, and the wiring