Best Practices for Firmware Versioning and Releases

Jump into any software development project, and you’ll find an important focus on project management and version release management. These practices are implemented even by individual developers, as well as groups of open-source developers. In the embedded world, there is an additional factor to consider: the hardware being developed to host the embedded application. The embedded development team needs to draw on practices from software development to manage versions and releases, but they must also ensure alignment with the hardware platform.

There is no objectively “best” strategy for implementing project management across both hardware platforms and their firmware. The strategy your team should use will depend on how different portions of the hardware platform are constructed (firmware modules, hardware modules, etc.). We’ve outlined some of the strategies embedded development teams can take in this article.

Anatomy of an Embedded Project

Before getting into best practices for managing firmware releases and version control, it’s important to look at the full range of possible components that can be contained in an embedded project. The graphic below summarizes three areas where developers will focus when building a new product: the electronic hardware, the embedded application, and finally the mechanical design of the final product. Collaboration must occur across all these areas with highest possible efficiency to ensure high quality, minimal time to market, and no errors in communication throughout a project.

Within each of these three areas, design assets will need to be kept in a version control system and tracked throughout the design process, as well as into the production phase when a product enters market. The challenge for embedded systems is structuring projects within version control. Should the embedded application, mechanicals, and hardware be tracked in a single repository, or should they be broken into separate repositories?

Single Repository for Hardware and Firmware

The simplest approach is to simply track everything in a project in its own repository. This means all the data on the schematics, PCB, mechanicals, and the codebase are tracked in a single repository. There is only a single release at a time that includes all data required for a product. This makes everything easy to align and manage, but it becomes difficult when developers start to reuse portions of the data in new projects.

If a developer wanted to use part of the codebase in a new product, then they could simply clone that portion of the data and import it into a new project. However, there is a risk that changes to the code (such as bug fixes) are not propagated back into the main branch. Obviously, this is problematic as one version of the codebase will contain remnant bugs, but the newer version does not, and no one will know what was changed! The exact same ideas apply to the hardware if any portion of the PCB is reused.

This means it may be beneficial to take a different approach with firmware, especially if it will ever be reused in a new project.

Hardware and Firmware in Different Repositories

The next approach is to put all hardware and all firmware in their own repositories that are tracked in parallel. Hardware versions are linked to most recent firmware versions, and this means any hardware changes will have to be aligned with the most recent firmware versions. In some cases, the embedded application may need to be updated frequently, resulting in multiple branches within the version control system. Teams should make sure they consolidate branches with pull requests periodically to avoid losing track of each hardware/firmware revision.

Firmware Versioned as Modules

Firmware can be further broken down into modules, meaning individual portions of the firmware are developed in isolation. This is the approach a team could take with driver or library development for modular products. Two example situations include:

1. A multi-board product composed of modules (think a base board and its expansion card or shield)
2. A PCB platform that allows swapping between multiple ASIC components in the layout

In #1, version control is implemented at the module level, which could include drivers for multiple components in a single codebase. In #2, drivers for individual ASICs are being developed and tracked in their own repositories. Note that these are not mutually exclusive; companies can still develop drivers for components in isolation and they can use these in new products as needed.

Mechanicals

Although the mechanicals will drive the physical placement of components within the PCB layout, and they can affect the resulting user experience due to placement of HMI elements, it’s possible to track mechanicals in their own repository. There is much greater collaboration between the PCB designer and the embedded development team, compared to collaboration with a mechanical designer. In many environments, the mechanical designer will provide constraints, or they will need to accommodate electrical changes driven by the PCB designer.

Therefore, it’s common to track the mechanical enclosure alongside the PCB design data. The reason is simple: finalized PCB updates need to align with the required mechanical updates. Therefore, they should be put into version control in the same repository and they should both be present in the release for a product. The exception to this is a simple off-the-shelf enclosure that is not specifically tailored to the design, such as you might find in a simple box build.

Any design team working on advanced electronic products and components can take control of their high-level designs with the complete set of data management tools from Cadence. Only Cadence offers a comprehensive set of circuit, IC, and PCB design tools for any application and any level of complexity.

Subscribe to our newsletter for the latest updates. If you’re looking to learn more about how Cadence has the solution for you, talk to our team of experts.