# Chiplab

> Chiplab is an MCP platform by Veecle that lets AI coding agents compile, simulate, and validate firmware on virtual instances of real microcontrollers (STM32, Nordic nRF) — no physical hardware. One MCP endpoint; the agent uploads an ELF, runs it on the target chip, and reads back UART output, traces, and verdicts.

## Connect

- MCP endpoint: https://chiplab.veecle.ai/mcp (HTTP MCP server, name it `chiplab`; browser sign-in on first use)
- Sign up / sign in: https://chiplab.veecle.ai (free tier, no credit card)
- [Examples repo](https://github.com/veecle/chiplab): ready-to-run firmware examples for every supported board, across bare-metal Rust, Embassy, Zephyr, and FreeRTOS — includes AGENTS.md instructions for coding agents.
- [Supported boards matrix](https://github.com/veecle/chiplab/blob/main/supported-boards.md): every board, chip, board key, and framework example.

## Pages

- [Home](https://veecle.ai/): Product overview — how agents use one MCP endpoint to ship firmware that runs.
- [Chiplab](https://veecle.ai/chiplab): The product in depth — virtual silicon, the MCP verbs (ask, run, build, test, simulate), and the shared corpus.
- [Pricing](https://veecle.ai/pricing): Credits-based pricing with a free daily pool; pay-as-you-do top-ups; enterprise on-prem.
- [Roadmap](https://veecle.ai/roadmap): Eight verbs (ask, run, build, test, bench, simulate, generate, automate) and the chip-family timeline.
- [Blog](https://veecle.ai/blog): Writing from the team on Chiplab, agents, and firmware on real silicon.
- [Now](https://veecle.ai/now): What we are working on right now.
- [News](https://veecle.ai/news): Announcements and updates.
- [About](https://veecle.ai/about): Our story — open-source Rust RTOS and a browser-based embedded IDE feeding Chiplab. Berlin, VC-backed.
- [Contact](https://veecle.ai/contact): Get in touch, request chips or toolchains.

## Blog

- [Wokwi vs Renode vs QEMU: hobby, professional, and CI tiers of embedded simulation](https://veecle.ai/blog/27-wokwi-vs-renode-vs-qemu): These three simulators are not competitors. They sit at different tiers of the same pipeline, and picking between them is a question about what you're doing, not which one wins.
- [We read every "embedded simulator comparison" on the internet. Most are written by resellers.](https://veecle.ai/blog/28-embedded-simulator-comparison-audit): The top-ranking embedded simulator comparison for the query gets Renode's license wrong, and it's published by a company that sells industrial monitors. That's not sloppiness, it's an incentive problem.
- [HIL is a scarcity workaround](https://veecle.ai/blog/29-hil-is-a-scarcity-workaround): Hardware-in-the-loop testing exists because you cannot give every engineer, every PR, and every regression suite its own bench. Most of what runs on HIL rigs today is there because nothing better was available, not because it needs physical silicon.
- [From datasheet to running firmware in one prompt](https://veecle.ai/blog/30-datasheet-to-firmware-one-prompt): I pointed an agent at a board it had never touched, an STM32L073 Nucleo, and asked for clock, UART, and LED bring-up. It worked on the first attempt, and the run log also caught it reading a register that doesn't exist on the virtual chip.
- [Hello world on STM32F4 Discovery with FreeRTOS — no hardware](https://veecle.ai/blog/31-hello-f4-no-hardware): A real FreeRTOS task printing "Hello world!" over USART2 on an STM32F4 Discovery, built with arm-none-eabi-gcc and run on Chiplab with no board on the desk. Full transcript, plus the parts of the board the simulation does not model.
- [Why UART is still the best debug interface in 2026](https://veecle.ai/blog/32-uart-still-wins): UART is the oldest debug interface still in daily use and the one every simulator gets right first. We printed a line over UART on all seven boards Chiplab supports, in one afternoon, and here is what that says about why it survives.
- [EmbedAgent and friends: what the LLM-for-embedded benchmarks actually measure](https://veecle.ai/blog/33-what-llm-embedded-benchmarks-measure): Three papers keep getting cited as if they were one LLM embedded systems benchmark. One scores functional pass rates, one scores whether wrong code was still useful to a human, and the third sits in between. Here is what each actually tests, and the thing none of them touch.
- [Blue Pill in 2026 — the $2 board you can now dev without owning](https://veecle.ai/blog/34-bluepill-2026): A real bare-metal Rust firmware image, run through Chiplab's STM32F103 Blue Pill simulation with no board on the desk, surfaced a genuine corner case in how the HAL crate talks to the chip — and the transcript to prove it.
- [Teach, don't market: our content strategy in public](https://veecle.ai/blog/35-teach-dont-market): The concrete editorial rules behind our developer content marketing strategy: cite primary sources, run real Chiplab instances, admit limitations, skip forced product mentions. And an honest note that it's still marketing.
- ["The code takes minutes. Proving it takes months." — anatomy of a firmware validation cycle](https://veecle.ai/blog/36-anatomy-of-a-firmware-validation-cycle): A stage-by-stage walkthrough of a firmware validation cycle, showing where the time actually goes. Every stage that involves typing takes minutes. Every stage that involves physical hardware takes days to months.
- [What LLMs get wrong about embedded code](https://veecle.ai/blog/05-what-llms-get-wrong): We cold-prompted two models for firmware on three different chips, compiled every answer exactly as returned, and ran the binaries on virtual hardware. Nearly every bug died in seconds, without a board, and the bench got exactly one job: the final sign-off.
- [We ran the same STM32 firmware on Renode vs QEMU: here's what diverged](https://veecle.ai/blog/07-renode-vs-qemu-same-firmware): Renode vs QEMU: the exact same unmodified STM32 hello-world firmware booted clean on Renode and crashed instantly on QEMU with a fatal register dump.
- [Renode vs QEMU for firmware development: what each actually models](https://veecle.ai/blog/08-renode-vs-qemu-what-each-models): Renode vs QEMU comparison: what each simulator actually models, from machine definitions and peripheral fidelity to timing, debugging, and CI fit.
- [The build passed. Why doesn't it run?](https://veecle.ai/blog/09-the-build-passed-why-doesnt-it-run): Compile-green is not works-on-hardware. Most embedded CI pipelines end at the linker, where a wrong UART peripheral compiles clean and stays silent.
- [LLMs write good firmware. They can't prove it.](https://veecle.ai/blog/10-llms-write-good-firmware-cant-prove-it): LLM firmware code generation benchmarks measure output, not execution. EmbedAgent, Englhardt, and Promwad agree: the gap is where firmware breaks.
- [An agent tried to fix a HardFault. There was no HardFault to fix.](https://veecle.ai/blog/11-an-agent-fixed-a-hardfault): I ran a Cortex-M HardFault debugging session on a virtual STM32F4 and got silence instead of a crash. Chiplab doesn't model fault escalation yet.
- [What 'cycle-accurate' actually means (and why you almost never need it)](https://veecle.ai/blog/12-what-cycle-accurate-actually-means): Cycle-accurate simulation has a precise engineering definition, and almost nobody who demands it from your embedded simulator actually needs it.
- [Wokwi alternatives for professional firmware work](https://veecle.ai/blog/13-wokwi-alternatives-professional-firmware): "Wokwi alternatives" mostly answers the wrong question — here''s the real ladder from browser toy to CI gate to an agent-accessible target, rung by rung.
- [E2B gives agents a computer. What gives them a microcontroller?](https://veecle.ai/blog/14-e2b-gives-agents-a-computer): Every AI agent sandbox — E2B, Modal, Daytona, the rest — virtualizes a Linux syscall boundary, and a microcontroller simply doesn't have one.
- [The agent infrastructure map](https://veecle.ai/blog/15-the-agent-infrastructure-map): Search got Exa, memory got Mem0, browser got Browserbase, and compute got E2B: the AI agent infrastructure stack has four filled slots and one empty one.
- [Hardware is becoming an API](https://veecle.ai/blog/16-hardware-is-becoming-an-api): Servers, GPUs, phones, and browsers all got a hardware API and stopped being manual — chips are the one resource that hasn't, and agents are why it's next.
- [Simulation vs HIL: what belongs in CI and what belongs in the lab](https://veecle.ai/blog/17-simulation-vs-hil-what-belongs-in-ci): Simulation vs HIL is a routing problem, not a war. A decision procedure for which firmware tests run in CI on every commit and which wait for the lab.
- [What simulation can't catch, and why it never tells you](https://veecle.ai/blog/18-what-simulation-cant-catch): A field guide to embedded simulation limitations, from two real Chiplab runs where the simulator returned zeros and invented RAM without raising one error.
- [MIL, SIL, PIL, HIL for firmware people](https://veecle.ai/blog/19-mil-sil-pil-hil-for-firmware-people): MIL SIL PIL HIL is model-based-design vocabulary aimed at firmware devs who have no plant model. What each rung runs, and which ones actually matter.
- [QEMU for Cortex-M: what works, what doesn't, and why](https://veecle.ai/blog/20-qemu-for-cortex-m-what-works): QEMU Cortex-M crashed my firmware before main. Renode ran it clean. QEMU was right. What QEMU Cortex-M board support covers, and what to reach for instead.
- [Renode alternatives: what would actually make you switch](https://veecle.ai/blog/21-renode-alternatives): Most pages ranking for "Renode alternatives" are SEO filler. Here is the honest version, by job — including the jobs where you should not switch.
- [Firmware CI ends at the linker](https://veecle.ai/blog/22-firmware-ci-ends-at-the-linker): Most firmware CI stops at the linker. Our own linker script put the stack in reserved memory and still built clean, because nothing in the toolchain runs it.
- [Every chip is an island](https://veecle.ai/blog/23-every-chip-is-an-island): There is no docker run for hardware. Embedded toolchain fragmentation runs ten layers deep, and every partial fix solves exactly one of them.
- [Copilot for firmware is solved. That was the easy half.](https://veecle.ai/blog/24-copilot-for-firmware-is-solved): AI firmware development already writes good code. The bottleneck is that the agent can never run it, so it never finds out that it was wrong.
- [Every hardware MCP server I could find, and what each one actually does](https://veecle.ai/blog/25-hardware-mcp-servers-reviewed): I audited every hardware MCP server I could find. Most wrap a serial port, most need a board on your desk, and almost none can execute firmware.
- [Why we won''t write "Chiplab vs X" pages](https://veecle.ai/blog/26-why-we-wont-write-chiplab-vs-pages): Competitor comparison pages are the highest-converting SaaS content there is. Here is the structural reason Chiplab will not publish a single one.
- [I was on holiday.\u00a0\nMy agent shipped the blog post anyway.](https://veecle.ai/blog/04-agent-shipped-the-post): Our last post argues that coding agents need a target to run on. Here's the receipt. That post, including the firmware run inside it, was produced by an agent while I answered three messages from a deck chair.
- [HIL won't scale to the AI era](https://veecle.ai/blog/06-hil-wont-scale-ai-era): AI doesn't make the bench obsolete. It makes the work before the bench non-negotiable.
- [Why your AI coding agent needs a target to run on](https://veecle.ai/blog/03-why-your-agent-needs-a-target): Coding agents work because they can run what they write and read the result. In embedded, that loop stops at the hardware. Here's the mechanism behind why, and what closing it takes.
- [Getting started with Chiplab: run firmware without the hardware](https://veecle.ai/blog/02-getting-started-chiplab): Connect your agent, run firmware on a simulated STM32F4, then port it to a board you don't own — about fifteen minutes, start to finish.
- [Chiplab demo: from MCP setup to a validated run on real hardware](https://veecle.ai/blog/01-chiplab-demo): Watch our Chiplab demo — set up as an MCP, build a new chip target, and validate on real hardware.

## Quick start (for agents)

1. Add the MCP server `https://chiplab.veecle.ai/mcp` to your MCP client config.
2. Call the discovery/help tool with no arguments for the current tool set and chip-specific gotchas.
3. Clone https://github.com/veecle/chiplab, build an example ELF, upload it, run it on the matching board, read the captured UART output.

## Optional

- Full text of this site in one file: https://veecle.ai/llms-full.txt
- [Privacy](https://veecle.ai/privacy)
- [Terms](https://veecle.ai/terms)
- [Imprint](https://veecle.ai/imprint)
- Community: https://discord.com/invite/F6GwZJ6ktP