Live data from Hacker News

I got almost all of my wishes granted with RP2350

dmitry.gr

281–290 of 356 posts

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

#281
post #157

Earlier quoted context omitted.

Mouser have 64 megabyte PSRAMs. I really want a Mac System 7 grade operating system for this chip...

No they do not. 64megabit

Did you bother to check? It's octal, not QSPI, so I don't know if it's compatible. (edit - and 1.8V, inconvenient)

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

#282

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…

>I have been developing a brushless motor driver based on the RP2040 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.

> dedicated MCU for BLDC motor control

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.

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

#283

Big day for my team (Pigweed)! Some of our work got mentioned in the main RP2350/Pico2 announcement [1] but for many months we've been working on a new end-to-end SDK [2] built on top of Bazel [3] with support for both RP2040 and RP2350, including upstreaming Bazel support to the Pico SDK. Our new "Tour of Pigweed" [4] shows a bunch of Pigweed features working together in a single codebase, e.g. hermetic builds, on-d…

Pretty awesome. I love Bazel and it seems you're making good use of it. It's such a difference seeing everything hermetically integrated with all workflows boiling down to a Bazel command.

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

#284

Earlier quoted context omitted.

Would've been cool for safety applications if the second core could be run in lockstep mode.

afaik that is a whole different rodeo on the silicon level

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

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

#285

I can't imagine someone using an RP2040 in a real product, but the RP2350 fixes enough of my complaints that I'd be really excited to give it a shot. 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…

> I can't imagine someone using an RP2040 in a real product 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 cust…

[dead]

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

#286
post #197
post #184

Earlier quoted context omitted.

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

It'd help to know how much area each core takes within the die. I would expect the ARM cores to be much larger, as well as use much more power.

The ARM cores are probably much larger, but I don't think that translates into better power efficiency _automatically_.

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

#287
post #29

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

>USB 2.0 HS

480 Mbps SERDES

> or 1Gb-Ethernet

1.25 Gbps SERDES

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

#289

Earlier quoted context omitted.

Thank you. It's been a major effort from the team, and I'm very proud of what they've accomplished.

Thanks for a great product! 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?

Cortex-M33 timings aren't documented, but one of our security consultants has made a lot of progress reverse engineering them to support his work on trace stacking for differential power analysis of our AES implementation. I've asked him to write this up to go in a future rev of the datasheet.

No official 48 GPIO board, I think: this is slightly intentional because it creates market space for our partners to do something.

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

#290

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