PIO (Programmable I/O) support for RP2040 / RP2350 — proposal + working prototype

[begeistert]

Hi! I've built PIO (Programmable I/O) support for RP2040 / RP2350 in nanoFramework and would love to contribute it upstream — opening this to gauge interest and figure out the preferred path before a formal feature request.

The gap

Today a Pico app can do GPIO / I2C / SPI / PWM / ADC from C#, but PIO — the chip's headline feature — isn't reachable at all. PIO is the reason people reach for a Pico: WS2812/NeoPixel, custom serial protocols, precise timing, quadrature decoding, DPI/HUB75, etc. There's also no managed way to author PIO programs (other approaches force the external pioasm tool + a raw ushort[], which loses the program metadata the runtime needs).

What I have (working prototype)

• An in-CLR inline PIO assembler — write PIO programs in C# with a fluent / System.Reflection.Emit-style builder (no external pioasm, no raw ushort[]), byte-exact vs pioasm (golden tests). It returns a rich PioProgram (wrap / side-set / shift metadata) that seeds the state-machine config automatically.
• A thin runtime API (Pio / PioBlock / PioStateMachine) backed by InternalCall native interop in nf-interpreter, version-aware for RP2350 PIO v1 (3rd block PIO2, FIFO PUTGET join, GPIO base).
• Validated end-to-end: byte-exact golden tests, behaviour on an RP2040/RP2350 emulator, and on real silicon — a Pico 2 blinking & fading its on-board LED via a C#-assembled PIO program running through the nanoCLR.

// Assemble a PIO program in C# (byte-exact vs pioasm), then run it on a state machine:
PioBlock pio   = Pio.Get(0);                       // 0..1 (RP2040) / 0..2 (RP2350)
uint offset    = pio.AddProgram(ws2812);           // loads instr memory, relocates JMPs
PioStateMachine sm = pio.ClaimStateMachine();
sm.Init(offset, PioStateMachineConfig.FromProgram(ws2812, (int)offset)  // wrap/side-set/shift auto-applied
                    .SideSetPins(2).OutPins(2, 1).ClockDivisor(15.625f));
pio.InitGpio(2);
sm.SetConsecutivePinDirs(2, 1, true);
sm.Enabled = true;
sm.Put(grb << 8);                                  // CPU just feeds the FIFO; the SM bit-bangs in hardware

Proposed shape

A nanoFramework.Hardware.Rp2040 library (same pattern as nanoFramework.Hardware.Esp32.Rmt, a chip-specific programmable-timing peripheral) + the PIO native in nf-interpreter, bound by the usual MDP checksum/version stubs.

Questions for the team

1. Is there interest in upstreaming PIO support for the RP2040/RP2350 family?
2. Preferred structure — a new nanoFramework.Hardware.Rp2040 org repo + the native in nf-interpreter?
3. How would you like the RP2350 PIO-v1 version-awareness handled?

I have a feature request drafted and runnable demo samples (WS2812 / blink / fade), and I'm happy to open the formal issue, split the work into the managed-library PR(s) and the nf-interpreter native PR(s), and demo the silicon run. Thanks! 🙏

[begeistert]

Quick update — I've published runnable demo samples with end-to-end validation:

https://github.com/begeistert/nf-rp2040-pio-samples — WS2812 / Blink / Fade.

Each sample is a tiny nanoFramework app that assembles its PIO program in C# at runtime. They come with
per-sample integration tests that boot the deployed app on the RP2040 nanoCLR inside an emulator
(no physical board needed) and assert it drives the PIO — and CI runs them on every push ✅. The
headline ones are also confirmed on real silicon: a Pico 2 blinking and fading its on-board LED through
the nanoCLR.

Happy to walk through any of it, and to open the formal feature request whenever there's interest. 🙂

[Ellerbach]

Great! You can then move those to the Samples repository once nf-interpreter and the managed side will be merged. We can add a specific category just for Pico devices!

[Ellerbach]

And further forward, similar as we have in the IoT.Device repository specific bindings for ESP32, you can definitely convert those DHT and WS led drivers into real bindings. We even have a naming convention for those :-) Really cool!