embassy-rs/embassy · error

Invalid PIO_NO: , expected one of 0,1,2

Error message

Invalid PIO_NO: {}, expected one of 0,1,2

What it means

embassy-rp's PIO state plumbing maps each PIO type (PIO0/PIO1/PIO2) to a static state instance via a match on `Self::PIO_NO`. The `_` arm is unreachable for valid PIO numbers, so it panics with the PIO_NO value and the list of valid values — 0,1,2 on RP235x (this arm), 0,1 on RP2040. Reaching it means the PIO_NO type-level constant is invalid or a platform mismatch occurred.

Solutions

1. Check your target/feature flags: `rp2040` vs `rp235x` builds define different valid PIO sets
2. Ensure you only instantiate Pio<PIO0>/PIO1 (and PIO2 only on RP235x)
3. If using cyw43-pio or another driver, verify the selected PIO instance exists on your chip
4. Report as a bug if reached with a legitimate PIO instance — this arm should be unreachable

Example fix

// before (rp2040 target)
let pio = Pio::new(p.PIO2, Irqs); // PIO2 does not exist on RP2040
// after
let pio = Pio::new(p.PIO1, Irqs); // or build with rp235x features

#[cfg(feature = "_rp235x")]
const _: () = assert!(PIO_NO <= 2);
#[cfg(not(feature = "_rp235x"))]
const _: () = assert!(PIO_NO <= 1);

When it happens

Trigger: Compile-time misuse where a PIO constant other than 0/1/2 reaches the match (essentially an internal invariant violation), or platform/feature mismatch where code built for RP235x uses a PIO number not defined for that target.

Common situations: Feature-flag mix-ups (building `_rp235x` code against RP2040 PIO abstractions); hand-rolled PIO trait impls with a wrong PIO_NO; this panic surfaces when cyw43-pio or other drivers reference PIO state on a mismatched target.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• pin is outside the PIO's GPIOBASE window .. ; use…
• All pins must either be <32 or >=16, in
• Failed to load PIO program
• Invalid PIO_NO: , expected one of 0,1
• Can only take the executor once

AI-assisted analysis of embassy-rs/embassy@463a07b963 (2026-09-10). Data as JSON: /api/errors/fd6a0766d8362ef4. Report an issue: GitHub.

Appendix: source

Thrown at embassy-rp/src/pio/mod.rs:1645

            1 => {
                static STATE_1: State = State {
                    users: AtomicU8::new(0),
                    used_pins: AtomicU64::new(0),
                };

                &STATE_1
            }
            #[cfg(feature = "_rp235x")]
            2 => {
                static STATE_2: State = State {
                    users: AtomicU8::new(0),
                    used_pins: AtomicU64::new(0),
                };

                &STATE_2
            }
            #[cfg(feature = "_rp235x")]
            _ => panic!("Invalid PIO_NO: {}, expected one of 0,1,2", Self::PIO_NO),
            #[cfg(not(feature = "_rp235x"))]
            _ => panic!("Invalid PIO_NO: {}, expected one of 0,1", Self::PIO_NO),
        }
    }
}

/// PIO instance.
#[allow(private_bounds)]
pub trait Instance: SealedInstance + PeripheralType + Sized + Unpin {
    /// Interrupt for this peripheral.
    type Interrupt: crate::interrupt::typelevel::Interrupt;
}

macro_rules! impl_pio {
    ($name:ident, $pio:expr, $pac:ident, $funcsel:ident, $irq:ident) => {
        impl SealedInstance for peripherals::$name {
            const PIO_NO: u8 = $pio;
            const PIO: &'static pac::pio::Pio = &pac::$pac;

View on GitHub (pinned to 463a07b963)