OpenCircuit

Inspiration

When using Wokwi, I sometimes ran into server congestion that interrupted the simulation workflow. That made me wonder: could I build a circuit simulator that people could get started with quickly, with less waiting before they could test an idea?

OpenSlide also inspired me to bring AI coding agents into the process. Instead of building every circuit manually, users could describe what they wanted and have an agent help generate the circuit and firmware, then inspect and test the result in the same workspace.

That became OpenCircuit: a local electronics workspace intended to help students, school electronics clubs, and community makers turn an idea into a prototype they can check and test.

What it does

Users describe a project to an AI coding agent, then watch the components and wiring update in the browser. OpenCircuit checks the circuit, compiles real firmware with the Arduino toolchain, and runs supported Arduino Uno and ESP32 simulations locally.

Users can view OLED output, press buttons, exchange serial messages, and adjust supported sensor inputs. When requirements change, they can ask the agent to update the project and test it again.

The materials page organizes inventory, purchase quantities, price sources, and budget estimates. Projects can be exported or restored to earlier revisions. When ready for a physical test, users can select the correct board and USB port and upload the firmware.

How I built it

The interface uses React and TypeScript with a local Node.js service. A shared core handles circuit rules, material planning, revisions, compilation, and simulation. Arduino CLI compiles the firmware, AVR8js runs supported Uno programs, and a Python bridge connects ESP32 simulation to PICSimLab QEMU.

Coding agents follow AGENTS.md and work through ordinary project files and the hw CLI. OpenCircuit does not include an AI model or an agent subscription.

I used Codex and Claude Code during development and demo preparation, and checked the results with automated tests, real compilation, and simulation. The demo video uses captions.

Challenges I ran into

One major challenge was keeping the canvas, wiring, firmware, and verification results consistent while an agent edited the files. The displayed state must correspond to the project actually being tested.

Compilation, simulation, and physical hardware tests also need to be distinguished clearly. For example, ESP32 DHT22 firmware can compile, but the current simulation engine cannot run that scenario correctly, so the temperature demo uses an Uno.

While preparing the portable package, I found tool settings tied to the original computer's absolute paths. The Windows launcher now generates settings for its current extraction location and uses the bundled runtime.

Accomplishments

The demo shows an agent-driven OLED project, a temperature alert, a follow-up requirement change, materials and budget planning, and project export. It also shows a real ESP32 firmware upload and serial output from the board.

I tested the Windows portable package after extracting it into another folder whose path contained spaces. Startup, real compilation, ESP32 LED and button behavior, bidirectional UART, and pause, step, and resume controls worked in that test.

All 167 unit tests passed. Of 50 browser tests, 48 passed on the first run; the remaining two passed when rerun individually.

What I learned

Helping someone finish an electronics project takes more than generating code. Component compatibility, wiring checks, materials, and environment setup all affect whether an idea becomes a working prototype.

Test results also need to be understandable and inspectable. Simulation limits must be clear: a successful simulation does not guarantee that the physical circuit will work.

What's next

I would like to invite students and workshop mentors to try the first-project workflow, observe where they get stuck, and improve the guidance. I also want to support more platforms and add more verified component models.

The source code and Windows portable package are available on GitHub. Community adoption and learning outcomes have not yet been measured.

Built With

• arduino
• avr8js
• claude
• codex
• esp32
• node.js
• playwright
• python
• qemu
• react
• typescript
• vite
• vitest