rp-hal for Rust on Raspberry Pi RP2040 and RP235x

Choosing the right rp-hal crate

rp-hal addresses a specific layer of embedded development: using Rust with the Raspberry Pi RP2040 and RP235x microcontrollers without writing every peripheral interaction from the register level. It is aimed at firmware developers, peripheral-driver authors, and people maintaining board support packages. The repository is a collection rather than one application crate.

The primary device crates are `rp2040-hal` and `rp235x-hal`. Use `rp2040-hal` for the RP2040, or `rp235x-hal` for the RP2350A, RP2350B, and variants with on-board Flash. `rp-hal-common` contains code shared by the two HALs, but the README says users will likely never need to depend on it directly. Separate example folders demonstrate GPIO, I²C, SPI, UART, PWM, PIO, sleeping, waiting on the RTC, and task spawning on Core 1.

The distinction between a HAL and a board matters. The HAL provides high-level drivers for internal peripherals such as SPI and I²C, but it does not know how a particular board connects those peripherals to pins. A board support package can add that wiring information. The README also notes that this repository's examples are intended for the Raspberry Pi Pico and Raspberry Pi Pico 2, while other BSPs live in a separate repository.

Preparing Rust targets and flashing tools

The documented setup starts with the latest stable Rust and the target support needed for the microcontroller family. The commands below install the bare-metal Rust targets listed by the README. The target choice matters because an RP2040 or other embedded program cannot be compiled as if it were a normal host executable.

These commands update rustup and install the listed targets:

rustup self update
rustup update stable
rustup target add thumbv6m-none-eabi
rustup target add thumbv8m.main-none-eabihf
rustup target add riscv32imac-unknown-elf

For flashing over SWD pins, the README suggests installing `probe-rs-tools` with Cargo. This is an optional route for developers using a debug probe:

cargo install --locked probe-rs-tools

For a setup without a debug probe, or for producing UF2 images for the USB bootloader, the project points to Raspberry Pi's `picotool`. The README directs users to a pre-built `picotool` binary for their system through the `picotool-releases` page. It does not provide a platform-specific download command, so the reader must obtain the appropriate binary separately.

After the tools are present, the README directs RP2040 projects to the RP2040 project template and RP235x projects to the RP235x project template. Those templates are the documented starting point for creating an application. The README does not include a complete Cargo manifest or application source example, so this article does not invent one.

Peripheral drivers and chip-family boundaries

The HAL's core job is to expose the microcontroller's internal peripherals through higher-level Rust interfaces. The documented examples cover GPIO, I²C, SPI, UART, PWM, PIO, sleep, and RTC behavior. That makes it possible for an application to describe peripheral operations without requiring the application to carry the complete low-level setup for every device block.

The boundary is explicit. `rp2040-hal` is for the RP2040, while `rp235x-hal` is for the RP235x family. The RP235x crate supports the RP2350A fully and describes support for the extra pins on the RP2350B as partial. This qualification is important for board authors. A board using an RP2350B-specific pin cannot be treated as identical to an RP2350A design merely because both are covered by the same crate.

RP235x variants with in-package Flash, including RP2354A and RP2354B, are described as programmatically equivalent to versions without on-board Flash because the Flash is electrically connected like an external QSPI Flash device. The README therefore states that no additional HAL support is required for that distinction.

PIO has a separate path. Applications that need Raspberry Pi PIO state machines are directed to `pio-rs`, which can also compile PIO programs at run time on the MCU. That is a complement to the HAL rather than evidence that `rp-hal` itself exposes every PIO workflow in one interface.

What board support packages still need to define

Using the HAL alone is reasonable when the application can define its own pin mapping or when a board support package already exists. The limitation is concrete: the HAL drivers do not know what each IO pin on a physical board is connected to. For example, a UART example may demonstrate the peripheral API while still using a pin arrangement that does not match the user's board.

The README says the repository previously contained many BSPs, but those were moved out because of their number. Board-specific packages are now available separately. This separation can keep the core HAL smaller and allows a board package to express wiring and board-level decisions, but it also means that a new board may need its own configuration or a package maintained outside this repository.

The repository contains `rp2040-hal-macros` and `rp235x-hal-macros` as well as the device HAL crates. The README does not document the macro crates' public configuration surface, so they should be treated as internal project components unless their API documentation says otherwise. Similarly, the examples demonstrate usage patterns, not a guarantee that their pin assignments match a purchased board.

For firmware that depends on a specific LED, sensor, display, or connector, the first design question should therefore be whether the wiring is represented by a BSP or explicitly handled by the application. A peripheral driver can be available while the physical board setup remains unfinished.

Binary metadata, PIO, and release packaging

The repository includes `rp-binary-info`, a library for generating metadata compatible with Raspberry Pi's `picotool`. The documented metadata can include the program name and version number. This is useful when firmware is inspected or packaged with picotool, because Rust binaries can carry the same kind of identifying information as binaries produced for the Raspberry Pi toolchain.

`rp-binary-info` is separate from the device HALs. It does not replace peripheral drivers, target configuration, or flashing. The dependency choice depends on the artifact workflow: a firmware project that only needs GPIO and I²C does not need metadata support, while a project that produces bootable or UF2-oriented artifacts may need it.

The release list shows `rp2040-hal` version 0.12.0 and `rp235x-hal` version 0.4.0 dated 2026-02-01, plus `rp-binary-info` version 0.1.2 dated 2026-01-17. These are separate package versions, so selecting a HAL does not imply that the metadata package has the same version or upgrade schedule.

The repository is not archived. Its last push was on 2026-10-13. The README points to API documentation for both `rp2040-hal` and `rp235x-hal`, a demo repository, a bug tracker, and Matrix support. It does not document a compatibility matrix for every peripheral, board, or release combination, so upgrade planning requires checking the relevant crate documentation and project template.

Operational limits and the cost of ownership

The clearest failure mode is assuming that a successful HAL compile also means a working board program. A program can target the correct architecture and still use pins that are unavailable, connected to the wrong peripheral, or assigned to a function owned by another part of the firmware. The README specifically warns that example pin-outs may not match a particular board.

There is another package-level constraint. `rp2040-hal` and `rp235x-hal` target different chip families, and their versions are independent. Code written against one crate should not be assumed to compile unchanged against the other. The RP2350B's partial extra-pin support also means that a successful RP2350A path is not proof of full RP2350B coverage.

The repository contains `on-target-tests/`, but the README does not explain how those tests are run or what hardware matrix they cover. It also does not document rollback, production deployment procedures, or a stated long-term support policy. Maintenance cost for an adopter is therefore tied to Rust target upgrades, crate upgrades, board package maintenance, and verification against the actual hardware.

The repository identifies Apache-2.0 as its license, and the top-level files include `LICENSE-APACHE`, `LICENSE-MIT`, and `NOTICE`. The README does not explain which files or subcomponents fall under each license. An organization should inspect those notices and the crate metadata when combining rp-hal code with other dependencies.

Editorial conclusion

Adopt rp-hal for Rust firmware targeting RP2040 or RP235x when you need access to on-chip peripherals and can handle target-specific setup. Do not treat it as a complete board definition or a substitute for a board support package. Verify first that the selected chip variant, Rust target, memory layout, debug or bootloader path, and required peripherals are covered by the relevant project template and HAL documentation.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rp-rs/rp-hal on GitHub