You're partially right. ESP32-C6 isn’t supported yet (only ESP32, S3, CAM, C3 for now), and the current flow is Arduino-based via arduino-cli — ESP-IDF support is planned a future You’re also right about binaries, you can’t upload an ELF/BIN yet, everything goes through the built-in compilation pipeline (but it’s on the roadmap).

Appreciate the feedback.

Thanks, appreciate it! Glad you like it

Thanks, appreciate it!

Yes,peripherals are fully emulated, not just the CPU. LEDs blink, buttons respond to clicks, Serial Monitor works, servos rotate, displays render (ILI9341 TFT), and we have 48 o more components from the wokwi-elements library. The Blink example should show the built-in LED toggling on pin 13. If it didn't blink for you, it might be a compilation issue

try the example Traffic Light : Simulate a traffic light with red, yellow, and green LEDs

does this handle the timing differences between browser execution and real time hardware? or is it focused on logic verification?

Both, with a nuance. The AVR simulator syncs to wall-clock time and each frame calculates cycles from real elapsed deltaMs, so delay(1000) takes 1 real second and timer-dependent code (PWM, millis()) runs at correct real time rates. The RP2040 and ESP32-C3 simulators use a fixed cycles-per-frame budget (125MHz/60 and 160MHz/60 respectively), which targets real time but doesn't compensate for frame drops . if the browser stutters, emulated time stretches slightly. All three are cycle-accurate at the instruction level though, so the logic and peripheral behavior is faithful to real hardware regardless of frame timing

PIO isn't abstracted yet, we use rp2040js which has a full PIO emulator that executes the actual PIO instruction set (MOV, SET, PUSH, PULL, etc.) cycle by cycle, including the FIFOs and clock dividers. So it's not an abstraction. it's a direct emulation of the PIO state machines, same as how avr8js runs real AVR instructions

Thanks! The rendering is DOM-based, circuit components are Web Components (from the wokwi-elements library) wrapped in React, and wires are SVG. No Canvas/WebGL, which keeps it simple for the component count we're dealing with (typically dozens, not thousands).

The emulation itself is pure JavaScript (avr8js), not WebAssembly. The simulation loop runs on requestAnimationFrame and executes 267K AVR instructions per frame (16MHz / 60fps) in a synchronous batch. Port listeners use dirty-checking so the UI is only notified when a GPIO register actually changes value and since all those cycles run in one JS microtask, React reconciles exactly once per frame regardless of how many state changes happened during the batch

So there's no explicit throttle interval like your 2 sec approach, but the architecture achieves something similar. the CPU runs freely, state changes are coalesced within each rAF frame, and the DOM only sees the final result. For your deck.gl case with thousands of points, the 2s batch makes sense since you're dealing with a much higher entity count hitting the GPU , our problem domain is simpler (dozens of components) but the cycle-accurate emulation is the expensive part

You can add peripherals There’s a “+” button on the right side of the circuit editor where you can add components like LEDs

Thanks! Yeah, that’s probably the easiest way to get started, just load an example and hit “Compile + Play”.

I tried to make it as close to zero-setup as possible so people can just jump in and experiment

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

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