Raspberry Pi’s first foray into the world of microcontrollers, the RP2040, was a very interesting chip. Its standout features were the programmable input/output units (PIOs) which enabled all sorts of custom real-time shenanigans. And that’s not to discount the impact of the Pi Pico, the $4 dev kit built around it.
Today, they’re announcing a brand-new microcontroller: the RP2350. It will come conveniently packaged in the new Pi Pico 2, and there’s good news and bad news. The good news is that the new chip is better in every way, and that the Pico form factor will stay the same. The bad news? It’s going to cost 25% more, coming in at $5. But in exchange for the extra buck, you get a lot.
For starters, the RP2350 runs a bit faster at 150 MHz, has double the on-board RAM at 520 kB, and twice as much QSPI flash at 4 MB. And those sweet, sweet PIOs? Now it has 12 instead of just 8. (Although we have no word yet if there is more program space per PIO – even with the incredibly compact PIO instruction set, we always wanted more!)
As before, it’s a dual-core chip, but now the cores are Arm Cortex M33s or RISC-V Hazard3s. Yes, you heard that right, there are two pairs of processors on board. Raspberry Pi says that you’ll be able to select which style of cores runs either by software or by burning one-time fuses. So it’s not a quad core chip, but rather your choice of two different dual cores. Wild!
Raspberry Pi is also making a big deal about the new Arm TrustZone functionality. It has signed boot, 8 kB of OTP key-storage memory, SHA-256 acceleration, a hardware RNG, and “fast glitch detectors”. While this is probably more aimed at industry than at the beginning hacker, we’re absolutely confident that some of you out there will put this data-safe to good use.
There is, as of yet, no wireless built in. We can’t see into the future, but we can see into the past, and we remember that the original Pico was wireless for a few months before they got the WiFi and Bluetooth radio added into the Pico W. Will history repeat itself with the Pico 2?
We’re getting our hands on a Pico 2 in short order, and we’ve already gotten a sneak peek at the extensive software toolchain that’s been built out for it. All the usual suspects are there: Picotool, TinyUSB, and OpenOCD as we write this. We’ll be putting it through its paces and writing up all the details next week.
I don’t know, little hard to get excited about this. Sure the spec bump is nice, and I imagine there’s a valid application for the core selection out there (even if I don’t know what it is). But now it’s more expensive and STILL doesn’t include wireless? Plus whenever they do the inevitable Pico 2 W, it will surely be like the last one, with a separate wifi chip that makes integrating it into your own projects much harder.
depending on package and whether or not it includes on-chip flash, its only 10-40 cents more expensive than the 70cent/pc RP2040
Using a separate chip for WiFi means that their microcontroller won’t be obsolete next year.
Umm, microcontrollers don’t need a ton of bandwidth and wifi can fall back to older standards. The ESP chips only support 2.4GHz wifi and they aren’t obsolete. Why they haven’t made something like one of the ESP chips blows my mind, unless they just aren’t capable of designing that RF magic on silicon.
RF is much harder to design in silicon than logic, and implementing the entire 802.11 WiFI standard from scratch on top of that and then getting it all tested for standards compliance access the whole world is also its own minefield. So yeah, it seems pretty reasonable that they’d use a separate chip for WiFi and focus on what they can do well, it looks like they’re avoiding having internal flash for the similar reasons. It might even all be limitations with the fab they’re using, the process node might not be favorable to creating transistors with the performance needed for RF
Lol, people were doing the same “ho hum, no wireless, this sucks” with the RP2040 and yet it turned out to be one of the most flexible, powerful and well documented microcontrollers available to date.
If you want integrated wireless, just get an Espressif chipset and be happy, there’s no need to whinge. Those of us who appreciate such things will happily be making awesome things with this new chip that aren’t just “stick something on the network”.
There is the 2040 based Pico W which has Wifi onboard. I have 4 of them doing different things.
Why do you even want wireless in a generic MCU?!? What most MCU use cases need is hard real-time, and software wireless stack, as in ESP32, is very much at odds with anything real-time.
I cannot think of a single case where I needed an MCU with an integrated wireless support. And I build a lot of stuff with MCUs and FPGAs.
+1
+1. And once RF is added to a product, your regulatory check boxes increase massively. The paperwork is often just not worth the feature.
More Info:
https://dmitry.gr/?r=06.%20Thoughts&proj=11.%20RP2350
It seems that the pure numbers when comparing the features don‘t even begin to actually describe the real improvements…
A quick nosey shows a few other fun things, including an on-board LDO/switch-mode supply and UART boot. No idea what I’d do with the RISC-V cores, but as someone else pointed out that’s a nice low-risk way to release a RISC-V device without a separate SKU which might not be popular.
The ARM cortex M33 cores are ARMv8 architecture, or 64 bit. But does anyone know what those Harvard3 RISC V cores are? Are they 32 bit, or are they 64 bit?
It’s an open-source core, it’s fully defined on GitHub:
https://github.com/wren6991/hazard3
Cortex-M33 is 32-bit, and implements the Armv8-M architecture. Think of it as a Cortex-M4 with TrustZone bolted on.
According to Arm, the M33 core can be up to 50% faster per MHz, compared to the M0+ core. In addition to the faster clock, the RP2350 might be up to 70% faster on standard operations, than the 2040.
https://www.arm.com/products/silicon-ip-cpu/cortex-m/cortex-m33
It’ll be nice to have Thumb2 and a Divide instruction!
“there are now RP2350 variants with built-in flash! They are called RP2354A nd RP2354B and they include 2MBytes of flash in-package.”
Sweet orca of Mallorca, I’m redesigning my stuff right now. I’m lazy and don’t have much space on the board. So I didn’t go for the RP2040. This changes everything for me.
This does simplify a lot.
I’m one of those people for whom the design burden of the QSPI flash kept me buying the Picos instead of the 2040s. (I know, maybe it’s just laziness.)
You are not alone.
This was the main dealbreaker for me. I know it might be silly but since everything else is so simple and accessible why not have the memory built in so I don’t need to worry about extra chips there.
Having worked with stm32 and qspi and that special hell the external loaders are I might have been biased from the get go…
As far as prices concerned I live in Canada and price that they always give on the raspberry pies and the Pecos are never what I see that I can get. So as far as I’m concerned this $5 thing is nothing but BS.
It’s always nice to have cheaper stuff but $5 USD is different from $5 CAD (worth more to more people) and that’s a hard thing to argue with.
The actually kind of silly thing is quoting the cost of Pi ‘Model-B’s without the supporting power supply and connectors. But its only silly from the perspective of their original mission which is way out the window now.
What are you smoking, Prrry? The Pico is currently selling from the official distributor in Canada for US$4.11.
And if you need ~500 of them for a conference, they’re even cheaper by the reel, and with no availability problems that we’ve seen.
Me: they have to have added USB 2.0 at this point, right
(checks specs)
“1 × USB 1.1 controller and PHY, with host and device support”
…
damnit!
I don’t think anyone was ever able to implement ULPI on the RP2040, but they did expand the PIO capabilities now. I don’t think it’s enough, but who knows. Even a soft ULPI interface through the PIOs would be fine, USB PHYs aren’t expensive. Yes, you could use a secondary interface chip, sure, but then they’re defining the various interfaces.
Frustrating as heck that a chip that can push in/out data at very high speeds is so bottlenecked at the USB side. Always surprised me that the common reaction when I mention it is “that’s not what this chip is for” – really? You can pretty trivially capture ~1 Gb/s data with the PIOs, but then the cheapest way to get the data off is probably to dump it to a microSD card in some sort of super-weird shared interface.
Agreed… that was the first thing I looked for.
Aside from the feature I most wanted, it’s a nice upgrade IMO, though…
I’m wondering if it’s some licensing issue or silicon IP core cost or something. It’s definitely not silicon area, since they were perfectly fine with dropping double the processor cores on the thing.
Just weird because it seems like having a small team look into what’s needed to adapt the PIOs to ULPI and the software stack for it seems like a better use of developer time than writing support code for an entirely different architecture (although the RISC-V core inclusion almost certainly is because they’re planning on moving to RISC-V solely in the future).
An actual USB2.0 HS PHY is quite costly in silicon area. The driver transistors are massive. It’s comparable to a simple CPU core in 40nm…
Modding an USB FS core to talk to an external PHY at HS speeds is relatively simple, but it is unlikely to be useful. Most of these simple device cores use a small amount of dual-port RAM to read and write data to the endpoints. This is fine at 12mbps but will be a big bottleneck at 480mbps.
You will need to add some form of streaming DMA to be able to exploit the way higher speed. Then you are getting into a seriously complex core with a lot of verification.
These new picos have the speed, the DMAs, and the ram to run USB 2.0 HS. What is missing is a USB controller with a ULPI. That way you can have the HS functionally but you only pay for it if you need it via the external transceiver. For instance this is exactly how USB HS is implemented in STM32H5/7.
“It’s comparable to a simple CPU core in 40nm…”
How about 2 of them? Because like I said, the RP2350 ends up with two totally unused CPU cores within a handful of microseconds, so I don’t think die size is the issue.
Yes, obviously, a full PHY is big, which is why I said a soft ULPI interface through the PIOs would be fine. You’d need to add quite a bit to the PIOs, I think (easy external clocking, probably) but those would be an impressive addition anyway.
“You will need to add some form of streaming DMA to be able to exploit the way higher speed. ”
Are we talking about the same chip here? The one that, y’know, has a full streaming DMA system? And whose predecessor could trivially integrate with ADC chips pushing over twice the amount of data that USB can?
The RP2040 can overwhelm an FT232H easily, so that’s not the issue. And yes, obviously, you could just add the FT232H, but then the FT232H is defining the USB interface.
My spidey-sense says it’s a licensing cost issue, since it’s the only thing that’d explain everything.
not much detail but some answer here https://forums.raspberrypi.com/viewtopic.php?p=2243021#p2243021
You’re implying taping out two completely different dies just to fit their SKUs is free. It’s absolutely not, and probably cost way more than the die area increase associated with USB 2.0 phy. They most likely had a physical footprint they needed to meet and had to cut some things out.
By the way, according to their website, you can select in software if you’re booting dual RISC-V or dual M33, so it’s not like they could’ve removed these and keep this feature anyway
The reason I said die size wasn’t an issue is that I would be absolutely gobsmacked if the whole RISC-V/ARM combined cores thing provides more of a draw for customers than adding a USB 2.0 or ULPI interface. I mean, Dmitry flat out said “eh, I like the ARM cores so I just stuck with them” whereas I guarantee he would’ve tested out a USB 2.0 interface if it was there.
I do understand the likely reason why it ended up this way – adding the RISC-V cores is basically just a drop-in core they have free access to, and the IP core they have for USB doesn’t do high-speed, and trying to interface that stock IP core to their (in-house) PIO stuff would require a level of engineering and testing that’s probably pushing it for them. It’s just unfortunate.
I’d suspect there is a “cost” both in silicon area (as somebody said the USB2-capable drivers are huge), power, IP-cost (more for mixed-signal particular stuff than the digital controller logic; that should be basically ‘trivial’), Area also needed for some additional tightly coupled SRAM as EP data buffers. I don’t think it needs to be any special SRAM, probably doesnt need to be dual-ported but probably dual-banked for double-buffering, with some DMA logic attached.
But besides area and mixed-signal components, I also suspect (just a guess) that the other main inhibitor might be requirements on special processes. Much like embedded flash is much harder to do than “plain & simple” CMOS, I suspect the PHY would perhaps also need some special process variants.
I think it’s also the exact same reasons we’ll find many, many times more MCUs with embedded ethernet – MAC only + RMII-interface to external 10/100/1G PHYs, than MCUs with embedded eth-PHYs as well.
So, just as they now offer a stacked-die multi-chip package; if USB2 was really needed, I’d suggest doing just digital HS 2.0 ctrl-logic, EP-ram and an ULPI interface in plain CMOS + an embedded separate ULPI PHY die.
Same thing with all the clueless users who cry “why no embedded Wifi?” etc. For one, embedded RF is hard; you’d be competing with ExpressIF and Nordic Semi etc; and it too would probably require special process technology > plain CMOS.
In that case too, a multi-die package solution would probably be easier. Or just use an external RF part, like on the Pico-W.
All this being said, yes it IS still possible to embed both HS-PHY and eth 10/100 PHYs, of course. For example, a bunch of the MCUs from Taiwanese Nuvoton do come with HS-PHY and CortexM cores. For example, see the M487 for a CM4 with plenty of RAM, Flash and dual USBs in some variants (FS + HS, OTG)
Other examples are BL616 which is on the tang nano 20k as usb hs to jtag/serial chip or the sipeed M0S board has it. And there is also the ch32v305/7. The 305 is used in cheap WCH Link-E debugger dongle or its mini clones. both are actually RISC-V not ARM. I use WCH linkE and also some cheaper blue WCH LinkE mini board with CMSIS-DAP debugger firmware with USB HS support from https://github.com/prosper00/CH32V305-DAPLink-HS and it works great. I can run nrf52 SWD at 8MHz and download whole flash in just few seconds (instead of tenths of seconds with USB FS). Point is these are relatively cheap but not super cheap, boards with them are ~US$5 including shipping on aliexpress, not sure about bulk prices of bare chips.
They added HSTX high-speed serial transmit. This might be a good way to get around this bottleneck.
The issue with ULPI is that it’s a PHY-owned bus, so it’s less about how fast you can dump data out than how fast you can respond to outside requests.
These chips are absolutely able to get data out at frightening rates, just not to USB without extra interfacing.
Well if you really really want a fast USB connection on your micro for your application then clearly this isn’t the chip for you, so I’d have to say those “that’s not what this chip is for” folks do have a point.
As not every micro is about fast data transfer to the outside world but lots of data hoovering, to apply math and logic straight to their own output, with the other slow interfaces if any used to inform and receive config details from the outside…
“Well if you really really want a fast USB connection on your micro for your application”
What I really want is a chip to replace the godawful FX2LP, and this chip is so, so close.
“so I’d have to say those “that’s not what this chip is for” folks do have a point.”
No, they don’t, because this chip could be made to do that with changes that wouldn’t just be a “fast USB connection,” and it’d almost certainly require far less silicon than 2 extra CPU cores that’ll just sit there totally unused.
If they just went the route of trying to make ULPI work with the PIOs, the main improvement would be probably something like allowing PIOs to run off external clocks, for instance, and that’s a general improvement, not a specific one.
The PIOs are by far the most unique thing about the RPi microcontrollers, and if there’s a common interface they can’t support, it makes sense to see what can be done. Even if you just basically say “ok this is a single separate PIO instance that’s externally clocked” or something.
“As not every micro is about fast data transfer to the outside world but lots of data hoovering”
The RP2040 is perfectly capable of dumping tons of data to the outside world, it just can’t do it in a way that’s literally the most common way to directly interface to modern computers.
I feel your pain of the “so close, but not quite…” :)
I think the most realistic option would’ve been a real USB2 core + dedicated ULPI interface. It’s the solution most STM32s with optional HS-USB was implemented; until a few more recent, and usually quite upper-end variants with actual on-chip HS-PHY.
I wouldn’t really want to “waste” a lot of PIOs to implement a soft-ULPI.
It would waste quite a bit of IO-pins anyway ofc, unless they’d managed a stacked-die variant with only internal pads that wouldn’t be bonded externally anyway
I can agree it would be nice, and the PIO really is a great reason to want the Pico stuff in your project. But when you are not setting the design requirements you have to use the chips others make, the pi folks decided more of their customers would be Risk curious than want higher speed USB interface, or perhaps they themselves wanted more Risk experience in house before moving to their own Risk CPU for a Pi 5-RV version or something…
So its not the chip for you (yet anyway), which is a shame. But outside of the FPGA type route where you just step up the family size until it has enough resources to pretend to be the silicon you wished existed we always have to pick from what is available and make do, with the Pi micro’s being really darn good chips for so many things (as frequently seen on HAD), just not fast USB connections..
“the pi folks decided more of their customers would be Risk curious than want higher speed USB interface”
Yes. And I’m virtually certain they’re wrong. That’s the entire point that I’m trying to make.
Problem is: The HS PHY certainly takes more silicon than those dinky small cores :)
It’d be a bit odd, but a USB HSIC PHY could be valuable as well, and they’re tiny.
I’m with you. There was a logic analyzer program written for the rp2040 and it could interface with sigrock. The main issue was that it couldn’t stream the data over USB and the storage wasn’t very large for longer/faster/wider captures.
With USB 2.0 we probably could’ve gotten some insane boosts to that and it could’ve made for a super cheap but super effective intro logic analyzer.
It’d be interesting to see if you could get ULPI using a tiny FPGA to handle the clock cross. You could definitely get RGMII working – heck, you might get RGMII with just a handful of dedicated logic chips using the HSTX.
Just weird that a cheap micro is probably easier to interface to gigabit ethernet than high-speed USB.
The TrustZone is a neat addition – I imagine we’ll see more secure, open RP2350-based Yubikey-like FIDO2 keys ( https://github.com/polhenarejos/pico-fido/ was one for the RP2040, but couldn’t store the keys securely).
It will be interesting to read about why they chose to include switchable architectures – ARM/RISC-V – I haven’t seen an explanation of why this would be beneficial.
“It will be interesting to read about why they chose to include switchable architectures – ARM/RISC-V – I haven’t seen an explanation of why this would be beneficial.”
To be honest, the main thing I can’t figure out is why they would bother doing this rather than just making it internally hidden – as in, you release multiple products with different part numbers but the same die, and let the user purchase each one separately.
I mean, in some sense, cool that they didn’t do this and let it be user-available, but I cannot imagine there aren’t going to be super-weird bugs that show up this way. I mean, if I were designing a product with this chip you’d absolutely want to disable it on anything that shipped just to cut down the weirdness possibilities.
Would the implementation be much different than blowing a fuse before/after packaging? If no, than this is just less hassle on them, as they don’t have to maintain different SKU’s, separate (but mostly the same) datasheets, etc. And buys them a bit of goodwill too.
Plenty of distributors offer pre programming services, so from their point of view, they wouldn’t really need to maintain it.
There’s some goodwill, sure, but I have my doubts it’ll be worth the support hassle. Something’s going to end up being weird, for instance, and it’ll be interesting to see if any strange attack vectors come from it.
I was looking at the microcontroller docs, and the RV core is less-capable (lacks FPU/DSP, integer divide, etc).
My theory is that they’re there to offer lower power consumption when you just need a little CPU to drive your application. They added some standard and custom RV extensions for bit-banging, so it seems well positioned for applications driven largely by PIO/peripherals.
Datasheet says it has the M extension (integer multiply/divide/modulo. (18 cycles for Divide/Modulo, though!)) (and some other useful extensions as well. RISC-V “extensions” make for confusing reading :-( )
No floats, though.
You’re right. I forget the M extension includes div and mod — it’s the Zmmul extension that’s only the multiply subset of M.
It’s a SKU control issue. Providing separate Arm-only and RISC-V-only versions doubles the number of SKUs of everything (RP2350A, RP2350B, RP2354A, RP2354B, Pico 2, Pico 2 W etc). More SKUs == more inventory, more overhead etc. Much easier to let the user choose (either per-boot or via OTP).
Probably to get the foot in the door of implementing risc-v in silicon, in preparation to more fully commit in some future product, whether that be for accessory cores or even the main core on the next MCU or PCIe bridge or, less likely, the pi 6
they were probably looking at the success of the tiny tapeout kickstarter and wanted to take some of the good ideas. They could have rolled with it and added an 8 bit core to make porting avrC code easier.
Or a Z80 for a decent 8-bit core.
I really really hope that there is FPU and atomic instructions and 256 level of priorities for interrupts in NVIC. I so much missed them from M4.
I know I know just buy a STM32F4… or nRF52840 and I have full drawer of them and use them for beeefy applications but neither Nordic nor ST have models with PIO like stuff.
There is an FPU, though I haven’t tried it yet. The interrupts I’m not certain about.
According to Dmitry’s blog there’s floating point support, I assume he means an FPU.
Also the PIO is such a game changer for ucs.
There is no FPU, but there is a co-processor available to ARM cores that’s about half-speed of an actual FPU for less die area. There have a comparison table in the datasheet.
dadd, dsub take 6 cycles; dmul 17, ddiv 51 and dsqrt 49
Software implementation had dadd, dsub take 70-90, dmul 75-90, ddiv 135-600 and dsqrt 130-650, so it’s quite an improvement.
each m33 core also has standard single precision fpu
The standard M33 floating point unit is there for single-precision arithmetic. The coprocessor is to accelerate double-precision arithmetic. There’s two accelerators, even, so that state need not be flushed/restored to switch between secure and insecure code. As you said, about half the speed of hardware double precision, but about 5-12x faster than software DP, depending on operation and the inputs you’re dealing with. A nice addition was fast ddiv/sqrt, which operate about 20% faster, give exact results when an exact result exists, and is otherwise precise within half a unit of the least significant digit before rounding.
52 interrupts, 6 of which are “unconnected to hardware.”
So they’ve about doubled the number of HW interrupts, (adding interrupts for OTP, TRNG, but haven’t taken advantage of the number theoretically available to do per-pin interrupts, or separate interrupts for Uart TX/RX or whatever.)
One really nice update to the SDK: a function for allocating available PIOs and SMs. I believe previously there was something like that for SMs, but it’s been expanded to search for PIOs and SMs with adequate program space. I was going to write something like this and was happy to see it in the SDK.
If you need pin pull-downs, check that you don’t need external resistors. I found a silicon bug (it’s in the datasheet, yeah) when the pin is an input with pull-down enabled it acts as a bus hold/bus keep. There is a work around but I don’t think it will work for PIO programs. I had to do a last minute reroll of my boards.
This should be interesting for some of the microcontroller-based OS projects. Something like Beepy/Beepberry with this instead of a full-blown Pi could be a pretty neat device.
Not much nicer than the rp2040 though, I’d imagine
All of my microcontroller needs were met by the original pico and it’s great $4 price. I’m excited to see what applications hackers will create with the new Pico 2. I don’t like that software will be fragmented by the different ISAs.
How much software out there for the rp2040 uses thumb ASM (wow, autocorrect tried to say ASMR)? I imagine that 95%+ of c/c++ code uses the SDK and thus targets libraries for peripheral interaction, and for the few that inline register manipulations, and I’m pretty sure that stuff like PORTB |= B00100000 is platform-agnostic. There can’t be more that 1 in 1000 rp2040, and I’d bet an order of magnitude less than even that, programs that are hand-optimized for the thumb ISA, most would reach for PIO on this platform before doing that.
How is it not mentioned that the DEFCON badge is powered by the RP2350 as an incentive for the bug bounty?
“To get RP2350 hardware into the hands of the engineers most likely to find these flaws, we’ve partnered with the DEF CON hacking convention, which starts today in Las Vegas. This year’s badge is powered by RP2350, and makes a great platform for experimenting with our security architecture”
Well MAYBE because the dev team was under a NDA until the official announcement from Raspberry Pi Ltd earlier today?
Poor Dmitry and the other would have been DDoS’d by everyone!
We simply didn’t know. We also didn’t know that Dmitry G had samples. (His writeup is awesome!)
That’s the thing with embargoed info — we all keep quiet and don’t share with each other until a certain date. It’s only now that the real work can start.
Not that exciting considering DEF CON is canceled.
Nice, but I’ll wait for the one with WiFi and Bluetooth.
Supposed to be here by end of the year. For me, I have a project that is RPI-3 based which will ‘talk’ to the Pico board (so Wifi not necessary). Good place to use the non-Wifi Pico boards as ‘support boards’ to the RPI main Linux boards. My wish list was for a RPI-X board with a Pico integrated on-board with it’s own header.
Looking forward to kicking its wheels so to speak. The RP2040 has met my needs for the simple projects I do, but nice to know we have a more powerful board to use if needed. A bonus is the ability to play around with RISC-V as well for fun in the same package.
Ugh, just bought picos yesterday for a project and was really hesitant if they had quite enough juice. Almost bought a teensy but went with the pico because I strongly prefer the development experience. This is just enough “extra” over the pico 1 I wouldn’t have had those thoughts…
You can reliably overclock the RP2040 up beyond 200MHz.
Also you’ll probably have a fun time actually getting your hands on a Pico 2 for a while yet.
Overclock the Pico! They have a lot of overhead, and it’s as simple as changing a line in the configs if it doesn’t work.
For the Vectorscope badge, I was running into bottlenecks left right and center, and then I was like “heck, I’ll try just doubling the clock speed” and then I made timings with like 15% headroom. I spent two days hammering on code to make it run tighter, only to change one define and solve all the problems. It was a happy day.
Won’t work if you have a 3x problem, but if you’re looking at a 2x problem…
What are you doing on it that you think it doesn’t have enough juice?
I brought one of these new boards on a whim in the UK as soon as I saw they were available £4. Postage and tax was £4.70 – lol.
Why bother when the EPS32 crushes it in performance, peripherals and cost.
Not to mention they have never been out of stock!!!
Well, duh – just don’t !? If the “EPS” meets your needs, by all means – keep using that!
If you eventually find some project with requirements that an RP2xxx would meet better, e.g. something the PIOs would be perfect for, then consider the RPs for that/those use cases.
Or if something else would be a better solution – use that.
Selecting best/smallest/cheapest/favorite/etc parts for different projects is the embedded designer’s job, isn’t it?
“ESP32 crushes it in performance”
I’ll take “statements that are hilariously wrong” for $600, Alex.
https://www.youtube.com/watch?v=bTYQ_Jrpz6Y
ESP32S2 doubled the performance of old pico. So you are wrong here.
What a useless benchmark. He uses two boards without a floating point unit and compares their floating point performance. Sure it is some benchmark that might be interesting to some users. But if you care about FP, choose a uC with a floating point unit. For instance some STM32F401/F411 based black pill board.
Also: If you really need that raw compute performance, maybe having a second core is not a bad idea. You can have one thread doing the compute and still have a core free to do real-time stuff.
CircuitPython. Ha! I don’t care about poorly controlled CPU benchmarking malarkey.
Microcontrollers are for controlling signals, not raw number crunching, and the pico’s PIO’s are king. Nothing else comes close, and some of the stuff I’ve done with PIO’s is quite literally impossible to achieve with any other microcontroller on the market; you would need to go to FPGA’s or ASICs instead.
Ah, maybe you should read a bit about the PIO units. Or check out a few projects.
Check out and understand the BlueSCSI SCSI emulator or the PicoMem ISA card.
There may be valid points why the ESP32 is better suited for specific usecases, but performance is not one of them. By a longshot.
honestly this is making me angry because it’s just rubbing my face in the fact that all a year later i still haven’t hardly gotten a chance to play with my rp2040
So who’s problem is that? (Says the man who has drawer full of RP2040 based boards ;) :) )
same
Hopefully they fixed the ADC bug
According to the datasheet it looks like they have. See in comments section here:
https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new-5-microcontroller-board-on-sale-now/#comments
“and we remember that the original Pico was wireless for a few months before”
Maybe let’s not use this language to suggest a lack of connectivity.
isn’t it more like “wireless-less”
Does no one else mind the lack of usb c?
No, because boards from other sources like Adafruit will pop up in no time…
That is true, I just wonder why they stuck with micro, do you think it’s compatability with the existing boards and branded cables or do any of us find micro preferable in some way?
It‘s a mystery to me, too.
I just don‘t complain :) Maybe it‘s cost, maybe backwards compatibility.
The new board is a drop in replacement for the old one.
Bets on how long it takes someone to get all four cores working simultaneously? 😏
I have to admit, that was my first thought.
Looking forward to going through the data sheet as bed time reading. The RP2040 data sheet, BTW, was a miracle of clarity, especially when compared to other microcontroller datasheets. I hope this one is similar.
Apparently, you can even enable one of each core, if you want. That should be interesting.
It’s interesting I guess. I’m glad to see USB peripherals and the RISC-V core but I’m not really sure at this price point who it’s for.
If I want to use a micro-controller for personal projects I’ll stick to something that is either cheaper or offers more features. So Either an ESP32 or NRF chip on the upper end. On the lower end I would go with a chip from WCH like a ch32v203 or a ch32v003.
On the other side if I’m designing for a client who wants to manufacture in bulk then it costs way too much. For example for a simple sensor module that uses rs485 I can get a ch32v003 for less than $0.15 meaning I could have about 33 uC for the same price as a single rp2350 devboard at the moment.
For the current price point it’s competing with the ESP32 and NRF products, but it lacks the features they offer.
Horses for courses. The other high-end chips you mention have nothing that competes with the PIOs for ultra-fast, custom IO, for instance.
(There are some pretty cool tricks you can pull with the ESP32’s flexible I2S and PWM peripherals, but they’re hacks.)
The RP2040 and RP2350 made some very fun choices in what they put on the silicon. Almost quirky, I would say. Dual architectures? What?
Do you need WiFi or Bluetooth? You know where to go. Do you need programmable high-speed IO? You know where to go.
Why do you compare price of bare ch32v003chip ($0.15) with price of whole Pico board? rp2350 chip is not 33*0.15
The RPi Pico 2 is interesting, but what I’m missing is why it is marketed as version two. For the single board computers from RPi, it made quite a bit of sense to number them. RPi 3 was more powerful than two, etc. In the microcontroller world, there is good reason to use an M0 core for some projects and more complex cores for other projects. To the point where microcontroller companies have hundreds of different chips concurrently, all for different purposes. RP2040 and RP2350 can easily coexist and fill different roles as well.
I would like to play with the new chip, and not just because of the additional features. I also find there is a large component of the fear of missing out. The anxiety comes partially about the microcontroller and projects the RP2040 is in currently, and where the new chip is likely better.
“and where the new chip is likely better.” Well, the ADC problem is supposed to be fixed on the newer board, so if you care about that, use the newer board. Also if you application was constrained by the 264K of memory, 520K will ‘help’. Board sleep watts appear to be lower as well. For such a ‘cheap’ controller, there is a lot going for it. If you the PIO, it looks like you have more of everything to expand usage. As I said in another post, the R2040 meets my current needs (have a drawer full of boards) but nice there is a big brother if needed. Plus I can now, cheaply, explore the RISC-V side of the world if I want. Looking forward to getting a few of the new boards.
It looks to me like the new chip is really just the old chip but better (plus explorable risc-v), especially the adc fix as Clark said. I don’t see anything that would incentivize rp2040 use over it other than a tiny bit of BOM cost
Tiny Circuits just launched Thumby COLOR with the announcement. Seems they have been working on it for long time.
Wouldn’t make sense to just make it a ausd core
And in software select how many of which cores you want, and what code runs on which core
This would make sense in embedded application like remote wireless networks, where you could use different cores for different tasks. Arm cores are probably better for more intensive tasks, while risc-v can be used for experimental or non critical things since it’s still new and no two risc-v are alike, unless it’s the same part #
A rtos or hypervisor can be used, and would allow for more extensive power management, especially if you have control over the clock speed in software….
A quad core
For $5 you could get a pi zero with built in wifi…and more capable
For $10 I can just get an fpga and esp32 and have more high speed gpio and DSP, with wifi Bluetooth and 240mhz
I can literally just put risc-v support on fpga if I need if it’s large enough
I can get fast io port, display acceleration, audio, and DSP
FPGA can be clocked using external crystal or pll
Run it at 500- 1ghz
Might need a heatsink
500mhz*
Add some dual port ram between CPU cores
I think the cheapest FPGA board you can get nowadays that can fit a risc-v core (other than SERV, which kinda doesn’t count as it’s so slow) is the Tang Nano 4k, which is ~$15 nowadays. It won’t run anywhere near 500MHz on a budget FPGA either, most run at about 100MHZ tops on the Gowin chips at least, and that’s if you disable a lot of features like barrel shifters, etc, to shorten the timing chain, greatly increases clocks per instruction. And this is for the food cores like picorv32 or vexriscv.
Even if you skip the risc-v core and go with a nano 1k (which itself barely <$10 nowadays) or similar, you have to learn an HDL, which is a lot harder for someone with programming experience to reason about than a very small set of PIO instructions. And then you have to synthesize a way for your FPGA to communicate with the STM32 and write the driver for the STM32, and most strategies (really, anything other than a parallel GPIO bus with DMA implemented on the STM32 side) will have way more cycles of delay between the synthesized behavior and the STM32 interacting with it relative to PIO.
Don’t get me wrong, I love implementing stuff on an FPGA (it’s my current main hobby), it’s just a completely different ballgame to getting stuff working with a fully-featured MCU dev board.
Obviously I haven’t read the datasheet yet … But someone on another forum pointed out the lack of an RTC on board the Pico 2. I actually used the RTC on the Pico RP2040 for time-stamping. Hmmmm.
From the DS:
The RP2040 Real Time Clock (RTC) is not used in RP2350. Instead, RP2350 has a timer in the Always-On power domain which is used for scheduling power-up events and can also be used as a real-time counter. The AON Timer works differently from the RP2040 RTC. It counts milliseconds to 64 bits and this value can be used to calculate the date and time in software if required.
Oooo, which is even better! Cool!
Ok, thanks, hat works if we can set the counter to ‘msecs since epoch’. Well, either that, or we have to do some calcs by getting base ‘seconds since epoch’ from another machine and then do diffs to calculate offset and then use the offset from base to calculate current time. Sounds like fun and we’ll have millisecond time stamping for alarms. That will work I suppose. More important to me once we get the Wifi version of the new board.
12 PIO’s? Oh wait – 12 state machines. 4 per PIO, like on the RP2040. So the rp2350 has 3 PIO blocks where the RP2040 had 2.
So, that would mean there is more instruction memory as well, right? 32 instructions per pio block shared among its 4 SM’s.
Very nice… verrrrry nice!
Here for all the comments complaining that this chip doesn’t solve their specific use-case so is therefore dumb and wrong.
If the designers listened to the internet they’d end up with the silicon equivalent of The Homer.
Exactly my thought!