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

31–40 of 413 posts

Re: I like the RP2040

#31

Post by nickcw »

If you are an electronics hobbyist but don't want to make/design your own surface mount boards (like me) there are lots of very accessible RP2040 boards at very low prices.

I've used it in the Raspbery Pi Pico ($5) which comes on a nice board with lots of IO. There is a W version for a bit more with WiFi.

If you don't mind slightly less IO then you can order an RP-2040 Zero. I got 6 off AliExpress for about $12. These only have 23 IO pins but they have a reset button, USB-C and are tiny (1.5cm x 2.5cm).

The nice thing about all of these is that they use the standard Raspberry Pi dev tools, micropython, C++ just works with convenient USB loading of the firmware.

Re: I like the RP2040

#32

Post by the__alchemist »

Havoc wrote: post #18

How are people using this in practice? I’ve never worked with a BGA device. I’m guessing you need to design a board send it to say pcbway and then have the equipment to solder the bga in?

That's the desired approach, yes, but... hot take incoming!

I think BGAs are easier to "hand" solder than other footprints (QFP, QFN etc). You drop the item in place, place it on a hot plate and or heat gun, and start melting it. Of course, if you screw it up, you are screwed. (Reballing sounds not worth it for most cases). And, you can't visually inspect.

I think this is because, at least for me, most of the soldering faults I have are due to uneven application, or improper amount of solder. BGA solves this.

Re: I like the RP2040

#33

Post by dvdbloc »

MegaDeKay wrote: post #17

The PIO's really are the star of the RP2040 show, giving it a capability that competing chips like the ESP32 can't match. They are appearing all over the place in the console hacking space for this reason. Lower power consumption in steep modes for battery-backed applications would be a welcome addition in any V2 version though.

Where can I learn more about how they are used in console hacking? This sounds very interesting

Re: I like the RP2040

#34

Post by freedomben »

HyulianGrader wrote: post #21
sshine wrote: post #14

Earlier quoted context omitted.

To elaborate on the alternative: When the bootloader is not read-only, you can upload another bootloader. This is great in a different way because custom bootloaders allow for more flexibility. For example, you may want to keep two copies of your firmware on the chip: One that you're uploading, and one you can fall back to if the most recent one has problems. This protects you against failure during firmware upload o…

Nobody in their right mind is updating a bootloader in the field OTA, let alone one inaccessible on a mountain top.

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

Re: I like the RP2040

#35

Post by timenova »

seba_dos1 wrote: post #20
ndiddy wrote: post #9

Earlier quoted context omitted.

He's saying that the bootloader is in ROM so it's unbrickable, but the application code that the bootloader jumps into can be updated over USB. Most mid-range and higher microcontrollers have a similar feature, but they almost always have a custom protocol that requires a specialized flashing program rather than showing up as a mass storage device.

To be frank, I don't get its appeal at all. Most hobbyist uCs were already unbrickable, and using mass storage mode for flashing is rather cumbersome and clunky to automate as soon as you're past hello worlds.

Hence they made the Pico Debug Probe [0]. It makes it super easy to reflash firmware to the Pico in a quick iterative loop.

However, the appeal of mounting as a mass storage device is not for iterative development (as you mentioned). Invariably something breaks, and the easiest way to get back on track is to reflash their default blank firmware using the mass storage interface.

[0] https://www.raspberrypi.com/products/debug-probe/

Re: I like the RP2040

#36

Post by IshKebab »

TL;DR: he likes it because there's only one version available, whereas most microcontrollers have many more than one variant.

This seems like a very weak argument.

IMO (just based on the specs; haven't actually used it), the main reason to use this is for the PIO stuff. That's a very niche use case though.

Re: I like the RP2040

#37

Post by dgroshev »

axoltl wrote: post #25

"(This is the same microcontroller, just two bugfix revisions.)" It is exactly the same microcontroller! They're just two different packaging options. One is a 7" reel with 500 units the other is a 13" reel with 3400 units. (See "Ordering code" in the datasheet ( https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p... ))

Ooops, you're right! Fixed & attributed.

Re: I like the RP2040

#39

Post by dave78 »

HyulianGrader wrote: post #21
sshine wrote: post #14

Earlier quoted context omitted.

To elaborate on the alternative: When the bootloader is not read-only, you can upload another bootloader. This is great in a different way because custom bootloaders allow for more flexibility. For example, you may want to keep two copies of your firmware on the chip: One that you're uploading, and one you can fall back to if the most recent one has problems. This protects you against failure during firmware upload o…

Nobody in their right mind is updating a bootloader in the field OTA, let alone one inaccessible on a mountain top.

I used to work on a product where we did exactly that, and the devices literally ran on mountain tops. Our development and testing process was very rigorous and would be unrecognizable to most developers today, however. We certainly weren't shipping new code to those devices after every sprint.

Re: I like the RP2040

#40

Post by relaxing »

kj4ips wrote: post #27
hitekker wrote: post #10

Earlier quoted context omitted.

Can you explain how? Genuinely curious. The author only refers to "security theater" which seems to be when a product or system around a product makes people feel like they're safer, when actually it's not making anything more safer or more secure. https://en.wikipedia.org/wiki/Security_theater

I suspect this mostly refers to "Code Protect" or similar functions, that are designed to stop the user for extracting the firmware from a device in the field. Typically, when this is enabled, large parts of the debug interface stop working, and turning it off requires a "secure" erase, that clears the loaded firmware. While many CP implementations are flawed, or can be bypassed by a skilled attacker (power glitching…

Consider that in other fields of computer security we treat a device where attackers have physical access to be de facto compromised.
Post reply on HN