4 ms·

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

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

amelius 3y ago
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.
- ndiddy 3y ago
  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 hardware specific features (and therefore datasheets).
  - amelius 3y ago
    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.
- crote 3y ago
  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.
  - Bene592 3y ago
    Why? If you use only 1.1 features on a 2.0 platform it would work just like on 1.1 but faster. If you're on a USB1.1 platform and want to use a 2.0 feature you could just use a 2.0 platform without any changes to the existing code
mardifoufs 3y ago
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.
- crote 3y ago
  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 it's a lot more involved than just your regular bundle of C libraries you can use with your normal tooling.
  - sam_bristow 3y ago
    I believe newer ESP32 chips are based on the Risc-V microarchitecture.
    - crote 3y ago
      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.
      - MrBuddyCasino 3y ago
        The C6 is pretty much a superset of the features of the old Xtensa based models.
        tbyehl 3y ago
        All the Espressif RISC-V chips so far are missing the USG-OTG feature of the S2/S3 and RP2040.

amelius 3y ago

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.

ndiddy 3y ago
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 hardware specific features (and therefore datasheets).
- amelius 3y ago
  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.
crote 3y ago
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.
- Bene592 3y ago
  Why? If you use only 1.1 features on a 2.0 platform it would work just like on 1.1 but faster. If you're on a USB1.1 platform and want to use a 2.0 feature you could just use a 2.0 platform without any changes to the existing code

mardifoufs 3y ago

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.

crote 3y ago
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 it's a lot more involved than just your regular bundle of C libraries you can use with your normal tooling.
- sam_bristow 3y ago
  I believe newer ESP32 chips are based on the Risc-V microarchitecture.
  - crote 3y ago
    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.
    - MrBuddyCasino 3y ago
      The C6 is pretty much a superset of the features of the old Xtensa based models.
      - tbyehl 3y ago
        All the Espressif RISC-V chips so far are missing the USG-OTG feature of the S2/S3 and RP2040.