Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I got almost all of my wishes granted with RP2350

dmitry.gr

Post reply on HN
Print view View original

271–280 of 356 posts

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

#271

Post by TaylorAlexander »

bboygravity wrote: post #242
ryukoposting wrote: post #224

Earlier quoted context omitted.

These examples are cute, but this isn't a comprehensive collection. Not even close. Given that PIO's most compelling use case is replacing legacy MCUs, I find it disappointing that they haven't provided PIO boilerplate for the peripherals that keep those archaic architectures relevant. Namely: Ethernet MII and CANbus. Also, if RP2xxx is ever going to play ball in the wireless space, then they need an out-of-box Bluet…

Just feed the boilerplate templates to Claude and ask it to "write a CANbus driver, use boiler plate as example" and done?

I have never had even the slightest luck getting any of the AI services to generate something as specialized as embedded system drivers.

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

#272

Post by crest »

TickleSteve wrote: post #253
ryukoposting wrote: post #219

Earlier quoted context omitted.

It's certainly useful, but having it embedded within the hardware with no way to properly secure it makes the RP2040 a non-starter for any product I've ever written firmware for.

it has secure boot and TrustZone.

Not the RP2040. That chip has no boot security from anyone with physical access to the QSPI or SWD pins.

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

#273

Post by defrost »

TaylorAlexander wrote: post #271
bboygravity wrote: post #242

Earlier quoted context omitted.

Just feed the boilerplate templates to Claude and ask it to "write a CANbus driver, use boiler plate as example" and done?

I have never had even the slightest luck getting any of the AI services to generate something as specialized as embedded system drivers.

I can't even get them to make me a sandwich :(

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

#274

Post by my123 »

IshKebab wrote: post #247
pclmulqdq wrote: post #225

Earlier quoted context omitted.

This is a really big deal. Verifying a core is hard, and if the repo doesn't come with a testbench, I'm very suspicious.

Even if it does I'm suspicious. The open source RISC-V verification systems are not very good at the moment: * riscv-arch-tests: ok, but a very low bar. They don't even test combinations of instructions so no hazards etc. * riscv-test: decent but they're hand-written directed tests so they aren't going to get great coverage * TestRig: this is better - random instructions directly compared against the Sail model, but…

See https://github.com/Wren6991/Hazard3/tree/stable/test for the test harnesses used. I wonder if they did release all they used there.

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

#275

Post by crote »

vardump wrote: post #262
crote wrote: post #255

Earlier quoted context omitted.

I feel like the PIO is just slightly too limited for that. You can already do some absolute magic with it, but it's quite easy to run into scenarios where it becomes really awkward to use due to the limited instruction count, lack of memory, and absence of a direct clock input. Sure, you can work around it, but that often means making significant sacrifices. Good enough for some hacking, not quite there yet to fully…

Any concrete examples? PIO is surprisingly flexible, even more so in RP2350.

You run into issues if you try to implement something like RMII, which requires an incoming 50MHz clock.

There's an implementation out there which feeds the clock to a GPIO clock input - but because it can't feed the PLL from it and the PIO is driven from the system clock that means your entire chip runs at 50MHz. This has some nasty implications, such as being unable to transmit at 100meg and having to do a lot of postprocessing.

There's another implementation which oversamples the signal instead. This requires overclocking the Pico to 250MHz. That's nearly double the design speed, and close to some peripherals no longer working.

A third implementation feeds the 50MHz clock into the XIN input, allowing the PLL to generate the right clock. This works, except that you've now completely broken the bootloader as it assumes a 12MHz clock when setting up USB. It's also not complete, as the 10meg half duplex mode is broken due to there not being enough space for the necessary PIO instructions.

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

#276

Post by my123 »

vardump wrote: post #244
dmitrygr wrote: post #239

Earlier quoted context omitted.

> Also, 520K of RAM wouldn't be enough to fit a the whole application + working memory for any ARM embedded firmware I've worked on in the last 5 years. what are you smoking? I have an entire decstation3100 system emulator that fits into 4K of code and 384bytes of ram. I boot palmos in 400KB of RAM. if you cannot fit your "application" into half a meg, maybe time to take up javascript and let someone else do embedded…

There are plenty of embedded applications that require megabytes or even gigabytes. For example medical imaging. As well as plenty that require 16 bytes of RAM and a few hundred bytes of program memory. And everything in between.

If it's in the gigabyte range it's just not an MCU by any stretch. And if it has a proper (LP)DDR controller it's not one either really

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

#277

Post by vardump »

my123 wrote: post #276
vardump wrote: post #244

Earlier quoted context omitted.

There are plenty of embedded applications that require megabytes or even gigabytes. For example medical imaging. As well as plenty that require 16 bytes of RAM and a few hundred bytes of program memory. And everything in between.

If it's in the gigabyte range it's just not an MCU by any stretch. And if it has a proper (LP)DDR controller it's not one either really

Yes and no. Plenty of such applications that use a µC + an FPGA. FPGA interfaces with some DDR memory and CMOS/CCD/whatever.

Up to you what you call it.

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

#278

Post by Rinzler89 »

TaylorAlexander wrote: post #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…

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

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

#279

Post by valdiorn »

ryukoposting wrote: post #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…

> 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 custom bootloader.

I've shipped at least a thousand "real" products with an RP2040 in them.

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

#280

Post by TaylorAlexander »

crote wrote: post #275
vardump wrote: post #262

Earlier quoted context omitted.

Any concrete examples? PIO is surprisingly flexible, even more so in RP2350.

You run into issues if you try to implement something like RMII, which requires an incoming 50MHz clock. There's an implementation out there which feeds the clock to a GPIO clock input - but because it can't feed the PLL from it and the PIO is driven from the system clock that means your entire chip runs at 50MHz. This has some nasty implications, such as being unable to transmit at 100meg and having to do a lot of p…

Just to clarify, and it sounds like the answer is yes, this is a problem even with an external 50MHz clock signal?
Post reply on HN