Embedder
PlatformWhite paper

Command Line Tool

Product

Overview

The Embedder CLI is a hardware-aware coding agent that lives in the terminal. It runs the same engine as our IDE and VS Code surfaces, so you get the datasheet-grounded reasoning, the closed-loop hardware verification, and the full catalog of 500+ MCUs, 3,000+ peripherals, and 30+ test equipment integrations, only now it shows up where firmware teams spend their time anyway: shells, Makefiles, scripts, CI runners, and SSH sessions into lab machines.

Why CLI

Firmware shops run on scripts. Build, flash, log, repeat, usually from a terminal and often over SSH to a lab machine wired to real hardware. The CLI just puts the agent there too. Pipe a log file in and get a root cause back out; kick off a regression sweep across a board farm from a single command; run the exact agent your engineers use locally inside your CI runner. There's no port to a different model and no separate inference path.

What the CLI does

The agent runs the full firmware loop (build, flash, test, debug) inside a single controlled session:

  • Ingest. Datasheets, reference manuals, errata, schematics, and the existing codebase become a queryable index the agent reasons over.
  • Plan. Specification-first mode. The agent drafts an implementation plan with citations from the datasheet before writing code. You review, then it executes.
  • Generate. Drivers, init sequences, HAL code, HIL test cases, written against the actual part. Native support for FreeRTOS and Zephyr; first-class Nordic, STMicro, NXP, Infineon, Espressif, TI.
  • Build & flash. Your existing toolchain (CMake, PlatformIO, west, vendor IDEs) driven from the agent loop, with results piped back as evidence.
  • Run on real silicon. Drive boards over JTAG/SWD via J-Link, ST-Link, and OpenOCD; an integrated serial terminal captures UART output and feeds it into the loop.
  • Debug. Ingest serial logs, GDB state, core dumps, and logic analyzer captures; cross-reference against the indexed docs to point at the offending line.

In CI

It's the same binary inside GitHub Actions, GitLab CI, and Jenkins. A setup we see often: every PR builds the firmware, flashes a board in your lab, runs the regression suite through the integrated serial terminal, and posts results back to the PR. When something fails, the agent reads the trace, points at the offending line, and proposes a fix.

Headless and lab workflows

The CLI runs over SSH, inside containers, and inside air-gapped networks with on-prem model hosting. In the air-gapped configuration it carries zero external runtime dependencies. So if your board farm sits in a locked cage and your team is scattered across time zones, this is how they reach it.

Who it's for

  • Teams with strong existing tooling. You've already poured years into scripts and Make; the CLI plugs into them rather than asking you to start over.
  • Platform and infra engineers who want agents running inside CI, build farms, and test orchestrators.
  • Remote and lab-based work, wherever the board sits in one place and the engineer in another.

Getting started

We provision and onboard access ourselves, configured against your toolchain, your boards, and your CI. To get the CLI running in your environment, book a call and we'll walk through a setup against one of your real boards.