TL;DR:
- The RP2350 chip in Raspberry Pi Pico 2 brings dual Cortex-M33 cores, hardware security (OTP, secure boot, TrustZone), and improved power management over the RP2040 — meaningfully expanding what’s feasible in low-cost edge sensing applications
- The Pico 2 W adds wireless connectivity, making it viable for standalone IoT sensor nodes at a price point that still undercuts most commercial alternatives
- MicroPython support is mature and the C/C++ SDK ecosystem has grown significantly; teams already on RP2040 should evaluate migration for new projects rather than design-starts
The original Raspberry Pi Pico was a surprise when it launched in 2021. A microcontroller from the Raspberry Pi Foundation at £3.60, with a dual-core ARM Cortex-M0+ chip, programmable I/O (PIO) blocks that nobody else had implemented in quite the same way, and an ecosystem built on top of mature C/C++ and MicroPython toolchains. It found its way into serious edge IoT applications alongside hobbyist projects.
The RP2350, launched in August 2024, is a more substantial upgrade than the naming suggests. Moving from Cortex-M0+ to Cortex-M33 is a meaningful architecture step. Adding hardware security features changes what you can deploy in regulated or security-conscious environments. And the RISC-V option — RP2350 can run either its ARM cores or two RISC-V Hazard3 cores — is an unusual engineering choice that has practical implications for teams with specific licensing requirements.
What’s New in RP2350
Dual Cortex-M33 cores at 150MHz. M33 is an ARMv8-M architecture. Against M0+, the main additions are DSP instructions, floating-point hardware, and TrustZone-M security extensions. For edge sensing applications, hardware floating point matters when you’re doing any kind of signal processing or sensor fusion. On M0+, floating-point operations fall back to software emulation; the performance difference for FP-heavy workloads is substantial.
Optional RISC-V cores. The RP2350 can run two Hazard3 RISC-V cores instead of the ARM cores. You choose at boot time. This is primarily useful for organisations with ARM architecture licence concerns, or developers who want to run open ISA toolchains throughout the stack. In practice, most teams will stick with the ARM cores and the existing SDK support, but the option is there.
520KB of SRAM. Double the RP2040’s 264KB. For edge AI inference on-device — running TinyML models locally — SRAM is often the binding constraint. 520KB opens up applications that weren’t viable on RP2040.
Hardware security: OTP and secure boot. The RP2350 includes 8KB of one-time programmable (OTP) memory for storing cryptographic keys, device identity, and boot configuration. Secure boot with signature verification means you can ensure only authorised firmware runs on the device. For industrial IoT deployments with tamper and integrity requirements, this is a meaningful addition. The RP2040 had essentially no hardware security; RP2350’s security model is still not as deep as purpose-built security MCUs, but it’s appropriate for a large class of edge deployments.
ARM TrustZone-M. The M33 architecture’s TrustZone support allows partitioning of firmware into secure and non-secure worlds. For IoT applications handling credentials or secure communications, this provides hardware-enforced isolation between security-critical code and application code.
Improved power management. The RP2350 has more fine-grained clock gating and sleep modes. For battery-powered sensor nodes where deep sleep current matters, the improvements are real. Exact numbers depend heavily on application configuration, but RP2350 can achieve sub-µA sleep current in optimised configurations.
The Pico 2 W for IoT Sensor Nodes
The Pico 2 W adds an Infineon CYW43439 wireless chip for Wi-Fi and Bluetooth LE alongside the RP2350. At a retail price of around £7, it’s positioned as a standalone wireless sensor node platform.
For edge IoT deployments where mains power is available or battery life requirements aren’t extreme, the Pico 2 W competes with ESP32 variants on price while offering a cleaner SDK, stronger Python support, and the RP2350’s hardware security features.
The SDK support for wireless on Pico 2 W has matured considerably since the original Pico W’s launch. MicroPython’s network module works reliably for Wi-Fi. Bluetooth LE support is available through the BLE stack. MQTT over Wi-Fi for telemetry is a common and well-documented deployment pattern.
Where the Pico 2 W loses to ESP32 is in community examples and third-party library breadth. The ESP32 ecosystem has had years more development. For teams starting a new design, both are viable; for teams inheriting a large MicroPython library of ESP32 examples, migrating isn’t cost-free.
MicroPython for Edge IoT
MicroPython on RP2350 is the practical choice for rapid prototyping and for teams whose primary skill is Python rather than embedded C. The MicroPython implementation for RP2040 and RP2350 is maintained by the Raspberry Pi Foundation with more attention than most MicroPython ports, which means it tracks CPython compatibility well and has fewer sharp edges.
For production deployments, the tradeoffs versus C/C++ are predictable: MicroPython is slower, uses more RAM, and has longer interrupt latency. For most sensor data collection and telemetry applications, these tradeoffs are acceptable. For real-time control loops with hard timing requirements, C/C++ is still the right choice.
The async programming model in MicroPython (asyncio in recent versions) works well for IoT applications that need to handle concurrent tasks: reading sensors on one coroutine, handling MQTT messages on another, managing Wi-Fi reconnection on a third.
Where RP2350 Fits in the Edge IoT Stack
The RP2350 competes in the low-end microcontroller category for edge sensing. It’s not an application processor — there’s no Linux, no Docker, no containerisation. It sits below devices like the Raspberry Pi Zero 2 W or CM4, which run full Linux distributions and handle more complex edge workloads.
The right division of labour in a typical edge IoT deployment:
RP2350 layer: Sensor reading, signal conditioning, local thresholding, communication with the next layer up. Time-sensitive tasks, interrupt-driven I/O, anything that needs hard real-time behaviour.
Linux edge device layer: Data aggregation, preprocessing, local inference for larger models, protocol translation, connection to cloud. Raspberry Pi CM4, NVIDIA Jetson, or equivalent.
Cloud/far edge layer: Long-term storage, training, fleet management, analysis that needs data from multiple edge nodes.
RP2350 fits at the bottom of this stack, and its price makes it viable for dense deployments — many sensor nodes per gateway.
Migration from RP2040
For teams already using RP2040 in production, RP2350 is pin-compatible in the Pico form factor and SDK-compatible at the API level. Migration for new projects is low-friction. For existing deployed hardware, there’s no reason to migrate running systems unless you need specific RP2350 features.
The PIO (programmable I/O) blocks have been extended in RP2350, with new instructions and additional state machines. PIO programs written for RP2040 should run on RP2350, but the additional PIO capability opens new possibilities worth reviewing if PIO is central to your design.