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

321–330 of 356 posts

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

#321

Post by doe_eyes »

limpbizkitfan wrote: post #64
doe_eyes wrote: post #22

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…

ST is a zillion dollar company that should be hiring the talent capable of delivering product that match the features in their sales pamphlets. Integration is tricky but a company with STs deep pockets should be able to root cause or at least help troubleshoot an issue, not ask for a fix like some nepotism hire.

I'm not an ST fanboy and they're not a vendor I use, but they are very popular in the 32-bit Cortex-M space, so they're clearly doing something right. Meanwhile, companies like Microchip that put effort into accessible documentation and tooling are getting table scraps.

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

#322

Post by [deleted] »

vardump wrote: post #257
bschwindHN wrote: post #254

Earlier quoted context omitted.

Right? Bidirectional capability at those speeds would be incredible for the price of this chip. Either way, still looking forward to see what people cook up with it, and hopefully I'll find a use for it as well. Maybe combine it with some cheap 1920x1080 portable monitors to have some beautiful dashboards around the house or something...

1920x1080 30 Hz DVI would require running RP2350 at least at 311 MHz ((1920 * 1080 * 30Hz * 10) / 2). Probably a bit more to account for minimal horizontal and vertical blanking etc. Multiplier 10 comes from 8b10b encoding. To fit in 520 kB of RAM, the framebuffer would need to be just 1 bpp, 2 colors (1920 * 1080 * 1bpp = 259200 bytes). From PSRAM I guess you could achieve 4 bpp, 16 colors. 24-bit RGB full color wou…

[deleted]

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

#323

Post by mastax »

It's a bit surprising that they put so much effort into security for the second microcontroller from a young consumer-oriented* company. My first instinct was to distrust it's security, simply due to lack of experience. However, the "experienced" vendors' secure micros have lots of known security bugs and, more crucially, a demonstrated desire to sweep them under the rug. Two security architecture audits, a $10k bug bounty, and designing a board for glitching as the DEF CON badge shows a pretty big commitment to security. I'm curious about how the Redundancy Coprocessor works. I still wouldn't be surprised if someone breaks it, at least partially.

* By perception at least. They have been prioritizing industrial users from a revenue and supply standpoint, it seems.

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

#324

Post by rscott2049 »

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…

Almost correct - the third implementation does generate the clock, but it isn't necessary to drive the clock directly from the system clock, as there are m/n clock dividers available. I use a 300 MHz system clock, and divide down to 50 MHz which works well. (I've also addressed a few other shortcomings of this library, but am not done yet...) Haven't looked at the 10 MHz half duplex mode, though.

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

#325

Post by digging »

jhugo wrote: post #260
bee_rider wrote: post #249

Earlier quoted context omitted.

It is kind of funny that both of the incorrect versions, peaked or peeked, sort of make more sense just based on the definitions of the individual words. “Peaked my interest” in particular could be interpreted as “reached the top of my interest.” Way better than stabbing my interest, in a French fashion or otherwise.

Right, but that meaning isn’t quite right. To pique your interest is to arouse it, leaving open the possibility that you become even more interested, a possibility which peaking of your interest does not leave open.

However, in the case where someone means "This interested me so much that I stopped what I was doing and looked up more information," peaked is almost more correct, depending on how one defines "interest" in this context (eg. "capacity for interest"? probably no; "current attention"? probably yes).

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

#326

Post by rscott2049 »

rowanG077 wrote: post #320
rscott2049 wrote: post #196

Earlier quoted context omitted.

I'm assuming you've looked at the pico-rmii-ethernet library? If so, I feel your pain - I've been fixing issues, and am about halfway done. (This is for the DECstation2040 project, available on github). Look for a release in late aug/early sep. (Maybe with actual lance code? Dmitry??) The RP2350 will make RMII slightly easier - the endless DMA allows elimination of the DMA reload channel(s).

I looked at it and dismissed it as too hacky for production. I don't remember the real reason why. I would have to look through my notes. The main question is whether the RP2350 will change that. As in it actually possible to do bug free without weird hacks.

Agreed. I re-wrote the Rx PIO routine to do a proper interrupt at EOF, and added a DMA driven ring buffer, which eliminated a lot of the hackiness...

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

#327

Post by ryukoposting »

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

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

Oh, I'm sure it's great for industrial, as long as you can live with the hardware security issues. In college, my first serious task as an intern was to take a Cortex-M0+ and make it pretend to be an 8051 MCU that was being obsoleted. Unsurprisingly, this was for an industrial automation firm.

I mimicked the 16-bit data bus using hand-written assembly to make sure the timings were as close as possible to the real chip. It was a pain in the ass. It would have been amazing to have a chip that was designed specifically to mimic peripherals like that.

It's great that there's a community growing around the RPi microcontrollers! That's a really good sign for the long-term health of the ecosystem they're trying to build.

What I'm looking for is a comprehensive library of PIO drivers that are maintained by RPi themselves. There would be a lot of benefits to that as a firmware developer: I would know the drivers have gone through some kind of QA. If I'm having issues, I could shoot a message to my vendor/RPi and they'll be able to provide support. If I find a bug, I could file that bug and know that someone is going to receive it and fix it.

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

#328

Post by rvense »

dmitrygr wrote: post #318
rvense wrote: post #281

Earlier quoted context omitted.

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

Did you? It doesnt do qspi mode

Of course I did. If you also did, you would know that they do in fact have 64 megabyte PSRAMs as I stated. So a helpful comment would have been "they're not compatible, though". Your reply as it stands just makes it sound like you maybe assumed that I don't know the difference between megabits and megabytes.

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

#329

Post by ryukoposting »

TickleSteve wrote: post #235
ryukoposting wrote: post #221

Earlier quoted context omitted.

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.

520K RAM is huge for most typical embedded apps. Most micros are typically around the 48K->128K SRAM.

Define "typical."

To my recollection, every piece of Cortex-M firmware I've worked on professionally in the last 5 years has had at least 300K in .text on debug builds, with some going as high as 800K. I wouldn't call anything I've worked on in that time "atypical." Note that these numbers don't include the bootloader - its size isn't relevant here because we're ramloading.

If you're ram-loading encrypted firmware, the code and data have to share RAM. If your firmware is 250K, that leaves you with 270K left. That seems pretty good, but remember that the 2040 and 2350 are dual-core chips. So there's probably a second image you're loading into RAM too. Let's be generous and imagine that the second core is running something relatively small - perhaps a state machine for a timing-sensitive wireless protocol. Maybe that's another 20K of code, and 60K in data. These aren't numbers I pulled out out of my ass, by the way - they're the actual .text and .data regions used by the off-the-shelf Bluetooth firmware that runs on the secondary core of an nRF5340.

So now you're down to 190K in RAM available for your 250K application. I'd call that "normal," not huge at all. And again, this assumes that whatever you're running is smaller than anything I've worked on in years.

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

#330

Post by ryukoposting »

dmitrygr wrote: post #239
ryukoposting wrote: post #221

Earlier quoted context omitted.

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.

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

I'm smoking multiprotocol wireless systems for industrial, medical, and military applications. To my recollection, the very smallest of those was around 280K in .text, and 180K in .data. Others have been 2-3x larger in both areas.

I would sure hope a decstation3100 emulator is small. After all, it's worthless unless you actually run something within the emulator, and that will inevitably be much larger than the emulator itself. I wouldn't know, though. Believe it or not, nobody pays me to emulate computers from 1978.

Post reply on HN