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

I like the RP2040

dgroshev.com

Post reply on HN
Print view View original

201–210 of 413 posts

Re: I like the RP2040

#201

Post by diydsp »

riskable wrote: post #131
jcalvinowens wrote: post #44

The lack of built-in flash kills it for me. STM32 M3s with comparable throughput are cheaper and don't require an external flash chip (example: STM32F103C8T6 for $1.20 from jlc). I love the generic PIO though, I really hope other manufacturers pick up on that.

I used to have the same beliefs but the flexibility of being able to use just about any pin for any purpose really sold me on the RP2040. When I decide to add a new feature to my boards I don't have to spend an hour examining the minutiae of the data sheet to see if I can use a given pin for SPI (oops: no, I can't because I enabled alternate function 3...). It saves a TON of track routing time and simplifies boards c…

Haven't used the RP2040 yet, but having worked with SPIRAM and SPIflash on the ESP32, and also on many different STM32s, I can say this: if your project reaches a certain size, lots of tasks or multiple chunks of discontiguous memory, then the caching of the SPI memories becomes a traffic jam and things that should be really fast get really slow. And you start running into lots of weird error messages from inside the esp-idf drivers that you can't do much about. It will drive you crazy. You have to start strategically partitioning your memory, create/delete tasks dynamically, adjust lots of params in menuconfig, etc etc.

Not a problem for most hobbyist projects, but when you start to push the limits the ESP32 feels like a chipboard apartment building compared to STM32's concrete and rebar. Hopefully the RP2040 doesn't suffer the same problems.

Re: I like the RP2040

#202

Post by dfox »

kragen wrote: post #191
dfox wrote: post #184

Earlier quoted context omitted.

Kind of cheating trick for the QFN substrate pad is to put a grid of somewhat higher diameter vias in there and solder the pad from the other side of the board through these vias. Another approach is to just ignore the substrate pad altogether (in many devices it should not be connected to anything anyway and has no real thermal management purpose).

i wonder if you could use the vias trick for the regular pins too, and bga balls

I have in fact seen the via trick used for 50mil pitch BGAs, but cannot remember where. I even vaguely recollect some board where that was used for CGA, which seems like really ridiculous idea (you don't use CGA packages and then invent some weird kludge pseudo-process).

Re: I like the RP2040

#203

Post by sangnoir »

gchadwick wrote: post #194
peteforde wrote: post #151

Earlier quoted context omitted.

Thanks for all of your rational contributions to those many threads, Jeff. It is an extremely weird situation, and a deeply bad look. If I was pressed for an opinion, I would say that I wish Eben had taken the high road and gone all in on supporting PIO despite the tangy mystery aftertaste for the simple reason that it would be a net-positive for developers. The way things stand, migrating away from the Arduino IDE t…

> It is an extremely weird situation, and a deeply bad look I never followed all the ins and outs but from having a quick look through the comments on https://github.com/platformio/platform-raspberrypi/pull/36 the following happened: - Developer independent of RPi opens PR to add RP2040 support to PlatformIO - PlatformIO don't want to merge it, expecting some financial contribution to help maintain the support (seems…

> Ultimately maintaining things isn't free.

This is a hypocritical stance for any project that accepts free contributions from the public. Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)?

Re: I like the RP2040

#204

Post by zbrozek »

peteforde wrote: post #120

I also like the RP2040, but I'd like to explain why I migrated away from it for my current project. First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling. Second, the top of the line ESP32-S3 comes in a module format that can be dropped on a PCB with basically nothing but a few decoupling capacitors. The RP2040 requires careful plac…

I really don't think there's any significant value to be gained by turning this into a module. Everyone wants a slightly different form factor and the thing is so easy to design around that a module isn't meaningfully achieving anything.

Touch is a niche single tasker. I'm glad they didn't include it. Using another ic for that makes sense, and folks being lazy and sticking to an EOL part to provide that functionality isn't RPi's problem. Or do it in software.

I'm with the OP on this one, I really think the foundation nailed the product definition.

Re: I like the RP2040

#205

Post by KaiserPro »

sangnoir wrote: post #203
gchadwick wrote: post #194

Earlier quoted context omitted.

> It is an extremely weird situation, and a deeply bad look I never followed all the ins and outs but from having a quick look through the comments on https://github.com/platformio/platform-raspberrypi/pull/36 the following happened: - Developer independent of RPi opens PR to add RP2040 support to PlatformIO - PlatformIO don't want to merge it, expecting some financial contribution to help maintain the support (seems…

> Ultimately maintaining things isn't free. This is a hypocritical stance for any project that accepts free contributions from the public. Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)?

> Besides rent-seeking, what reason could justify preventing the community from maintaining features/microcontrollers that the organization is unwilling to (due to costs)?

Platformio I suspect.

Re: I like the RP2040

#206

Post by kragen »

dfox wrote: post #202
kragen wrote: post #191

Earlier quoted context omitted.

i wonder if you could use the vias trick for the regular pins too, and bga balls

I have in fact seen the via trick used for 50mil pitch BGAs, but cannot remember where. I even vaguely recollect some board where that was used for CGA, which seems like really ridiculous idea (you don't use CGA packages and then invent some weird kludge pseudo-process).

wow, i'd never even heard of cgas

Re: I like the RP2040

#207

Post by KaiserPro »

dragontamer wrote: post #190
morio wrote: post #188

Earlier quoted context omitted.

I find hand soldering QFN is faster, easier and more reliable than (T)QFP once you got enough practice. If you need to rework the QFN part the key is to FLOOD the footprint with good solder flux from a syringe. Do not use one of those flux pens, those do not dispense enough flux.

> If you need to rework the QFN part the key is to FLOOD the footprint with good solder flux from a syringe. I've never tried this but this makes a lot of sense in my mind's eye. I'll try this next time I have such an issue. ------- TQFP seems nice because I can sloppily shove tons of solder down, and then just wick up all the excess solder with solder wick. In fact, I purposefully over-solder all the TQFP joints for…

Yeah I've been seeing a bunch of chip swaps that use this method, its wild how forgiving it appears to be.

Re: I like the RP2040

#208

Post by croes »

HyulianGrader wrote: post #83
flohoff wrote: post #80

The issue is that its a comparison about apples to peaches. The RPI2040 is JUST the chip whereas the ESP32 come with tons of peripherals for your liking. From Wifi/Bluetooth Antenna, LI Battery Controller, Ethernet whatever, Display or Camera Connector - You choose. And then we have a multitude of even CPU choices and when running on a coin cell it makes a difference powering a second, unnecessary core or even wifi.…

It's safe to assume he's talking about the chip in both cases. You can connect either of them to a battery charger, camera, or nuclear reactor but all of those 'peripherals' are completely irrelevant to this comparison.

But if it's about the chip then just grab any ESP32.

Re: I like the RP2040

#209

Post by aswanson »

zbrozek wrote: post #204
peteforde wrote: post #120

I also like the RP2040, but I'd like to explain why I migrated away from it for my current project. First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling. Second, the top of the line ESP32-S3 comes in a module format that can be dropped on a PCB with basically nothing but a few decoupling capacitors. The RP2040 requires careful plac…

I really don't think there's any significant value to be gained by turning this into a module. Everyone wants a slightly different form factor and the thing is so easy to design around that a module isn't meaningfully achieving anything. Touch is a niche single tasker. I'm glad they didn't include it. Using another ic for that makes sense, and folks being lazy and sticking to an EOL part to provide that functionality…

The pico board is the de facto module for me. Very cheap and breaks out every useful signal.

Re: I like the RP2040

#210

Post by aswanson »

peteforde wrote: post #120

I also like the RP2040, but I'd like to explain why I migrated away from it for my current project. First, the drama with PlatformIO really rubbed me the wrong way. I'm taking the side of the developers who are hurt by confusion in tooling. Second, the top of the line ESP32-S3 comes in a module format that can be dropped on a PCB with basically nothing but a few decoupling capacitors. The RP2040 requires careful plac…

Pico board is the module. I agree that placing the xtal etc is too much.
Post reply on HN