When it comes to embedded engineering, toolchains are the worst. Getting a new toolchain up and running correctly is often hard, and often prone to breaking when the IDE or other software is upgraded. A plethora of different toolchains for different hardware makes things even more murky, and if you want to get into time-saving tricks like automated testing, you’re in for a wild ride.
Those pain points led to the creation of the Pigweed project. As Keir Mierle demonstrates in this workshop from the 2020 Hackaday Remoticon, Pigweed is a set of libraries to make working with embedded development more hacker-friendly. The collection is accessed via commandline, and coordinates work with existing libraries to deliver unit testing, linting, static analysis, logging, and handling key-value stores, all alongside more commonly called-for tasks like compiling and flashing.
Demonstrated on a Teensy microcontroller and an STM32 Discovery board, the presentation drives home the utility of Pigweed, a Google project that was released as open source back in March of 2020. Graphical IDEs for these platforms are nowhere in sight, yet test firmware is built and flashed to these devices with relative ease. Unit testing, traditionally a sticky subject for on-chip applications, is demonstrated both emulated on the computer side, and running on the boards themselves. As the capabilities of microcontrollers have ballooned in recent years, writing tests for existing functions and confirming them during new development is becoming a must-have in your skillset.
There’s much more shown off here, so grab the workshop repository to follow along. It’s still considered experimental, and the irony of having to learn the intricacies of the Pigweed toolchain to ease the pain of other toolchains is not lost on us. However, most people reading will have their own affinity for the ability to use unified tools and commandline automation; this is a fascinating way to deliver a number of powerful software development techniques to low-level hardware projects.
Their method of “bootstrapping” pigweed
pw_env_setup is our compromise solution for this problem that works on Mac, Windows, and Linux. It leverages the Chrome packaging system CIPD to bootstrap a Python installation, which in turn inflates a virtual environment.
Not complicated at all.
I honestly have a hard time understanding what problem this solves, and how deploying a rube goldberg machine instead of using make is any easier.
How does one use make to run automated unit tests on embedded hardware? Please provide details.
5 minutes in and I had no idea what they were trying to do?
Part of why embedded development is so far behind seems to be embedded programmers have so much difficulty explaining INTENT. If you can’t tell me in 30 seconds what you are doing – you’ve already messed up.
platformio?
That’s what I thought too.