Before trying iroh on RP2350, check the board behind the demo

Image: Raspberry Pi Ltd, RP2350 documentation photograph, CC BY-SA 4.0. Original file unchanged. Actual RP2350 chip, showing its marked top and underside, from Raspberry Pi documentation. This is a hardware reference, not the Pimoroni Presto assembly, an iroh connection test or a PING photograph. Capture date and individual photographer are unstated. Exact image source · Documentation permission · Licence.

A networking demo running on a tiny processor can make a project look close to finished. Before choosing a board around it, find out what else made the demonstration work. Raspberry Pi's new spotlight on iroh is useful for that exercise: the same RP2350 chip appears in several products, but the wireless connection, memory and software environment belong to a particular setup.

Raspberry Pi published its account on 6 November, pointing to iroh running on Pimoroni's Presto. Ruediger Klaehn's linked engineering account is dated 14 September and calls the work a proof of concept. This is a new manufacturer spotlight on an existing experiment, not a newly launched networking board or evidence of a finished product. Raspberry Pi's account · Original engineering account.

Start with the exact board

Klaehn distinguishes the Presto, with Wi-Fi and a touchscreen, from a bare Pico 2 without Wi-Fi. His account reports a basic hello example on Pico 2; he says a Pico 2 W was unavailable for testing. Do not turn that expectation into a completed Pico 2 W demonstration. The successful echo connection is described on Presto, whose extra hardware matters to the result.

Raspberry Pi's current documentation identifies RP2350 as a microcontroller used in Pico 2-family boards and other manufacturers' designs. Our photograph shows that actual chip, not a whole development board. It helps identify the hardware family while keeping the missing assembly visible. A shared processor name does not establish that two products have the same radio, memory or display. Chip documentation source.

Read the software environment as part of the design

The repository describes an experimental Rust standard-library environment for Presto, combining a custom target with the Pico SDK, FreeRTOS and a networking stack. This is not an ordinary desktop application copied onto a board. The README lists host prerequisites and specific dependency revisions; its working host setup was tested on Apple Silicon macOS. PING has not built, flashed or run this code. Current project README.

External memory is another part of the reported implementation. The engineer describes using Presto's PSRAM for Rust allocations, while other system work remains in internal memory. The screen and networking also compete for resources. Those details explain why the assembled example needs to be understood as a system; they do not establish throughput, battery life or reliability for a reader's own device.

Keep an experiment separate from a support promise

The engineering post offers contact for production support, while the current repository describes this code as a proof of concept rather than a production-supported Rust target. Those are different statements. An offer to discuss support does not make the example a guaranteed deployment path. Ask which board, software revision and maintenance arrangement a supplier would actually support before treating an experiment as a project dependency.

Include configuration in the handover

The README warns that its Wi-Fi configuration is embedded in the firmware image, so the resulting ELF file contains the password and must be treated as sensitive. A shared source repository and a compiled demonstration therefore need different handling. Before passing a build to another person, establish what configuration it contains and how the receiving team supplies its own. This article does not inspect anyone's credentials or execute flashing commands.

For a maker working with a classroom in Accra, a workshop in Nairobi or a collaborator in London, begin with the actual equipment available to the receiving person. Record the board model, external components, source revision and intended test. Agree what counts as a successful demonstration, then keep the observed result beside that setup. These are suggested working habits, not claims about local stock, service availability or measured performance.

The next useful question is small: can the intended team reproduce the particular example on its own documented hardware? A photo of the chip cannot answer it, and a connection reported by the author cannot replace that check. Keep untested variations and unresolved dependencies visible instead of extending one result to every product in a processor family.

The value of this port is the engineering path it exposes, with its boundaries still attached. Read the source before choosing the shortcut. For another distinction between a useful maker resource and a finished project, see PING's Steam Frame CAD guide.