feature: Wokwi simulation support (RDT-551) #230
Conversation
|
Thanks for the PR @urish!
Perhaps you can try to do it the same way this is handled in pytest-embedded-qemu, by creating a full flash image? |
github-actions
bot
changed the title
I considered that, but then realized it is probably beneficial to have an easy way to simulate any esp-idf project in Wokwi for VSCode and in general using the CLI. So solving this at pytest-embedded level won't benefit VSCode nor the CLI. Internally, I've been using I'm trying to figure out what would be the most user friendly way for IDF users. Any thoughts? |
|
If you can support reading the information from |
wokwi-cli 0.7.0 and later support specifying "flasher_args.json" as the firmware to simulate. This simplifies the pytest driver code, and allows us to support non standard configurations (e.g. custom bootloader or non standard partition layout).
|
Right, added support for reading flasher_args.json. I like how this simplifies the code for the pytest driver. |
There was a problem hiding this comment.
Thank you for your PR!
I'd like to comment a bit on the project layout.
pytest-embedded-wokwi Dependencies
For now, wokwi service highly bundled with the idf. For example, in create_wokwi_toml, it depends on flasher_args.json. It makes the WokwiCLI hard to run without ESP-IDF binaries.
How about we make pytest-embedded-wokwi always depends on pytest-embedded-idf, not optionally? I prefer the original way you implement it, as pytest-embedded-idf-wokwi
WokwiDut Inheritance
In the IdfUnityDutMixin, we provide some functions to interact with the c unity framework. If WokwiDut can also inherit from this mixin class, the users could also use run c test cases on wokwi. That would make it even better :)
Overall your PR LGTM! Thanks again!
|
@urish Thank you for adding the test. Now everything runs perfectly. One last thing, could you help add |
|
Done! Locally, I'm developing on Windows, so I converted that script to Python, to make it cross platform. If you are interested, here's the python version that I'm using: #!/usr/bin/env python3
import sys
import subprocess
import os
DEFAULT_PACKAGES = [
"pytest-embedded",
"pytest-embedded-serial",
"pytest-embedded-serial-esp",
"pytest-embedded-idf",
"pytest-embedded-jtag",
"pytest-embedded-qemu",
"pytest-embedded-arduino",
"pytest-embedded-wokwi"
]
def run_command(command):
try:
subprocess.check_call(command, shell=True)
except subprocess.CalledProcessError as e:
print(f"An error occurred: {e}")
return 1
return 0
def main(action):
res = 0
# one-time command
res |= run_command("pip install -U pip")
if action in ["install-editable", "build", "publish"]:
res |= run_command("pip install -U flit")
for pkg in DEFAULT_PACKAGES:
os.chdir(pkg)
if action == "install-editable":
res |= run_command("flit install -s")
elif action == "install":
res |= run_command("pip install .")
elif action == "uninstall":
res |= run_command(f"pip uninstall -y {pkg}")
elif action == "build":
res |= run_command("flit build")
elif action == "publish":
res |= run_command("flit publish")
else:
print("invalid argument. valid choices: install-editable/install/uninstall/build/publish")
return 1
os.chdir("..")
return res
if __name__ == "__main__":
action = sys.argv[1] if len(sys.argv) > 1 else "install"
exit_code = main(action)
sys.exit(exit_code) |
|
@urish Thanks again for your great PR! |
Functional implementation draft. Tested with https://github.com/espressif/gh-esp-test-template on simulated ESP32C6.
The Wokwi CLI still has no support for specifying multiple flash images. You can either give it an application binary file or elf file to load at 0x10000, using a default bootloader and partition table, or specify a full flash image to load. I'm still trying to figure out what's the best way to address it. Meanwhile, we only provide the app image to the CLI as a workaround.Also, we can automatically download the CLI for the user, in case it's not installed. Not sure if this is a good idea, and where we should install it. It's distributed as a single binary, and currently supports Linux (arm, x64), MacOS (arm, x64) and Windows (x64).
I'd appreciate your guidance on how to move forward with this.
Here's the output from the test setup I used, for reference: