The board is late. Your firmware does not have to be.
CARME gives every developer every board, on the laptop and in CI. The binary you build is the binary it runs. When the hardware arrives, the firmware is already written, debugged and tested.
$ west build -b nrf52840dk/nrf52840 samples/bluetooth/peripheral_hr$ carme boards/nrf52840dk.cmboard --firmware build/zephyr/zephyr.elf --uart uart0*** Booting Zephyr OS ***Bluetooth initializedAdvertising successfully startedEvery board, for every developer, all the time.
No waiting for hardware
Start on the day the part is chosen. 250+ boards and SoCs are ready, and a custom board is a short .cmboard on top of a listed SoC.
No hardware on your desk
No probes, no cables, no “who has the board”. Every developer has as many boards as they want, and the same ones.
No flaky test rack
Firmware CI on emulated boards is fast, parallel and gives the same result every time. A failure is a bug, not a loose USB cable.
Debugging the board cannot give you
Stop every core at once. Watch a peripheral register. Break when DMA writes a buffer. Step back from a crash to the write that caused it. Trace every interrupt with its exact time.
Nothing to replace.
- Operating systems
Zephyr, FreeRTOS, NuttX, Tock, seL4, embedded Linux, bare metal
- Toolchains
GCC, LLVM/Clang, vendor toolchains; any ELF, binary, HEX or S-record
- Build systems
west, CMake, Make, Yocto, Buildroot, vendor IDE projects
- Debuggers
GDB, and every IDE that speaks to GDB: VS Code, Eclipse-based vendor IDEs, CLion
- Test tools
.cmtest (pytest style), plus anything that talks over UART, sockets or GDB
- CI
GitHub Actions, GitLab CI, Jenkins, Buildkite, in a container
The tests a board on a desk never gets to run.
The bootloader and the update:power cut in the middle of a firmware update, then check the device still boots.
The radio network:a gateway and fifty nodes, with packet loss, out of range nodes and interference you set.
The sensor at its limits:replay a recorded flight into the IMU, a heat soak into the thermometer, a drained battery into the fuel gauge.
The long run:a week of uptime in minutes, to find the counter that wraps and the leak that grows.
The CAN bus:four ECUs, one bus, error frames and bus-off on demand.
A mesh network that behaves the same on every run.
Connect boards over Ethernet, CAN, BLE, 802.15.4, LoRa and UART in a .cmsystem. Every node runs its own firmware, and every run plays out the same way, so a timing bug in a mesh network can be replayed and fixed.
Start on a chip before samples exist.
When your silicon vendor ships a CARME model of a new chip, you start on it before samples exist. Their virtual dev kit runs the same SDK and the same examples as the board will.
Common questions.
Is it a simulator of my code, or of the hardware?
Of the hardware. CARME runs the machine code your compiler produced on emulated CPUs and peripherals, so you test the binary you will ship.
How fast is it?
Most microcontroller firmware runs faster than real time. Linux boots in seconds to minutes depending on the platform, and a checkpoint lets every test start after boot.
What if a peripheral I use is not modelled?
Write it in Python from its register description, or ask us: we add models for test partners first.
Does it replace the board completely?
For development and CI, most of the time. Keep a few boards for final validation, analogue behaviour and RF; run everything else on CARME.
Full-system emulation for embedded and silicon teams
For silicon teams
Software ready when the silicon is
RTL in the loop
HDL and firmware, tested together
Lumina integration
One flow from RTL to running firmware
Testing and CI
Every test, every board, every commit
Boards and SoCs
250+ boards and SoCs, ready to boot
CPUs
Arm, RISC-V, SPARC, Power, x86, Xtensa, MSP430, TriCore
Peripherals
650+ register-exact models