Live data from Hacker News

I got almost all of my wishes granted with RP2350

dmitry.gr

91–100 of 356 posts

Re: I got almost all of my wishes granted with RP2350

#91

Earlier quoted context omitted.

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." Source: https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/

But not 2+2? That seems too bad to have each architecture run code based on their strengths for quad core workloads.

Why not both: power distribution and cooling? Having to route twice as many wide buses, and put in twice as much of L0 caches?

Re: I got almost all of my wishes granted with RP2350

#92

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?

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.

Re: I got almost all of my wishes granted with RP2350

#94
post #15

Some specs here: https://www.digikey.ca/en/product-highlight/r/raspberry-pi/r... 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…

Hazard3 RTL: https://github.com/Wren6991/Hazard3

I wonder how well it's been verified.

Re: I got almost all of my wishes granted with RP2350

#95
This is very exciting! For the last several years I have been developing a brushless motor driver based on the RP2040 [1]. The driver module can handle up to 53 volts at 30A continuous, 50A peak. I broke the driver out to a separate module recently which is helpful for our farm robot and is also important for driver testing as we improve the design. However this rev seems pretty solid, so I might build a single board low cost integrated single motor driver with the RP2350 soon! With the RP2040 the loop rate was 8khz which is totally fine for big farm robot drive motors, but some high performance drivers with floating point do 50khz loop rate.

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!

[1] https://github.com/tlalexander/rp2040-motor-controller

[2] https://twitter.com/TLAlexander

Re: I got almost all of my wishes granted with RP2350

#96
post #43

Earlier quoted context omitted.

Wow, can't wait. Love the 5V GPIO and security features.

5V GPIO is a huge deal for me - this immediately opens up a huge range of integrations without having to worry about line level conversion. I can’t wait to use this!

Does tolerant mean ok to do? Or it just won’t fry your chip but you should actually run at 3.3?

Re: I got almost all of my wishes granted with RP2350

#98

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?

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.

[1] https://arstechnica.com/gadgets/2023/03/risc-y-business-arm-...

[2] https://gwern.net/complement

Re: I got almost all of my wishes granted with RP2350

#99
post #85
post #78

Gross, the dev board uses micro-USB. It's 2024! Otherwise amazing work. Exactly what's needed to compete with the existing giants.

Perhaps the unfortunate choice of micro USB is to discourage real consumer products from being built with the dev board.

I wonder if it is more about simply shaving a few cents off. Full USB-C protocol implementation may be much more difficult.
Post reply on HN