Hardware tests, no jumpers

Why this conversation

Automated tests are only as good as the hardware they run on, and in embedded work that hardware is expensive and takes up space. Franklin Cooper Jr. has spent over 15 years at Texas Instruments on embedded software, contributing to open source projects from the Linux kernel to U-Boot and Yocto, and is now joining the Zephyr team. The host met him in front of the Texas Instruments booth on the Thursday morning of Open Source Summit Europe in Prague, on the day of his talk about a low-cost FPGA for hardware testing. The rest of that week is in Open Source Summit Europe 2026: who we met.

This is a short conversation, about five minutes, built around one idea.

The problem: hardware is the limit

As people want to do more with AI, Franklin says, the team found that testing is very important. But testing real peripherals needs real equipment, and you are constrained by both cost and space. His example: you may want to test a peripheral with a $400 tool, but if your board has four instances of that peripheral, you are not going to buy four of those tools. The alternatives are to reconfigure the wiring by hand between runs, or to buy far more equipment than the budget or the bench allows.

WireWeaver and an off-the-shelf FPGA

His answer is to let an FPGA do the rewiring. The FPGA routes the signals from whichever instance is under test to the one tool, which saves cost and space and makes testing easier. The solution is a Python script he calls WireWeaver, together with an off-the-shelf FPGA.

Asked which reference hardware a developer should buy, he says he will always recommend TI hardware, but the approach is agnostic. He built it as a contribution to the open source community, and it works with any microcontroller or processor that fits a company’s needs.

It is deliberately small. He did not want a large framework tied to one software stack. You provide a file that describes the routing, and it routes your connections. In Zephyr that means using it with Twister and pytest; it also works with TI’s low-level SDK, with MCAL, or with Linux. It is a building block for whatever test setup you already have.

Test what you ship

The host asked whether this means a developer can start with a development kit and scale up to bigger systems. Franklin’s point is about what gets tested. Software developers do not necessarily want to test on a custom test board; they want to test exactly what is about to ship. Whatever boards you are working on, you can connect them to this setup, so there is a one-to-one connection between what you test and what you ship, with less friction in between.

Upstream first

Franklin closes with Texas Instruments’ approach to open source: an upstream-first mentality, from Linux to Zephyr, contributing to the community first before going back to the downstream work. He is excited about what his team is doing on the Zephyr side.

His conference presentation is public and, he believes, recorded. The code is on GitHub under his account, at github.com/fcooper/wireweaver, alongside his other repositories.