Pico de Gallo lets Rust developers build embedded drivers on a laptop

Pico de Gallo changes the embedded Rust loop from a flash-reset grind into something much closer to normal systems development. Instead of editing code, waiting for a target build, reflashing a board, power-cycling it, and chasing logs through a probe, you plug a Raspberry Pi Pico 2 into your laptop and treat it as a USB-attached protocol bridge. That shift matters because most driver work is not about squeezing cycles out of a microcontroller core, it is about getting byte-level protocol logic, initialization order, and error handling right.

What Pico de Gallo actually is

Pico de Gallo is a small landing board built around the Raspberry Pi Pico 2, and its job is specific: expose common embedded peripherals to a host PC over USB. The board surfaces I2C, SPI, UART, GPIO, PWM, ADC, and 1-Wire, so the laptop can talk to real hardware through a typed Rust interface instead of through a one-off bench setup. The host side is a real Rust crate, and the firmware speaks postcard-rpc, which gives the setup a proper protocol layer rather than a pile of ad hoc scripts.

That distinction is why the project is more interesting than a simple adapter board. Pico de Gallo is not a logic analyzer, and it is not a debug probe. It is trying to be a development bridge, which means the value is in making driver code easy to exercise repeatedly while keeping the hardware conversation real.

The workflow shift is the point

The core promise is simple: write embedded driver logic on your laptop, then hit real peripherals through the Pico 2 without dragging the target chip into every iteration. The project’s introduction is explicit about the pain it is trying to remove: no flashing, no SWD probe, no clock or pin-mux setup, and no linker scripts getting in the way. That is a big deal if you have spent any time fighting embedded Rust on a board that is just barely configured enough to print one useful line before the next reset.

The article’s example code leans on `pico_de_gallo_hal` and `embedded_hal::i2c::I2c`, which is the right clue to read closely. This is not a toy abstraction layer for fake devices. It is a host-side setup that still speaks in the same traits and driver vocabulary you already use for actual embedded work, so the code path you test on the laptop maps cleanly onto the code path you would eventually run on hardware.

The practical payoff is iteration speed. When you are debugging a sensor bring-up sequence or a flaky register transaction, the bottleneck is usually not the silicon itself. It is the time lost waiting for a build-and-flash loop to finish before you can answer one small question about the bus.

Why embedded-hal is the right backbone

Pico de Gallo makes sense because embedded Rust already has a portability story built around `embedded-hal`. The crate is the common trait layer many driver authors target, and its documentation points developers toward `embedded-hal-async` for async and await use cases and `embedded-io` for serial or UART-style byte streams. The repository also emphasizes the key advantage of the model: write the driver as a generic library on top of `embedded-hal`, and you can support multiple targets instead of hard-wiring yourself to a single board.

That portability matters here because the bridge does not ask you to give up the embedded-hal mental model. It keeps the API shape familiar, so a driver written against typed traits can be tested through the laptop bridge and later reused across Cortex-M microcontrollers, AVR microcontrollers, and even embedded Linux. In other words, Pico de Gallo is not inventing a new embedded Rust lane. It is trying to make the existing lane less painful to drive in.

How it fits with the tools Rust developers already use

Pico de Gallo is not the first attempt to make embedded driver work less hardware-dependent. `embedded-hal-mock` already exists for testing drivers in CI without hardware, and `embedded-test` works with `probe-rs` to run unit and integration tests directly on embedded devices. Those tools are useful, but they solve different slices of the problem.

The useful way to think about Pico de Gallo is as the middle ground between pure simulation and on-target testing. Mocking is great when you want fast CI coverage. On-target tests are great when you need the exact board. Pico de Gallo gives you a real, wired-up peripheral conversation from the laptop, which is often the sweet spot when you are iterating on protocol behavior and do not want to keep paying the flash-reset tax. It lowers the barrier for trying out embedded Rust driver code at home because your workstation becomes the main development surface, not the board.

Why the Pico 2 is a sensible host for this

The choice of Raspberry Pi Pico 2 is not random, either. Raspberry Pi launched Pico 2 on August 8, 2024, and positioned it as a meaningful step up from the original Pico family. The board keeps the same form factor and I/O, but adds a higher core clock speed, double the memory, more powerful Arm cores, optional RISC-V cores, new security features, and upgraded interfacing capabilities.

That makes Pico 2 a natural fit for a USB bridge that has to juggle several buses and expose them cleanly to a host. Raspberry Pi also has the wireless Pico 2 W variant, which adds 2.4GHz 802.11n Wi-Fi and Bluetooth 5.2 at a $7 price point. Pico de Gallo does not need wireless to make its point, but the broader Pico 2 line shows that this is a platform with enough headroom and polish to serve as more than a barebones microcontroller demo board.

Getting started is intentionally boring

The installation side is refreshingly unglamorous. Pico de Gallo’s host tool is `gallo`, and the docs say that on most platforms you can use it without extra drivers. That matters because a lot of embedded toolchains fail in the first five minutes, usually at the point where your operating system, USB stack, and vendor tooling all decide to disagree. Here, the setup is meant to be dull in the best possible way: plug in the board, run the host tool, and start exercising the driver logic.

That low-friction entry point is what makes the project bigger than one board or one clever demo. It pushes embedded Rust toward a workflow where the laptop is not just the place you write code, it is the place you prove the code works against real bus transactions before you ever commit to the target loop.

Pico de Gallo is really about changing the unit of pain. It takes embedded driver work out of the flash-reset trap and moves it to a laptop-native loop where `embedded-hal` code, real hardware, and fast iteration finally line up.