iroh Reaches RP2350, but a Networking Port Is More Than a Radio
Published November 8, 2026

A Raspberry Pi Pico 2 board for hardware context, not the running Presto demonstration. The bare Pico 2 does not include Wi-Fi.
Raspberry Pi highlights iroh on RP2350. The earlier engineering account explains standard-library assumptions, board differences and proof-of-concept limits.
A microcontroller can have enough computing power for an interesting application and still run into a much less glamorous obstacle: the networking library expects an operating environment the board does not provide.
That is the useful part of iroh's RP2350 demonstration. Raspberry Pi highlighted the port on November 6, but the original engineering account dates to September 14. This is a newly highlighted proof of concept, not a new microcontroller, a finished Raspberry Pi SDK feature or a production-ready drop-in networking package.
The Library Wants More Than a Radio
iroh is a Rust networking stack intended to be embedded in applications. Bringing it to a small device is not simply a matter of attaching Wi-Fi. The original account explains that iroh does not currently support Rust's no_std environment, the stripped-down setting often used for microcontroller software.
One possible response would be to maintain extensive patches. The author instead explored a way to provide the standard-library environment the networking stack expects. That choice is interesting because a working demonstration and a maintainable port are different achievements.
The public example repository is the appropriate starting point for inspecting the implementation. It should be read alongside its dependencies and current instructions, rather than treated as evidence that every RP2350 application can enable the same features with one configuration switch.
Original conceptual stack diagram, not a wiring guide or a claim that all transports were tested.
Two Boards, Different Connections
The development account discusses both a bare Raspberry Pi Pico 2 and Pimoroni's Presto. The Presto demonstration uses Wi-Fi and a touchscreen. The bare Pico 2 does not acquire Wi-Fi simply because the same processor can run networking software.
A processor, a board, a radio and a software transport are separate parts of a system. Identifying which example uses which connection is essential before ordering hardware or adapting a design.
The supporting Pico 2 photographs show a real board for hardware context. They are not photographs of the Presto demonstration or proof that the photographed board is running iroh.
General Capability Is Not a Tested Transport List
Raspberry Pi describes iroh's broader ability to connect devices over different kinds of links. Its article identifies Wi-Fi for the Presto demonstration. That should not become a claim that the RP2350 port has independently demonstrated cellular, Bluetooth LE and LoRa operation in this project.
For a maker evaluating the example, the first questions are concrete: which board is the target, which connection is used, what runtime provides the required facilities, and which parts of the example remain experimental? The answers belong in the repository and engineering notes, not in an imagined universal compatibility table.
Likewise, a secure networking building block does not automatically make the complete product secure. Application behavior, credentials, updates and the surrounding software still need appropriate attention. This report does not claim an independent security audit of the port.
Underside of a Pico 2 board, for hardware identification only; not evidence of software running.
Why the Port Is Worth Reading
The interesting result is that a substantial Rust networking stack can be made to work within a small embedded system by addressing its operating assumptions. That is more transferable than a promise that one demonstration has solved mesh networking for every board.
The author's own description remains a useful boundary: a proof of concept. Makers can inspect real code and a real engineering account while keeping the distance between "it runs" and "it is ready for my deployed device" in view.
What has been the biggest obstacle when moving a library onto a smaller device: memory, operating-system assumptions or the connection itself? Tell us in the comments below.


Comments
Member comments are temporarily unavailable.
Log in to join the discussion.