llms.txt
# 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.
- [Now](https://veecle.ai/now): What we are working on right now, plus press, podcasts, and announcements.
- [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
- [Zephyr's Twister hardware map is a YAML file, not a product](https://veecle.ai/blog/zephyr-twister-hardware): The zephyr twister hardware map is 67 lines of schema and three CLI flags at v4.4.1. Every HIL-at-scale talk re-derives primitives Zephyr documented years ago.
- [RTT vs SWO vs UART: choose the constraint, not the tutorial](https://veecle.ai/blog/rtt-vs-swo-vs-uart): RTT vs SWO vs UART vs semihosting: the only four-way writeup is a SEGGER blog that gives UART one sentence. Everyone else copies the last tutorial.
- [Your rust embedded unit test runs on the host. The Book barely mentions it.](https://veecle.ai/blog/rust-embedded-unit-test): A rust embedded unit test on the host is Zephyr unit_testing, not native_sim. probe-rs runs the on-device harness. The Embedded Rust Book has one bullet.
- [Stop grepping Renode stdout. It already ships a test runner.](https://veecle.ai/blog/renode-robot-framework): Renode ships a built-in test server, a keyword library, and renode-test for the point where Monitor scripts grow assertions, timeouts, and reports.
- [A firmware instruction trace is not code coverage](https://veecle.ai/blog/firmware-instruction-trace): A firmware instruction trace is a list of addresses. Turning it into line coverage takes DWARF and renode-retracer, which emits LCOV DA only, not MC/DC.
- [Espressif already published the QEMU ESP32 limitations list](https://veecle.ai/blog/qemu-esp32-limitations): Espressif's QEMU matrix marks WiFi, Bluetooth, USB, RMT, I2C, I2S and ULP unsupported. The qemu esp32 limitations are already in that README.
- [The LLM wrote the skills. The ESP-IDF score went down.](https://veecle.ai/blog/llm-embedded-benchmark): IoT-SkillsBench dropped ESP-IDF from 31/42 to 27/42 with LLM-written skills. Human-written skills hit 41/42 on the same llm embedded benchmark.
- [You cannot simulate MCU power consumption. You can only measure it.](https://veecle.ai/blog/simulate-mcu-power-consumption): Every tool that actually measures MCU power consumption needs a probe on silicon. Simulation will still give you a number. That number is not a measurement.
- [native_sim is not a unit test. Zephyr had to write that down.](https://veecle.ai/blog/zephyr-native-sim): Zephyr native_sim and unit_testing both run on the host. The docs say they are fundamentally different, because people still keep mixing them up.
- [CMock is not a simulator. The STM32 HAL keeps proving it.](https://veecle.ai/blog/mocking-stm32-hal-unit-test): A mocking STM32 HAL unit test checks your call contract, not the chip. The October 2025 CMock header-chain thread is still the same 2017 mix-up.
- [Firmware fuzzing in emulation works. Now you trust a peripheral model.](https://veecle.ai/blog/firmware-fuzzing-emulation): Firmware fuzzing emulation is real: P2IM, HALucinator, Fuzzware, Renode and AFL++. Delete the chip and the peripheral model becomes the thing you have to trust.
- [MC/DC is not branch coverage with extra steps](https://veecle.ai/blog/mcdc-coverage-embedded): MC/DC coverage for embedded asks whether each condition moved the outcome. Branch coverage never does. For a && b that is three tests, not four.
- [Embedded simulation cost: published prices stop where the checkout stops](https://veecle.ai/blog/embedded-simulation-cost): Embedded simulation cost is public at the bottom and quote-only higher up. Public evidence points to the buying motion, not a clean fidelity threshold.
- [RTOS trace in a simulator: the format was never the hard part](https://veecle.ai/blog/rtos-trace-simulator): RTOS trace in a simulator is a transport problem. Zephyr CTF over UART reached Renode capture, mixed into combined stdout, not a decoder-ready file.
- [ESP-IDF 6.0 did not remove one thing. It removed four different things.](https://veecle.ai/blog/esp-idf-v6-migration): The ESP-IDF v6.0 migration is four fates wearing one word. Nine legacy drivers are gone, but legacy I2C still compiles with an end-of-life warning until v7.0.
- [Arm has its own simulator. Here is what it actually models.](https://veecle.ai/blog/arm-fvp-vs-qemu-renode): Arm ships its own Cortex-M simulator, Fast Models. What an FVP models, what it refuses to, and how it compares to QEMU and Renode for real firmware work.
- [SEGGER shipped a simulator. Here's what it does and what it doesn't.](https://veecle.ai/blog/ozone-sim-teardown): SEGGER's Ozone-Sim runs firmware with no probe and no peripheral emulation. A teardown of what that scope actually buys you in CI, and what it rules out.
- [The chip vendors showed up: hardware MCP servers, six months later](https://veecle.ai/blog/hardware-mcp-servers-2026): Arm, Nordic, ADI, Espressif, Microchip, Silicon Labs and TI now ship hardware MCP servers. I found no official server from ST, Infineon or Renesas.
- [MCP went stateless. Some of us are holding a running chip.](https://veecle.ai/blog/mcp-went-stateless): MCP went stateless on 2026-07-28: sessions are gone and cross-call state now rides on explicit handles. That is easy for a cart and hard for a live target.
- [The best AI-firmware diagnoses agree. Their cures don't.](https://veecle.ai/blog/right-diagnosis-wrong-cure): The strongest 2026 writing on whether AI can write firmware converges on the diagnosis. Its proposed cures diverge, and only some have evidence.
- [HIL won't scale to the AI era](https://veecle.ai/blog/hil-wont-scale-ai-era): AI doesn't make the bench obsolete. It makes the work before the bench non-negotiable.
- [Wokwi vs Renode vs QEMU: hobby, professional, and CI tiers of embedded simulation](https://veecle.ai/blog/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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.
- [Why your AI coding agent needs a target to run on](https://veecle.ai/blog/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/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/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
