Codebase Management for Embedded Systems

Product development teams working on advanced technologies are firmly multidisciplinary, drawing on electrical, mechanical, and firmware/software engineers. The firmware side of hardware development often happens after the hardware is completed, and sometimes by a totally different team that is not directly involved in the hardware design and PCB layout.

To keep a project on track and in sync with the hardware being developed, development teams should use several systems to keep track of the codebase, the overall project, and synchronization to hardware. Teams have a responsibility to ensure the codebase and hardware align with each other at all times, and that firmware/software releases are not non-functional due to simple mismatches across the product data. To accomplish these goals, there are some simple systems and processes that help ensure alignment across development disciplines.

What Hardware Teams Need For Code Management

Before we outline the embedded systems development process, we should look at the various information management and development systems needed to successfully build an embedded application alongside a hardware system.

More important than a list of systems for code development and maintenance is the process for implementing these tools when developing for embedded systems. Hardware design and development must often run in parallel to these tasks, and changes in the hardware during development can force changes in the codebase.

Knowledge Sharing in Project Management

Team leads need to implement a project management process that ensures any hardware changes that drive code changes are actually implemented in the code. The best way to do this is to implement a mutual project management system where developers and hardware designers are tagged on the same issues. Working together across disciplines helps get these resolved before they create difficult-to-diagnose errors during build and testing.

Code Review and Collaboration

Developers may use tools like Gerrit or Crucible to submit code changes for review by their peers. Code reviews involve examining the proposed changes, providing feedback, suggesting improvements, and ensuring overall code quality. The important task here is ensuring any changes to hardware (e.g., interface requirements) are reflected in the code through a mutual review between the hardware and firmware teams.

Continuous Integration and Build Automation

Continuous integration (CI) practices are employed to automate the build process, ensuring that changes are integrated and tested frequently. A CI server like Jenkins is configured to monitor the version control system for new code changes. It triggers the build process, compiles the code, and performs automated tests to identify any integration issues or build failures. Successful builds generate executable binaries or firmware images ready for further testing and deployment.

Testing and Debugging

Comprehensive testing is crucial to ensure the functionality, stability, and reliability of the embedded system. Unit testing frameworks like Unity or CppUTest are employed to write and execute automated tests for individual software components. Additionally, hardware-specific testing, system integration testing, and acceptance testing are performed to validate the overall system behavior. JTAG debuggers and other hardware debugging tools assist in diagnosing and resolving issues at the hardware level.

Code Driving Hardware

The opposite process is to allow the code to drive hardware development for an embedded system. In this direction, the code already exists and has been qualified on an existing device, and the code may already be deployed on a device in the market. If the code is kept static and is used as the guide for the rest of the system, the functionality and interfaces required in the code will drive the rest of the hardware design.

The process for code driving hardware development is relatively simple and does not require as much back-and-forth collaboration between hardware and firmware/software teams:

1. Primary processor (MCU, FPGA, etc.) is selected that supports the existing code
2. Existing peripherals required in the new system are reused in new schematics and in the PCB layout
3. New peripherals can be added around the processor in #1
4. The existing code can be expanded to support new peripherals and features

This is a typical approach used when a team wants to reuse existing code in a new system. It also supports reuse of the existing primary chipset design, including right down to the existing layout for the processor. For example, the PCB layout engineer can take the existing processor and decoupling network, copy the layout section to a similar stackup, and wire up the other peripherals in the design.

The LQFP-100 package on the left side of this board can be reused along with its embedded application as the basis for a new PCB design.

If you reuse portions of a PCB layout in a new embedded development project, the PCB layout practices used in the new system must match those used in the original system, particularly with regard to the main digital processor. This is important for digital processors in embedded systems as it helps ensure signal integrity and power integrity for the main interfaces on the processor.

Engineers who build advanced fine-line HDI PCBs and packages trust the complete set of PCB design tools in Allegro PCB Designer. Allegro is the industry’s best PCB design and analysis software from Cadence, offering a range of product design features with a complete set of management and version control capabilities. Allegro users can access a complete set of schematic capture features, mixed-signal simulations in PSpice, and powerful CAD features, and much more.

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.