I don't really get it. It's not even competitive with an ESP32 -- it has no communications at all.
>Before the end of the year, we expect to ship a wireless-enabled Pico 2 W, using the same Infineon 43439 modem as Pico W, and versions of both Pico 2 and Pico 2 W with pre-installed 0.1-inch headers.
Raspberry Pi Foundation released a RP2040 based dev board(Pico W) with an additional external wireless chip, as have others(including boards with an additional ESP32 just do comms).
A CPU just plain can't do this. Even if you want to pretend it's one cycle per pixel the realtime constraints at higher resolutions are way out of the realm of feasible. We struggle to do CPU driven audio in realtime as-is (Audio is measured in Khz of bandwidth rather than Mhz).
You can do this at very low resolutions easily enough (again it's exponential with resolution increase) but then you have a low resolution screen.
I worked with an ST Micro processor and small TFT display. The routine to write to the screen was to save the contents to RAM and then point a graphics renderer to that RAM. Double and triple buffering were required to avoid screen tearing (screen update with partial previous and next screen mixed.)
(And, like the predecessor Pi Pico, a version with wireless will be coming later.)
That, and it's super well documented and easy to get code running on it.
ESP32 is a great complement to it though for projects needing wifi or BLE
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.
https://hackaday.com/2014/08/26/new-chip-alert-the-esp8266-w...
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?
Are people in this thread just misguided in saying the esp doesn’t have Pio or am I missing something?
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.
https://www.raspberrypi.com/news/what-is-pio/
https://tutoduino.fr/en/pio-rp2040-en/
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.
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.
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.