Skip to main content
Chiplab boots a virtual instance of each supported chip on open simulation platforms — today that means Renode, with QEMU and more support planned as coverage grows — and captures the UART output for you to read back.

​
OS / frameworks

Chiplab runs the same firmware pattern across five OS/framework combinations:
  • bare-metal — vendor-HAL / direct-register Rust firmware (no async runtime).
  • embassy-rust — the same firmware on the Embassy async runtime.
  • zephyr-os — the same firmware on the Zephyr RTOS (C, built with west).
  • freertos — the same firmware on the FreeRTOS kernel (C, built with make + arm-none-eabi-gcc).
  • threadx — the same firmware on the Eclipse ThreadX kernel (C, built with make + arm-none-eabi-gcc).

​
Board matrix

Every board Chiplab supports today, its chip, and its board key — the identifier your MCP client passes when starting a run. A checkmark links to a ready-to-run example for that OS/framework (— = not available yet). The canonical copy of this matrix lives in supported-boards.md; if the two ever diverge, that file is authoritative. Call Chiplab’s discovery/help tool (ask) to confirm the current, authoritative set of boards — it may be ahead of what’s listed here.

​
What simulation covers

Each run includes:
  • CPU execution of your ELF binary.
  • UART/USART/LPUART peripherals — all output is captured and returned in the run’s output.
  • Peripheral registers and interrupt timing matching the physical chip.
Runs are bounded to a fixed amount of virtual CPU time (not wall-clock time).

​
Don’t see your chip?

Please don’t hesitate to ask — requests really do shape what we add next. Open a request on GitHub with your target MCU and use case, and our team will review it — or come say hi on Discord.