3 Tips for Managing Embedded Software Version

Managing embedded software configurations can be difficult. Today’s systems are frequently intended to work in different products for different clients over long periods of time.

These systems must be simple to configure so that the coding can not be a nightmare and the risks of incorrect configuration are reduced.

We’ll look at three suggestions for embedded version control that I’ve found to ease configuration and reduce technical debt during the life of a product in this post.

Tip-1 – Use different repos

It’s tempting to put all of a product’s code into a single revision control repository when developing on an embedded device.

After all, it’s just one product, so shouldn’t everything related to it be in one place? NO, I would say! The codebase configuration management can be greatly improved by splitting the application into numerous repositories.

In many circumstances, a product code will be utilized across many product SKUs and may appear in various forms to suit client requirements for a decade or more. As a result, teams can study their product’s architecture thoroughly and save all settings code in a separate repository.

This produces the core product code as well as many configuration repositories that control how the core software will behave. This has the advantage of not forcing modifications to the program that may mistakenly propagate to other systems if setting changes are required for a specific SKU or customer.

Configuration isn’t the only thing that benefits from having its own repository. There may also be advantages to separating the application’s layers into different repositories. 

Separating drivers, middleware, and the application into different repositories, for example, can make developers to thinking more about the code’s interfaces and abstractions, reducing layer coupling.

Many teams, for example, struggle to switch embedded systems during the chip scarcity because their applications are intimately coupled to their hardware.

Tip-2 – Use YAML, JSON, and XML files to your advantage.

Developers will employ a number of similar words to manage the setup of their systems in many embedded products. For example, if I have two separate systems, one with two controllable relays and the other with four, programmers will write C code that looks like this:

#if SKU == PRODUCT_1

            // Custom configuration for two relays.

#elif SKU == PRODUCT_2

            // Custom configuration for four relays.

#else

            #error “The Product SKU has not been defined!”

#endif

If the product is basic, a few similar statements strewn about the code isn’t a major concern; nevertheless, today’s systems are quite complicated, with thousands of these lines strewn about. As you may expect, this becomes a pain to maintain and configure.

Developers can use configuration files instead of conditional compilation. File systems can be used in two different ways. To begin, developers can simply create C module settings to store product configuration data. The program, logic, and driver activation functions get these configuration variables. Second, configuration files written in C are simple to set up and manage.

Using configuration in YAML, JSON, and/or XML format is a more current technique. Think back at the number of a similar examples, we could build a YAML file for a 2 configuration that looks like this:

—

Hardware:

    Relays:

        0x01:GPIO01

        0x02:GPIO15

This is an example of a four-relay configuration YAML file:

—

Hardware:

    Relays:

        0x01:GPIO01

        0x02:GPIO15

        0x03:GPIO22

        0x04:GPIO23

How does one use YAML, JSON, and XML files to configure a C/C++ application? There are a few options, but the one I’ve used the most is to develop a script that reads the YAML file and then generates the C code equivalent. For instance, the following is an example of a process:

I understand that utilizing a configuration file written in a language other than C and depending on a script to construct the configuration feels complicated to some. However, I’ve discovered that, when done correctly, this strategy may be a good and useful tool to organize system configuration.

Tip-3 – Use a package manager for C/C++.

A package manager is another tool that developers can use to manage their product settings. Package management can help developers maintain track of their program’s dependencies.

The package manager can also be incorporated into a build system, allowing developers to easily manage their builds, including configuration management.

For C/C++ developers, there are various package managers to choose from. For example, the Microsoft C/C++ doing it vcpkg, a freely distributed application. The vcpkg utility can be used to integrate or add private 3rd modules, frameworks, and open-source code.

Conan, on the other hand, is open-source product management that is also frequently used. Each software has its own set of benefits and drawbacks, but regardless of which one you choose, it can be extremely useful in managing software configuration.

Conclusions

Embedded software has evolved from simple control applications to complex systems that frequently necessitate complicated configuration management. In small projects, old approaches like conditional compilation might be useful, but as the complexity and size of the project grow, developers must turn to more current tools.

Package managers and automated fashion configuration files, for example, can significantly improve a system’s configuration management. However, effective use of these technologies requires teams to be disciplined.