Emuko: Fast RISC-V emulator written in Rust, boots Linux (opens in new tab)

(github.com)

70 pointsfelipap27d ago6 comments

6 comments

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.

general146527d ago

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.

tl2do27d ago

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.

skelpmargyar26d ago

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.

general146527d ago

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.

skyberrys27d ago

What inspired you to create this emulator? Was it the using Rust component?

j / k navigate · click thread line to collapse

6 comments

tl2do27d ago

general146527d ago

So if you correctly abstract business logic from peripheral code, you can do most of your development without ever uploading to target.

tl2do27d ago

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.

skelpmargyar26d ago

general146527d ago

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.

skyberrys27d ago

What inspired you to create this emulator? Was it the using Rust component?

j / k navigate · click thread line to collapse