This is very exciting! For the last several years I have been developing a brushless motor driver based on the RP2040 [1]. The driver module can handle up to 53 volts at 30A continuous, 50A peak. I broke the driver out to a separate module recently which is helpful for our farm robot and is also important for driver testing as we improve the design. However this rev seems pretty solid, so I might build a single board low cost integrated single motor driver with the RP2350 soon! With the RP2040 the loop rate was 8khz which is totally fine for big farm robot drive motors, but some high performance drivers with floating point do 50khz loop rate.<p>My board runs SimpleFOC, and people on the forum have been talking about building a flagship design, but they need support for sensorless control as well as floating point, so if I use the new larger pinout variant of the RP2350 with 8 ADC pins, we can measure three current signals and three bridge voltages to make a nice sensorless driver! It will be a few months before I can have a design ready, but follow the git repo or my twitter profile [2] if you would like to stay up to date!<p>[1] <a href="https://github.com/tlalexander/rp2040-motor-controller">https://github.com/tlalexander/rp2040-motor-controller</a><p>[2] <a href="https://twitter.com/TLAlexander" rel="nofollow">https://twitter.com/TLAlexander</a>
I can't imagine someone using an RP2040 in a real product, but the RP2350 fixes enough of my complaints that I'd be really excited to give it a shot.<p>There's a lot going for the 2040, don't get me wrong. TBMAN is a really cool concept. It overclocks like crazy. PIO is truly innovative, and it's super valuable for boatloads of companies looking to replace their 8051s/whatever with a daughterboard-adapted ARM core.<p>But, for every cool thing about the RP2040, there was a bad thing. DSP-level clock speeds but no FPU, and no hardware integer division. A USB DFU function embedded in boot ROM is flatly undesirable in an MCU with no memory protection. PIO support is extremely limited in third-party SDKs like Zephyr, which puts a low ceiling on its usefulness in large-scale projects.<p>The RP2350 fixes nearly all of my complaints, and that's really exciting.<p>PIO is a really cool concept, but relying on it to implement garden-variety peripherals like CAN or SDMMC immediately puts RP2350 at a disadvantage. The flexibility is very cool, but if I need to get a product up and running, the last thing I want to do is fiddle around with a special-purpose assembly language. My hope is that they'll eventually provide a library of ready-made "soft peripherals" for common things like SD/MMC, MII, Bluetooth HCI, etc. That would make integration into Zephyr (and friends) easier, and it would massively expand the potential use cases for the chip.
Some specs here: <a href="https://www.digikey.ca/en/product-highlight/r/raspberry-pi/raspberry-pi-sc1631-pico-2" rel="nofollow">https://www.digikey.ca/en/product-highlight/r/raspberry-pi/r...</a><p>Based on the RP2350, designed by Raspberry Pi in the United Kingdom<p>Dual Arm M33s at 150 MHz with FPU<p>520 KiB of SRAM<p>Robust security features (signed boot, OTP, SHA-256, TRNG, glitch detectors and Arm TrustZone for Cortex®-M)<p>Optional, dual RISC-V Hazard3 CPUs at 150 MHz<p>Low-power operation<p>PIO v2 with 3 × programmable I/O co-processors (12 × programmable I/O state machines) for custom peripheral support<p>Support for PSRAM, faster off-chip XIP QSPI Flash interface<p>4 MB on-board QSPI Flash storage<p>5 V tolerant GPIOs<p>Open source C/C++ SDK, MicroPython support<p>Software-compatible with Pico 1/RP2040<p>Drag-and-drop programming using mass storage over USB<p>Castellated module allows soldering directly to carrier boards<p>Footprint- and pin-compatible with Pico 1 (21 mm × 51 mm form factor)<p>26 multifunction GPIO pins, including three analog inputs<p>Operating temperature: -20°C to +85°C<p>Supported input voltage: 1.8 VDC to 5.5 VDC
Big day for my team (Pigweed)! Some of our work got mentioned in the main RP2350/Pico2 announcement [1] but for many months we've been working on a new end-to-end SDK [2] built on top of Bazel [3] with support for both RP2040 and RP2350, including upstreaming Bazel support to the Pico SDK. Our new "Tour of Pigweed" [4] shows a bunch of Pigweed features working together in a single codebase, e.g. hermetic builds, on-device unit tests, RPC-centric comms, factory-at-your-desk testing, etc. We're over in our Discord [5] if you've got any questions<p>[1] <a href="https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new-5-microcontroller-board-on-sale-now/" rel="nofollow">https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new...</a><p>[2] <a href="https://opensource.googleblog.com/2024/08/introducing-pigweed-sdk.html" rel="nofollow">https://opensource.googleblog.com/2024/08/introducing-pigwee...</a><p>[3] <a href="https://blog.bazel.build/2024/08/08/bazel-for-embedded.html" rel="nofollow">https://blog.bazel.build/2024/08/08/bazel-for-embedded.html</a><p>[4] <a href="https://pigweed.dev/docs/showcases/sense/" rel="nofollow">https://pigweed.dev/docs/showcases/sense/</a><p>[5] <a href="https://discord.gg/M9NSeTA" rel="nofollow">https://discord.gg/M9NSeTA</a>
You can pick either ARM cores or RISC-V cores on the same die? Never saw design like this before. Will this impact price and power consumption?<p>"The Hazard3 cores are optional: Users can at boot time select a pair of included Arm Cortex-M33 cores to run, or the pair of Hazard3 cores. Both options run at 150 MHz. The more bold could try running one RV and one Arm core together rather than two RV or two Arm.<p>Hazard3 is an open source design, and all the materials for it are here. It's a lightweight three-stage in-order RV32IMACZb* machine, which means it supports the base 32-bit RISC-V ISA with support for multiplication and division in hardware, atomic instructions, bit manipulation, and more."
RP2040 had Doom ported to it. <a href="https://kilograham.github.io/rp2040-doom/" rel="nofollow">https://kilograham.github.io/rp2040-doom/</a><p>RP2350 looks very much like it could potentially run <i>Quake</i>. Heck, some of the changes almost feel like they're designed for this purpose.<p>FPU, two cores at 150 MHz, overclockable beyond 300 MHz and it supports up to 16 MB of PSRAM with hardware R/W paging support.
It's a bit surprising that they put so much effort into security for the second microcontroller from a young consumer-oriented* company. My first instinct was to distrust it's security, simply due to lack of experience. However, the "experienced" vendors' secure micros have lots of known security bugs and, more crucially, a demonstrated desire to sweep them under the rug. Two security architecture audits, a $10k bug bounty, and designing a board for glitching as the DEF CON badge shows a pretty big commitment to security. I'm curious about how the Redundancy Coprocessor works. I still wouldn't be surprised if someone breaks it, at least partially.<p>* By perception at least. They have been prioritizing industrial users from a revenue and supply standpoint, it seems.
Can’t find an official announcement or datasheet yet, but according to this post:<p>* 2x Cortex-M33F
* improved DMA
* more and improved PIO
* external PSRAM support
* variants with internal flash (2MB) and 80 pins (!)
* 512KiB ram (double)
* some RISC-V cores? Low power maybe?<p>Looks like a significant jump over the RP2040!
Speak of the devil: <a href="https://news.ycombinator.com/item?id=41156743">https://news.ycombinator.com/item?id=41156743</a><p>Very nice that the "3" turned out to mean the modern M33 core rather than the much older M3 core. It has a real FPU!
Can someone explain the benefit of having essentially 4 cores (2 ARM + 2 RISC-V) on the chip but only having 2 able to run simultaneously? Does this take significantly less die space than having all 4 available at all times?
Lots of nice improvements here. The RISC-V RV32I option is nice -- so many RV32 MCUs have absurdly tiny amounts of SRAM and very limited peripherals. The Cortex M33s are a biiig upgrade from the M0+s in the RP2040. Real atomic operations. An FPU. I'm exited.
<a href="https://www.raspberrypi.com/products/rp2350/" rel="nofollow">https://www.raspberrypi.com/products/rp2350/</a><p>4 variants? "A" and "B" variants in QFN60 and QFN80, "2350" and "2354" variants with and without 2MB Flash. CPU can be switched between dual RISC-V @ 150MHz or dual Cortex-M33 @ 300MHz by software or in one-time programming memory(=permanently).<p>Datasheet, core switching details, most of docs are 404 as of now; I guess they didn't have embargo date actually written in `crontab`.<p>e: and datasheet is up!
I'm most excited for the partition and address translation support - partitions can be mapped to the same address for A/B boot slots (and it supports "try before you buy" to boot into a slot temporarily). No more compiling two copies for the A and B slots (at different addresses)!
This looks awesome a really great step up from the RP2040. I'm a big fan of the original and I'm excited to see all the improvements and upgrades.<p>I imagine with the new secure boot functionality they've got a huge new range of customers to tempt to.<p>Also exciting to see them dip their toe into the open silicon waters with the hazard 3 RISCV core <a href="https://github.com/Wren6991/Hazard3">https://github.com/Wren6991/Hazard3</a>.<p>Of course it they'd used Ibex <a href="https://github.com/lowrisc/ibex">https://github.com/lowrisc/ibex</a> the RISC-V core we develop and maintain at lowRISC that would have been even better but you can't have everything ;)
I see CMSIS definitions for the RP2040 at <a href="https://github.com/raspberrypi/CMSIS-RP2xxx-DFP">https://github.com/raspberrypi/CMSIS-RP2xxx-DFP</a> but none for RP2350. Maybe they'll eventually appear in that repo, given its name is RP2xxx? I thought vendors are legally obligated to provide CMSIS definitions when they license an ARM core.
Aha, the 3 is for M33, not Cortex M3 (as some speculated based on the name). That makes a lot more sense! Integrated FPU is a big improvement over the RP2040, and M33 is a modern but proven core.
I presume the article was edited to change its headline after it was submitted to HN, but it's interesting that it doesn't match up with the HN title. It's still a subjective but positive title, but somehow feels like it has a different tone to the title on HN:<p>HN: "I got almost all of my wishes granted with RP2350"<p>Article: "Why you should fall in love with the RP2350"<p>title tag: "Introducing the RP2350"
Can anyone speak about plans for a Pico 2 W (or Pico W 2)? I've been playing around recently with mine and even just syncing with the current time over wifi opens up a lot of possibilities.
Not off topic but a bit tangentially...<p>How difficult would be emulating an old SRAM chip with an RP2040 or an RP2350? It's an early 80s (or older) 2048 word, 200ns access time CMOS SRAM that is used to save presets on an old Casio synth. It's not a continuous memory read, it just reads when loading the preset to memory.<p>I feel like PIO would be perfect for that.
What is the process node used? Who is fabbing this for them? Given that the new chip is bigger, my guess is the same (old) process node is being used. RP2040 is manufactured on a 40nm process node.<p>Whoops, I read the fine print: RP2350 is manufactured on a 40nm process node.
This is fantastic news. Is there information on power consumption?
This is something that precludes a good deal of use cases for the RP2040 unfortunately and any improvements here would be good, but maybe the RP's are just not made for ultra low power?
> 1 × USB 1.1 controller and PHY, with host and device support<p>Sure, after integrating USB 2.0 HS or 1Gb-Ethernet the pico2-board will cost more than $5. So, integrated high-speed interfacing with PC was not a nice-to-have option (for special chip flavor)?
> I got almost all of my wishes granted with RP2350<p>I got all mine, these guys really listened to the (minor) criticisms of the RP2040 on their forums and knocked them out of the ball park. Cant wait to get my hands on real hardware. Well done guys
This has 2 of the 3 features (float support, faster clock) + more POI that was keeping me on ESP32. For projects that need wifi, and can tolerate the random interrupts, I'll stick with ESP32.
While I completely agree with the content of the post, I still think that QFN packages in general, and RP2350's in particular, are very hobbyist-averse.<p>Moving all GND pins to the bottom pad makes this chip usable only by people with a reflow oven. I really hoped to see at least a version released as (T)QFP.
Looks like the SDK got updated a couple hours ago:<p><a href="https://github.com/raspberrypi/pico-sdk/commit/efe2103f9b28458a1615ff096054479743ade236">https://github.com/raspberrypi/pico-sdk/commit/efe2103f9b284...</a>
> > I was not paid or compensated for this article in any way<p>> However the Raspberry Pi engineer in question WAS compensated for the samples, in the form of a flight over downtown Austin in Dmitry's Cirrus SR22.<p>Hahah, I’ve been in that plane. Only in my case, it was a flight to a steak house in central California, and I didn’t actually do anything to get “compensated”, I was just at the right place at the right time.<p>Anyway, I am extremely excited about this update, RPi are knocking it out of the park. That there is a variant with flash now is a godsend by itself, but the updates to the PIO and DMA engines make me dream up all sorts of projects.
I suppose this isn't the first time a company that started out as a hobbiest board manufacturer produced really amazing micro controllers but man is it insane how far they've knocked the ball out of the park.
Related:<p><i>Raspberry Pi Pico 2, our new $5 microcontroller board, on sale now</i><p><a href="https://news.ycombinator.com/item?id=41192341">https://news.ycombinator.com/item?id=41192341</a>
I think it's a good way to introduce these chips, and it's a great project, but the author's (frankly weird) beef with STM32H7 is detracting from the point they're trying to make:<p>> So, in conclusion, go replan all your STM32H7 projects with RP2350, save money, headaches, and time.<p>STM32H7 chips can run much faster and have a wider selection of peripherals than RP2350. RP2350 excels in some other dimensions, including the number of (heterogenous) cores. Either way, this is nowhere near apples-to-apples.<p>Further, they're not the only Cortex-M7 vendor, so if the conclusion is that STM32H7 sucks (it mostly doesn't), it doesn't follow that you should be instead using Cortex-M33 on RPi. You could be going with Microchip (hobbyist-friendly), NXP (preferred by many commercial buyers), or a number of lesser-known manufacturers.
> So, in conclusion, go replan all your STM32H7 projects with RP2350, save money, headaches, and time.<p>Except the STM32H7 series goes up until 600MHz.<p>Overclocking is cool, but you can't do that on most commercial projects.
I wish there was a way to share memory with a Pi. The PIO looks great for high speed custom IO, but 100Mb scale interface to/from it is quite hard/unsolved.
Hmm, it's really nice that they fixed so many complaints. But honestly, reading the errata sheet, I had to chuckle that Dmitry didn't tear this chip to pieces.<p>I mean, there's erratums about obscure edge cases, about miniscule bugs. Sure, mistakes happen. And then there's this: Internal pull-downs don't work reliably.<p>Workaround: Disconnect digital input and only connect while you're reading the value. Well, great! Now it takes 3 instructions to read data from a port, significantly reducing the rate at which you can read data!<p>I guess it's just rare to have pull-downs, so that's naturally mitigating the issue a bit.
In terms of security features, it lacks on-the-fly external memory (flash and PSRAM) encryption and decryption as ESP32 and some newer STM32s did.
Decrypting by custom OTP bootloader and running entirely in the internal SRAM maybe sometimes limited for larger firmware.
New BusPirate 5XL&6 also dropping today - use the 3250<p><a href="https://buspirate.com/" rel="nofollow">https://buspirate.com/</a>
> It overclocks insanely well<p>says the guy with engineering samples and creme of the creme silicon parts... i expect most that will actually be available when they do to their normal schedule of scraping the literal bottom of the barrel to keep their always empty stocks that will not be the case.