Simulate an Arduino project with no hardware at all
- 192parts on the bench
- 25boards running now
- 1.00xreal time, on every board
The part has not arrived, the board is at the office, or the last one let its smoke out: whatever the reason, the practical question is the same. Can the sketch and the wiring plan be checked before any physical part is involved? For an Arduino Uno or an ESP32-C3 project, the answer is yes, and the circuit above is exactly that: a real board, a real breadboard, and a sketch that compiles and runs against a modeled chip rather than a mock standing in for one.
This is a practical guide rather than a single-topic explainer: it walks through what "simulating without hardware" actually buys you, the steps to try it on a project of your own, and, just as importantly, what it will not catch, so nothing here overpromises what a simulator can do for a real build.
What "without hardware" actually means here
There are two different things people mean by testing Arduino code without hardware, and they solve different problems. The first is unit-testing the plain logic of a sketch, the parts that do not touch a pin directly, on a regular computer with a mocking library standing in for digitalRead and friends; this is a real and useful technique for a sketch with substantial non-hardware logic in it, and it tells you nothing about timing, wiring or what the physical pins actually do. The second, what Mokxi does, is running the whole sketch, compiled the same way it would be for the real board, against a cycle-accurate model of the chip and the parts wired to it, so pin states, timers and the breadboard connections are all real rather than assumed. Both are legitimate; they answer different questions.
From an idea to a working sketch, step by step
Open the editor and drop a board onto the canvas: an Arduino Uno for a first project, or an ESP32-C3 for one that will eventually want more pins or more processing headroom. Drag a breadboard next to it, and the parts the project needs from the catalog, an LED, a resistor, a pushbutton, whatever the build calls for. Wire them the way you would on the bench, pin to breadboard row, part to part, using the actual jumper-wire distances a real build would need rather than a schematic shorthand. Write the sketch in the panel next to the canvas, in the same C++ an Arduino IDE would accept. Press Run, and the same clang toolchain that ships with the editor compiles it for the board actually on the canvas, then executes the result against the modeled chip while the breadboard responds in real time.
What this catches before you solder anything
An LED wired backwards stays dark here exactly as it would on the bench, with the added benefit that nothing is at risk while you find the mistake. A resistor picked too small shows an unrealistic current on the probe rather than a smell. A button that seems to fire twice is showing a real bounce, the same bounce a real tactile switch produces, and the debounce page on this site is built entirely around watching that happen and fixing it. A fade sketch that assumes hardware PWM on a pin with no timer behind it does nothing, here and on the real board alike, which is a mistake far cheaper to find before the parts are wired than after.
It also catches the class of mistake that has nothing to do with electronics at all: a sketch that compiles but does the wrong thing, a state machine that gets stuck, a variable that should have been unsigned long and was not. None of that needs a single physical part to find, only the actual firmware running against something that behaves like the actual chip, which is exactly what a compiled-and-executed simulation gives and a hand-traced reading of the code does not always catch.
What it will not catch
The live simulation has limits. Diodes, transistors and MOSFETs have device models, but on the canvas there is no temperature dependence, component-to-component manufacturing tolerance or electrical noise. A circuit that is marginal on a real bench because of a slightly out-of-spec part or noisy wiring may look stable here. Nor does it replace a continuity check on a soldered board, or catch a cold solder joint, a shorted trace or a damaged part. Simulating a project is a strong first check, and the physical build still needs testing.
Sharing the result
A circuit built this way is also easier to hand to someone else than a photo of a breadboard is: a saved project keeps the exact wiring and the exact sketch together, in a form somebody else can open, run and change rather than only look at. That is worth using for asking for help on a circuit that is not working as expected, since "here is the wiring and the code, and here is what it does when I press Run" answers most of the follow-up questions a photo alone invites.
No account is needed for that hand-off either: the Share sheet's Copy link button packs the whole circuit into the link itself, so pasting it into a forum post or a chat message is the entire step.
Questions
Do I need an account to try this?
No. The simulator, every board and every part in the catalog work with no account and no time limit; an account exists only so a saved project survives a closed tab.
Will the code I write here work on my real board unchanged?
For the peripherals Mokxi models, the Uno and ESP32-C3 use the real memory map and register offsets, so the firmware can run on the physical board. Test it on hardware before relying on it, especially if it uses wireless behavior or peripherals outside the model.
Can I simulate a project that uses WiFi or a sensor Mokxi does not model?
WiFi is simulated on supported boards: the code can join a network and serve or fetch pages inside Mokxi, with no radio or real internet. For a sensor Mokxi does not model, you can still check the GPIO, timing and logic around it using a switch, a clock or a fixed value as a stand-in.
Is this the same as unit-testing my code on my laptop?
No, and both are worth knowing about. Unit testing checks the plain logic of a sketch on a regular computer with hardware calls mocked out; this runs the real compiled firmware against a modeled chip and breadboard, which is closer to the real build but is a different kind of test.
What should I do once the parts actually arrive?
Build the same circuit on the real breadboard from the same wiring the simulator showed, upload the same sketch, and check it behaves the same. Anything that differs is worth investigating: it is either something the simulator does not model, or something worth checking on the physical build, like a loose connection or a part that does not match its expected value.
Keep going
Build this for real
Open the editor, change a value and watch the number move with it. Nothing to install, and no account needed.