Provision Simulations as if they are VMs

We just launched our cloud to run your firmware against modern, popular MCUs — from code, not from a browser tab.

The web app is great for building and debugging interactively. But most embedded teams don’t have a simulation culture at all: testing means a board on a desk, a debugger probe, and someone manually flashing builds. That doesn’t scale past one desk, and it definitely doesn’t run in CI. Our cloud SDK is our answer — everything the simulator does, scriptable.

MCUs are code

A project, a graph, components, firmware. No GUI, no string-based wiring — you connect actual bus-level signals:

const client = createClient(env.SIM86_API_KEY)

const project = await client.createProject("smart-fan-controller")
const graph = project.graph

const mcu = graph.addComponent(Components.ADAFRUIT_STM32F405_EXPRESS)
const imu = graph.addComponent(Components.MPU6050)

mcu.setFlash("./firmware.elf") // path or Uint8Array

// connect physical bus-level signals
graph.connect(imu.pins.sda, mcu.pins.sda)
graph.connect(imu.pins.scl, mcu.pins.scl)

Streams and records

Everything the simulation produces is observable. Streams emit live during the run — sensor outputs, even individual CPU registers:

// live sensor output
imu.stream("gyro").subscribe(({ x, y }) => {
  console.log("IMU:", { x, y })
})

// program counter transitions, sampled every 35ms of simulation time
mcu.cpu0.stream("pc", { throttle: 35 }).subscribe((pc) => {
  console.log("PC:", pc)
})

Streams are for watching; keep them throttled. For anything high-frequency, record it instead and query it after the run:

mcu.record({
  include: [
    "cpu0.sp",   // stack pointer register transitions
    "usart",     // tx/rx streams
    "i2c.0x04",  // I2C register at offset 0x04 from peripheral base
    "rtt",       // Segger RTT
  ],
})

Run it, poke it, query it

Runs are bounded in simulation time, and you can schedule events against the timeline — inject sensor values, press reset, see how your firmware reacts:

const run = await graph.run({
  duration: 5000, // 5 seconds of simulation time
  record: { include: ["cpu0.pc", "cpu0.sp", "usart"] },
})

// scheduled events (timing guaranteed within ±10ms)
await run.at(1000).do(() => {
  imu.setYGyro(5)
})
await run.at(3000).do(() => {
  mcu.pressReset()
})

const logs = await run.logs()

Runs are persisted, so postmortems don’t require reproducing anything:

const logs = await client
  .getProject("my-project-id")
  .getRuns("my-run-id")
  .logs()

It pairs brilliantly with Claude Code

Coding agents are only as good as their feedback loop, and embedded development normally has the worst one imaginable: flash a board and watch it. The SDK gives an agent the loop it actually needs. Point Claude Code at a repo with the SDK installed and it can compile your firmware, run it on a simulated board, read the logs, register transitions, and bus traffic, and keep iterating until the behavior is right — unattended.

Why this matters

Most simulators are deterministic: the same binary produces the same execution, every time. That’s convenient — and it’s exactly why firmware that passes a deterministic simulator still dies on real hardware, where clocks drift and interrupts land at the worst possible moment.

Simulator86 is stochastic. Every run injects controlled timing variation, the way real silicon does. So a passing run isn’t “it worked once under lab conditions” — surviving runs here means your firmware has a genuinely working path on hardware. Put that in CI, on every commit, and you have something most embedded teams have never had: regression testing that actually predicts hardware behavior.

The SDK is available now. If you’re a business looking to build a simulation culture, talk to us.

推荐订阅源