Raspberry Pi Pico 2 W Pinout: Every GPIO, ADC, and What Changed from Pico W

The Raspberry Pi Pico 2 W looks, at a glance, like a drop-in replacement for the original Pico W -- same 40-pin castellated layout, same board outline, same $7-ish price bracket. That similarity is mostly true, but it hides two changes worth understanding before wiring a project: the RP2350 chip underneath has meaningfully different ADC and PWM behavior than the RP2040 it replaces, and the debug pin position actually moved on the physical board, which has already tripped up people copying wiring photos from the original Pico 2 (non-wireless).

This guide covers the complete Pico 2 W pinout -- GPIO, ADC, PWM, I2C, SPI, and UART -- with specific attention to what changed from the Pico W and what silently stayed the same, so a MicroPython or C SDK project written for the older board ports over without surprises.

What Actually Changed From the Pico W

Before the pin-by-pin breakdown, the headline differences worth knowing:

The GPIO numbering and function assignment is, pin-for-pin, the same as the original Pico W. If you already have a Pico W project's wiring diagram, it applies directly to the Pico 2 W -- with the one exception of the debug header, which sits in a different physical location even though it carries the same three signals (SWDIO, GND, SWCLK).

Full GPIO Pinout Reference

The pinout continues symmetrically down the other edge of the board through GP16-GP22 and GP26-GP28 (the ADC-capable pins), with ground and the VBUS/VSYS/3V3 power pins along the top edge -- the full reference matches the silkscreen printed directly on the board, which is worth checking against physically since it's the fastest way to confirm orientation on a breadboard.

The Debug Pin Move (A Real Gotcha)

This is the change most likely to catch someone off guard, precisely because it's easy to assume "wireless" and "non-wireless" variants of the same chip generation share a board layout. They don't, at least not here: on the plain Raspberry Pi Pico 2, the three-pin SWD debug header sits at the bottom edge of the board. On the Pico 2 W, that same header is relocated to the center of the board, on the underside, to make room for the wireless module's antenna placement.

The signals themselves are unchanged -- SWDIO, GND, SWCLK, same order -- but if you're following a wiring photo or PCB footprint intended for the non-wireless Pico 2 and expecting it to also fit a Pico 2 W, it won't physically align. This matters most for anyone designing a carrier PCB meant to accept either variant interchangeably; the two need separate debug-header footprints unless the design deliberately omits the debug header from the layout.

ADC: 3 Usable Channels, One Internal

The RP2350's ADC is still 12-bit, same resolution as the RP2040, but the datasheet and multiple community teardown reports note improved reference stability on the newer silicon -- in practice this shows up as noticeably less jitter in analog readings without any code changes, which matters for projects reading low-voltage sensors like thermistors or light-dependent resistors where a few ADC counts of noise previously mattered.

One RP2350-specific detail worth knowing: GPIO 29, which functions as ADC3 to monitor VSYS, is not broken out to the header on the wireless variant the way it partially is on some non-wireless boards -- it's used internally to coordinate with the wireless module's power management. Don't plan a design around external access to that specific ADC channel on the W variant.

PWM: More Flexible Slice Allocation

The RP2350 keeps the RP2040's PWM architecture -- GPIOs are grouped into slices, each slice has two channels (A and B), and any two GPIOs sharing a slice output the same underlying frequency, though each channel within a slice can have an independent duty cycle. What's improved on the RP2350 is slightly more flexible slice-to-pin mapping in the updated SDK, giving firmware a bit more room to avoid conflicts when several PWM outputs are needed simultaneously (multiple servo channels, for instance).

# MicroPython -- basic PWM fade example on GP15
from machine import Pin, PWM
import time

led = PWM(Pin(15))
led.freq(1000)

while True:
    for duty in range(0, 65535, 512):
        led.duty_u16(duty)
        time.sleep_ms(5)
    for duty in range(65535, 0, -512):
        led.duty_u16(duty)
        time.sleep_ms(5)

Nearly every GPIO on the board supports PWM output -- the practical constraint is almost never "can this pin do PWM," it's "does this pin's slice conflict with another PWM signal I already assigned," which is worth checking against the SDK's slice-mapping table before finalizing a pinout for anything with more than 2-3 simultaneous PWM outputs.

I2C, SPI, and UART Pin Mapping

I2C: Two peripherals, I2C0 and I2C1, each mappable to several GPIO pairs. Defaults most commonly used: I2C0 on GP4 (SDA) / GP5 (SCL), I2C1 on GP6 (SDA) / GP7 (SCL). Any GPIO can theoretically be remapped to either peripheral in software, but only one bus instance of each peripheral can be active at a time -- you get two simultaneous I2C buses total, not more.

SPI: Similarly, SPI0 and SPI1 are available, each with flexible pin mapping. Common defaults are SPI0 on GP16 (MISO) / GP18 (SCK) / GP19 (MOSI) / GP17 (CS), and SPI1 on GP8 (MISO) / GP10 (SCK) / GP11 (MOSI) / GP9 (CS).

UART: UART0 and UART1, remappable, with GP0 (TX) / GP1 (RX) as the most common default for UART0 -- also the pair used for USB-serial style debugging in many project templates.

The Onboard LED: A WiFi-Chip Quirk That Carries Over

One behavior that trips up people new to the wireless Pico variants, unchanged from the Pico W: the onboard LED is not wired to a standard GPIO the way it is on the non-wireless Pico. It's connected through the CYW43439 wireless chip itself, on a line labeled WL_GPIO0. This means the simple machine.Pin(25, machine.Pin.OUT) pattern that toggles the LED on a plain Pico does nothing on the Pico 2 W -- instead:

# MicroPython -- correct LED control on Pico 2 W
from machine import Pin
import time

led = Pin("LED", Pin.OUT)  # Resolves to the WiFi-chip-routed LED automatically

while True:
    led.toggle()
    time.sleep(0.5)

Using the string "LED" instead of a numeric pin lets MicroPython resolve the correct underlying pin regardless of which Pico variant the code runs on -- this is the recommended, forward-compatible way to write LED-blink code for any wireless Pico board, and it's worth using even on the plain Pico 2 for portability.

Quick Reference: Safe First Picks

As with most microcontroller pinouts, starting a new project on the "safe first picks" and only reaching for more specialized pins once the simple options are exhausted keeps early debugging sessions from getting tangled up in peripheral conflicts that have nothing to do with the actual bug being chased.

The RP2350's Less-Obvious Feature: Hardware Security

Beyond the doubled RAM and flash, the RP2350 introduces a feature that doesn't show up in a pinout diagram but is worth knowing about for anyone building a product rather than a one-off project: hardware-backed security partitioning based on Arm TrustZone, plus support for signed boot. This lets firmware separate a "secure world" (handling things like credentials or cryptographic keys) from the main application code at the silicon level, something the RP2040 had no equivalent for.

For hobbyist projects this rarely matters day to day, but it's part of why the RP2350 positions itself as a more production-ready successor rather than purely a speed bump -- Raspberry Pi's own documentation frames it as suitable for commercial designs that need tamper-resistant credential storage, a category the original Pico line was never really aimed at. Also notable: the RP2350 supports both Arm Cortex-M33 and RISC-V Hazard3 cores on the same silicon, selectable at boot, though the Arm cores are what ship active by default and what nearly all existing MicroPython/C SDK tooling targets.

Power Pins and Supply Options

For battery-powered builds, VSYS is almost always the right connection point rather than VBUS, since VBUS is physically tied to the USB connector's 5V line and isn't meant to be back-fed externally. A LiPo-to-VSYS connection through a simple boost or buck-boost regulator, depending on the battery's voltage range relative to VSYS's 1.8-5.5V window, is the standard pattern for portable Pico 2 W projects.

Migrating an Existing Pico W Design

For anyone with an existing PCB or breadboard layout built around the Pico W, the practical migration checklist is short: confirm the debug header footprint accounts for the relocated center-position SWD pins if the design includes one, double check any code reading ADC3/GPIO 29 directly rather than through the standard VSYS-monitoring helper functions, and re-flash with firmware built against the RP2350 target rather than assuming the RP2040 binary will run (it won't -- the two chips require separately compiled firmware, even though the source code itself is typically unchanged).

Everything else -- GPIO numbering, I2C/SPI/UART defaults, the physical 40-pin castellated footprint for through-hole or SMD mounting -- carries over directly, which is by design. Raspberry Pi's stated goal with the Pico 2 line was pin-compatible continuity specifically so existing carrier boards and enclosures wouldn't need a redesign just to take advantage of the faster chip.

Quick Answers to Common Pico 2 W Pin Questions

Does existing Pico W MicroPython code run unmodified on the Pico 2 W? Almost always, yes, for anything using standard GPIO, I2C, SPI, ADC, and PWM calls -- the pin numbering and API are identical. The main things to double check are code that reads GPIO 29/ADC3 directly (behaves slightly differently, as noted above) and any firmware built specifically against the RP2040 target rather than RP2350 in the build system.

Can I use a Pico W's debug probe cable on a Pico 2 W? The cable itself works fine; what changes is where you connect it, since the header physically moved to the board's center on the W variant. Check the silkscreen or this guide's diagram before assuming a Pico 2 (non-W) debug photo applies.

Is the Pico 2 W's WiFi range or performance different from the Pico W? No -- both use the same Infineon CYW43439 wireless chip, so WiFi and Bluetooth performance is effectively identical between the two boards. The performance improvements on the Pico 2 W are entirely on the processing side (RP2350 vs RP2040), not the radio.

Where to Go From Here

Once the relocated debug header and the GPIO-29/ADC3 quirk stop being surprises, migrating an existing Pico W project over is mostly a firmware-target change rather than a rewiring job — the GPIO numbering, I2C/SPI/UART defaults, and 40-pin footprint all carry over directly. From there, the RP2350's hardware security features covered above are worth exploring the moment a project moves from a one-off build toward something meant to ship, since that's the use case they're actually aimed at.