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.
The first generation ran on an RP2350 paired with the same FPGA approach; v2 moved to the STM32 for its Ethernet MAC and SPI bandwidth while keeping the same board footprint and the same clean split: the MCU does protocol and policy, the FPGA does timing.
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.