Coming from a software background and having moved into embedded, I’ve been surprised how many firmware teams I’ve contracted/consulted to in the past who don’t do any CI and don’t always see a lot of value in it. Can feel 10ish years behind a lot of other software practices.[*] So thanks for writing this, @fbo.
Beyond setting up automated builds, which are not that different to setting up automated builds for “big software”, the next thing I see embedded engineers often struggle with is structuring their code so it’s possible to run meaningful tests on the host. In case you’re looking for encouragement for new blog post topics. ;)
[*] Insert joke about how still writing everything in C is 25 years behind a lot of other software practices.
@projectgus - This is my experience as well. I’d go one step further: forget CI, embedded teams often don’t use a version control system, or do code review (which I see as another run down the ladder from CI in terms of eng. sophistication).
For teams that do consider CI, the hurdle often is that they believe they need to do hardware-in-the-loop testing. This raises the complexity bar a good bit, and dooms many CI deployments. In reality, software-only tests run on x86 are much better than nothing, and take no more than an afternoon to put in place. I’m hoping that by spreading that gospel, I can help teams in the industry make the jump.
We’re writing a post on how to unit test firmware, hopefully we’ll hit the notes you’re looking for. We also welcome guest writers ;-). I’d be thrilled to edit / polish any post on embedded topics folks here want to write.