I often say the ‘product behind the product’ is the tester used for quality-checking a hardware product. Reputable factories will test 100 percent of every product shipped, and the more complex a product, the more complex the tester. Without an automated tester, confirming every solder joint quickly becomes an error-prone exercise in tedium, even for a run of a couple of dozen boards for an art or hobby project meant to be shared among friends.
Surprisingly, there is no convention for dealing with even the most common issues facing the production of simple IoT-style devices, such as loading firmware, testing radios, and checking all the GPIOs are wired up correctly. Time and time again, I had found myself frustrated because I was spending more time writing test code than I was building the product itself. Sean ‘xobs’ Cross, was similarly frustrated when developing the test programs for projects like Novena (hsmag.cc/vMblMf) and Chibitronics (chibitronics.com), so he created a testing infrastructure called Exclave (hsmag.cc/xBVSgP). The idea behind Exclave is to create a standardised tool for stringing together sets of small POSIX-compliant scripts that can be quickly and safely rearranged to accommodate various production testing scenarios.
By relying on small scripts that can be written in any language, Exclave makes it easier to reuse the single-purpose scripts inevitably written during board bring-up for debugging and validation of point features. By creating a system that defines dependencies between the scripts and wrapping them into scenarios, Exclave makes sure that important tests don’t get accidentally skipped or commented out as the overall test flow is optimised for production throughput.
I’ve used Exclave to develop testers for about a half dozen products and, despite its rough edges, Exclave has shaved months off product development cycles. Exclave enables me to quickly build production testers for even fun art projects meant to be shared only among a few friends. While Exclave can run on any POSIX-compliant OS, I usually just install it on a Raspberry Pi and take advantage of the native GPIOs to handle most of the tasks, from uploading firmware over OpenOCD, to testing GPIOs, to driving simple ADC/DACs on a Pi HAT to verify analogue signals. If you’re considering building more than a few of anything, I encourage you to take a look at this freely available, open-source project. For a more detailed look at designing and running a test jig, take a look at my blog on the subject: hsmag.cc/rXxUtU