Can’t find an official announcement or datasheet yet, but according to this post:
* 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?
Only $1 more than the original Pico, that's an absolute steal. Although the Pico2 doesn't have PSRAM onboard so there's room for higher end RP235x boards above it.
Make one in an Arduino Uno form factor and double the price and they'd make a killing :-)
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.
Well there's the UNO-R4 Renasas I suppose, but this would be much cooler indeed. There's also the 2040 Connect in the Nano form factor with the extra IMU.
Downside is it occupies a CS on the QSPI controller, presumably bonding to the same pads as the QSPI pins on the package, so now you only have one external memory IC. It's a very small tradeoff all things considered, but is still technically a tiny disadvantage over highly integrated MCUs.
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.
Be careful with assumptions though. Being 5V tolerant doesn't mean that your 3V output can sufficiently drive an input that expects 0-5V levels correctly.
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.
A better question might be why anyone is using a MAX7219 on a new design in 2024. There are so many other choices for displays than a 20 year-old IC from a company that's gone through two changes of ownership since.
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.
> Being 5V tolerant doesn't mean that your 3V output can sufficiently drive an input that expects 0-5V levels correctly.
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.
Even if it does I'm suspicious. The open source RISC-V verification systems are not very good at the moment:
* 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.
Not sure why this is downvoted but the sleep and dormant pico examples have quite some issues, they are still in "extras" and not in "core", so while documentation of features is my personal favorite aspect of the pico, there is room for improvement here still.
It is downvoted because it is a low effort sarcastic comment which provides no real contribution to the discussion. Your comment actually provides real feedback as to where there are currently issues.
I'm having trouble seeing where the datasheet actually says the GPIO pins are 5V tolerant.
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.
Yep, I edited a few minutes ago to mention a reference I found in the datasheet. It's cool, but the reality seems a little more nuanced than that quote would indicate, since that only appears to work for GPIO-only pins, not just pins being used as GPIO. (So, if a pin supports analog input, for example, it will not be 5V tolerant.)
I'd rather have it run on the lower voltage - generally easier to step down than buck up. Either way, the modules are pretty cheap, small, and easy to find.
The regulator can take that, but as far as I can see it's only for DVDD, the core voltage of 1.1 V. You also need at least IOVDD, which should be between 1.8 V and 3.3 V. So you'll need to supply some lower voltage externally anyway.
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.
You're right, after re-reading the Power section on the datasheet it seems connecting 5V to the VREG_VIN should suffice to power the digital domains, but if you want to use the ADC, you still need a external 3.3V source.
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...
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.
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.
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?
"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."
This "switchable cores" thing has been appearing in some products for a few years now, for example Sipeed SG2002 (LicheeRV). The area occupied by the actual instruction core is usually pretty small compared to peripherals and internal memories.
Apparently (this is news to me), you can also choose to run 1+1 Arm/RISC-V, you don't have to switch both cores either/or.
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."
Yea, i was hoping for 2+2 myself but I suspect it's because the setup doesn't have the ability to mediate peripherals between the cores in a way that'd let that work. I.e. trying to turn on both Risc-v and arm #1 cores means that there'd be bus conflicts. It'd be cool if you could disable the io on the risc-v cores and do all hardware io through arm (or vice versa) so you can use the unconnected ones for just pure compute tasks (say run ws2812b led strips with the arm cores but run python/javascript/lua on the risc-v cores to generate frames to display without interrupting the hardware io).
We did look at this, but the AHB A-phase cost of putting a true arbiter (rather than a static mux) on each fabric port was excessive. Also, there's a surprising amount of impact elsewhere in the system design (esp debug).
yeah lockstep requires a whole bunch of things to verify and break deadlocks. I suspect you need three processors to do that as well (so you know which one has fucked up.)
It is not necessary that there is triple modular redundancy with lockstep, I know of microcontrollers with two processors, who throw an error when the results from instructions don't match.
This seems like a great way to test the waters before a potential full-on transition to RISC-V. It allows to validate both technically and market reception, for a much lower cost than taping out a additional chip.
I really hope people don't do this. Or at least not try to sell it as ARM vs RISC-V tests.
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.
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.
That is exactly what the "limited dual issue" is - two non-conflicting pre-decoded instructions (either 16b+16b or if a stall has occurred) can be sent down the execution pipe at the same time. I believe that must be a memory op and an ALU op.
I do wonder if the unavailability of some of the security features and -- possibly a big deal for some applications -- the accelerated floating point on the RISC-V cores would skew that experiment, though.
Indeed, though I'm curious about the rationale behind it. It is a 'plan B' in case their relationship with ARM sours? It is aiming for cost-cutting in the future (I can't imagine the ARM licences are costing them much given the price of the RP2040, but maybe they're absorbing it to get marketshare)
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.
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`.
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:
> 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.
1. Nobody has a wider selection of peripherals than a chip with 3 PIOs.
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!
I'm not arguing you can't be angry with them, I'm just saying that to me, it detracts from the point about the new platform. Regarding #1, I'm sure you know that peripherals in the MCU world mean more than just digital I/O. Further, even in the digital domain, the reason PIO isn't more popular is that most people don't want to DIY complex communication protocols.
[edit: I retract this, I see you’ve had secretly in your possession to play with for over a year. You lucky dog. ]
> 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.
they're complaining now because they still feel the pain now. while writing the article, they're thinking of how things would have been different on previous projects if they had had this chip, and that is digging up pain and they felt it should be expressed.
I don't know what's so unclear. Have you never had a strong opinion about someone else's stuff? Man, I have.
FlexIO is (I think) powerful, however... I'm not sure if it's me or the way they describe it with all the bit-serialisers/shifters interacting - but I grok the PIO assembly a damn sight easier than FlexIO.
TFA states extensive 300Mhz OC with no special effort (and he's been evaluating pre-release versions for a year).
"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."
The STM32H7 and other M7 chips have caches - performance is night and day between 2x300MHz smaller, cacheless cores and chips with L1 caches (and things like TCM, etc.)
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.)
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.
As other posters have mentioned, this has 2 Cortex-M33 cores @ 150 MHz, not @ 300 MHz.
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.
ST is a zillion dollar company that should be hiring the talent capable of delivering product that match the features in their sales pamphlets.
Integration is tricky but a company with STs deep pockets should be able to root cause or at least help troubleshoot an issue, not ask for a fix like some nepotism hire.
I'm not an ST fanboy and they're not a vendor I use, but they are very popular in the 32-bit Cortex-M space, so they're clearly doing something right. Meanwhile, companies like Microchip that put effort into accessible documentation and tooling are getting table scraps.
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?
Coordinating access to the memory bus and peripherals is probably not easy to do when the cores weren’t ever designed to work together. Doing so could require a power/performance penalty at all times, even though most users are unlikely to want to deal with two completely different architectures across four cores on one microcontroller.
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.
They actually let you choose one Cortex-M33 and one RISC-V RV32 as an option (probably not going to be a very common use case) and support atomic instructions from both cores.
All of the public mentions of this feature that I've seen indicated it is an either/or scenario, except the datasheet confirms what you're saying:
> 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.
cores are high bandwidth bus masters. Making a crossbar that supports 5 high bandwidth masters (4x core + dma) is likely harder, larger, and higher power than one that supports 3.
It's actually 10 masters (I+D for 4 cores + DMA read + DMA write) versus 6 masters. Or you could pre-arbitrate each pair of I and each pair of D ports. But even there the timing impact is unpalatable.
Beyond the technical reasons for the limit, it provides for a relatively painless way to begin to build out/for RISC-V[1] without an uncomfortable transition. For those who just want a better next iteration of the controller, they have it. For those who build tools, want to A/B test the architectures, or just do whatever with RISC-V, they have that too. All without necessarily setting the expectation that both will continue to coexist long term.
[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.
I see a business decision here.
Arm cores have licensing fees attached to them.
Arm is becoming more restrictive with licensing and wants to capture more value [1]:
> 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.
Each arm/riscv set likely share cache and register space (which takes most of the die space by far), resulting in being unable to use them both simultaneously.
Considering that these are off-the-shelf Cortex-M designs I doubt that Raspi was able or would be allowed to do that. I'd expect most of the die to be the 512K SRAM, some of the analog and power stuff and a lot of it just bond pads.
Unless the USB-C connector costs $7-10, these are beyond ridiculously overpriced compared to the official dev board. At least throw in an IMU or something if you plan to sell low volumes at high prices jeez.
The cheapest one I've seen so far is the XIAO RP2350, which is $5, same as the official Pico board. I'm sure there will be more cheap options once more Chinese manufacturers get their hands on the chips, no-name USB-C RP2040 boards are ridiculously cheap.
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.]
Personally I have about three dozen USB-A to USB-C cables lying around and the thought of actually spending money to acquire extra Micro USB cables in 2024 is very unappealing.
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.
> 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.
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?
I think you misread what I wrote: consumer electronic device
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?
Even if you interpreted that sentence right, that's not a reasonable rebuttal. If a feature stops someone from buying a product, then it makes sense to complain about the feature. Their non-purchase doesn't invalidate the complaint. It's only when someone isn't interested in the category at all that complaints lose their value.
> 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.
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.
It's not a huge deal, but it's still a very strange choice on a product released in 2024.
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?
> 1 × USB 1.1 controller and PHY, with host and device support
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)?
RP1 I/O chip on RPi5 has so many high-speed interfaces. I've been thinking RP2350 could be some smart I/O chip for a PC/notebook/network attached computers (with only 1 necessary high-speed connection).
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 did that, not just SRAM but also ROM, to fool a MC68EZ328 successfully. It works well. PIO + DMA does it well. Specifically i replaced rom & ram in an old Palm Pilot with an RP2040:
Thought I had more than this, but it's been literally decades...
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.
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.
Many people seem excited about the FPU. Could you help me understand what hardware floating point support is needed in a MCU for? I remember DSPs using (awkward word-size) fixed point arithmetic.
I think you highlight the exact issue rather well... fixed-point DSP instructions are awkward to use. The FPU and the double-precision hardware with its baked operations work with IEEE floats out of the box, so the programmer can be "lazy." A thousand new programmers can write something like `* 0.7` in C++ inside a tight loop without it stealing 200 instructions from the timing of the rest of the program.
I wonder what other uses people will find for it. It's one-way data transfer, I wonder if it could be hooked up to a USB 2.0 or USB 3.0 peripheral, or an ethernet PHY, or something else.
Pretty sure I'm going to link it up with an FPGA at some point - as long as the data is unidirectional, this is a promise of 2400 Mbit/sec - which for a $1 microcontroller is insane. If it overclocks like the processor, you're up to 4800 MBit/sec ... stares into the distance
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...
Right? Bidirectional capability at those speeds would be incredible for the price of this chip.
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...
1920x1080 30 Hz DVI would require running RP2350 at least at 311 MHz ((1920 * 1080 * 30Hz * 10) / 2). Probably a bit more to account for minimal horizontal and vertical blanking etc. Multiplier 10 comes from 8b10b encoding.
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.)
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.
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.
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 ;)
I'm assuming you've looked at the pico-rmii-ethernet library? If so, I feel your pain - I've been fixing issues, and am about halfway done. (This is for the DECstation2040 project, available on github). Look for a release in late aug/early sep. (Maybe with actual lance code? Dmitry??) The RP2350 will make RMII slightly easier - the endless DMA allows elimination of the DMA reload channel(s).
I looked at it and dismissed it as too hacky for production. I don't remember the real reason why. I would have to look through my notes. The main question is whether the RP2350 will change that. As in it actually possible to do bug free without weird hacks.
USB-C doesn't require anything special USB wise as it's decoupled from the versioned standard. It just has more pins and works with all modern cables. Ideally the cables won't wear out like Mini and Micro and get loosey goosey in the ports.
Yep, a USB-C connector is more or less a drop in replacement for MicroUSB if you don’t need USB3 or USB-PD. With one aggravating exception: it requires adding two 5.1kΩ pulldown resistors to be compatible with C-C cables. Thus signaling to a charger that the sink is a legacy non-PD device requesting 5V.
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”.
For a device, USB-C requires two resistors that older USB ports don't.
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.
Hm, I've used mine as a USB host with an adapter? Not sure of the details, I suppose OTG is the online/runtime switching and I was just running as fixed host?
For the microcontroller however, the use in commercial products is encouraged.
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.
You're confusing USB C and USB 3.1+. USB C is just the physical spec. You can design a cheap device that will only support USB 2 if you just connect ground, Vbus, D+ and D- and gasp add two resistors. It will work just as well as the micro-usb plug.
completely valid, but i would like to think the org is still designing for accessibility for newbies in mind.
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 USB-C port that only supports USB2 data and power only needs a few resistors across some pins to trigger legacy modes and disable high current/voltage operation. All the extra bits are the things that jack up the cost.
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.
How about connections not becoming flaky after you've plugged in the cable a few times. Micro USB was horribly unreliable. USB-C isn't great either, but it's an improvement. Maybe they will get it right some day.
I always hear that but I never had a micro usb fully fail on me but my phone's usb-c are lint magnets and get super loose and refuse to work. When that happened on micro it was usually the cable tabs a bit worn but the cable always worked.
FWIW the Pimoroni Tiny 2040 and Tiny 2350 use usb-c, but as mentioned by other commenters, the cost for these usb-c boards is higher.
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.
USB-C is way more complicated, even if you're not trying to push 4K video or 100W power through it. The interface chip ought to be more complex, and thus likely more expensive.
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.
Yes, indeed, I've checked, and apparently you don't need anything beyond this if you don't want super speed or power delivery (past 5V 3A).
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.)
355 comments
[ 2.9 ms ] story [ 305 ms ] thread* 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!
https://www.raspberrypi.com/products/raspberry-pi-pico-2/
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.
I’m just happy to have one fewer component on my boards.
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.
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!
Looks like Espressif will keep getting my business. What a missed opportunity by RPI.
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...
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
I can’t wait to use this!
So yes it means it's okay but if you can you should go for 3.3.
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.
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.
* 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.
Low power suspend? In a Pi Foundation product? Impossible.
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.
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.
But the µC itself runs on 3.3V and is not totally 5V-capable. You'd need level converters to interface with 5V.
> A separate, nominally 3.3 V, low noise supply (VREG_AVDD) is required for the regulator’s analogue control circuits.
It seems it would be painful trying to run this without 3.3 V.
The TL;DR is that 3.3v must be fed into IOVDD for 5.5v tolerance to work.
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...
Part of the GPIOs are CMOS are 5v-tolerant, and TTL considers 2v HIGH, thus it is possible to interface some 5v hardware directly.
"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."
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/
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.
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.
I would expect the ARM cores to be much larger, as well as use much more power.
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.
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.
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.
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!
> 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 don't know what's so unclear. Have you never had a strong opinion about someone else's stuff? Man, I have.
NXP FlexIO says "Hello!"
Maybe it's just me. Maybe.
STM32H7 tops out at 600MHz. This has 2x 300MHz at 2-3 cycles/op FP64. So maybe your applications can fit into this?
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...
"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."
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.)
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.
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.
Official product page: https://news.ycombinator.com/item?id=41192269
Raspberry Pi Pico 2, our new $5 microcontroller board, on sale now - https://news.ycombinator.com/item?id=41192341 - Aug 2024 (71 comments)
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.
> 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
[1] https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
[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.
> 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-...
[2] https://gwern.net/complement
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:
https://shop.pimoroni.com/products/pimoroni-pico-plus-2
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 (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.
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?
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?
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.
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?
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)?
[1] https://www.raspberrypi.com/news/rp1-the-silicon-controlling...
480 Mbps SERDES
> or 1Gb-Ethernet
1.25 Gbps SERDES
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
Do you have anything published?
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 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.
https://www.mouser.com/ProductDetail/877-FM16W08-SG
I will re-test and try to get better sleep state in my code either today or tomorrow!
[1] https://github.com/raspberrypi/pico-examples/blob/master/dvi...
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...
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...
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.)
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 ;)
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”.
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.
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.
also "proper" usb-c support is another can of worms, and maybe sticking to an older standard gives you freedom from all that.
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.
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.
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.
[1]: https://shop.pimoroni.com/products/pimoroni-pico-plus-2
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.
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.)