Future of Firmware

If you went back in time 20 years and showed an embedded systems engineer the hardware we have today, they would be amazed: megabytes of flash and RAM, CPUs that can execute hundreds of millions of instructions per second, built-in wireless peripherals. All for a few dollars.  If you then showed them the toolchain most embedded engineers are still using they'd be confused, "Oh yeah cool, I know these" they'd say in disbelief, and probably a little despair.

Our industry still relies heavily on a set of tools and protocols(GDB, UART, Make, etc) that were created before Die Hard came out. Not that the 1980s weren't great, but a lot of really awesome innovations have come out since then. Unfortunately, compared to software engineering our industry has been very slow on the adoption of these technologies. And for good reason. Many of the products we develop have a mean time to failure of years or even decades. We design mission critical infrastructure that CAN NOT FAIL. So it makes sense to always default to tried and true. But we shouldn't get so stuck in our ways that we are incapable of learning and improving.

We created this field guide to spotlight the amazing tools that are available to embedded engineers today, right now. The best part is that these tools have already been battle-tested and proven out by our fellow engineers in the software world. We're really just borrowing techniques they've been using for years, and adapting them to meet the quirky needs of firmware development.

This Field Guide is comprised of a series of tours through the core concepts and new technologies that we believe will be a part of every embedded systems engineer's toolkit in the future. If you are willing to make some small changes to your working approach we can assure you this: Not only will you ship faster with fewer bugs, you'll actually enjoy the development process more. For our team it led to a rediscovery of our passion for the craft of embedded systems development.

Continuous Integration With On-Target Testing is a Must

Every line of firmware in a project will have corresponding tests(i.e. unit tests, system tests, etc) that run automatically using a modern build server like GitHub Actions or CircleCI. Because firmware is so tightly coupled with hardware in embedded systems, these tests MUST include on-target tests.

Despite being practically mandatory throughout the software world, continuous integration is an alien concept to most firmware teams. New code takes weeks or months to get integrated into a master branch because teams rely on tedious and slow manual testing, requiring dedicated engineering support, to catch code regressions.

Firmware Development Doesn't Depend on Proximity to the Hardware

More than ever, teams are distributed and people expect to work from literally anywhere with a good internet connection. "Remote" debugging should look and feel exactly like regular debugging. Being able to flash firmware, set breakpoints in code, stream serial output, read ADC, write GPIO, monitor communications busses like CAN or SPI, etc etc, should all be de-coupled from an engineers distance from their device-under-test(DUT). Your ability to develop and debug your firmware shouldn't require you to be sitting right next to your hardware.

Build Environments Are Portable

Engineers will be able to clone a project and immediately build it. Containerization technologies like Docker allow engineers to encapsulate everything needed(compiler, linter, build system, scripting language, etc) to build and test their project...in their project.

Too often cloning the project is only the beginning, the hard part is installing the necessary toolchain components and dependencies. At best this is time-consuming, at worst, it's an intractable IT nightmare.

Use a Modern Build System

Make should be revered...and then retired. Makefiles are notoriously fragile and debugging them can be maddening. There are now better builds systems that are easier to maintain and build faster. (e.g. CMake+Ninja). Even if you are committed to using make, you should use a modern build system manager like CMake to manage your builds versus manually editing Makefiles.

‍

Realizing the above concepts will unleash a wave of innovation by making collaboration, testing, and development orders of magnitude easier, allowing teams to launch products at a pace currently unimaginable. It's an exciting time to be a modern embedded engineer. Yippee-ki-yay indeed.

‍

‍