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

11–20 of 413 posts

Re: I like the RP2040

#11

Post by perbu »

cockings wrote: post #4

> The RP2040 is impossible to brick. It comes with a read-only bootloader that can either mount as a USB mass storage device (firmware updates can just be copypasted to the "storage device"), or use its own simple USB protocol. Can anyone explain what this means? How is it both read-only and updateable? If the latter, how is it unbrickable?

The bootloader is read-only, the firmware it boots is updateable.

The bootloader allows you to update the device with new firmware. MCU are different than computers. And since you can't overwrite the bootloader, you can't brick the MCU. You can always just reset it.

fwiw; I've never bricked an MCU buy flashing something weird onto it. The hobbyist MCUs sold are typically quite easy to re-flash with new firmware.

Re: I like the RP2040

#12

Post by HyulianGrader »

nit: There are 6 different espressif microcontrollers in that table, not "dozens".

Espressif also went many years with only the ESP8266, then many years more after introducing the ESP32 before this recent binge of releasing a new series every time they blink. ESP-IDF is really suffering for it, so I hope Raspberry avoid this fate or at least find a better way to support them all.

Re: I like the RP2040

#13

Post by [deleted] »

cockings wrote: post #4

> The RP2040 is impossible to brick. It comes with a read-only bootloader that can either mount as a USB mass storage device (firmware updates can just be copypasted to the "storage device"), or use its own simple USB protocol. Can anyone explain what this means? How is it both read-only and updateable? If the latter, how is it unbrickable?

[deleted]

Re: I like the RP2040

#14

Post by sshine »

orlp wrote: post #8
cockings wrote: post #4

> The RP2040 is impossible to brick. It comes with a read-only bootloader that can either mount as a USB mass storage device (firmware updates can just be copypasted to the "storage device"), or use its own simple USB protocol. Can anyone explain what this means? How is it both read-only and updateable? If the latter, how is it unbrickable?

The bootloader is read-only. What the bootloader loads isn't. If the thing you're trying to boot into is faulty, it doesn't matter because you can just replace the thing the bootloader is trying to load. If the bootloader itself was faulty, the device would be bricked.

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 or post-deployment failure, because you only overwrite one of the two. So if the device switches off while flashing it, and you boot back up, a custom bootloader can just default to the older copy.

But... what if you update the bootloader and it fails?

Then you can't use the bootloader to upload new firmware. Bricked.

To unbrick a bootloader you need to overwrite the bootloader using alternative methods that don't involve the bootloader, which usually involves attaching wires to the print. This is highly inconvenient in a production setting: Maybe your hardware is encased, embedded in a bigger thing, or located on a pole on a mountain top in a different country.

So a read-only bootloader is a safe choice, and you can make other workarounds wrt. flexibility.

Re: I like the RP2040

#15

Post by antirez »

I switched from ESP32 to the RP2040 because it's a much more reliable and documented device. My only concern right now with the RP2040 is that there are many ESP32 models with SPIRAM but it's not so simple to find a SPIRAM equipped RP2040 board. To be honest, given that the C development environment of the RP2040 is so good, you can make good use of the memory, but when one wants to develop a large MicroPython project, the SPIRAM is really a great asset. Other than that, everything about the RP2040 is just great.

Re: I like the RP2040

#17

Post by MegaDeKay »

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.

Re: I like the RP2040

#18

Post by Havoc »

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?

Re: I like the RP2040

#19

Post by ndiddy »

cide1 wrote: post #3

The lack of security features really limits where this can be used in commercial designs.

In general, read-out protection provides a very limited level of protection that I wouldn't rely on to stop cloning. There's quite a few firms that will extract the firmware from protected microcontrollers for a couple thousand dollars (i.e. https://russiansemiresearch.com/ ) which is a drop in the bucket considering the potential profit from industrialized cloning. Lots of microcontroller series also have exploits that can allow hobbyists with very little funding to bypass read-out protection (here's one for the STM32F0 series for example: https://github.com/racerxdl/stm32f0-pico-dump ).

Re: I like the RP2040

#20

Post by seba_dos1 »

ndiddy wrote: post #9
cockings wrote: post #4

> The RP2040 is impossible to brick. It comes with a read-only bootloader that can either mount as a USB mass storage device (firmware updates can just be copypasted to the "storage device"), or use its own simple USB protocol. Can anyone explain what this means? How is it both read-only and updateable? If the latter, how is it unbrickable?

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.
Post reply on HN