BENCH PATH ────────────────────────────────────────────────────────────── Language -> ownership, traits, async, error model Runtime -> Embassy tasks, cooperative scheduling, timing Signals -> GPIO, PWM, I2C, display protocols, drivers Motion -> L298N DC motor, servo channels, stepper-oriented control Feedback -> segment displays, TM1637, encoders, status output Platform -> Axum, SQLx, auth, WebSockets, API integration Pico / RP board -> GPIO ownership at compile time -> PWM for motor speed and actuator timing -> I2C expansion with PCA9685 -> task-based concurrency with Embassy -> web-facing Rust services later in the book
This material sits between a language book and a lab manual. It starts with the compiler because Rust’s ownership system, trait model, and async story are not optional background if you want to write firmware that stays correct as the project grows. But it does not remain abstract for long. The embedded half is clearly pointed at real bench hardware: the Pico, motor drivers, segment displays, servo controllers, encoder feedback, and timing-sensitive peripherals.
Your theme across the existing chapters is already clear: deep navy navigation, ivory paper, serif display typography, long-form book rhythm, side navigation, and chapter-style sections instead of a startup-style marketing page. This index now follows that theme directly so it feels like the front matter of the same book rather than a different site pasted in front of it.
The practical center of the project is not just “embedded Rust.” It is embedded Rust that can drive something you can see, measure, and control. That means numbers on a display, duty cycle on a motor enable pin, angle control on a servo rail, protocol timing over GPIO and I2C, and eventually stepper-friendly pulse patterns that hold up under real scheduling constraints.
That is why Embassy matters here. That is why the PCA9685 chapter matters. That is why the PWM and motor capstone matters. The hardware chapters are teaching a coherent control stack, not isolated demos.
You said you are working with a Pico, L289N or L298N-style motor drivers, segment displays, servo motors, and stepper motors. The landing page should say that plainly. It should also explain why those parts belong together: they force the firmware to coordinate outputs, timing, power stages, bus protocols, and feedback surfaces rather than hiding in toy examples.
PICO BENCH MAP ──────────────────────────────────────────────────────────────── // Display path from Chapter 6 / Chapter 8 TM1637 CLK -> GPIO2 TM1637 DIO -> GPIO3 // Servo expansion path from Chapter 9 PCA9685 SDA -> GPIO4 // I2C0 SDA PCA9685 SCL -> GPIO5 // I2C0 SCL PCA9685 VCC -> 3V3 logic PCA9685 GND -> GND // Encoder path from Chapter 10 Encoder CLK -> GPIO6 Encoder DT -> GPIO7 // L298N drive path from Chapter 10 L298N IN1 -> GPIO8 L298N IN2 -> GPIO9 L298N ENA PWM -> GPIO10 // Power notes Pico GND -> common ground with L298N and PCA9685 Motor supply -> external supply to L298N Servo supply -> external 5V rail on PCA9685 as needed // Stepper direction Reserve the next free GPIO pair for STEP and DIR when you add your stepper driver chapter or A4988 / DRV8825 wiring.
STEPPER DRIVER MAP (A4988 or DRV8825) ──────────────────────────────────────────────────────────────── // Step-direction control — continue from GPIO10 STEP -> GPIO11 DIR -> GPIO12 ENABLE -> GPIO13 // active LOW — pull LOW to energise driver // Microstepping (tie to GND or 3V3 per resolution table) MS1 -> GPIO14 // or hard-wire to fix resolution MS2 -> GPIO15 MS3 -> GPIO16 // DRV8825 only // Power VMOT -> 12 V motor supply // put 100 µF cap across VMOT–GND VDD -> 3V3 logic GND -> common ground (shared with Pico + L298N + PCA9685) // SLEEP / RESET (A4988) SLEEP -> RESET or GPIO // tie together to keep driver awake RESET -> SLEEP or GPIO // Notes for Embassy step-pulse task Set current-limit trimpot BEFORE connecting motor windings. A4988 max ~2 A/phase; DRV8825 max ~2.2 A/phase. Minimum STEP pulse high: 1 µs — use Timer::after_micros(1).await
Displays give the project a local operator surface. They let you show RPM, angles, counts, error codes, or state transitions directly on the bench without depending on a terminal. That makes them ideal for motor and control experiments where immediate visible feedback matters.
The Pico does not drive a motor directly. The H-bridge sits between logic and power, letting GPIO choose direction while PWM determines delivered energy. This is where firmware becomes electromechanical: forward, reverse, braking, duty-cycle control, and safe switching behavior.
Servo timing is much easier to scale when it is pushed through a dedicated PWM controller. The PCA9685 keeps the Pico free for scheduling, input handling, communications, and higher-level coordination while still giving clean control over multiple channels.
Steppers are the natural next expansion because they reward deterministic timing and explicit state handling. Rust and Embassy are a strong fit for step-direction patterns, acceleration ramps, synchronized movement, and multi-task coordination around motion planning.
The display is your dashboard. The motor driver is your power stage. The servo controller is your timing offload. The stepper path is your precision motion expansion. The Pico sits in the middle coordinating all of them. And the bonus chapter closes the loop: a DualShock 4 in your hand driving the L298N over WiFi — the toy that deserved to be built, finally built.
Every part listed here appears as an active subject in at least one chapter — not as background. The chapters drive motors, read encoders, update displays, and push servo channels. These are the components that make that possible.
RP2040 microcontroller. Dual-core Cortex-M0+, 264 KB SRAM, 2 MB flash, 26 GP pins, 2× I2C, 2× SPI, 2× UART, 8× PIO, 16× PWM slices. The entire firmware stack runs here. Pico W adds CYW43439 Wi-Fi/BT for network chapters.
Four 7-segment digits driven over a 2-wire serial protocol (CLK + DIO). Gives you a local operator surface: RPM, counts, angles, state codes. Chapter 8 builds the driver from scratch against the bit-banged timing spec.
12 V / 2 A logic-controlled H-bridge. Two IN pins select direction, ENA pin accepts PWM for speed. Includes 5V onboard regulator for Pico logic supply when motor voltage ≤ 12 V. Chapter 10 controls direction and duty cycle from Pico GPIO and PWM slice 5A.
I2C-addressed PWM controller at 400 kHz I2C, 12-bit resolution per channel. Frees the Pico from managing servo timing directly. Address pins allow up to 62 boards on one bus. Used in Chapter 9 via GPIO4 (SDA) and GPIO5 (SCL) on I2C0.
Yellow TT motor or N20 gear-motor with two-channel encoder output (A/B). CLK → GPIO6, DT → GPIO7. Used in Chapter 10 to close the speed-feedback loop: PWM drives the L298N, encoder reports actual shaft position, firmware reconciles the two.
The bonus chapter turns a standard PS4 DualShock 4 into a wireless remote for the L298N bench motor. A Python script on the host PC pairs via Bluetooth Classic, reads the 64-byte HID report at 60 Hz, and forwards it as a raw UDP packet to the Pico 2W over LAN. No special hardware beyond the controller and your home Wi-Fi.
SG90 or MG90S 9g servos on PCA9685 channels. NEMA 17 (or equivalent) stepper motor with A4988 or DRV8825 driver module. Steppers use STEP/DIR/ENABLE on GPIO11–13 and optional MS1–MS3 on GPIO14–16 for microstepping resolution.
The bench needs three voltage sources, all sharing a single ground reference: 3V3 from the Pico (logic for Pico, PCA9685 VDD, driver VDD), 5 V servo rail on the PCA9685 V+ header for servo power, and 12 V motor supply for the L298N VMOT and stepper VMOT. Never power motor stages from the Pico 3V3 or VSYS pin — the inductive spike on motor shutdown will reach GPIO and corrupt or destroy the RP2040. Connect all GND rails together at one point on the breadboard.
The book’s sequence is sensible as written, and the landing page should expose that clearly instead of scattering the content into generic cards. The reader needs to understand where they begin, where the hardware chapters start, and what the later web chapters are doing in the same project.
The opening chapters build the mental model that makes the rest of the book readable instead of mystical.
The toolchain chapter is the bridge from Rust knowledge into working board-level development.
This is the embedded core of the project and the section most aligned with your bench hardware.
The later chapters show how the same Rust stack can power APIs, dashboards, persistence, and live interfaces around your embedded systems.
A DualShock 4 contains two analog sticks, two triggers, fourteen buttons, a touchpad, a gyroscope, an accelerometer, and a rumble motor. Every input arrives in a 64-byte HID report at 60 Hz. This chapter reads that report, parses it into a typed Rust struct, and drives your bench motor with the left stick.
ControllerState struct parsed at the UDP boundary — Embassy tasks consume clean named fields, not byte offsets.The current structure already has room for stepper-specific work without changing the book’s logic.
The landing page now behaves like proper front matter for the same book: the same nav chrome, the same sidebar structure, the same serif-and-mono rhythm, and a tighter content column so it does not open up into empty space.
It also says your hardware focus directly instead of burying it in generic marketing language.