For a hobbyist embedded developer like me, the adoption of RISC-V in the ESP series is big news. In day-to-day development, instruction sets are often abstracted away by the compiler, but I appreciate open specifications and architectures. This makes me particularly interested in how an emulator like Emuko could facilitate evaluating code without the slow process of repeatedly burning it to ROM. I'm keen to see reports of its application in actual ESP32 development.
Or you can write code which can directly run on x86, i.e. FreeRTOS does support that without issues. For peripherals drivers you will need to burn it on chip regardless because emulator rarely can emulate peripherals in some reasonable way.
So if you correctly abstract business logic from peripheral code, you can do most of your development without ever uploading to target.
For a hobbyist embedded developer like me, the adoption of RISC-V in the ESP series is big news. In day-to-day development, instruction sets are often abstracted away by the compiler, but I appreciate open specifications and architectures. This makes me particularly interested in how an emulator like Emuko could facilitate evaluating code without the slow process of repeatedly burning it to ROM. I'm keen to see reports of its application in actual ESP32 development.
Or you can write code which can directly run on x86, i.e. FreeRTOS does support that without issues. For peripherals drivers you will need to burn it on chip regardless because emulator rarely can emulate peripherals in some reasonable way.
So if you correctly abstract business logic from peripheral code, you can do most of your development without ever uploading to target.
You could have HTTP API to GDB bridge and achieve same control with QEMU
Same for UART bridge - Have a look on STM32L403 implementation in QEMU which I believe does implement UART as well. And ADC and other peripherals.
And regarding autosnapshot, that's can be done via GDB as well - save RAM + registers and then load them back.