Raspberry Pi Pico SDK 2.3.0 Ships: What Changed

Raspberry Pi Pico SDK 2.3.0 shipped on 2026-07-19, per the official pico-sdk GitHub releases page. The release covers both the original RP2040-based Pico family and the RP2350-based Pico 2, bundles updated CYW43 wireless firmware for the Pico W, ships incremental toolchain-integration fixes, and lands alongside a community demonstration turning a Pico W into a driverless USB WiFi adapter. Existing projects can stay pinned to 2.2.x; new projects should start on 2.3.0.

In brief — 2026-07-19 · Raspberry Pi shipped Pico SDK 2.3.0. RP2040 + RP2350 supported. New CYW43 firmware for Pico W networking. Incremental CMake and toolchain improvements. Not a breaking release, but touches the wireless stack, so any Pico W project should be re-tested after upgrade rather than assumed compatible.

What happened

The Raspberry Pi Foundation released version 2.3.0 of the Pico C/C++ SDK on 2026-07-19. This is the tenth minor release in the 2.x series and continues the pattern established by 2.1.x and 2.2.x: incremental updates that add capability without breaking the ABI or the CMake target surface that existing projects rely on. The release covers the full Pico lineup — the original 2021-era Pico with an RP2040, the wireless Pico W, the Pico H with pre-soldered headers, and the more recent RP2350-based Pico 2 and Pico 2 W boards.

Notable in the 2.3.0 changeset are updated CYW43 firmware and driver code for the wireless-equipped boards, an updated bundled TinyUSB with better composite-device support, and a set of small CMake improvements that clean up how external projects consume pico_sdk_import.cmake. Full release notes live at the pico-sdk GitHub releases page — read them before upgrading a shipped project.

Why it matters

For anyone with an active Pico project, the immediate question is whether to upgrade. The honest answer for anything already deployed is: not yet. Pin the project to the SDK version it was validated against and upgrade deliberately when you want a new capability, when a dependency needs it, or when you have time to re-test end to end. That is the standard embedded-toolchain hygiene, and SDK 2.3.0 is a minor release rather than a critical fix, so there is no urgency.

For new projects, starting on 2.3.0 is straightforward and gives you the current wireless stack, the current TinyUSB, and the current CMake integration. There is no realistic reason to start a fresh project on an older SDK in July 2026 unless you're following a tutorial that predates the release.

The parallel piece of community news worth mentioning is a widely-circulated demonstration on Adafruit's blog and elsewhere: turning a Raspberry Pi Zero W or Pico W into a driverless USB WiFi adapter — the host machine sees it as a standard USB Ethernet class device and connects through it without needing a driver install. This is a maker demo rather than a shipped product feature, and the Pico W's onboard CYW43 (updated by 2.3.0) is the wireless side of that trick. Read the Adafruit blog writeup for the full recipe before relying on it for anything load-bearing.

The source

Full release-notes and the changelog live at the pico-sdk GitHub releases page. The Raspberry Pi C SDK documentation has the getting-started material for anyone new. The Adafruit blog covers the driverless-adapter demo in more detail than we do here.

What to have on the bench

Building for the Pico family with SDK 2.3.0 is comfortable on any recent Linux, macOS or Windows machine, but a dedicated build host keeps the environment reproducible and speeds up the tight iterate-flash-test loop that RP2040/RP2350 work rewards. Our reference bench for this article:

• Build host: Raspberry Pi 4 Computer Model B 8GB. Runs Debian-based Linux, builds the SDK against ARM GCC in reasonable time, and stays powered on as a permanent flashing station. The 8GB RAM tier matters if you keep multiple project trees open at once — full builds of the SDK's examples plus a small application tree use several hundred megabytes of build cache.
• Companion Pico W kit: Vilros Raspberry Pi Zero W Basic Starter Kit. The Zero W is a useful companion for Pico projects that need a Linux side (SSH, longer-running processes, disk logging). The bundled case and power supply mean you can leave the Zero powered on next to the build host without extra hunting for parts.
• Toolchain storage: WD Blue SN550 1TB NVMe. Put the toolchain, the SDK checkout, and the build tree on fast storage. Compile times on slow SD media are the usual bottleneck, not CPU speed. The Pi 4 does not have onboard M.2, so this drive would sit in a USB 3 NVMe enclosure — still meaningfully faster than the SD card.

Boot the build host, install git, cmake, gcc-arm-none-eabi, and a text editor of your choice, clone the pico-sdk at the 2.3.0 tag, and you're ready to build.

Real-world numbers to expect

The Pico family's spec sheet has not changed with SDK 2.3.0 — a software release does not add cores or memory — but a few numbers are worth restating in the context of a fresh 2026 build:

The SDK 2.3.0 changelog matters most for the Pico W and Pico 2 W lines because the wireless firmware is the largest moving piece between minor releases. On the two RP2350 boards the M33 cores are meaningfully faster than the M0+ pair on the RP2040 (both at higher clock and with a more capable pipeline), which shows up in floating-point-heavy code — DSP filters, PID loops with fractional gain terms, and USB descriptor parsing all run several times faster on the M33. Neither MCU has hardware floating-point on the M0+ variant, so if you need FP performance, budget the RP2350.

The driverless USB WiFi adapter trick

The community demo circulating in the same week as 2.3.0 uses the Pico W's onboard CYW43 wireless chip as the radio and the RP2040's USB peripheral as a standard USB CDC/ECM Ethernet class device. Plug the Pico W into a host machine over USB and the machine sees a network interface without needing a driver install — the class-compliant CDC ECM endpoint enumerates on Linux, macOS, and modern Windows (11 24H2+ ships the driver in-box; older Windows will need a manual RNDIS variant).

Practical numbers, per the Adafruit writeup: throughput lands around 8–12 Mbps on WiFi 4 in a typical home network. That is not a replacement for a proper USB 3 adapter — a modern WiFi 6/7 USB stick will hit 500 Mbps+ — but it is enough for SSH, remote-shell work, browsing text, or bootstrapping a machine that came without wireless. The 15W-ish that a Pico W draws over USB is well within any host's port budget.

The tradeoff is latency and reliability: the CYW43 was designed as an embedded wireless radio for IoT-style traffic, and its firmware's handling of sustained streaming traffic (video, downloads) is less mature than a laptop-grade WiFi part. For anything longer than "get me an SSH session so I can install the real driver," use the real driver. As a recovery tool or a maker project it's genuinely useful.

Upgrade checklist

If you decide to move an existing project from 2.2.x to 2.3.0:

1. Do it in a branch, not on main.
2. Delete build/ entirely before rebuilding — stale CMake caches cause 80% of "the SDK broke my project" reports and are almost always the actual culprit.
3. Rebuild every configuration your project uses (release, debug, and any board-specific variants).
4. If Pico W is in the mix, run a full connectivity test against the actual access point your device will use — not a "clean" test AP. Wireless-stack regressions are the failure mode that hurts most.
5. Compare flash-image sizes before and after. A large size delta usually signals a linker-script change worth understanding before shipping.

None of this is 2.3.0-specific — it is the same drill for any SDK bump. Following it makes upgrades boring, which is the goal.

When NOT to jump to 2.3.0

There are two situations where skipping this release is the right call:

Production units already in the field. If you have deployed hardware — sensor nodes, kiosks, museum installations, art pieces — that is running against a validated 2.2.x SDK build, do not upgrade the firmware on those units purely to be on the current SDK. Firmware bumps introduce a small but non-zero risk of subtle behavior change, and rolling back a bricked unit that is halfway up a wall is a bad afternoon. Wait until you need a specific new capability, then bundle the SDK upgrade with a real feature push.

Long-running research code. Code that ships alongside a paper or is referenced in reproducibility documentation should stay pinned to the SDK version it was validated against. Reproducibility beats novelty here — anyone rebuilding from your instructions should get the same binary, and the SDK version is part of that. Note the pin in the README, mention it in the paper's methods section, and move on.

For everything else — active development, unshipped projects, new builds — 2.3.0 is the right choice.

Common pitfalls

• Assuming pinning works when it doesn't. If your CI clones the SDK by branch rather than tag, you are not actually pinned. Verify the checkout resolves to a specific commit before calling it stable.
• Trusting make incremental rebuilds. For the Pico SDK, make sometimes misses header changes that CMake would catch on a re-configure. Delete the build directory when you upgrade.
• Building on the Pico W target directly. You cannot build the SDK on the Pico itself — it's a microcontroller. Build on the host, flash the resulting UF2 file to the Pico. Newcomers to embedded work occasionally miss this.
• Ignoring firmware/driver split. CYW43 has a firmware component (running on the wireless chip) and a driver component (running on the RP2040/RP2350). SDK updates can touch either or both — check the release notes rather than assuming which side changed.

Worked example: a fresh 2.3.0 project

For anyone new to the Pico toolchain, a minimal 2.3.0 project looks like this. On a Raspberry Pi 4 host running Debian:

sudo apt-get install -y git cmake gcc-arm-none-eabi build-essential
mkdir ~/pico && cd ~/pico
git clone --branch 2.3.0 --recursive https://github.com/raspberrypi/pico-sdk.git
export PICO_SDK_PATH=$HOME/pico/pico-sdk
mkdir hello && cd hello

A minimal CMakeLists.txt for a Pico W blink-and-connect example is under 20 lines and calls out to pico_sdk_import.cmake from the SDK. Build with a standard out-of-tree mkdir build && cd build && cmake .. && make, and the resulting hello.uf2 file drags-and-drops onto the Pico's mounted BOOTSEL volume. First-boot success rate on 2.3.0 is high — the SDK's example CMakeLists have been iterated on for years and rarely regress. The failure modes when they do appear are almost always at the toolchain layer (missing gcc-arm-none-eabi, wrong path to the SDK), not the SDK itself.

Bottom line

Pico SDK 2.3.0 is a low-drama incremental release worth adopting for new projects and worth deferring on stable deployed ones until you have upgrade time budgeted. The wireless-stack updates are the most likely place to run into subtle behavior differences, so any Pico W code should be re-tested rather than trusted after upgrade. The parallel community demo turning a Pico W into a driverless USB WiFi adapter is a fun weekend build but not a supported product — treat it accordingly.

Related guides

• Best Raspberry Pi for Klipper in 2026: Pi 4 8GB vs Alternatives
• Qwen 3.8 Open Weights: What Fits on a 12GB GPU
• CompactFlash as a Win98 Boot Drive: Sizes, Limits, Gotchas

Citations and sources

• pico-sdk — GitHub releases
• Raspberry Pi — C/C++ SDK documentation
• Adafruit Blog

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.