Make MPY ARCH supports for ESP32C3 RISCV
Checks
-
I agree to follow the MicroPython Code of Conduct to ensure a safe and respectful space for everyone.
-
I've searched for existing issues regarding this feature, and didn't find any.
Description
I tried to use Micropython to do real-time tasks on the ESP32C3, but it doesn't support hard interrupts, I can't get the timestamp and Pin state of the IRQ event (why don't MPY give such important informations rather then a useless Pin object), and if I use timer for resampling, the time jitter of the timer event is too bad (also a soft interrupt), so I had to try to use native code mpy, but the RISCV architecture of ESP32C3 is not supported, and there is no way to do it without customizing the firmware. How can I get millisecond-level time processing accuracy?
Code Size
I'm not sure about the code size requirement for this feature, maybe it's less than several kilo-bytes.
Implementation
- I intend to implement this feature and would submit a Pull Request if desirable.
- I hope the MicroPython maintainers or community will implement this feature.
- I would like to Sponsor development of this feature.
esp32/esp32_common.cmake: RISC-V improvements.
Summary
This PR contains some RISC-V specific improvements to the ESP32 port's build script.
The main change is the migration of the ESP32C3/ESP32C6 gchelper implementation over to the native version. This is to make the RISC-V boards' behaviour in line with what most other ports do, and to follow the request found in the generic gchelper source file: to use the native version if possible. This should also be compatible with future ESP32C2 board support, as the RISC-V CPU version in use is the same as the ESP32C6.
Two other changes perform some minor cleanup work by removing obsolete directives, with the last providing the proper architecture name to mpy-cross when needed. The old implementation did that only for Xtensa.
Testing
A build for ESP32_GENERIC_C3 was built without errors and the full test suite was run on an ESP32C3 board with the exactly same behaviour: machine_i2s_rate fails on my board both with current master and with my changes.