After originally building and deploying the Particle firmware code from my desktop,
I wanted to get proper CI/CD put in place for it.
Creating a custom build
wrapped around the
let me do nice things like excluding test code from firmware compilation.
Creating a custom upload
(yeah yeah) let me solve one part of Particle’s aggravating approach to versioning:
firmware has a
that must be defined at build time and then provided at upload time, even though it’s also encoded in the binary.
My script scans the source file for the definition of
and uses that to formulate the right API call.
It’d still be nicer if this could all be more free-form (e.g. allow for
commit SHAs as a version ID) but this makes it at least somewhat less painful.
Side note: You’ll still see various one-off “whoops, I forgot to increment the PRODUCT_VERSION” commits in the codebase. Eesh.
I don’t write a lot of test code, but when I do, I have to mock stuff out.
The firmware tests are primarily to test the setpoint scheduler
as well as minor primitives like the queue type
underlying all reporting back to the cloud.
Since this is C++, I chose
as the test harness and it’s been lovely.
I stood up a whole bunch of mocks
for all the stuff provided by the Particle environment that either I needed to control (like time) or just needed to be able to compile.
It’s a little surprising that there isn’t already a ready-to-go version of this sort of stuff provided by Particle themselves.
Since I’d previously made
available from the Flatbuffers exercise, it was easy to compile and run this code as part of CI/CD
using yet another custom test
— easier than doing it in
I don’t think I actually caught any bugs in the firmware code with these tests but I do feel a lot better knowing this complex bit of logic
does have decent test coverage since — unlike with just about all the other code which really just transports data from here to there —
the scheduler logic would fail in more subtle ways, particularly in ways that may lead to angry housemates.