* 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?
Looks like a significant jump over the RP2040!
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!
https://github.com/raspberrypi/pico-sdk/commit/efe2103f9b284...
Based on the RP2350, designed by Raspberry Pi in the United Kingdom
Dual Arm M33s at 150 MHz with FPU
520 KiB of SRAM
Robust security features (signed boot, OTP, SHA-256, TRNG, glitch detectors and Arm TrustZone for Cortex®-M)
Optional, dual RISC-V Hazard3 CPUs at 150 MHz
Low-power operation
PIO v2 with 3 × programmable I/O co-processors (12 × programmable I/O state machines) for custom peripheral support
Support for PSRAM, faster off-chip XIP QSPI Flash interface
4 MB on-board QSPI Flash storage
5 V tolerant GPIOs
Open source C/C++ SDK, MicroPython support
Software-compatible with Pico 1/RP2040
Drag-and-drop programming using mass storage over USB
Castellated module allows soldering directly to carrier boards
Footprint- and pin-compatible with Pico 1 (21 mm × 51 mm form factor)
26 multifunction GPIO pins, including three analog inputs
Operating temperature: -20°C to +85°C
Supported input voltage: 1.8 VDC to 5.5 VDC
"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.
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."
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).
Datasheet, core switching details, most of docs are 404 as of now; I guess they didn't have embargo date actually written in `crontab`.
e: and datasheet is up!
> So, in conclusion, go replan all your STM32H7 projects with RP2350, save money, headaches, and time.
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.
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.
Official product page: https://news.ycombinator.com/item?id=41192269
2. And my beef is personal - I spent months (MONTHS of my life) debugging the damn H7, only to find a set of huge bugs in the main reason I had been trying to use it (QSPI ram support), showed it to the manufacturer, and had them do nothing. Later they came back and, without admitting i was right about the bugs, said that "another customer is seeing same issues, what was the workaround you said found?" I told them that i'll share the workaround when they admit the problem. Silence since.
I fully reserve the right to be pissy at shitty companies in public on my website!
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)?
Having both architectures available is a cool touch. I believe I criticized the original RP2040 for not being bold enough to go RISC-V, but now they’re offering users the choice. I’ll be very curious to see how the two cores compare… I suspect the ARM cores will probably be noticeably better in this case.
https://www.raspberrypi.com/for-industry/powered-by/product-...
Pimoroni has a maxed-out pin-compatible version with 16MB flash, 8MB PSRAM, and USB-C:
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.
I feel like PIO would be perfect for that.
https://photos.app.goo.gl/KabVe5CrfckqnFEt7
https://photos.app.goo.gl/LGAkp6HoYAJc3Uft7
Edit: I did not yet update the rePalm article but much about that is in the Palm discord. https://discord.gg/qs8wQ4Bf
see #repalm-project channel
> I have been anti-recommending STM’s chips to everyone for a few years now due to STM’s behaviour with regards to the clearly-demonstrated-to-them hardware issues.
You certainly reserve the right. However it is unclear to me why the recommendation to complaints over a months-long period is a product that has just been released.
Trying to ask in a very unbiased way since as a hobbyist I’m looking into ST, Microchip, and RP2040. For my part I’ve had two out of four RP2040 come to me dead on arrival, as part of two separate boards from different vendors - one being Pi Pico from Digilent. Not a ton of experience with Microchip but I hear they have their own problems. Nobody’s perfect, the question is how do the options compare.
I try to dissuade n00bs from starting their arduino journey with the ancient AVR-based devices, but a lot of the peripherals expect to plug into an Uno.
> The ARCHSEL register has one bit for each processor socket, so it is possible to request mixed combinations of Arm and RISC-V processors: either Arm core 0 and RISC-V core 1, or RISC-V core 0 and Arm core 1. Practical applications for this are limited, since this requires two separate program images.
That is fascinating... so, likely what dmitrygr said about the size of the crossbar sounds right to me: https://news.ycombinator.com/item?id=41192580
Do you have anything published?
Low power suspend? In a Pi Foundation product? Impossible.
Eben Upton: "They're selectable at boot time: Each port into the bus fabric can be connected either to an M33 or a Hazard3 via a mux. You can even, if you're feeling obtuse, run with one of each."
Source: https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
[1] https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
I will re-test and try to get better sleep state in my code either today or tomorrow!
Do you live in a universe where micro-USB cables are not available, or something? There's gonna be something or other that needs micro-USB for the next decade, so just buy a few and move on. They're not expensive.
[later edit: I bet it has to do with backwards compatibility. They don't want people to need to rework case designs to use something that is meant as a drop-in replacement for the Pi Pico 1.]
I wanted to do a clone or two of said cartridges, that use, IIRC (I'm not in my workshop right now) a couple Hitachi HM6116FP each.
I've also seen some clones from back in the day using a CXK5864PN-15L, that's 8 kilowords, and getting 4 switchable "memory banks" out of it...
I don't know what's so unclear. Have you never had a strong opinion about someone else's stuff? Man, I have.
Raspberry Pi Pico 2, our new $5 microcontroller board, on sale now - https://news.ycombinator.com/item?id=41192341 - Aug 2024 (71 comments)
You’re limited to those two exact kinds of cores, but you know every other thing on the entire computer is 100% identical.
It’s not SBC 1 vs SBC 2, but they have different RAM chips and this one has a better cooler but that one better WiFi.
I know the RP2040's overclock a lot but these are significantly more complex chips, it seems less likely they'll overclock to 2x the base frequency.
[1] https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new...
I imagine with the new secure boot functionality they've got a huge new range of customers to tempt to.
Also exciting to see them dip their toe into the open silicon waters with the hazard 3 RISCV core https://github.com/Wren6991/Hazard3.
Of course it they'd used Ibex https://github.com/lowrisc/ibex the RISC-V core we develop and maintain at lowRISC that would have been even better but you can't have everything ;)
EDIT: okay, section 14.8.2.1 mentions two types of digital pins: "Standard Digital" and "Fault Tolerant Digital", and the FT Digital pins might be 5V tolerant, it looks like.
The SRAM in that H7 is running at commensurately-high speeds, as well.
Comparing an overclocked 2xM33 to a non-overclocked M7 is also probably a little inaccurate - that M7 will easily make more than the rated speed (not nearly as much as the RP2040 M0+, though.)
Raspberry Pi Pico 2, our new $5 microcontroller board, on sale now
[1] While it's possible they are envisioning dual architecture indefinitely, it's hard to imagine why this would be desirable long term esp. when one architecture can be royalty free and the other not, power efficiency, paying for dark silicon etc.
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!
> The Financial Times has a report on Arm's "radical shake-up" of its business model. The new plan is to raise prices across the board and charge "several times more" than it currently does for chip licenses. According to the report, Arm wants to stop charging chip vendors to make Arm chips, and instead wants to charge device makers—especially smartphone manufacturers—a fee based on the overall price of the final product.
Even if the particular cores in the RP2350 aren't affected, the general trend is unfavorable to Arm licensees. Raspberry Pi has come up with a clever design that allows it to start commoditizing its complement [2]: make the cores a commodity that is open-source or available from any suitable RISC-V chip designer instead of something you must go to Arm for. Raspberry Pi can get its users accustomed to using the RISC-V cores—for example, by eventually offering better specs and more features on RISC-V than Arm. In the meantime, software that supports the Raspberry Pi Pico will be ported to RISC-V with no disruption. If Arm acts up and RISC-V support is good enough or when it becomes clear users prefer RISC-V, Raspberry Pi can drop the Arm cores.
[1] https://arstechnica.com/gadgets/2023/03/risc-y-business-arm-...
I (deliberately) haven’t bought a consumer electronic device that still uses Micro USB in years so don’t accumulate those cables for free anymore like with USB-C.
Of course ubiquitous USB-C dev boards/breakout boards without 5.1kΩ resistors for C-C power is its own frustration ... But I can tolerate that having so many extra USB-A chargers and cables. Trigger boards are great because they necessarily support PD without playing the AliExpress C-C lottery.
That peaked my interest, here's the video for those who want to save a few clicks: https://www.youtube.com/watch?v=fFhTPHlPAAk
I absolutely love that they use bike parts for the feet and wheels.
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.
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.
The RP2350 fixes nearly all of my complaints, and that's really exciting.
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.
I haven't actually built anything (been paying attention to Taylor's work, though), but I came to the same conclusion that bike wheels & tires would probably be a good choice. It also doesn't hurt that we have many discarded kids' bikes all over the place.
I ran into this problem using an ESP32 to drive a Broadcom 5V LED dot-matrix display. On paper everything looked fine; in reality it was unreliable until I inserted an LS245 between the ESP and the display.
I found (1) HM6116, (4) HM65256's (1) HM6264 and wonder of wonders, a Dallas battery-backed DS1220, although after 20+ years the battery is certainly dead. All in DIP packages of course.
And a couple of 2114's with a 1980 date code! that I think are DRAM's.
If any of this is useful to you, PM me an address and I'll pop them in the mail.
I love having usb-c on all my modern products, but with so many micro-usb cords sitting around, I don't mind that the official Pico and Pico 2 are micro-usb. At least there are options for whichever port you prefer for the project you're using it in.
Which is apparently an impossible ask for manufacturers of dev boards or cheap devices in general. It’s slightly more understandable for a tried and true dev board that’s just been connector swapped to USB-C (and I’ll happily take it over dealing with Micro) but inexcusable for a new design.
My hope is Apple going USB-C only on all their charging bricks and now even C-C cables for the iPhone will eventually force Chinese OEMs to build standard compliant designs. Or deal with a 50% Amazon return rate for “broken no power won’t charge”.
I live in a universe where type C has been the standard interface for devices for years, offering significant advantages with no downsides other than a slightly higher cost connector, and it's reasonable to be frustrated at vendors releasing new devices using the old connector.
It's certainly not as bad as some vendors of networking equipment who still to this day release new designs with Mini-B connectors that are actually officially deprecated, but it's not good nor worthy of defending in any way.
> I bet it has to do with backwards compatibility. They don't want people to need to rework case designs to use something that is meant as a drop-in replacement for the Pi Pico 1.
Your logic is likely accurate here, but that just moves the stupid choice back a generation. It was equally dumb and annoying to have Micro-B instead of C on a newly designed and released device in 2021 as it is in 2024.
The type C connector was standardized in 2014 and became standard on phones and widely utilized on laptops starting in 2016.
IMO the only good reason to have a mini-B or micro-B connector on a device is for physical compatibility with a legacy design that existed prior to 2016. Compatibility with a previous bad decision is not a good reason, fix your mistakes.
Type A on hosts will still be a thing for a long time, and full-size type B still makes sense for large devices that are not often plugged/unplugged where the size is actually a benefit, but the mini-B connector is deprecated and the micro-B connector should be.
But the µC itself runs on 3.3V and is not totally 5V-capable. You'd need level converters to interface with 5V.
Perhaps they could be more ready-made, but there are loads of official PIO examples that are easy to get started with.
https://github.com/raspberrypi/pico-examples/tree/master/pio
RP2350 looks very much like it could potentially run Quake. Heck, some of the changes almost feel like they're designed for this purpose.
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.
There are one-time programmable registers for Vendor, Product, Device and Language IDs that the bootloader would use instead of the default. It would be interesting to see if those are fused on the Pico 2.
Declaring yourself as a host/device is also a bit different: USB-C hardware can switch. Micro USB has a "On-the-go" (OTG) indicator pin to indicate host/device.
The USB PHY in RP2040 and the RP2350 is actually capable of being a USB host but the Micro USB port's OTG pin is not connected to anything.
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.
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!
I guess it's just rare to have pull-downs, so that's naturally mitigating the issue a bit.
Cortex-M7 is in a different size class than Cortex-M33, it has a speed about 50% greater at the same clock frequency and it is also available at higher clock frequencies.
Cortex-M33 is the replacement for the older Cortex-M4 (while Cortex-M23 is the replacement for Cortex-M0+ and Cortex-M85 is the modern replacement for Cortex-M7).
While for a long time the Cortex-M MCUs had been available in 3 main sizes, Cortex-M0+, Cortex-M4 and Cortex-M7, for their modern replacements there is an additional size, Cortex-M55, which is intermediate between Cortex-M33 and Cortex-M85.
Edit: I see, there are “examples”. I’d rather have those be first-class supported things.
[1] https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new...
[2] https://opensource.googleblog.com/2024/08/introducing-pigwee...
[3] https://blog.bazel.build/2024/08/08/bazel-for-embedded.html
I suppose the main draw of the regulator is that the DVDD rail will consume the most power. 1.1 V is also much more exotic than 3.3 V.
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
You can still find a number of cheap gadgets with micro-USB on Aliexpress. Likely there's some demand, so yes, you can build a consumer product directly on the dev board, depending on your customer base.
"It overclocks insanely well. I’ve been running the device at 300MHz in all of my projects with no issues at all."
Also
"Disclaimer: I was not paid or compensated for this article in any way. I was not asked to write it. I did not seek or obtain any approval from anyone to say anything I said. My early access to the RP2350 was not conditional on me saying something positive (or anything at all) about it publicly."
Do you think that would be a good IC to drive these with a RP2040? https://www.analog.com/en/products/max7219.html
Anyway, a 74LS245 isn't a level shifter, it's an octal buffer. It just happened to be the right choice for my needs. In your application, I'd suggest an actual level shifter. You can find level shift breakout boards at Sparkfun and Adafruit.
It's fine for TTL (like your 74LS245 is), which registers voltages as low as 2V as a logical 1. Being able to directly interface with TTL eases up so many retrocomputing applications.
I did not realize how many pins in a USB-C socket are duplicated to make this possible. (For advanced features, you apparently still need to consider the orientation of the inserted cable.)
Because what you are really testing is the Cortex-M33 vs the Hazard 3, and they aren't equivalent.
They might both be 3 stage in-order RISC pipelines, but Cortex-M33 is technically superscalar, as it can dual-issue two 16bit instructions in certain situations. Also, the Cortex-M33 has a faster divider, 11 cycles with early termination vs 18 or 19 cycles on the Hazard 3.
But I've watched it be insanely detrimental to the productivity of smaller companies and teams who don't understand the mountain of incidental complexity they're signing up for when adopting it. It's usually because a startup hires an ex-Googler who raves about how great Blaze is without understanding how much effort is spent internally to make it great.
Whoops, I read the fine print: RP2350 is manufactured on a 40nm process node.
(Although, interest peaking is possible!)
I think it's cool as a cucumber that we can choose fully open-source RISC-V if we want. My guess is the RV cores are slower clock-per-clock than the M33 cores; that is benchmark scores for M33's will be better, as Hazard3 is only 3-stage pipeline - but so is M33. Can't wait for the benchmarks.
I guess you are very serious about competing with industrial MCU’s.
We had to use a 2040 shortly after it came out because it was impossible to get STM32’s. Our customer accepted the compromise provided we replaced all the boards (nearly 1000) with STM32 boards as soon as the supply chain normalized.
I hope to also learn that you now have proper support for development under Windows. Back then your support engineers were somewhat hostile towards Windows-based development (just learn Linux, etc.). The problem I don’t think they understood was that it wasn’t a case of not knowing Linux (using Unix before Linux existed). A product isn’t just the code inside a small embedded MCU. The other elements that comprise the full product design are just as important, if not more. Because of this and other reasons, it can make sense to unify development under a single platform. I can’t store and maintain VM’s for 10 years because one of the 200 chips in the design does not have good support for Windows, where all the other tools live.
Anyhow, I explained this to your engineers a few years ago. Not sure they understood.
I have a project that I could fit these new chips into, so long as we don’t have to turn our workflow upside down to do it.
Thanks again.
Are you saying DFU is not useful without an MMU/MPU? Why would that be?
[1] https://github.com/raspberrypi/pico-examples/blob/master/dvi...
I guess you’re not gonna be buying a Pi Pico 2, then. So why are you complaining about something you aren’t going to use?
If you ignore the FPU (I think it can be power gated off) the two cores should be roughly the same size and power consumption.
Dual issue sounds like it would add a bunch of complexity, but ARM describe it as "limited" (and that's about all I can say, I couldn't find any documentation). The impression I get is that it's really simple.
Something along the line of "if two 16 bit instructions are 32bit aligned, and they go down different pipelines, and they aren't dependant on each other" then execute both. It might be limitations that the second instruction can't access registers at all (for example, a branch instruction) or that it must only access registers from seperate register file bank, meaning you don't even have to add extra read/write ports to the register file.
If the feature is limited enough, you could get it down to just a few hundred gates in the instruction decode stage, taking advantage of resources in later stages that would have otherwise been idle.
According to ARM's specs, the Cortex-M33 takes the exact same area as the Cortex-M4 (the rough older equivalent without dual-issue, and arguably equal to the Hazard3), uses 2.5% less power and gets 17% more performance in the CoreMark benchmark.
Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years.
Given that PIO's most compelling use case is replacing legacy MCUs, I find it disappointing that they haven't provided PIO boilerplate for the peripherals that keep those archaic architectures relevant. Namely: Ethernet MII and CANbus.
Also, if RP2xxx is ever going to play ball in the wireless space, then they need an out-of-box Bluetooth HCI implementation, and it needs sample code, and integration into Zephyr.
I speak as someone living in this industry: the only reason Nordic has such a firm grip on BLE product dev is because they're the only company providing a bullshit-free Bluetooth stack out of the box. Everything else about nRF sucks. If I could strap a CYW4343 to an RP2350 with some example code as easily as I can get a BT stack up and running on an nRF52840, I'd dump Nordic overnight.
Dev boards or niche specialized hardware are about the only thing I've willingly bought with Micro USB in 4+ years. As much as I try to avoid it given my preference for USB-C, sometimes I don't have a good alternative available.
> So why are you complaining about something you aren’t going to use?
Because it looks like a great upgrade to my RP2040-Zero boards that I would like to buy but I really dislike the choice of connector? What is wrong with that?
Borrowed from just-as-weird French "piquer" - to stab or jab.
PIO is a huge selling point for me and I'm thrilled to see them leaning into it with this new version.
It's already as you hoped. Folks are developing PIO drivers for various peripherals (i.e., CAN and WS2812, etc.)
I can use PIO in the other direction, but this has DDR, so you'll never get the same performance. It's a real shame they didn't make it bi-directional, but maybe the use-case here is (as hinted by the fact it can do TMDS internally) for DVI out.
If they had make it bidirectional, I could see networks of these little microcontrollers transmitting/receiving at gigabit rates... Taken together with PIO, XMOS would have to sit up straight pretty quickly...
Maybe it's just me. Maybe.
[1] Is English just badly pronounced French [video]:
what are you smoking? I have an entire decstation3100 system emulator that fits into 4K of code and 384bytes of ram. I boot palmos in 400KB of RAM. if you cannot fit your "application" into half a meg, maybe time to take up javascript and let someone else do embedded?
https://github.com/KevinOConnor/can2040
https://github.com/sandeepmistry/pico-rmii-ethernet
My biggest issue with their wireless implementation is that I get my boards made at JLCPCB and Raspberry Pi chose a specialty wireless chip for the Pico W which is not widely available, and is not available at JLCPCB.
For example medical imaging.
As well as plenty that require 16 bytes of RAM and a few hundred bytes of program memory. And everything in between.
Part of the reason we went with RP2040 was the design philosophy, but a lot of it was just easy availability coming out of the chip crunch.
* riscv-arch-tests: ok, but a very low bar. They don't even test combinations of instructions so no hazards etc. * riscv-test: decent but they're hand-written directed tests so they aren't going to get great coverage * TestRig: this is better - random instructions directly compared against the Sail model, but it's still fairly basic - the instructions are completely random so you're unlikely to cover lots of things. Also it requires some setup so they may not have ran it.
The commercial options are much better but I doubt they paid for them.
So is almost any non-trivial peripheral feature. Autonomous peripheral operation, op-amps, comparators, capture/compare timers…
Zephyr tries to provide a common interface like desktop OSes do and this doesn't really work. On desktop having just the least common denominator is often enough. On embedded you choose your platform because you want the uncommon features.
Way better than stabbing my interest, in a French fashion or otherwise.
TBH, Java + Bazel + Discord makes it seem like its out of step with the embedded world.
Either way, still looking forward to see what people cook up with it, and hopefully I'll find a use for it as well. Maybe combine it with some cheap 1920x1080 portable monitors to have some beautiful dashboards around the house or something...
Sure, you can work around it, but that often means making significant sacrifices. Good enough for some hacking, not quite there yet to fully replace hard peripherals.
To fit in 520 kB of RAM, the framebuffer would need to be just 1 bpp, 2 colors (1920 * 1080 * 1bpp = 259200 bytes).
From PSRAM I guess you could achieve 4 bpp, 16 colors. 24-bit RGB full color would be achievable at 6 Hz refresh rate.
I guess you might be able to store framebuffer as YUV 4:2:0 (=12 bits per pixel) and achieve 12 Hz refresh rate? The CPU might be just fast enough to compute YUV->RGB in real time. (At 1920x1080@12Hz 12 clock cycles per pixel per core @300 MHz.)
(Not sure whether the displays can accept very low refresh rates.)
The chip needs a) 1.1V to power the cores, b) 1.8V-3.3V to power IO, and c) 3.3V to properly operate USB and ADC.
The chip has one onboard voltage regulator, which can operate from 2.7V-5.5V. Usually it'll be used to output 1.1V for the cores, but it can be used to output anything from 0.55V to 3.3V. The regulator requires a 3.3V reference input to operate properly.
So yeah, you could feed the regulator with 4-5V, but you're still going to need an external 5V->3.3V converter to make the chip actually operate...
Literally «piquer» means “to sting” or “to prick” more than stab or jab, it's never used to describe inter-human aggression.
And piquer is colloquially used to mean “to steal” (and it's probably the most common way of using it in French after describing mosquito bites)
Edit: and I forgot to mention that we already use it for curiosity, in fact the sentence “it piqued my curiosity” was directly taken from French «ça a piqué ma curiosité».
Pretty much everyone has a USB-C cable lying around on their desk because they use it to charge their smartphone. I probably have a Micro-B cable lying around in a big box of cables somewhere, last used several years ago. Even cheap Chinese garbage comes with USB-C these days.
Sure, Micro-B is technically just fine, but why did Raspberry Pi go out of their way to make their latest product more cumbersome to use?
DSP extensions and FPU support are also decent, so good for robotics, (limited) AI, audio, etc.
Also great for learning embedded systems. Very low barrier of entry, just need to download IDE and connect it with an USB cable.
A (small?) ask. Can we have instruction timings please? Like how many cycles SMLAL (signed multiply long, with accumulate) takes?
Will there be an official development board with all 48 GPIOs exposed?
> 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.
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.
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.
For comparison, RP2350 errata in Appendix E of [1]
[0] https://www.st.com/en/microcontrollers-microprocessors/stm32...
[1] https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p...
I guess it depends whether you store to X (or Y), normalize & round (NRDD; is it really necessary after each addition?) and load X back every time.
Both X and Y have 64 bits of mantissa, 14 bits of exponent and 4 bits of flags, including sign. Some headroom compared to IEEE 754 fp64 53 mantissa and 11 bits of exponent, so I'd assume normalization might not be necessary after every step.
The addition (X = X + Y) itself presumably takes 2 cycles; running coprocessor instructions ADD0 and ADD1. 1 cycle more if normalization is always necessary. And for the simplest real world case, 1 cycle more for loading Y.
Regardless, there might be some room for hand optimizing tight fp64 loops.
Edit: This is based on my current understanding of the available documentation. I might very well be wrong.
There's an implementation out there which feeds the clock to a GPIO clock input - but because it can't feed the PLL from it and the PIO is driven from the system clock that means your entire chip runs at 50MHz. This has some nasty implications, such as being unable to transmit at 100meg and having to do a lot of postprocessing.
There's another implementation which oversamples the signal instead. This requires overclocking the Pico to 250MHz. That's nearly double the design speed, and close to some peripherals no longer working.
A third implementation feeds the 50MHz clock into the XIN input, allowing the PLL to generate the right clock. This works, except that you've now completely broken the bootloader as it assumes a 12MHz clock when setting up USB. It's also not complete, as the 10meg half duplex mode is broken due to there not being enough space for the necessary PIO instructions.
Can I ask why? There's dedicated MCU for BLDC motor control out there that have the dedicated peripherals to get the best and easiest sensored/sensorless BLDC motor control plus the supporting application notes and code samples. The RP2040 is not equipped to be good at this task.
Why not? It's a great chip, even if it has some limitations. I use it in several of my pro audio products (a midi controller, a Eurorack module, and a series of guitar pedals). they are absolutely perfect as utility chips, the USB stack is good, the USB bootloader makes it incredibly easy for customers to update the firmware without me having to write a custom bootloader.
I've shipped at least a thousand "real" products with an RP2040 in them.
During the chip shortage, specialized chips like this were very hard to find. Meanwhile the RP2040 was the highest stocked MCU at digikey and most other places that carried it. The farm robot drive motors don't need high speed control loops or anything. We just needed a low cost flexible system we could have fabbed at JLCPCB. The RP2040 also has very nice documentation and in general is just very lovely to work with.
Also SimpleFOC was already ported to the RP2040, so we had example code etc too. Honestly the CPU was the easy part. As we expected, getting a solid mosfet bridge design was the challenging part.
No official 48 GPIO board, I think: this is slightly intentional because it creates market space for our partners to do something.
also "proper" usb-c support is another can of worms, and maybe sticking to an older standard gives you freedom from all that.
Would they be more effective with thin wheels? Both humans and cattle seem to sink in a few inches and stop; I don’t know what’s under the layer of mud and what makes up a rice paddy.
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.
[1] https://www.raspberrypi.com/news/rp1-the-silicon-controlling...
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.
[1]: https://shop.pimoroni.com/products/pimoroni-pico-plus-2
I remember we had to use either VSC or PyCharm (can't remember which) in conjunction with Thonny to get a workable process. Again, it has been a few years and we switched the product to STM32, forgive me if I don't recall details. I think the issue was that debug communications did not work unless we used Thonny (which nobody was interested in touching for anything other than a downloader).
BTW, that project used MicroPython. That did not go very well. We had to replace portions of the code with ARM assembler for performance reasons, we simply could not get efficient communications with MicroPython.
Thanks again. Very much a fan. I mentored our local FRC robotics high school team for a few years. Lots of learning by the kids using your products. Incredibly valuable.
[1] https://www.mouser.dk/datasheet/2/1127/APM_PSRAM_OPI_Xccela_...
HN: "I got almost all of my wishes granted with RP2350"
Article: "Why you should fall in love with the RP2350"
title tag: "Introducing the RP2350"
* By perception at least. They have been prioritizing industrial users from a revenue and supply standpoint, it seems.
I mimicked the 16-bit data bus using hand-written assembly to make sure the timings were as close as possible to the real chip. It was a pain in the ass. It would have been amazing to have a chip that was designed specifically to mimic peripherals like that.
It's great that there's a community growing around the RPi microcontrollers! That's a really good sign for the long-term health of the ecosystem they're trying to build.
What I'm looking for is a comprehensive library of PIO drivers that are maintained by RPi themselves. There would be a lot of benefits to that as a firmware developer: I would know the drivers have gone through some kind of QA. If I'm having issues, I could shoot a message to my vendor/RPi and they'll be able to provide support. If I find a bug, I could file that bug and know that someone is going to receive it and fix it.
To my recollection, every piece of Cortex-M firmware I've worked on professionally in the last 5 years has had at least 300K in .text on debug builds, with some going as high as 800K. I wouldn't call anything I've worked on in that time "atypical." Note that these numbers don't include the bootloader - its size isn't relevant here because we're ramloading.
If you're ram-loading encrypted firmware, the code and data have to share RAM. If your firmware is 250K, that leaves you with 270K left. That seems pretty good, but remember that the 2040 and 2350 are dual-core chips. So there's probably a second image you're loading into RAM too. Let's be generous and imagine that the second core is running something relatively small - perhaps a state machine for a timing-sensitive wireless protocol. Maybe that's another 20K of code, and 60K in data. These aren't numbers I pulled out out of my ass, by the way - they're the actual .text and .data regions used by the off-the-shelf Bluetooth firmware that runs on the secondary core of an nRF5340.
So now you're down to 190K in RAM available for your 250K application. I'd call that "normal," not huge at all. And again, this assumes that whatever you're running is smaller than anything I've worked on in years.
I would sure hope a decstation3100 emulator is small. After all, it's worthless unless you actually run something within the emulator, and that will inevitably be much larger than the emulator itself. I wouldn't know, though. Believe it or not, nobody pays me to emulate computers from 1978.
Easiest would be to wire up two chips with bidirectional links and use a fault handler to transfer small blocks of memory across. You're reimplementing a poor man's MESIF https://stackoverflow.com/questions/31876808.
> The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary.
(quote swiped from https://en.wikiquote.org/wiki/James_Nicoll)
USB3 and altmodes require extra signal lines and tolerances in the cable.
High-voltage/current requires PD negotiation (over the CC pins AFAIK)
Data and power role swaps require muxes and dual-role controllers.
That's all the stuff that makes USB-C a pain in the ass, and it's all the sort of thing RPi Nanos don't support.
Also, are there any other approaches that might be better and would offer 100meg or even gigabit links with the RP2350? Thanks!
The Bazel team has done an amazing job, the VM is embedded and trimmed. It’s as easy and download and run.
And worst case you can invest in Buck2.
I’m just happy to have one fewer component on my boards.
(Above is with killall -s QUIT ping) As you can see, it eventually hangs, and CMSIS reports: target halted due to breakpoint, current mode: Handler HardFault xPSR: 0x61000003 pc: 0x200001c4 msp: 0x20040f40
like you said, the connector does not have to follow the standards. i have seen hdmi ports being used to carry pcie signal (not a good like but here is one such device https://pipci.jeffgeerling.com/cards_adapter/pce164p-no6-ver...) amgon other things. it is still non-standard behaviour.
A potential alternative would have been a directly memory-mapped NOR flash die, but that would have required more bond wires, more dedicated pads on the die, a port on the bus, and on top of that the memory die would have been more expensive too.
An older (and often impractical) alternative is to use a single die with both flash and SoC on, in the same process. This usually forces a larger-than-desired process node to match the flash technology, making the SoC take up more space. The result requires no extra bond wires or pads, but now you're really manufacturing a flash chip with an MCU attached.
Looks like Espressif will keep getting my business. What a missed opportunity by RPI.
Turns out I wasn't passing the RX data properly to LWIP...
Why do we use "tickle" there? Because a tickle is a type of stimulation, and "fancy" here means "interest", so one is effectively saying "this stimulates my interest".
If we then consult Oxford Language's definition of pique, we find:
> stimulate (interest or curiosity). "you have piqued my curiosity about the man"
The word "piqued" in "this piqued my curiosity" serves as something along the lines of: stimulated, aroused, provoked
This is aligned with the French word "piquer", as a "prick" or "sting" (much like a tickle) would stimulate/arouse/provoke.