Live data from Hacker News

I got almost all of my wishes granted with RP2350

dmitry.gr

101–110 of 356 posts

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

#101

And still no USB C on the official devboard.

> And still no USB C on the official devboard. 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…

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.

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

#102

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…

Edit: See comment below; The RP2350 can be powered by a 5V supply.

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

#103
post #85

Earlier quoted context omitted.

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.

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.

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

#104
post #43

Earlier quoted context omitted.

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?

It usually means it's clamped so it might result in a small amount of wasted energy/heat but no damage.

So yes it means it's okay but if you can you should go for 3.3.

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

#105

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…

> for our farm robot

That peaked my interest, here's the video for those who want to save a few clicks: https://www.youtube.com/watch?v=fFhTPHlPAAk

I absolutely love that they use bike parts for the feet and wheels.

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

#106
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, for every cool thing about the RP2040, there was a bad thing. DSP-level clock speeds but no FPU, and no hardware integer division. A USB DFU function embedded in boot ROM is flatly undesirable in an MCU with no memory protection. PIO support is extremely limited in third-party SDKs like Zephyr, which puts a low ceiling on its usefulness in large-scale projects.

The RP2350 fixes nearly all of my complaints, and that's really exciting.

PIO is a really cool concept, but relying on it to implement garden-variety peripherals like CAN or SDMMC immediately puts RP2350 at a disadvantage. The flexibility is very cool, but if I need to get a product up and running, the last thing I want to do is fiddle around with a special-purpose assembly language. My hope is that they'll eventually provide a library of ready-made "soft peripherals" for common things like SD/MMC, MII, Bluetooth HCI, etc. That would make integration into Zephyr (and friends) easier, and it would massively expand the potential use cases for the chip.

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

#107

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?

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.

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

#108
post #105

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…

> for our farm robot That peaked my interest, here's the video for those who want to save a few clicks: https://www.youtube.com/watch?v=fFhTPHlPAAk I absolutely love that they use bike parts for the feet and wheels.

I have given some thought to a two-wheeled electric tractor for dealing with mud -- horse paddocks turn into basically a 1-foot deep slurry after heavy rain and it can be easier to deal with something small that sinks through the mud, down to solid ground than something using large floatation tires. Additional problem with large tires is that they tend to throw mud around, making everyone nearby even more dirty.

I haven't actually built anything (been paying attention to Taylor's work, though), but I came to the same conclusion that bike wheels & tires would probably be a good choice. It also doesn't hurt that we have many discarded kids' bikes all over the place.

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

#109

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?

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.

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

#110
post #71

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…

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.

My thoughts exactly - a risc-free (hurhur) way to get RISC-V in the hands of many, many devs.
Post reply on HN