Embedded teams end up with a bench full of equipment that is hard to share, hard to automate, and difficult to use remotely. A power supply, a logic analyzer, a debug probe, a UART adapter, maybe a scope and a signal generator — each with its own cables, its own quirks, and a physical location that is almost always not where your CI runner lives. The moment a test needs real hardware, it stops being something CI can do and becomes something a person has to do at the bench.
The BenchPod is our answer to that problem: a single networked box that collapses the instruments around a device-under-test (DUT) into one device your tests can drive over the network.
What it does
A BenchPod sits between your CI and a target board and exposes the operations a hardware test actually needs:
- Programmable power control — switch the target on and off, power-cycle it, schedule a delayed power-on, and monitor current and voltage per rail. Power is gated through electronic eFuses, so a misbehaving DUT can't take the bench down with it.
- Flashing over SWD — the pod is itself a network-attached debug probe. It drives an OpenOCD backend through the pod to flash and debug an SWD target, so swapping
stm32f4x.cfgforstm32h7x.cfgornrf52.cfgis all it takes to support a different board. - UART capture and console — sample the DUT's serial output to assert on its boot banner, or hold an interactive console session and drive the firmware's command interface live.
- A logic analyzer with 12 bidirectional channels — observe and drive GPIO, and decode bus traffic (I2C today) so you can assert what the firmware actually did on the wire, not just that it booted.
- Sensor emulation — the pod can pretend to be an I2C sensor (a BMP280) on two channels while you capture UART, so you can test how firmware behaves with and without a peripheral present, without soldering anything.
- A 16-bit analog front-end — a 1 MSPS ADC with a ±30 V input range and a 16-bit DAC, with an on-board calibration relay so the pod can validate its own DAC-to-ADC path. That turns the pod into a programmable signal source and a measurement instrument, not just a digital tool.
Everything is reachable over the network from a JSON API, a Python SDK with a pytest plugin, an MCP server for AI agents, and the EmbeddedCI cloud.
What's inside
The v2.0.0 BenchPod is a two-(plus)-chip design that keeps the timing-critical work close to the hardware:
- An STM32H563 microcontroller runs the firmware: networking (native Ethernet via an on-board PHY, plus Wi-Fi through an ESP32-C3 acting as a dumb NIC), the command server, and the orchestration logic.
- An iCE40 UltraPlus FPGA with 8 MB of PSRAM owns the fast, deterministic work: logic-analyzer capture, ADC/DAC streaming, and the SWD bit-banging used for flashing. The microcontroller sends high-level commands ("capture 4096 samples", "flash this target", "drive the DAC"); the FPGA does it at the sample-rate clock without the CPU in the loop. Captures stream straight into the PSRAM rather than a small on-chip buffer, so a single recording can run from a short high-rate burst up to millions of samples — several seconds of analog or logic capture — with the MCU reading it back afterward over its high-speed bus.
That split is the thing to hold on to: the MCU does protocol and policy, the FPGA does timing. The STM32 was chosen for its Ethernet MAC and the SPI bandwidth needed to move captures off the FPGA quickly.
Why a box, and not a rack
You could build all of this from separate instruments. Plenty of teams have. The difference is what happens next:
- It's shareable. The pod connects out to the network, so the bench in one office can be driven by a runner — or an engineer — anywhere. The hardware stops being tied to one desk.
- It's automatable. Every operation is an API call, which means it's a test step. There's no GUI to click and no instrument to manually arm.
- It's reproducible. Power sequencing, flashing, and capture happen the same way every run, because the pod does them — not a human remembering the order.
That's the whole point of the BenchPod: take the parts of embedded testing that only work on real hardware, and make them as easy to put in CI as a unit test. For the practical version of that — wiring a DUT, flashing it, and asserting on UART from pytest — see Why Hardware CI Needs Real Devices and Running Hardware CI with GitHub Actions.