Live data from Hacker News

I got almost all of my wishes granted with RP2350

dmitry.gr

81–90 of 356 posts

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

#81

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, includin…

> STM32H7 chips can run much faster STM32H7 tops out at 600MHz. This has 2x 300MHz at 2-3 cycles/op FP64. So maybe your applications can fit into this?

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.)

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

#82

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…

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.

Page 13: "GPIOs are 5 V-tolerant (powered), and 3.3 V-failsafe (unpowered)"

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

#83
post #82

Earlier quoted context omitted.

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.

Page 13: "GPIOs are 5 V-tolerant (powered), and 3.3 V-failsafe (unpowered)"

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.)

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

#84

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, includin…

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 se…

> 1. Nobody has a wider selection of peripherals than a chip with 3 PIOs.

NXP FlexIO says "Hello!"

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

#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.

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

#86

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…

> Low-power operation Low power suspend? In a Pi Foundation product? Impossible.

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.

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

#87

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.

It's in this post - https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-new...

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

#90

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.

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).
Post reply on HN