The ESP32 is a fine series of MCUs, but it doesn't have PIOs, a choice between ARM and RISC-V (or both!), 5v-tolerant IO -- to name a few things that this new RP2350 provides.
There's a ton of stuff in the world that uses an MCU and doesn't have wireless, and that would not benefit from having wireless.
But if RP2350 features and wireless are both necessary today, then nothing but a few schekels and some space on the board stops anyone from integrating those things. One can have both.
Remember, even the ESP8266 was first seen in English-speaking DIY circles as just a way to add wifi to things like Arduino projects and not so much as a capable, programmable MCU itself.
There’s multiple people saying this so I’ll just ask politely. Every esp has a multitude of gpios. The esp8266 mentioned is almost entirely gpios on its pin out. I’ve used these extensively and it’s great for flexibility. From led indicators to full on activating a relay.
You say it’s not the same as the pi’s pios. So I’ll ask. What does the pi do here that the esp doesn’t?
The PIOs are state machines that let you develop custom peripherals that run asynchronously, not taking up CPU time. You could probably bitbang some custom peripherals on an ESP32/ESP8266, but that takes up a lot of CPU time and power.
The RP-series PIOs are little programmable IO controllers. They can do can do their own thing, running independently of the software running on the MCU's CPU core, which allows them to work in tight little loops with very precise and predictable timing.
People use PIOs to do all kinds of things.
For instance, here is a method for using RP2040 PIO to produce VGA signals, using nothing but a Pi Pico, some jumper wires, and a few resistors on a breadboard: https://vanhunteradams.com/Pico/VGA/VGA.html
I myself have used RP2040 PIO to get a consistent PWM output in what was a bit of a boondoggle. I was working in Micropython, and the documentation for that said it supported hardware PWM output on this hardware, but that output was affected by the code in my main loop and was glitchy in ways that I found to be unusable. Rather than investigate the apparent issue with Micropython, I instead put together a thing in RP2040 PIO assembler that produced adjustable PWM with absolutely perfect consistency regardless of whatever I was doing in software.
And at least in my own example: The performance hit of doing this was zero since PIO is a dedicated hardware block that handles jobs like this in any way that I can program up.
Now, sure: I'd rather have used hardware PWM because that's simpler for me. And the ESP32 does have hardware PWM. But that PWM block only does PWM -- it can't be adjusted to do other things, whereas the RP-series PIOs can run arbitrary code to handle IO tasks. (So why didn't I pick an ESP, instead? That's easy enough to explain: I already had a Pi Pico in-hand.)
---
Meanwhile, as a general construct: There is absolutely zero reason to fanboy one MCU platform over another. It is absolutely OK that there are multiple competing inexpensive DIY-friendly-ish things in this space. This isn't Highlander. This isn't the fucking Super Bowl or the World Cup. There can be more than one.
You're missing something but it's actually easy to get confused about.
GPIO: general purpose input/output. A pin that can be used by the main CPU core(s) to interrogate the outside world.
PIO: programmable input-output. A small, I/O dedicated state-machine that can be custom-programmed in a minimal assembly language to handle I/O tasks/simple protocols/state management, over GPIO/I2C/SPI etc., without taxing the primary CPU.
Some microcontrollers have basic features a little similar, but it's something the RP series is taking a lot more seriously than most. The RP2040 has eight of these PIO state machines; the RP2350 has 12.
There are some astonishing examples of what these things can do. But basically think of these as delegated GPIO/SPI/I2C etc. co-processors that can blaze away at high speeds on I/O tasks without needing the main cores until something "high-level" occurs.
Makes sense. I’ve worked a lot with multipurpose gpio that can also be configured as spi or i2c but this is another step beyond that. Thanks to everyone for this!
(And, like the predecessor Pi Pico, a version with wireless will be coming later.)