4 ms·

Yay for 5ghz and Risc-v. Only other thing is ble with actual ble power consumption from Espressif. Speaking of which, Nordic bought out that WiFi startup late

Yay for 5ghz and Risc-v. Only other thing is ble with actual ble power consumption from Espressif. Speaking of which, Nordic bought out that WiFi startup late 2020 but have been silent on their WiFi mcu since https://youtu.be/PLdpg-YXhv0 https://youtu.be/PLdpg-YXhv0

jabl 4y ago
It's still a single core CPU, though, whereas the Xtensa-based ESP32 has a dual core CPU. Not sure people are actually using that second core in practice though.. And yes, this is probably an excellent case where RISC-V can win; wouldn't surprise me if RISC-V already has better toolchain support than Xtensa despite being a much younger ISA. Some benchmarks on the earlier ESP32-C3 at https://hackaday.com/2021/02/08/hands-on-the-risc-v-esp32-c3-will-be-your-new-esp8266/ https://hackaday.com/2021/02/08/hands-on-the-risc-v-esp32-c3... ; it seems it has the same core as the new ESP32-C5 except it's clocked at 160 MHz instead of 240 MHz. Extrapolating those ESP32-C3 benchmark results out to 240 MHz would suggest it's a bit spiffier than a single core Xtensa ESP32 but not enough to catch the dual core xtensa.
- jareklupinski 4y ago
  I make displays out of discrete lights and panels, when I use dual-core chips I usually use one core for driving pixels and scanning continuously while the other core does network stuff and actual framebuffer content updates. Makes for a very glitch-free and seamless experience :)
- nerpderp82 4y ago
  Once RVV implementations start working their way down into MCUs, there will be little to no reason for Xtensa, this probably a 3-5 year time frame. The ESP32 is going a bunch of SDR with Xtensa VLIW/DSP core afaik. You would have to measure cpu cycle jitter under adverse wifi conditions to see if the single core is an issue. I would assume that the wifi stack is hardware scheduled on that core with dedicated scratch ram, and that the rest of the cache and cpu cycles are granted to the user visible core only while not needed. I think a whole lot of applications didn't use the second xtensa core on the earlier parts.
- deleted 4y ago
  [deleted]
- bri3d 4y ago
  It's extremely common to use both cores on the dual core Xtensa because you can bind ESP tasks (WiFi/Bluetooth) to one core and schedule your application code on the second core, reducing jitter visible to the application code. The cores were even named Core0 - PROtocol and Core1 - APPlication in the initial ESP-IDF design, where the core affinity model was going to be more strongly enforced (thankfully they backed off on this idea and now it is fully configurable SMP).
- cwt137 4y ago
  I think developers using the Arduino platform on the ESP32 are mostly just using one core. Developers using the Espressif's SDK are more likely to use both cores.
- Taniwha 4y ago
  They've indicated that there's multi-core risc-vs in their future ....
- qalmakka 4y ago
  RISC-V is a way more supported architecture than Xtensa for the single fact it has upstream support from LLVM. After years Espressif still hasn't managed to get its LLVM backend upstreamed, which means using Rust or everything depending on LLVM is a hassle.
rasz 4y ago
>Yay for ... and Risc-v why? You as a user get 2x less computing power and celebrate it because vendor saved on licensing?

jabl 4y ago

It's still a single core CPU, though, whereas the Xtensa-based ESP32 has a dual core CPU. Not sure people are actually using that second core in practice though.. And yes, this is probably an excellent case where RISC-V can win; wouldn't surprise me if RISC-V already has better toolchain support than Xtensa despite being a much younger ISA. Some benchmarks on the earlier ESP32-C3 at https://hackaday.com/2021/02/08/hands-on-the-risc-v-esp32-c3-will-be-your-new-esp8266/ https://hackaday.com/2021/02/08/hands-on-the-risc-v-esp32-c3... ; it seems it has the same core as the new ESP32-C5 except it's clocked at 160 MHz instead of 240 MHz. Extrapolating those ESP32-C3 benchmark results out to 240 MHz would suggest it's a bit spiffier than a single core Xtensa ESP32 but not enough to catch the dual core xtensa.

jareklupinski 4y ago
I make displays out of discrete lights and panels, when I use dual-core chips I usually use one core for driving pixels and scanning continuously while the other core does network stuff and actual framebuffer content updates. Makes for a very glitch-free and seamless experience :)
nerpderp82 4y ago
Once RVV implementations start working their way down into MCUs, there will be little to no reason for Xtensa, this probably a 3-5 year time frame. The ESP32 is going a bunch of SDR with Xtensa VLIW/DSP core afaik. You would have to measure cpu cycle jitter under adverse wifi conditions to see if the single core is an issue. I would assume that the wifi stack is hardware scheduled on that core with dedicated scratch ram, and that the rest of the cache and cpu cycles are granted to the user visible core only while not needed. I think a whole lot of applications didn't use the second xtensa core on the earlier parts.
deleted 4y ago
[deleted]
bri3d 4y ago
It's extremely common to use both cores on the dual core Xtensa because you can bind ESP tasks (WiFi/Bluetooth) to one core and schedule your application code on the second core, reducing jitter visible to the application code. The cores were even named Core0 - PROtocol and Core1 - APPlication in the initial ESP-IDF design, where the core affinity model was going to be more strongly enforced (thankfully they backed off on this idea and now it is fully configurable SMP).
cwt137 4y ago
I think developers using the Arduino platform on the ESP32 are mostly just using one core. Developers using the Espressif's SDK are more likely to use both cores.
Taniwha 4y ago
They've indicated that there's multi-core risc-vs in their future ....
qalmakka 4y ago
RISC-V is a way more supported architecture than Xtensa for the single fact it has upstream support from LLVM. After years Espressif still hasn't managed to get its LLVM backend upstreamed, which means using Rust or everything depending on LLVM is a hassle.

rasz 4y ago

>Yay for ... and Risc-v why? You as a user get 2x less computing power and celebrate it because vendor saved on licensing?