Bringing up a new embedded device has traditionally followed the same sequence: read and understand the datasheet, translate it into the device’s register maps, prototype on a breadboard or a starter kit, get the compiler and libraries in place for an initial build, and only once that setup is ready begin the real work of writing code, building it, flashing it and validating the behaviour on the bench.
For a developer bench-top board with multi-bus communication across SPI, I2C, UART and GPIO, that sequence typically takes an experienced team 16 to 24 weeks, and most of that time goes on setup and on finding the faults that only appear on real silicon, rather than on the firmware itself.
The timeline is conventionally dominated by:
Translating register maps from datasheets into peripheral initialisation drivers.
Manually wiring the test harness and configuring instruments.
Writing ad-hoc test scripts that break whenever the pinout changes.
Chasing silicon-dependent race conditions and power transients that software-in-the-loop simulation cannot detect.
Bringing up the signal acquisition gateway tested an alternative workflow: replacing manual bench bring-up with Synapsio, the agentic firmware workbench Better Devices builds and operates, end to end, and the time to bring up the device dropped from weeks to days. Synapsio is an internal closed-loop platform that uses LLM-driven agents to automate firmware synthesis, physical device flashing and time-correlated measurement, with an engineer reviewing and approving each stage before it reaches hardware.
The complete firmware implementation, functional bring-up and automated HIL regression suite were completed in fourteen calendar days.
The gateway board integrates:
The bench consists of three primary subsystems:
The host machine running Synapsio and the compiler and programmer toolchain.
The simulation and instrumentation bridge running the logic analyser, mixed-signal scope, and programmable stimulus channels.
The device running firmware for the gateway.
Rather than relying on unconstrained LLM outputs, Synapsio strictly isolates non-deterministic reasoning (planning) from deterministic hardware execution: compilation, flashing, and electrical measurement.
The engineer supplies a single input, the test intent, which describes how the device should behave:
For the gateway, the intent was: “Perform loopback test using DMA ring-buffer integrity, and timing validation across SPI1 and UART2.”
From that intent, the Synapsio agent workflow plans the work, picks the parts, drafts and checks the wiring, confirms the wire harness on the test bench, writes the test plan, generates the firmware, flashes the device, and runs the tests on the bench. The first seven stages are described below; the eighth, where the captured trace is reconciled against the plan, has a section of its own.
The agent workflow parses the test intent into register addresses, timing constraints, and pinout definitions based on the device datasheet, then generates two parallel artifacts:
Firmware Plan: Peripheral setup, register configurations, interrupt management and handlers.
HIL Test Plan: Expected signal timelines, stimulus patterns, voltage threshold limits (0.0 V to 3.3 V) and timeout tolerances.
Working from the plan, Synapsio selects the components the bench needs and drafts the wiring between the device, the instrumentation bridge, and the stimulus channels. The draft is checked against the device’s pinout and electrical limits before anything is connected: logic-level compatibility, bus loading, and channel-to-pin assignments are all validated at this stage.
Once the physical wire harness is ready and approved, Synapsio confirms it matches the drafted wiring. Continuity and pin-mapping checks run through the instrumentation bridge, so a swapped pair or a missing connection is caught before any firmware is flashed. Because the harness is declared in YAML rather than hard-coded into test scripts, a pinout change is only an update instead of a rewrite.
With the harness confirmed, the HIL Test Plan from Step 1 is finalised into executable assertions: which stimulus to inject on which channel, what the captured trace must show, and within what tolerance. The plan is fixed before the firmware is written, so the firmware is validated against an independent specification rather than against its own behaviour.
Synapsio writes the device firmware and immediately pipes it through the cross-compiler with strict linting flags.
If a syntax error, register naming mismatch, or type issue occurs, the compiler diagnostic output is fed back into the agent loop.
The agent refactors the code automatically until a clean firmware image is generated. No unverified binary ever touches physical silicon.
The firmware is flashed to the device, the board is reset to a clean power state, and Synapsio confirms the device has come up correctly before stimulating any I/O.
Synapsio drives the planned stimulus into the device on real silicon and captures the electrical response, logic levels, timing and voltage, on a microsecond timeline.
Synapsio evaluates the captured physical trace against the formal test plan:
If the captured physical behaviour matches expected parameters within tolerance, the test passes. If an anomaly occurs, Synapsio pairs the exact timestamped signal trace with the relevant line of firmware for developer inspection.
The gateway bring-up was benchmarked against comparable internal controller projects executed using standard manual bench workflows.
6–8 Weeks
6 Days
4–6 Weeks
4 Days
6–10 Weeks
4 Days
16–24 Weeks (4–6 Mo)
14 Days (2 Wks)
Software-in-the-loop simulation runs in idealised environments where peripherals respond instantly and power rails never fluctuate. Synapsio’s physical signal capture isolated two faults that would have escaped SIL.
The SPI and UART buses were both active at the same time. The interrupt handling for one kept the other waiting for 12 microseconds, long enough for a single byte to be lost from the UART buffer. Every software test had passed this code. On the bench, Synapsio’s timeline assertions caught the missing byte, showed the exact moment it happened, and pointed at which handler was running. The fix was in the NVIC priority grouping, and it took an afternoon once the timeline showed where to look.
This is the interrupt design that passed engineer review. It compiled clean, it read correctly, and it was correct as long as only one bus was busy. Under contention it lost data. A software test would have passed it. The bench caught it on the first run.
Simultaneous switching of multiple GPIO lines caused an instantaneous 210 mV drop on the board’s internal 3.3 V rail, breaching the minimum input threshold (VIH) of an adjacent sensor transceiver.
On most boards this is a reliability fault. On a signal acquisition gateway it is a correctness fault: a measurement device whose own rail dips when its GPIOs switch would report clean signals as marginal, and nobody would know why. This was a hardware decoupling limitation, not a firmware defect, and no firmware test would normally find it. It was caught because the scope was on the rail during a firmware test, and it was fixed before layout freeze rather than after a respin.
Building dedicated HIL infrastructure internally is often bottlenecked by the requirement for specialised test engineering talent.
Synapsio is built and operated by Better Devices, embedded engineering consultancy, Berlin.