Model in. Firmware out.

Edge Impulse is end-to-end (data + training + deployment) but biased toward their cloud and a curated subset of boards. STM32Cube.AI deploys to STM32 only. TFLite-Micro is a runtime, not a build tool — you wire the toolchain yourself. Darml is the missing piece: bring-your-own-model, span every reasonable target, one CLI. If you've already trained your model and don't want to live inside any vendor's ecosystem, that's the gap Darml fills.

We picked one board per performance tier — Cortex-M4 (stm32f4), Cortex-M7 (stm32h7), M55 + NPU (stm32n6); Arduino Uno-class (avr-mega328) and Mega-class (avr-mega2560) — rather than enumerate every variant. The full STM32 family has hundreds of chips (F0 / F1 / F3 / G0 / G4 / L0 / L4 / L5 / U5 / WL / WB / MP1 / N6 …) that differ in core, FPU presence, peripherals, and memory layout, so each one needs a verified runtime template and CI build, not just a board-ID change. We add on demand: open an issue with chip + dev-board name and we'll prioritize.

Yes. The output is a standard PlatformIO project (for MCU targets) or a Dockerfile + Python script (for Linux targets). No precompiled blobs, no obfuscation. The C/C++ glue is generated from templates you can read in the source tree (darml/infrastructure/templates/). Inspect, diff, fork as you want.

On the free Core tier, no — every build runs locally. On Pro Cloud, your model is uploaded to our build farm (EU/Frankfurt), held only for the duration of the build, and deleted when the artifact is downloaded. On Pro Self-Hosted, the entire stack runs in your network; nothing ever leaves.

We do post-training quantization (PTQ) only — no quantization-aware training, no fine-tuning, no knowledge distillation. Expect 1–3 % accuracy drop for dense networks, 3–8 % for typical CNNs, 5–15 % for larger CNNs without per-channel calibration. The verified-builds matrix above includes an inference roundtrip test (FP32 vs INT8) that asserts argmax-stable on ≥ 80 % of samples — if your model deviates more than that, the test fails loudly. Bring your own calibration data via --calibration-data for tighter results.

Yes. Darml auto-detects already-quantized .tflite and .onnx (QDQ format) inputs and skips its own quantize step — you'll see a "Model is already quantized; skipping." warning, then convert / compile / package run normally. If you've done QAT or your own PTQ with real calibration data in your training pipeline, hand us the result and we deploy it as-is. The free Core tier is enough to ship if you quantize upstream.

The runtime libraries we wrap (TFLite Micro, emlearn) have been used in regulated environments, but Darml itself is not certified. For functional-safety pipelines, the path is: use Pro Self-Hosted (for traceability), pin a Darml release, and keep the generated code under your normal change-control process. Talk to hello@darml.dev if you need a signed reproducibility statement.

A counter in ~/.darml/counter increments when a build hits the compile step. Failed pre-flight checks (won't-fit) don't count. Rolling 24-hour window. The cap exists to keep the free tier sustainable, not to gate features — every target, every model format, every architecture is available on Core.

Core is genuinely free software — fork it, ship it, sell derivatives, no strings. Pro contains the parts that take real ongoing work to maintain (auto-quantization across formats, ONNX→TFLite conversion, hosted build farm, license signing). Selling Pro is what funds Core. Standard open-core.

Core stays MIT — fork it, run it forever. Pro Self-Hosted licenses are HMAC-signed and validated locally; they keep working as long as your existing key hasn't expired. The license verification code is in the public Pro client, so you can audit it. We don't phone home.