Luke (author of Hazard3) provided some context regarding including the Hazard3 cores alongside the M33's:
> I can't compare the sizes of the two cores. The final die size would likely have been exactly the same with the Hazard3 removed, as std cell logic is compressible, and there is some rounding on the die dimensions due to constraints on the pad ring design. I can say that we taped out at a very high std cell utilisation and we might have saved a few grey hairs during final layout and STA by deleting the RISC-V cores.
Their partners already have tons of alternative boards ready to go, including a few which are drop-in replacements for the Pico, if you don't mind spending a bit more for USB-C:
The problem is most of the boards from partners are specialized with different hardware add-ons and have a significant markup at about 10 USD a board, which makes it harder to justify buying a handful of boards to tinker with. It's quite unfortunate.
Oh, I was trying to understand why cheap chiniseum USB-C-powered products off Amazon were only charging from a cheap USB-A brick and not from my quality USB C chargers.
Ugh, that one was killing me the other day. I went through 3 different cables before I found a hardware designer on the company's discord who could explain the issue.
I suspect the microUSB would actually fail in OTG mode for the same reasons in that case though? It's the same thing in terms of needing extra resistors.
Probably so they can say that it's a drop-in upgrade over the Pico 1. It's not a drop-in upgrade if you have to redesign your project's case to use it.
No, it just needs 2 extra resistors to work properly, but will work as-is if you use USB-A to USB-C cables and as long as you don't pull more power than available by default (i.e. you can request 3A @ 5V just by adding two resistors, but without it you're limited to USB's defaults)
In the past, when usb-c just got introduced micro usb ports for significantly cheaper than usb-c, so it made some sense. Today, it makes no sense.
Indeed, that is a well-written technical book that one could read cover-to-cover. It has a clear progression of topics, and all of the text is beautifully written:
"Once secure boot is enabled, the bootrom verifies signatures of images from all supported media: flash, OTP, and images preloaded into SRAM via the UART and USB bootloaders. At this point you lose the ability to run unsigned images; during development you may find it more convenient to leave secure boot disabled. The next section describes the generation of signed images to run on a secure-boot-enabled device."
"The chip-level reset subsystem shares a register address space with other power management subsystems in the always-on domain. The address space is referred to as POWMAN elsewhere in this document. A complete list of POWMAN registers is provided in Section 6.4, “Power Management (POWMAN) Registers”, but information on registers associated with the brownout detector are repeated here."
"The clocks block provides independent clocks to on-chip and external components. It takes inputs from a variety of
clock sources, allowing the user to trade off performance against cost, board area and power consumption. From these
sources it uses multiple clock generators to provide the required clocks. This architecture allows the user flexibility to
start and stop clocks independently and to vary some clock frequencies whilst maintaining others at their optimum
frequencies."
Wow, this seems to address every complaint about the RP2040 I had. Be sure to read all the way to the bottom for the "One more thing" section. You can choose Cortex-M33 or RISC-V at boot time transparently!
For a mass produced product, why waste die space on RISC-V cores that can only be used instead of the Cortex cores? Why not just use that die space for more ram or another ARM core? Doesn't it make sense to sell a variant that is entirely RISC-V?
Supposedly it didn’t require any measurable amount of additional die space, because other things constrained the minimum size of the die (like the I/O pads), according to one of the Raspberry Pi engineers.
An additional ARM core would have required significant changes to the crossbar. Right now, only two cores can be active, not three.
If I were to guess, they probably concluded that `cumulative wasted manufacturing cost` < `engineering fees and costs of maintaining two entirely different chips`.
I think this type of pseudo-wasteful design is not unheard of when manufacturer had two markets to deliver to that had substantially different processing, but not I/O, requirements, as well as when some of major features in already manufactured chip didn't work out and ways to offset losses would be nice.
Wild-ass guess; but I assume there is a lot of overlap in the functionality between the type of cores which would mean only a small amount of extra space is required for the additional RISC-V instruction set support as opposed to having distinct CPU cores.
Maybe a good place to ask this: does anyone know of an all-in-one board for battery management in small mobile devices? Recently started playing with the ESP32 and was surprised there isn't a ready-to-go board on AliExpress for handling usb battery charging with simultaneous device powering. I want to add a LiPo to my design and have it just work like my cell phone does.
Adafruit has a couple of LiPo charger boards, but they don't have the integration you'd want: you'd need a separate USB cable for charging.
ISTR that some of their ESP32 boards do, though. i.e., charge LiPo through the USB port.
Also, I think some of the Heltec boards do. I have one here with a JST battery connector, but I haven't used it in so long, I'm not sure. I think this is the one I have: https://heltec.org/project/wifi-kit32-v3/
Though I'll also not I'm having some problems getting it to take an upload properly, but I tend to find most of the LILYGO stuff takes a little experimentation to get everything right, then it is reliable once you know what it likes.
ESP32 chips supposedly has an integrated BMS, and it's used in M5Stack as well as Seeeduino XIAO. Weird part is it's not clearly stated how it works other than you're supposed to solder a battery on.
I'm currently exploring 2-cell solutions: BQ25886, BG25887, MP5461, MP2672, LTC3118, MP2639C, IP2326, BQ294533, MCP73213. And here are some single cell solutions: IP2312, ETA9740, TP5100, IP5328P, MCP73834, MCP73833, LTC1734, LTC4121.
I found some modules on aliexpress with usbc connector, for example:
Looks like it's an "and" in silicon and an "or" at boot time?
>RP2350 includes a pair of open-hardware Hazard3 RISC-V cores which can be substituted at boot time for the Cortex-M33 cores. Our boot ROM can even auto-detect the architecture for which a second-stage binary has been built and reboot the chip into the appropriate mode
So we've seen people discuss doing dirty tricks like trapping and emulating writes, among other horrible things, to get external RAM "working" on an RP2040. The RP2350 datasheet says it supports read/write memory mapping on its new QSPI memory interface. So, does that mean one can just straightforwardly hook up PSRAM? I'm not much of a hardware person but this seems very promising. (And also, I'm really curious how much better the performance will be if you can do that.)
Oh I see. I either got merged into this discussion from another thread or came here from a dupe link, but I was looking at the product page which didn't seem to talk about it.
Readit News
> I can't compare the sizes of the two cores. The final die size would likely have been exactly the same with the Hazard3 removed, as std cell logic is compressible, and there is some rounding on the die dimensions due to constraints on the pad ring design. I can say that we taped out at a very high std cell utilisation and we might have saved a few grey hairs during final layout and STA by deleting the RISC-V cores.
https://x.com/wren6991/status/1821582405188350417
I was hoping that the next iteration would start using USB-C even if it costed a bit more per-board.
https://www.raspberrypi.com/for-industry/powered-by/product-...
Thought it might be the cable at first, but it was general. Just couldn’t think of a reason why it wasn’t supported though…
1: I still have a ton of micro-USB cables, and a decreasing number of things to use them for. Some are unused, still in unopened packages.
2: Devices like this don't get moved and plugged/unplugged frequently, which is what kills the connector.
> Picossci2 Breakout is a drop-in replacement for Pico 2, with a USB-C connector.
My guess is the RPi foundation has a _ton_ of extra micro USB connectors they want to use up.
In the past, when usb-c just got introduced micro usb ports for significantly cheaper than usb-c, so it made some sense. Today, it makes no sense.
Larger package (60 or 80 pins)
Variant with 2 MB in-package Flash
Secure boot and encrypted boot
Two security execution contexts
Random number generator
SHA-256 accelerator
8 kB of OTP ROM (separate from the 32 kB BOOTROM)
8 channel HSTX high speed serial transmitter
30->48 GPIO (18 more, in the 80 pins)
8->12 PIO state machines
12->16 DMA channels
RISC-V and ARM (selectable at boot, individually per core)
Cortex-M0+->Cortex-M33 (I don't know what that means in practice)
133->150 MHz core clock
https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p...
Not in terms of the product specs (which are also really nice), but in terms of layout and content.
Indeed, that is a well-written technical book that one could read cover-to-cover. It has a clear progression of topics, and all of the text is beautifully written:
"Once secure boot is enabled, the bootrom verifies signatures of images from all supported media: flash, OTP, and images preloaded into SRAM via the UART and USB bootloaders. At this point you lose the ability to run unsigned images; during development you may find it more convenient to leave secure boot disabled. The next section describes the generation of signed images to run on a secure-boot-enabled device."
"The chip-level reset subsystem shares a register address space with other power management subsystems in the always-on domain. The address space is referred to as POWMAN elsewhere in this document. A complete list of POWMAN registers is provided in Section 6.4, “Power Management (POWMAN) Registers”, but information on registers associated with the brownout detector are repeated here."
"The clocks block provides independent clocks to on-chip and external components. It takes inputs from a variety of clock sources, allowing the user to trade off performance against cost, board area and power consumption. From these sources it uses multiple clock generators to provide the required clocks. This architecture allows the user flexibility to start and stop clocks independently and to vary some clock frequencies whilst maintaining others at their optimum frequencies."
I am thoroughly impressed!!
I think the 60 pin version is the same size as RP2040.
Supposedly it didn’t require any measurable amount of additional die space, because other things constrained the minimum size of the die (like the I/O pads), according to one of the Raspberry Pi engineers.
An additional ARM core would have required significant changes to the crossbar. Right now, only two cores can be active, not three.
I think this type of pseudo-wasteful design is not unheard of when manufacturer had two markets to deliver to that had substantially different processing, but not I/O, requirements, as well as when some of major features in already manufactured chip didn't work out and ways to offset losses would be nice.
ISTR that some of their ESP32 boards do, though. i.e., charge LiPo through the USB port.
Also, I think some of the Heltec boards do. I have one here with a JST battery connector, but I haven't used it in so long, I'm not sure. I think this is the one I have: https://heltec.org/project/wifi-kit32-v3/
Though I'll also not I'm having some problems getting it to take an upload properly, but I tend to find most of the LILYGO stuff takes a little experimentation to get everything right, then it is reliable once you know what it likes.
I found some modules on aliexpress with usbc connector, for example:
- IP2326 https://www.aliexpress.com/item/1005007175222069.html
- CN3302 https://www.aliexpress.com/item/1005006203228418.html
but I haven't tested them yet.
You can also get version to fit the Pico, or even a RP2040 based board with integrated battery management.
>RP2350 includes a pair of open-hardware Hazard3 RISC-V cores which can be substituted at boot time for the Cortex-M33 cores. Our boot ROM can even auto-detect the architecture for which a second-stage binary has been built and reboot the chip into the appropriate mode
https://www.raspberrypi.com/documentation/microcontrollers/s...
The post claims PSRAM is supported.
Either way, that seems like great news.