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.
That's a solid approach, and for high-level logic, it's definitely the way to go.
I find that a lot of my development time is actually spent on lower-level tasks—like writing custom string operations—since we don't have the rich standard libraries of a host environment.
This is exactly where an emulator really shines for me. It enables a "device-less" workflow where I can work through those low-level details on a sofa at a cafe without needing to bring the physical hardware along just to verify the behavior.
RISC-V is supported on QEMU. The available devices don't have a ton of peripherals compared to aarch64, but it exists. Even FreeRTOS has a QEMU virt port for RISC-V. And if you have unit tests QEMU could easily run those accurately.
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.
That's a solid approach, and for high-level logic, it's definitely the way to go.
I find that a lot of my development time is actually spent on lower-level tasks—like writing custom string operations—since we don't have the rich standard libraries of a host environment.
This is exactly where an emulator really shines for me. It enables a "device-less" workflow where I can work through those low-level details on a sofa at a cafe without needing to bring the physical hardware along just to verify the behavior.
RISC-V is supported on QEMU. The available devices don't have a ton of peripherals compared to aarch64, but it exists. Even FreeRTOS has a QEMU virt port for RISC-V. And if you have unit tests QEMU could easily run those accurately.
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.
What inspired you to create this emulator? Was it the using Rust component?
[dead]