[Documentation/Feature] Remote output emulation (QEMU-226)

[mtribiere]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Described the feature in detail and justified the reason for the request.
• Provided specific use cases and examples.

Feature description

Hello,
I was wondering if the connecting an external process to qemu to inspect and inject GPIO states was possible.
Maybe the feature is already implemented, but I am unable to find any substantial amount of documentation to help me understand this process.

Thanks

Use cases

The idea for me would be to build an emulation/testing software to avoid flashing the real hardware again and again.
Here is an example of a similar software (that doesn't use qemu):
Here

Alternatives

No response

Additional context

No response

[igrr]

Hi @mtribiere, there was a similar request in #41 but so far I haven't found a reasonable way to implement this.

If you need to observe and inject GPIO states then Wokwi emulator might be a better option than QEMU at this point.

[lcgamboa]

Hi @mtribiere, I use something similar to your request in the PICSimLab open-source simulator. I use a modified version of Qemu that implements GPIO support. The modified version of Qemu is compiled as a library, and the interface is done through callbacks. Take a look at these two functions: void qemu_picsimlab_set_pin(int pin, int value) that's written on GPIO Input and static void pout_irq_handler(void *opaque, int n, int level) callback thas called on ESP32 write on GPIO output. You can link the Qemu library to your code or modify Qemu by adding a socket to communicate with your simulator (I've used this approach, but it makes the simulation much slower).

[mtribiere]

Hi @igrr, thank you for the sugestion. I did take a look at Wokwi but I'm looking to do everything in a local evironnment, so a web-based tool probably won't cut it.

[mtribiere]

Hi @lcgamboa thank you for your suggestion. I like the idea of modifying qemu to redirect the gpio callbacks.
If I understand correctly, you trigger an interrupt that will be handled by the pout_irq_handler vector is that correct? In that case why not directly overriding the void qemu_picsimlab_set_pin function and emitting to the socket from there?

[lcgamboa]

Hi @mtribiere, the pout_irq_handler is called by esp32 to write to an output pin, and qemu_picsimlab_set_pin is called by the application to set one esp32 input pin. Take a look at the old support using sockets (this code is for stm32, but can be modified to be used with esp32). As I said before the socket version is very slow compared to the direct lib use, but if your use case is only to implement a push-button it is sufficient.