Command line tool

Flash in your terminal.

The Flash platform as a command-line tool. Point it at a firmware project and generate, build, and debug for your exact board — without leaving the shell.

$ curl -fsSL https://flash1402225.gitlab.io/flash/install | bashmacOS · Linux · WSL

flash — ~/Projects/Firmware/esp32-sdk-c

Flash

Normal

add a BME280 driver over i2c and log temperature every 2 s

plan

1resolve BME280 · datasheet from cache
2add component bme280 — i2c driver + 2 s sampling task
3build for esp32c6 · flash · verify on serial

read_datasheetBME280 · Bosch Sensortec ➔ addr 0x76 · i2c · 8 regs

write_filecomponents/bme280/bme280.c +148 −0

Allow edit? components/bme280/bme280.c

yes, and don't ask again for this file
yes, once
no, tell Flash what to do differently

↑↓ move · ↵ confirm · esc deny

esp_err_t bme280_init(i2c_port_t port, uint8_t addr)

ESP_RETURN_ON_ERROR(i2c_master_probe(port, addr, 50), TAG, "probe");

xTaskCreate(bme280_task, "bme280", 3072, NULL, 5, NULL);

build_firmwareidf.py build ➔ ok 42.6 s · 102 KB / 4 MB

read_serialusbmodem1101 · 115200

I bme280: 24.8 C · 41 %RH

driver added, built and verified on the board

~/Projects/Firmware/esp32-sdk-c ψ feature/bme280*

!bash/commands@files

qwen2.5-coder:7b

PROJECT

ESP32-C6normalized

Core

Architecturerisc-v

MCUESP32-C6

Board—○ unset

CPU freq160 MHz

Memory

Flash4 MB

RAM512 KB

External RAM—○ none

Software

OSfreertos

Frameworkesp-idf

Toolchainriscv32-esp-elf-gcc

Capabilities

wifible802.15.4low-power

[r] recollect[c] copy[e] export[↵] details

The Flash TUI — switch between Project, Build, Debug and Settings; click the active tab to collapse the panel. Detected context is illustrative.

What it does

Reads your project context

Schematics, datasheets, SDKs, existing code, and build logs become deterministic hardware context the agent can reason over.

Generates for your exact board

Pins, buses, peripherals, clocks, and constraints — mapped to your SDK version, build system, and project structure.

Closes the build–debug loop

Flash reads compiler output, runtime errors, and debug logs, then iterates without you pasting errors into a new prompt.

Local, private, or hybrid models

Run entirely on local models inside your security boundary, or route to cloud models when you choose — your call, per task.

Scriptable and CI-friendly

A plain command-line interface composes with your shell, Makefiles, and pipelines — no GUI in the loop.

Keeps project memory

Context persists across bring-up, integration, and debugging instead of starting from zero every session.

In the session

Command	What it does
`/init`	Index the project, detect the platform and write FLASH.md
`/model · /provider`	Pick the brain — local runtime or cloud provider, per session
`/mode`	Interaction mode: normal, plan, teach, debug
`/build · /debug`	Open the build or the serial/MQTT panel next to the chat
`/peripherals`	Component inventory — add, resolve and attach datasheets
`! bash · @file`	Run a shell command, or attach a file from the visual browser

Why the CLI first

Firmware work already lives in the terminal — build systems, flashing tools, debuggers, and version control. The command-line tool meets that workflow instead of replacing it, so Flash drops into the loop you already run.

It also runs where your code has to: over SSH on a build server, inside a container, or on an air-gapped machine with local models only. Nothing about the interface assumes a connection to a public AI API.

11+
MCU vendor SDKs: 12+
RTOS & embedded platforms: 6
Schematic & EDA formats: 0
Data leaving your network on-prem

How it works

Schematic ingestion

How your board becomes a structured model.

Hardware interaction

The build, flash, and serial-debug loop.

Supported platforms

MCU families, RTOS, toolchains, and EDA formats.

Put Flash in
your shell.

Request a demo Read the docs