4 ms·

> Wouldn't abandoning Xtensa architecture for RISC-V help? Are there any plans to simplify the stack? I mean, the new one's are already risc-v based and they a

> Wouldn't abandoning Xtensa architecture for RISC-V help? Are there any plans to simplify the stack? I mean, the new one's are already risc-v based and they added tier-3 compiler support for those in rust recently (1.56 IIRC), not sure if they still plan to release xtensa based ones in the future.

po1nt 5y ago
Yes but they didn't yet release dual-core RISC-V based or did I miss it? I use it's dual-core capabilities extensively as I heavily utilize WiFi and still have to maintain low-latency processing of IO input. Didn't look much into RISC-V ESP but does it have some interrupts without multiplexor?
- tlamponi 5y ago
  Yes, esp32-c3 [0] can be bought already, e.g., from mouser [1] or sparkfun [2] either as dev kit or as native module for a self-designed PCB. [0]: https://www.espressif.com/en/products/socs/esp32-c3 https://www.espressif.com/en/products/socs/esp32-c3 [1]: https://www.mouser.de/new/espressif/espressif-esp32c3wroom02-wifi-ble-module/ https://www.mouser.de/new/espressif/espressif-esp32c3wroom02... [2]: https://www.sparkfun.com/products/18034 https://www.sparkfun.com/products/18034
  - kingosticks 5y ago
    They asked for dual core. The C3 is single core. > ESP32-C3 is a single-core, 32-bit, RISC-V-based MCU with 400KB of SRAM, which is capable of running at 160MHz https://www.espressif.com/en/news/ESP32_C3 https://www.espressif.com/en/news/ESP32_C3
    - tlamponi 5y ago
      And ESP's rust support provides threads and async supprot nonetheless. With a zero-cost async implementation you may not require multiple cores, for some hard realtime stuff maybe, but even that can be handled by the work scheduler.
      - bri3d 5y ago
        The challenge in single-core timing-important ESP development is using the wireless peripherals effectively while maintaining I/O scheduling. Even with "zero-cost async" at the application layer, the WiFi and Bluetooth implementations are mostly software and will be getting scheduled on that same single CPU. You don't really get to control their scheduling in a granular manner, so meeting timing is pretty hard in many situations. This is probably the most annoying thing about ESP development, but mostly goes away when you can just dedicate a core to the "ESP stuff" and then run your application on the other core.
        tlamponi 5y ago
        They are mostly software but the actual time critical RF stack isn't, those esp's have that in HW (at least their manual suggests that) and the remainig Bluetooth or wifi stuff does not need to run in an interrupt disabled critical section, so can work fine with an time critical app, but naturally depends on how much transmissions need to happen and how time critical and compute intensive the application is.
      - kingosticks 5y ago
        "low-latency processing of IO input" may well be talking about hard realtime stuff, for which threads/async on a single core doesn't help you.
        tlamponi 5y ago
        They do help, hard realtime only means that there can be no blocking (critical) section with a possible unbound time limit, toggling an IO register with a lower frequency as the CPu clock can still be done while shovelling in datagrams into the RF stack that can DMA acces in withput any CPu doings anyway..
        kingosticks 5y ago
        i agree it can be done but it's a fragile balancing act. What I don't agree with is that Rust provides anything particularly special allowing you to do this.

po1nt 5y ago

Yes but they didn't yet release dual-core RISC-V based or did I miss it? I use it's dual-core capabilities extensively as I heavily utilize WiFi and still have to maintain low-latency processing of IO input. Didn't look much into RISC-V ESP but does it have some interrupts without multiplexor?

tlamponi 5y ago
Yes, esp32-c3 [0] can be bought already, e.g., from mouser [1] or sparkfun [2] either as dev kit or as native module for a self-designed PCB. [0]: https://www.espressif.com/en/products/socs/esp32-c3 https://www.espressif.com/en/products/socs/esp32-c3 [1]: https://www.mouser.de/new/espressif/espressif-esp32c3wroom02-wifi-ble-module/ https://www.mouser.de/new/espressif/espressif-esp32c3wroom02... [2]: https://www.sparkfun.com/products/18034 https://www.sparkfun.com/products/18034
- kingosticks 5y ago
  They asked for dual core. The C3 is single core. > ESP32-C3 is a single-core, 32-bit, RISC-V-based MCU with 400KB of SRAM, which is capable of running at 160MHz https://www.espressif.com/en/news/ESP32_C3 https://www.espressif.com/en/news/ESP32_C3
  - tlamponi 5y ago
    And ESP's rust support provides threads and async supprot nonetheless. With a zero-cost async implementation you may not require multiple cores, for some hard realtime stuff maybe, but even that can be handled by the work scheduler.
    - bri3d 5y ago
      The challenge in single-core timing-important ESP development is using the wireless peripherals effectively while maintaining I/O scheduling. Even with "zero-cost async" at the application layer, the WiFi and Bluetooth implementations are mostly software and will be getting scheduled on that same single CPU. You don't really get to control their scheduling in a granular manner, so meeting timing is pretty hard in many situations. This is probably the most annoying thing about ESP development, but mostly goes away when you can just dedicate a core to the "ESP stuff" and then run your application on the other core.
      - tlamponi 5y ago
        They are mostly software but the actual time critical RF stack isn't, those esp's have that in HW (at least their manual suggests that) and the remainig Bluetooth or wifi stuff does not need to run in an interrupt disabled critical section, so can work fine with an time critical app, but naturally depends on how much transmissions need to happen and how time critical and compute intensive the application is.
    - kingosticks 5y ago
      "low-latency processing of IO input" may well be talking about hard realtime stuff, for which threads/async on a single core doesn't help you.
      - tlamponi 5y ago
        They do help, hard realtime only means that there can be no blocking (critical) section with a possible unbound time limit, toggling an IO register with a lower frequency as the CPu clock can still be done while shovelling in datagrams into the RF stack that can DMA acces in withput any CPu doings anyway..
        kingosticks 5y ago
        i agree it can be done but it's a fragile balancing act. What I don't agree with is that Rust provides anything particularly special allowing you to do this.