5 ms·

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 ES

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.

dgroshev 2y ago
I ended up cutting a section on Rust support from the post, but if you're open to Rust (iirc you were sceptical at some point?), async Rust is really pleasant to use in embedded. Dario Nieuwenhuis, one of the main people behind Embassy, gave a great overview talk at RustNL: https://www.youtube.com/watch?v=H7NtzyP9q8E https://www.youtube.com/watch?v=H7NtzyP9q8E
- the__alchemist 2y ago
  I disagree. Rust on embedded is fantastic (I do STM32 programming on rust all the time, and have used the RISC-V ESP chips and nRF-52 as well), but Async Rust on embedded suffers from the same problems of contagion and coloring that non-embedded async rust has.
  - fleventynine 2y ago
    Everything had tradeoffs, but the composability of the state machines built by the compiler's async support allows you to easily build multi-tasking bare-metal systems with thousands of "tasks" and no RTOS (or SRAM-wasting threads). I highly recommend playing with Embassy for a week before discounting this approach for embedded software. If you care about RAM consumption, you need to share the stack between tasks, forcing you to write event-driven code. Rust async makes this easy, and a bit of function coloring is no big deal compared to converting blocking code into event-driven code the traditional way...
    - the__alchemist 2y ago
      I have - it does not avoid the structural and compatibility problems of Async in other contexts.
      - fleventynine 2y ago
        Can you go into more details? Most of the criticism I've read tends to be more abstract ("I don't like how ALL my blocking-style calls need to be async"), and doesn't propose an alternative mechanism to async that can provide a similar coding style in the same tight RAM footprint.
        the__alchemist 2y ago
        I think you'll find details regarding any discussion of async in rust and other languages - I don't mean to casually dismiss your question, but my objections are not unique. The alternative mechanism is to use interrupts, DMA, multiple cores, distributed devices (eg a CAN network) a state machine, an RTOS, or, it sounds like in context of this thread, PIOs! You get the point. Do these provide a similar coding style? No, and that's the point. The coding style is the objection. I find the "how else would you do it" style questions that come up frequently re Async rust (embedded or not) amusing. It's as if there is a new method of accomplishing a task, and asking a world that has been accomplishing this task for decades how it's possible to accomplish the task without the new thing!
        fleventynine 2y ago
        As I see it, if you need everything to run on a single cpu core, the alternatives are to either implement threads (wasting memory on redundant stacks) or to write the event-driven state machines manually. Whether the state machine is pumped by interrupts or not doesn't change anything IMHO. Because of RAM constraints, all the bare-metal projects I've worked on have used manually-written state machines, and I'm comfortable enough with this approach. But sometimes these state machines can be hard to understand when the control flow is complicated, and I am seriously considering adding some compiler-generated state machines that will fit nicely into my existing model.
- antirez 2y ago
  Thanks, I prefer using C :) But happy that there are options out there.
- galangalalgol 2y ago
  A bit late to the thread but it is still on the front page. I've got some esp32 risc-v eval boards I've meant to mess with, but I'm nervous about their availability due to political instability and also while the rust support seems pretty great, I don't really know what is going on down in the hal and whatnot. Is rust on the 2040 well supported? Is it too well supported? Is it well enough documented that I could start with no software of any sort and load a pure rust blob and have it do some uart or something? My motivation is to recapture the feel of the c64 or Amiga1k wherebthe only mmu is optional page protection at most and you know what everything in memory is doing.
  - dgroshev 2y ago
    If I get your question right, you still need some host software (like a rust compiler)! It's not exactly micropython experience. The bare minimum would be one of the examples [1] compiled with a Rust compiler and then transformed into a .uf2 file with elf2uf2 [2]. You can then just drag and drop the .uf2 file into the "mass storage device" presented by the bootloader. To get the bootloader to mount, you press a button on a Raspberry Pico (or short two outputs if you're using bare RP2040) while plugging it in. You'll probably want a debug probe [3] driven by probe-rs [4] at some point, it's just much more convenient to flash and debug with it. [1]: https://github.com/embassy-rs/embassy/tree/main/examples/rp/src/bin https://github.com/embassy-rs/embassy/tree/main/examples/rp/... [2]: https://github.com/JoNil/elf2uf2-rs https://github.com/JoNil/elf2uf2-rs [3]: https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html https://www.raspberrypi.com/documentation/microcontrollers/d... [4]: https://probe.rs/ https://probe.rs/
selfmodruntime 2y ago
I heavily disagree. I‘ve been working with the Espressif ecosystem for a couple of months now and it‘s the best documented microcontroller platform out there.
- throwaway15968 2y ago
  Completely agreed. ESP-IDF is incredible and the dev experience is miles beyond STM32 (my opinion).
  - dailykoder 2y ago
    > STM32 (my opinion). STM32 is horrible, if you don't want to use the HAL.. Everything I used (Atmel, ESP32, rp2040) was better than that - Tho I heard NXP is bad.
    - 15155 2y ago
      STM32 is great if you choose to use the community-maintained Embassy HAL for these chips. Zero vendor code, async/await - it's a dream. The same code will more or less run abstractly on an RP2040, as well (for common peripherals/traits.)
- 15155 2y ago
  Meanwhile NXP is producing 3000+ page PDFs with behavioral examples.
- casept 2y ago
  Only if you use their SDK. Quite a few parts of the chip lack actual register-level documentation, not so on the 2040.
mardifoufs 2y ago
Did you use esp-idf? Or the Arduino libs?
- antirez 2y ago
  ESP-IDF, Arduino IDE is untouchable for serious stuff IMHO.
  - mardifoufs 2y ago
    Yeah agreed, that's why I was wondering! But esp-idf has been great recently. It used to be very patchy and undocumented but I prefer it over everything else now. I'll check the rp2040 docs and try out the dev board I've had for a while, because now I'm wondering if I'm missing something haha
  - orphea 2y ago
    > Arduino IDE is untouchable for serious stuff Yes, but AFAIK you don't have to use Arduino IDE for Arduino stuff? e.g. there is PlatformIO.
  - 15155 2y ago
    Embassy is next-level in terms of developer experience. If you must use C, ESP-IDF/Arduino aren't terrible. But you still don't really have a package manager or means to abstract anything, especially across devices. The cohesion present in Embassy between the HALs, probe-rs, etc. is really amazing. With Embassy for example, I can run the same async/interrupt-driven I2C driver code on any number of different MCUs across various manufacturers. This holds true for many, many different types of peripherals in the ecosystem. For the unique peripherals, implementation style and interface are extremely consistent and high-quality.
- reassembled 2y ago
  You can use Arduino libs via ESP-IDF. The IDF environment comes with a lot of libraries on its own but it is a development environment first and foremost. The design of IDF is very open and easy to understand throughout the stack. It is very easy to integrate external libraries via CMake as well.
15155 2y ago
The RP2040 only has one QSPI port. JLC will assemble a RP2040 board for you for <$3/pc at quantities of 5.
- shadowpho 2y ago
  I think it’ll be more expensive. When I was looking at jlc it seemed to be $100/10 was starting point if you want assembly
  - MartijnBraam 2y ago
    It all depends on how you select the parts. I've ordered a set of 5 boards for $12 total including shipping and assembly.
  - 15155 2y ago
    You need to carefully select JLC basic parts. QSPI, XOSC, etc. can all be had without paying fees. I've ordered 5+ boards with RP2040s that have come out to "cheaper than Pico" prices.

dgroshev 2y ago

I ended up cutting a section on Rust support from the post, but if you're open to Rust (iirc you were sceptical at some point?), async Rust is really pleasant to use in embedded. Dario Nieuwenhuis, one of the main people behind Embassy, gave a great overview talk at RustNL: https://www.youtube.com/watch?v=H7NtzyP9q8E https://www.youtube.com/watch?v=H7NtzyP9q8E

the__alchemist 2y ago
I disagree. Rust on embedded is fantastic (I do STM32 programming on rust all the time, and have used the RISC-V ESP chips and nRF-52 as well), but Async Rust on embedded suffers from the same problems of contagion and coloring that non-embedded async rust has.
- fleventynine 2y ago
  Everything had tradeoffs, but the composability of the state machines built by the compiler's async support allows you to easily build multi-tasking bare-metal systems with thousands of "tasks" and no RTOS (or SRAM-wasting threads). I highly recommend playing with Embassy for a week before discounting this approach for embedded software. If you care about RAM consumption, you need to share the stack between tasks, forcing you to write event-driven code. Rust async makes this easy, and a bit of function coloring is no big deal compared to converting blocking code into event-driven code the traditional way...
  - the__alchemist 2y ago
    I have - it does not avoid the structural and compatibility problems of Async in other contexts.
    - fleventynine 2y ago
      Can you go into more details? Most of the criticism I've read tends to be more abstract ("I don't like how ALL my blocking-style calls need to be async"), and doesn't propose an alternative mechanism to async that can provide a similar coding style in the same tight RAM footprint.
      - the__alchemist 2y ago
        I think you'll find details regarding any discussion of async in rust and other languages - I don't mean to casually dismiss your question, but my objections are not unique. The alternative mechanism is to use interrupts, DMA, multiple cores, distributed devices (eg a CAN network) a state machine, an RTOS, or, it sounds like in context of this thread, PIOs! You get the point. Do these provide a similar coding style? No, and that's the point. The coding style is the objection. I find the "how else would you do it" style questions that come up frequently re Async rust (embedded or not) amusing. It's as if there is a new method of accomplishing a task, and asking a world that has been accomplishing this task for decades how it's possible to accomplish the task without the new thing!
        fleventynine 2y ago
        As I see it, if you need everything to run on a single cpu core, the alternatives are to either implement threads (wasting memory on redundant stacks) or to write the event-driven state machines manually. Whether the state machine is pumped by interrupts or not doesn't change anything IMHO. Because of RAM constraints, all the bare-metal projects I've worked on have used manually-written state machines, and I'm comfortable enough with this approach. But sometimes these state machines can be hard to understand when the control flow is complicated, and I am seriously considering adding some compiler-generated state machines that will fit nicely into my existing model.
antirez 2y ago
Thanks, I prefer using C :) But happy that there are options out there.
galangalalgol 2y ago
A bit late to the thread but it is still on the front page. I've got some esp32 risc-v eval boards I've meant to mess with, but I'm nervous about their availability due to political instability and also while the rust support seems pretty great, I don't really know what is going on down in the hal and whatnot. Is rust on the 2040 well supported? Is it too well supported? Is it well enough documented that I could start with no software of any sort and load a pure rust blob and have it do some uart or something? My motivation is to recapture the feel of the c64 or Amiga1k wherebthe only mmu is optional page protection at most and you know what everything in memory is doing.
- dgroshev 2y ago
  If I get your question right, you still need some host software (like a rust compiler)! It's not exactly micropython experience. The bare minimum would be one of the examples [1] compiled with a Rust compiler and then transformed into a .uf2 file with elf2uf2 [2]. You can then just drag and drop the .uf2 file into the "mass storage device" presented by the bootloader. To get the bootloader to mount, you press a button on a Raspberry Pico (or short two outputs if you're using bare RP2040) while plugging it in. You'll probably want a debug probe [3] driven by probe-rs [4] at some point, it's just much more convenient to flash and debug with it. [1]: https://github.com/embassy-rs/embassy/tree/main/examples/rp/src/bin https://github.com/embassy-rs/embassy/tree/main/examples/rp/... [2]: https://github.com/JoNil/elf2uf2-rs https://github.com/JoNil/elf2uf2-rs [3]: https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html https://www.raspberrypi.com/documentation/microcontrollers/d... [4]: https://probe.rs/ https://probe.rs/

selfmodruntime 2y ago

I heavily disagree. I‘ve been working with the Espressif ecosystem for a couple of months now and it‘s the best documented microcontroller platform out there.

throwaway15968 2y ago
Completely agreed. ESP-IDF is incredible and the dev experience is miles beyond STM32 (my opinion).
- dailykoder 2y ago
  > STM32 (my opinion). STM32 is horrible, if you don't want to use the HAL.. Everything I used (Atmel, ESP32, rp2040) was better than that - Tho I heard NXP is bad.
  - 15155 2y ago
    STM32 is great if you choose to use the community-maintained Embassy HAL for these chips. Zero vendor code, async/await - it's a dream. The same code will more or less run abstractly on an RP2040, as well (for common peripherals/traits.)
15155 2y ago
Meanwhile NXP is producing 3000+ page PDFs with behavioral examples.
casept 2y ago
Only if you use their SDK. Quite a few parts of the chip lack actual register-level documentation, not so on the 2040.

mardifoufs 2y ago

Did you use esp-idf? Or the Arduino libs?

antirez 2y ago
ESP-IDF, Arduino IDE is untouchable for serious stuff IMHO.
- mardifoufs 2y ago
  Yeah agreed, that's why I was wondering! But esp-idf has been great recently. It used to be very patchy and undocumented but I prefer it over everything else now. I'll check the rp2040 docs and try out the dev board I've had for a while, because now I'm wondering if I'm missing something haha
- orphea 2y ago
  > Arduino IDE is untouchable for serious stuff Yes, but AFAIK you don't have to use Arduino IDE for Arduino stuff? e.g. there is PlatformIO.
- 15155 2y ago
  Embassy is next-level in terms of developer experience. If you must use C, ESP-IDF/Arduino aren't terrible. But you still don't really have a package manager or means to abstract anything, especially across devices. The cohesion present in Embassy between the HALs, probe-rs, etc. is really amazing. With Embassy for example, I can run the same async/interrupt-driven I2C driver code on any number of different MCUs across various manufacturers. This holds true for many, many different types of peripherals in the ecosystem. For the unique peripherals, implementation style and interface are extremely consistent and high-quality.
reassembled 2y ago
You can use Arduino libs via ESP-IDF. The IDF environment comes with a lot of libraries on its own but it is a development environment first and foremost. The design of IDF is very open and easy to understand throughout the stack. It is very easy to integrate external libraries via CMake as well.

15155 2y ago

The RP2040 only has one QSPI port. JLC will assemble a RP2040 board for you for <$3/pc at quantities of 5.

shadowpho 2y ago
I think it’ll be more expensive. When I was looking at jlc it seemed to be $100/10 was starting point if you want assembly
- MartijnBraam 2y ago
  It all depends on how you select the parts. I've ordered a set of 5 boards for $12 total including shipping and assembly.
- 15155 2y ago
  You need to carefully select JLC basic parts. QSPI, XOSC, etc. can all be had without paying fees. I've ordered 5+ boards with RP2040s that have come out to "cheaper than Pico" prices.