> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adsumnetworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Why it exists

> Embedded firmware work is two jobs at once. General coding agents help with neither, because both live outside the source file.

Embedded firmware work is two jobs at once: a lot of routine, repetitive setup, and a handful of genuinely hard problems. General coding agents help with neither well, because both live outside the source file.

## The routine you would rather automate

Scaffolding a project, wiring devicetree and Kconfig, generating logging, adding a BLE service or a sensor, writing tests, bringing up a new board. Tedious, easy to get subtly wrong, and a steady drain on the day. Adsum does this work for you, idiomatically, on both ESP and nRF, so you spend your time on the part that is actually yours.

## The hard bugs you cannot grep

The failures that cost real days do not show up in the source:

* A missing `settings_load()` after `bt_enable()` compiles fine, connects fine, and silently breaks GATT notifications after the first reconnect.
* An ESP-IDF partition or flash-config mismatch that builds cleanly and only fails at runtime.
* A Central/Peripheral connection-parameter mismatch that only surfaces when you correlate timestamps across two separate log streams.
* A BLE peripheral that pairs cleanly under test but drops bond state every cold boot because `CONFIG_BT_SETTINGS` is set without flash storage backing it.

None of these are in the file you are staring at. Adsum reads the device, captures the live logs, and works them the way a senior engineer does.

## The part general agents do not have

Why it is good at the hard parts is real human expertise. Adsum is augmented with expert-reviewed firmware knowledge, curated by engineers who have shipped it, loaded on demand and validated against an open benchmark on real hardware. That is the difference between an agent that guesses and one that knows. See [how it works](/architecture).

## What working the firmware dev loop needs

| Pillar                                   | Today                                                                                                          | Roadmap                                                             |
| :--------------------------------------- | :------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------ |
| **Native SDK integration**               | nRF Connect SDK (Zephyr) and ESP-IDF: build, flash, monitor, board-aware project assessment                    | Older NCS LTS, more ESP-IDF coverage                                |
| **Hardware-in-the-loop instrumentation** | Live RTT/UART capture (nRF) and serial-log capture (ESP), J-Link control, multi-device capture and correlation | BLE sniffer, power profiling, spectrum analysis                     |
| **Expert-reviewed firmware knowledge**   | BLE and Wi-Fi stacks, NCS/Zephyr and ESP-IDF internals, board specifics, curated failure-mode libraries        | Thread, Matter, LTE-M; power-budget and protocol-correctness review |
| **Tool-use skills for the whole loop**   | prototype, add-feature, test & validate, build/flash/debug, log generation and analysis                        | More workflows as protocols and tooling land                        |