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

RP2040 Boot Sequence

vanhunteradams.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: RP2040 Boot Sequence

#21

Post by tonyarkles »

duskwuff wrote: post #8
stevefolta wrote: post #5

Earlier quoted context omitted.

And where the document talks about SSI, it essentially means SPI (just with differential signalling etc.)? In other words, is it this SSI?: https://en.wikipedia.org/wiki/Synchronous_Serial_Interface >

It's a "synchronous serial interface" similar to SPI, but that isn't what the Wikipedia article you're linking to is about. It's the DW_apb_ssi peripheral from Synopsys ( https://www.synopsys.com/dw/ipdir.php?c=DW_apb_ssi ).

It's always a bit funny to me how much of the Synopsis IP ends up in different chips. As an example a decade+ ago I implemented a from-scratch USB Peripheral stack on an STM32 microcontroller, basically because the vendor SDK wasn't capable of doing what I needed or being readily modified to do what I needed. A couple of years ago I was debugging some firmware for a chip from a completely different vendor and noticed that the USB registers looked... familiar. Looked back at the original project and was somewhat surprised to discover that it was exactly the same registers in the same order just mapped to a different spot in memory.

Re: RP2040 Boot Sequence

#22

Post by joezydeco »

parl_match wrote: post #19
joezydeco wrote: post #13

Earlier quoted context omitted.

I don't totally agree with this perspective. Adafruit ships these in dev boards with a CircuitPython layer ready to go - you can have it up and doing something in 90 seconds if you're the Arduino type of hobbyist. You don't need to know a thing about the bootloader at all except maybe to hold down the bootstrap line with a pushbutton to reflash the system if it's bricked. The USB loader is incredibly slick and modern…

Missing the point. There's a huge amount of us who are between "complete and bare metal understanding of the soc" and "using python". STM32 nailed it, RP2040 is gaining a reputation for complexity.

I get the perspective. And I agree that RP2040 needs the equivalent of STMCube or even CubeMX. But they're not there yet. Are they banking on the community to provide that with the same amount of love that RPi got? I don't see that happening for multiple reasons.

Re: RP2040 Boot Sequence

#23

Post by daghamm »

vbezhenar wrote: post #10

This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the ot…

This is still a huge step up compared to the broadcom chips in raspberry 1-4.

On the big brothers, you have this odd CPU + GPU mish-mash and everything (including interrupt and mem layout) can look different depending on which one is currently running the show.

Re: RP2040 Boot Sequence

#24

Post by skybrian »

crmd wrote: post #20
Goz3rr wrote: post #11

Earlier quoted context omitted.

That doesn't seem unusual to me, given that to get to this page you either have to be searching for the specific terms already (and know what they are) or come from the homepage -> RP2040 (Raspberry Pi Pico) projects -> Custom serial bootloader for the RP2040 -> Preliminary reading RP2040 boot sequence

I came to that page directly from the front page of HN. I think it's reasonable to assume a significant portion of their traffic today directly to this page didn't already know what RP2040 is. Missed opportunity to educate readers.

It might be nice, but most web pages aren't written with Hacker News in mind. We share them anyway.

You should expect to sometimes encounter documents where you aren't the target audience and you have to look up terms.

Re: RP2040 Boot Sequence

#25

Post by freedom-fries »

vbezhenar wrote: post #10

This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the ot…

> May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked

My experience was opposite of yours. I found RP2040 refreshing compared to the complexity of dealing with proprietary toolchains that other devices required for me to start working with their chips. Nearly every part of RP2040 was documented in great detail and usable exclusively with the tools I could find in Arch Linux repo (when using Linux) and Homebrew (when using Mac). I could drop down to assembly or move up to C++, or even Rust or Python depending on whether I wanted to tool around or just get things done.

Even more impressive was that I was able to use debugger with another RP2040 Pico acting as SWD debug probe (Google Picoprobe) which again worked the same across Mac and Linux with the software I already had (gdb) and saved me from buying yet another piece of JTAG hardware with questionable software support.

Oh, and every single software with RP2040, including UF2 boot-rom, second stage bootloader and examples are on Github, which allowed me to go as deep as I wanted and more importantly, just get on with what I needed to do when I wanted things to just work.

I've worked with uC on and off, but never I have worked with a uC that just worked with just worked with tools I already had. I now work exclusively with RP2040, even when I find other chips much more capable (ESP32 in this case). RP2040 allows me to futz around as long as I want, as deep or shallow as I have time on hand, plus when I stop futzing around, it allows me to just flash new ROM over USB and get on do what I /need/ to do.

Oh.. and I just love the USB mass-storage mode – no more custom flasher tools, just `cp blah.uf2 /mnt/RP2040/` and off I go. I can smoke it, but I can't brick it! Plus, when I need quick iteration I can just use PicoProbe and do `code - flash - debug - code` almost as fast as I can hit keyboard buttons.

RP2040 is a game changer for me!

Re: RP2040 Boot Sequence

#26

Post by parl_match »

joezydeco wrote: post #22
parl_match wrote: post #19

Earlier quoted context omitted.

Missing the point. There's a huge amount of us who are between "complete and bare metal understanding of the soc" and "using python". STM32 nailed it, RP2040 is gaining a reputation for complexity.

I get the perspective. And I agree that RP2040 needs the equivalent of STMCube or even CubeMX. But they're not there yet. Are they banking on the community to provide that with the same amount of love that RPi got? I don't see that happening for multiple reasons.

I think their aggressive price point is at odds with their mission.

The mission used to be "unit of computing for education and makers at a super low pricepoint". This feels more like "create the lowest pricepoint possible".

Re: RP2040 Boot Sequence

#27

Post by duskwuff »

vha3 wrote: post #12

Some fun easter eggs in the bootrom. It seems like kilograham is a Doors fan: https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...

There's another really subtle easter egg hidden in bootrom_rt0.S:

https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...

And the explanation:

https://news.ycombinator.com/item?id=30970274

Re: RP2040 Boot Sequence

#28

Post by RicoElectrico »

vbezhenar wrote: post #10

This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the ot…

What really sets apart RP2040 is the amount of SRAM you get for the price. Other "outsiders" like Espressif are also generous.

Mainstream MCU manufacturers really skimp on it, even if you don't need Cortex-M4/7 to run a simple GUI you have to buy a whiz-bang part with huge pinout, very rich peripherals you won't need and a matching price tag for those.

Re: RP2040 Boot Sequence

#29

Post by amelius »

freedom-fries wrote: post #25
vbezhenar wrote: post #10

This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the ot…

> May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the other hand just worked My experience was opposite of yours. I found RP2040 refreshing compared to the complexity of dealing with proprietary toolchains that other devices required for me to start working with their chips. Nearly every part of RP2040 was documented in great detail and usable exclusively with the tools I could find i…

Personally, I want a processor agnostic platform.

I don't want to invest in one processor only to find out later that I needed USB2.0 instead of USB1.1, and then needing to read 500 pages of datasheets to move to a different platform.

Reading datasheets was nice at one point, but now it feels more like filling out tax forms.

Re: RP2040 Boot Sequence

#30

Post by teaearlgraycold »

jcalvinowens wrote: post #17
vbezhenar wrote: post #10

This complexity forced me to abandon it for learning and switch to STM32. I was able to write blinky with few dozens of assembly instructions for STM32. I spent like month reading about SPI, QSPI, flash chips and still was not able to understand how to proceed with RP2040 other than copy&paste their "bootloader" as an opaque blob. May be I'm weird, but for me RP2040 was terrible chip for learning ARM. STM32 on the ot…

I think it depends on what you want. Having worked quite a bit with both, I think the average beginner would find the rp2040's cmake based SDK more accessible than stm32cube, which I dislike immensely. The CircuitPython support is also really interesting for somebody who isn't a programmer but wants to experiment. But if you're already an experienced programmer and want to roll your own stuff, I absolutely agree stm3…

I’m a programmer but appreciate CircuitPython. I used the KB2040 to build two bespoke mini keyboards. It took just a few dozen lines of Python. Couldn’t be happier with it.
Post reply on HN