Live data from Hacker News

RP2040 Boot Sequence

vanhunteradams.com

41–50 of 54 posts

Re: RP2040 Boot Sequence

#41
post #29

Earlier quoted context omitted.

> 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.

The problem is that processor agnostic platforms have to follow the lowest common denominator. An agnostic USB library which works on both USB2.0 and USB1.1 microcontrollers is going to be limited to USB1.1 features.

Re: RP2040 Boot Sequence

#42

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.

I believe a big reason for this is that the RP2040 is manufactured on a relatively modern process node. Mainstream MCU manufacturers use ancient nodes, which means using the same amount of SRAM is a lot more expensive area-wise.

It probably also helps that the RP2040 (and most Espressif chips too!) don't include any onboard flash. Adding a nontrivial amount of on-chip flash is quite expensive, so they just used that area budget for extra SRAM instead. If you want more than a few hundred K of flash you need to use an external chip anyways, so why bother with on-chip flash at all?

Re: RP2040 Boot Sequence

#43
post #40

Earlier quoted context omitted.

Isn't the toolchain for the esp almost fully open source (ESP-IDF)? The only part that aren't super open on the esp32 are the radio related firmware and blobs, but those are just not even there in the rp2040 anyways and not related to the toolchain itself.

If I recall correctly, a not-insignificant issue is (was?) that the ESP is based on the relatively obscure Xtensa microarchitecture - which is poorly supported (if at all) by the regular open-source toolchain. This means you have to use forks provided by Espressif, rather than just using the standard ones provided by your OS. It's still open-source so a lot better than having to use a proprietary compiler or IDE, but…

I believe newer ESP32 chips are based on the Risc-V microarchitecture.

Re: RP2040 Boot Sequence

#44
post #40

Earlier quoted context omitted.

If I recall correctly, a not-insignificant issue is (was?) that the ESP is based on the relatively obscure Xtensa microarchitecture - which is poorly supported (if at all) by the regular open-source toolchain. This means you have to use forks provided by Espressif, rather than just using the standard ones provided by your OS. It's still open-source so a lot better than having to use a proprietary compiler or IDE, but…

I believe newer ESP32 chips are based on the Risc-V microarchitecture.

Yup. The original ES32, ESP32-S2, and ESP32-S3 use Xtensa, but the ESP32-C2, -C3, -C6, and -H2 use RISC-V.

Unfortunately they don't all have the same feature set, so you'll often still see the Xtensa variants in the wild as they are are simply a better product overall.

Re: RP2040 Boot Sequence

#45
post #42

Earlier quoted context omitted.

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.

I believe a big reason for this is that the RP2040 is manufactured on a relatively modern process node. Mainstream MCU manufacturers use ancient nodes, which means using the same amount of SRAM is a lot more expensive area-wise. It probably also helps that the RP2040 (and most Espressif chips too!) don't include any onboard flash. Adding a nontrivial amount of on-chip flash is quite expensive, so they just used that…

AFAIK Espressif parts that do include flash just co-package it ;) From what I know, ESP8266 is TSMC 40 nm and TSMC offers embedded flash down to 28 nm (their website must be outdated).

Re: RP2040 Boot Sequence

#46
post #44

Earlier quoted context omitted.

I believe newer ESP32 chips are based on the Risc-V microarchitecture.

Yup. The original ES32, ESP32-S2, and ESP32-S3 use Xtensa, but the ESP32-C2, -C3, -C6, and -H2 use RISC-V. Unfortunately they don't all have the same feature set, so you'll often still see the Xtensa variants in the wild as they are are simply a better product overall.

The C6 is pretty much a superset of the features of the old Xtensa based models.

Re: RP2040 Boot Sequence

#47
post #8

Earlier quoted context omitted.

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…

The same thing has happened in the Linux kernel - there are multiple semi-duplicate SoC USB drivers for the Synopsys core.

Re: RP2040 Boot Sequence

#49
post #35
post #29

Earlier quoted context omitted.

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.

It depends on what you're looking for. If you're doing hobbyist stuff, using Arduino libraries (or even Linux single-board computers) will get you a processor agnostic solution. However, if you're dealing with production in volume, using 95% of the capabilities of a 45 cent chip is much better than using 50% of the capabilities of a 2 dollar chip, and there's nothing that'll get you there besides dealing with hardwar…

Volumes have to be very large to make up for R&D costs. For consumer stuff, maybe yes. In industry, it is quite normal to make <1000 pieces of some electronic instrument. In that case, optimizing on cents doesn't make sense.

Re: RP2040 Boot Sequence

#50
post #44

Earlier quoted context omitted.

Yup. The original ES32, ESP32-S2, and ESP32-S3 use Xtensa, but the ESP32-C2, -C3, -C6, and -H2 use RISC-V. Unfortunately they don't all have the same feature set, so you'll often still see the Xtensa variants in the wild as they are are simply a better product overall.

The C6 is pretty much a superset of the features of the old Xtensa based models.

All the Espressif RISC-V chips so far are missing the USG-OTG feature of the S2/S3 and RP2040.
Post reply on HN