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

191–200 of 413 posts

Re: I like the RP2040

#191

Post by kragen »

dfox wrote: post #184
kragen wrote: post #121

Earlier quoted context omitted.

i admit to being intimidated by qfns still. any tips for hand-soldering them successfully?

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

Re: I like the RP2040

#192

Post by ChiefNotAClue »

crote wrote: post #153

I have mixed feelings about the RP2040. On the one hand, it's a great chip for hobbyists. It's cheap, it's easily available, it's easy to build a board around, and it offers plenty of stuff for your average application. On the other hand, it's definitely a bit lacking from a professional perspective. The peripherals are fine , but once you start looking into the details it's easy to run into limitations. That XIP int…

Well said. I'll add that, as a hobbyist, you'll eventually work on more involved projects and run into those exact limitations.

Re: I like the RP2040

#193

Post by throwup238 »

peteforde wrote: post #151
geerlingguy wrote: post #133

Earlier quoted context omitted.

It seems like Espressif are in the same situation as Pi w/r/t PlatformIO[1]. As an outsider, it sounds like PlatformIO was trying to extract a very large annual payment from RPi and Espressif, and that was after the initial support was added in, and some of the community started adopting it. It's a weird situation, but I think PlatformIO built up a dominant position by supporting all these platforms and accepting com…

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…

Can you provide a TLDR to what the state of things are? I was under the impression that ESPHome was built on top of PlatformIO so this sounds scary...

Re: I like the RP2040

#194

Post by gchadwick »

peteforde wrote: post #151
geerlingguy wrote: post #133

Earlier quoted context omitted.

It seems like Espressif are in the same situation as Pi w/r/t PlatformIO[1]. As an outsider, it sounds like PlatformIO was trying to extract a very large annual payment from RPi and Espressif, and that was after the initial support was added in, and some of the community started adopting it. It's a weird situation, but I think PlatformIO built up a dominant position by supporting all these platforms and accepting com…

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

  - They discuss this with RPi, ultimately RPi don't want to pay the asked contributions so that PlatformIO are happy maintaining support (this also seems reasonable)

  - End result is no RP2040 support in PlatformIO
Ultimately maintaining things isn't free. RPi have chosen the development environment(s) they wish to support and it hasn't included PlatformIO. What's weird or a bad look?

Re: I like the RP2040

#195

Post by dfox »

seba_dos1 wrote: post #150
moefh wrote: post #129

Earlier quoted context omitted.

Just to note: with the RP2040 you don't need additional hardware (debug probe) for quick iterative development, you can use picotool[1] (using -f allows you to flash and reboot without needing to get it to bootsel mode). [1] https://github.com/raspberrypi/picotool

...and it doesn't use mass storage at all, blocking access to it in a clunky way to prevent simultaneous usage. UMS seems like a nice idea when you first hear about it, but it doesn't really offer much once you look at it closer. The only proper argument for it is "no special software needed", but it a world where picotool is `apt install picotool` away that's not very advantageous anyway and only causes automount an…

The whole UF2 idea has to do with the educational background of RaspberryPi. The protocol was invented by Microsoft for use in some kind of similar educational board with the express purpose of not needing drivers, being reasonably crossplatform and crucially not needing any special permissions to access the device. The end result is that in some kind of educational setting you can use some kind of cloud/remote IDE on iPad, stick the RPi-Pico into the iPad and flash it, no blessing from Apple needed.

Re: I like the RP2040

#196

Post by 0x457 »

Aurornis wrote: post #136
krisoft wrote: post #125

Earlier quoted context omitted.

Maybe look at the ESP32 chip's datasheet? [1] This is the first sentence in it: "ESP32 is a single 2.4 GHz Wi-Fi-and-Bluetooth combo chip designed with the TSMC low-power 40 nm technology." That's the chip. Not the development board. 1: https://www.espressif.com/sites/default/files/documentation/...

The Espressif chips are available as cheap modules, and frequently used as such. People generally refer to the module, not the isolated chip. The modules are effectively like a chip that you solder to the board.

Modules are "just" chip + all necessary hardware to start + antenna connector/pcb antenna. Those modules don't add any functionality to the chip.

The main benefit of those modules is: it's already certified with FCC and others, so you don't have to re-certify your design for radio communication. Since RP2040 does not have a radio, this is unnecessary.

Re: I like the RP2040

#197

Post by seba_dos1 »

dfox wrote: post #195
seba_dos1 wrote: post #150

Earlier quoted context omitted.

...and it doesn't use mass storage at all, blocking access to it in a clunky way to prevent simultaneous usage. UMS seems like a nice idea when you first hear about it, but it doesn't really offer much once you look at it closer. The only proper argument for it is "no special software needed", but it a world where picotool is `apt install picotool` away that's not very advantageous anyway and only causes automount an…

The whole UF2 idea has to do with the educational background of RaspberryPi. The protocol was invented by Microsoft for use in some kind of similar educational board with the express purpose of not needing drivers, being reasonably crossplatform and crucially not needing any special permissions to access the device. The end result is that in some kind of educational setting you can use some kind of cloud/remote IDE o…

Oh. So it's just a result of locked-down walled gardens being so widespread that they influence the world around them. Depressing, but thank you for pointing it out anyway; on my phone I can just run picotool itself and it's easy to forget how dystopian it all got outside of the niche I'm in.

Re: I like the RP2040

#198

Post by dave78 »

dragontamer wrote: post #176
dave78 wrote: post #89

Earlier quoted context omitted.

I built a custom RP2040-based board by designing it KiCad and then sending it off to JLCPCB to be fabbed and they assembled the SMT components. I didn't do a direct comparison, but it was cheap - cheap enough that it's possible that getting the board pre-assembled from JLC was cheaper than buying the raw parts in low quantities from Digikey and assembling it myself (which, given my experience level, would be pushing…

> To do a decent PCB layout you'll need to use very small passives in order to get the placement right. 0402 (inches) is small but doable. They really start to feel like grains of sand at that point. But I personally stick with 0805 and 0603 when doing my own board layouts. I can't say I've ever felt space constrained. The placement of decoupling capacitors can be a few mil off, and in fact the "extra space" for plac…

> Especially for hobby projects, I don't think anyone is really in the business of counting up the savings of 0.01" in the hobby world. Like, how small are you actually aiming for, and is it really so bad that you can't add another 0.5" to your board?

It's not really about saving board space. Decoupling capacitors need to be placed "close" to the chip, and at higher clock frequencies this can be an issue. There's enough decoupling caps needed on a RP2040 that doing them in 0805 would require moving them quite a bit further away from the chip just to have room to place them all.

An ATmega (Arduino) at something like 8MHz is really forgiving and you can take a lot of liberties with the layout. The RP2040 runs much faster at 133MHz, so presumably the tolerances are much tighter. Admittedly, I didn't try a doing a design with 0805s for the RP2040 but I read enough from people more experienced than me that gave me the impression that compromising the layout with larger passives had a greater chance of things not working right.

Since assembly is so cheap at places like JLC these days, even in small quantities, it really wasn't worth the hassle. I've done many other boards by hand with 0805s and and agree they're pretty easy to deal with.

Re: I like the RP2040

#199

Post by seba_dos1 »

mdp2021 wrote: post #179
weinzierl wrote: post #171

I think the PIO state machines are pretty cool and relatively unique. I am also glad the Foundation resisted the temptation to market them as extra cores and sell the RP2040 as 10-core processor. When it comes to the Raspi Pico and similar devices[1], I think UF2 flashing is the best thing since sliced bread. This alone lowers the barrier for beginners significantly. Things I don't like: power consumption. But you ca…

> Things I don't like: power consumption I understand it could use ~0.08W, given it draws 3.3V at ~24mA... I am not a specialist, is that a lot? Ref.: https://learn.sparkfun.com/tutorials/rp2040-thing-plus-hooku...

Yes, it's a lot. It will empty a 1000mAh battery in about two days. In sleep states, you'll find it challenging to reach a single month on RP2040 while you can build things with other controllers that would last years on the same battery.

Re: I like the RP2040

#200

Post by dfox »

HyulianGrader wrote: post #62
freedomben wrote: post #34

Earlier quoted context omitted.

I don't disagree, but it leads to the question from the security guy: how do you fix CVEs in the bootloader after it's shipped (aka in the field)?

If you anticipate the need to update the bootloader, you would use a multistage bootloader approach where the first is never altered (as the bootloader should never be altered) and its main function is to select which updatable second stage bootloader to load from multiple options (multiple so that even if one is interrupted mid-update by the application, there is a valid fallback). My gut says if you're worried abou…

Particularly neat approach to both reducing the attack surface of the bootloader and improving the reliability of the actual OTA update process is to have only the bootloader flash the active application/second-stage flash partition. The idea is that the normal application code somehow acquires the new version, verifies it and writes it into separate flash partition and then reboots, bootloader sees that record and, does minimal check for correctness and flashes that to right location. That way the bootloader does not have to know anything about how to get the new firmware image and does not process any untrusted input.
Post reply on HN