Deploy with confidence.

Bring your board. Get a simulator for it.

Run your firmware, test failures, and validate your whole system—on your own infrastructure.

Autonomous inspection drone
RunningRealtime00:18.420Simulation00:18.420
Terminal
~/drone $ west build -b nucleo_f767zi flight-controller-- west build: generating a build system-- Board: nucleo_f767zi-- Configuring done[1/142] Preparing syscall dependency handling[97/142] Building C object CMakeFiles/app.dir/src/imu.c.obj[98/142] Building C object CMakeFiles/app.dir/src/main.c.obj[142/142] Linking C executable zephyr/zephyr.elfMemory region         Used Size  Region Size  %age Used           FLASH:       38412 B         2 MB      1.83%             RAM:        9216 B       512 KB      1.76%Build finished: flight-controller/build/zephyr/zephyr.elf~/drone $ 
Ln 1, Col 1Spaces: 4
Observe2

Live signals

STM32F767 · PB8 ↔ MPU6050 · SCL
STM32F767 · PB9 ↔ MPU6050 · SDA
3V3GND3V3GND3V3GNDGND3V3GND3V3GND3V3GND3V3GNDGNDI²CSPIUARTGPIO
NUCLEO-F767ZI development board with an STM32F767 microcontrollerPrimary flight controller STM32F767
Seeed Studio XIAO ESP32-C3 board with an ESP32-C3 RISC-V microcontrollerTelemetry ESP32-C3
Raspberry Pi Pico 2 board with an RP2350 microcontrollerSafety monitor RP2350
MPU-6050 six-axis motion sensor board (I2C)Motion MPU6050
BMP280 barometric pressure sensor board (I2C)Altitude BMP280
MCP9808 temperature sensor board (I2C)Thermal MCP9808
ST7789 colour TFT display module (SPI)
Mission display ST7789
SSD1306 OLED display (I2C)Status SSD1306
Piezo buzzerFault tone
Red LEDFault state

Used by engineers at

GooglexAIEspressif
Supported platforms
  • Zephyr
  • FreeRTOS
  • Rust
  • Embassy
  • Arduino
  • and pretty much anything else

See it run before you talk to anyone.
Real firmware. Virtual hardware. Extraordinary fidelity.

Run a complete embedded system in your browser.

An AI plays Snake

An ESP32-C3 asks an AI model for every move over TLS 1.3 from the chip, with two displays, tilt controls and a buzzer.

  • Rust
  • Embassy

Two controllers, one bus

Two controllers share sensors, a display and a serial link.

  • ESP-IDF
  • Rust

Doom on RP2040

The full game running unmodified on a simulated RP2040, drawn to a colour display.

  • pico-sdk
Source on GitHub ↗

Interrupt handling

Trigger a hardware interrupt and watch the firmware respond.

  • Rust

Retro Player

A controller plays tunes on a passive buzzer, with an LCD and button controls.

  • Rust

A display-driven device

A controller drives a colour display from two button inputs.

  • ESP-IDF
  • FreeRTOS

Custom environments

Turn up the interference. Watch packets stop arriving. See whether your firmware detects the loss and recovers.

RF Environment
sensorgateway2 radios
Environment
Typical home
Typical distance
8 m
Non-Wi-Fi interference

More noise. Less room for the signal.

System behaviorExample run
01
Sensor firmwareSending heartbeats
Running
02
Wireless deliveryReaching the gateway
Receiving
03
Gateway firmwareListening for the next heartbeat
Serial · gatewayINFO heartbeat received

Illustrative RF scenario. PCB layouts: Olimex ESP32-DevKit-LiPo and ESP32-PoE · KiCad · Apache 2.0.

Multi-node systems

Run your controllers together. Follow a command from one firmware to the next, across the whole system.

ST AEK-MCU-C4MLIT1 CAN command controller illustration
SPC58EC80E5AEK-MCU-C4MLIT1
Fold mirror
CAN
ST AEK-MOT-MR200G1 mirror motor controller illustration
SPC582B60E1AEK-MOT-MR200G1
Fold command received

OTA for a fleet

Test your update across 10,000 simulated devices before rollout.

Stable network
1,042/2,500simulated systems passed
1,458 pending
Weak signal
638/1,800simulated systems passed
1,162 pending
Download interrupted
586/1,658simulated systems passed
1,072 pending
First-boot power loss
65/342simulated systems passed
276 pending
1 failed recovery
Packet loss
710/2,000simulated systems passed
1,290 pending
Network reconnect
638/1,700simulated systems passed
1,062 pending

Start with
supported hardware.

Try available boards and components, connect them, and run your firmware.

Explore the dashboard

Simulate your hardware.

Share your PCB design files, schematics, and usual hardware documentation. We handle the simulation model. Run your firmware, test connected systems, and reproduce failures before deployment.

Connect the model to your existing tools, integrate with your SystemC simulator, or co-simulate with Verilog.

Discuss your system

Available on our cloud or your infrastructure.

Before an evaluation.

What engineering teams usually need to establish first.

What is Simulator86?

Simulator86 is a programmable simulation environment for developing, testing, and validating embedded systems before relying on physical hardware.

Can Simulator86 run our real firmware?

Yes. Simulator86 runs compiled firmware inside a virtual hardware environment, allowing teams to test the software they intend to ship.

Does Simulator86 support our framework and libraries?

Yes. Simulator86 is framework- and library-agnostic: if your firmware runs on the real supported chip, it runs on Simulator86.

What can embedded teams use Simulator86 for?

Teams use Simulator86 to develop firmware, reproduce difficult failures, automate testing, and validate system behavior at scale.

Which devices and systems can Simulator86 support?

Simulator86 supports a growing range of embedded architectures, devices, and connected systems. We evaluate each target system to confirm the right simulation coverage.

How does Simulator86 fit into an engineering workflow?

Teams can use Simulator86 interactively, integrate it into automated workflows, or connect it to AI engineering tools through the IDE, SDK, and MCP.

How do we evaluate Simulator86 for our product?

Start with a technical evaluation. We’ll review your firmware, target system, and engineering goals to determine how Simulator86 can support your team.

Bring your board. Get a simulator for it.

Run on your own servers. Work with us under NDA. Test analog behavior and functional logic, improve your HIL setup, and more.

Bring your board