Good catch!!! thanks for pointing that out

The container pulls additional assets on first run (mainly emulation dependencies), which is why there's extra downloading even with -d.

You're right that it can be confusing. I'll update the instructions to make this clearer (and probably remove -d so users can see what's happening)

That’s awesome — and exactly the kind of use case I had in mind

Being able to iterate without constantly flashing hardware can save a lot of time early on.

If you end up trying it in your workflow, I’d love to hear how it goes

Exactly,that’s the idea. Not having to flash the chip a thousand times just to see if everything works. The goal is to let you test the setup as fast as possible, ideally without installing anything locally

I’m currently working towards that.

The Raspberry Pi emulation already runs Python, and I’d like to extend that into proper MicroPython / CircuitPython support for microcontrollers as well

It’s a bit tricky depending on the board/emulator, but definitely a priority!

Fair enough , though there’s quite a bit of low-level work behind it (emulation cores, QEMU integration, protocol timing, etc)

Definitely inspired by existing tools, but trying to push further into full multi-board emulation and local-first workflows

Thanks, appreciate it! Glad you like it

[flagged]