Live data from Hacker News

I got almost all of my wishes granted with RP2350

dmitry.gr

221–230 of 356 posts

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

#221

Earlier quoted context omitted.

For my work, the lack of flash memory integration on the 2040 is a deal breaker. You cannot secure your code. Not sure that has changed with the new device.

It has: you can encrypt your code, store a decryption key in OTP, and decrypt into RAM. Or if your code is small and unchanging enough, store it directly in OTP.

You can certainly do that, sure, but any Cortex-M MCU can do that, and plenty of others have hardware AES acceleration that would make the process much less asinine.

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.

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

#222

Alright, what's the max image resolution/framerate someone is going to pump out with the HSTX peripheral?

Unfortunately the starter example [1] hasn't made it into the public tree (yet ?) [1] https://github.com/raspberrypi/pico-examples/blob/master/dvi...

I wonder what other uses people will find for it. It's one-way data transfer, I wonder if it could be hooked up to a USB 2.0 or USB 3.0 peripheral, or an ethernet PHY, or something else.

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

#223
post #215
post #197

Earlier quoted context omitted.

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.

Hard to tell. If you ignore the FPU (I think it can be power gated off) the two cores should be roughly the same size and power consumption. Dual issue sounds like it would add a bunch of complexity, but ARM describe it as "limited" (and that's about all I can say, I couldn't find any documentation). The impression I get is that it's really simple. Something along the line of "if two 16 bit instructions are 32bit ali…

That is exactly what the "limited dual issue" is - two non-conflicting pre-decoded instructions (either 16b+16b or if a stall has occurred) can be sent down the execution pipe at the same time. I believe that must be a memory op and an ALU op.

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

#224

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…

> My hope is that they'll eventually provide a library of ready-made "soft peripherals" Perhaps they could be more ready-made, but there are loads of official PIO examples that are easy to get started with. https://github.com/raspberrypi/pico-examples/tree/master/pio

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 Bluetooth HCI implementation, and it needs sample code, and integration into Zephyr.

I speak as someone living in this industry: the only reason Nordic has such a firm grip on BLE product dev is because they're the only company providing a bullshit-free Bluetooth stack out of the box. Everything else about nRF sucks. If I could strap a CYW4343 to an RP2350 with some example code as easily as I can get a BT stack up and running on an nRF52840, I'd dump Nordic overnight.

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

#225
post #15

Earlier quoted context omitted.

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

I wonder how well it's been verified.

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.

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

#226

Earlier quoted context omitted.

cores are high bandwidth bus masters. Making a crossbar that supports 5 high bandwidth masters (4x core + dma) is likely harder, larger, and higher power than one that supports 3.

It's actually 10 masters (I+D for 4 cores + DMA read + DMA write) versus 6 masters. Or you could pre-arbitrate each pair of I and each pair of D ports. But even there the timing impact is unpalatable.

Which is even more impressive yet :)

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

#227

Earlier quoted context omitted.

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

> 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. I guess you’re not gonna be buying a Pi Pico 2, then. So why are you complaining about something you aren’t going to use?

I think you misread what I wrote: consumer electronic device

Dev boards or niche specialized hardware are about the only thing I've willingly bought with Micro USB in 4+ years. As much as I try to avoid it given my preference for USB-C, sometimes I don't have a good alternative available.

> So why are you complaining about something you aren’t going to use?

Because it looks like a great upgrade to my RP2040-Zero boards that I would like to buy but I really dislike the choice of connector? What is wrong with that?

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

#228

Earlier quoted context omitted.

* piqued

yes, piqued. English, so weird! ;-) (Although, interest peaking is possible!)

> English, so weird

Borrowed from just-as-weird French "piquer" - to stab or jab.

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

#229

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…

We're using 2040's in a variety of "real" products for an industrial application.

PIO is a huge selling point for me and I'm thrilled to see them leaning into it with this new version.

It's already as you hoped. Folks are developing PIO drivers for various peripherals (i.e., CAN and WS2812, etc.)

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

#230
post #135

Earlier quoted context omitted.

To clarify: You can connect a 5V power source by connecting it to the VSYS pin which leads into the on-board voltage regulator. But the µC itself runs on 3.3V and is not totally 5V-capable. You'd need level converters to interface with 5V.

You're right, after re-reading the Power section on the datasheet it seems connecting 5V to the VREG_VIN should suffice to power the digital domains, but if you want to use the ADC, you still need a external 3.3V source.

See section on physical pin gpio electrical tolerances.

The TL;DR is that 3.3v must be fed into IOVDD for 5.5v tolerance to work.

Post reply on HN