embedded software maintainability - configuration

Question

I am developing a embedded software that is meant to run on two to three different family of micro controllers. For now we have makefiles that reads the configuration switches and does compilation.

The process is getting more and more tedious for both developers and non developers to stay updated with compile switches and build configurations. I know Linux kernel uses ncurses for generating compile configurations. I am looking for a similar tool, but cross platform. It should run on Windows and Linux. I know this will still not solve the problem but its more appealing to non developers also I can quickly share my .config file or compare it with existing. The configurations will be in specific order and a diff tool here will help.

Can anyone share their experience with similar project maintenance or a reference project (embedded and common code base for multiple micros). Just want to know best practices.

PS : Language used C, 8/16 bit micros, no OS just timer based batch scheduler (baremetal)

Forta

Cold you elaborate on what's becoming "more and more tedious", exactly? What's changing that's making the situation worse -- or, from another direction, what part of the problem needs solving? – Packet

Well to start with, the software stack is highly configuration dependent (since it runs on very low end micros). A developer has to go through source code to understand what these switches mean. In nurses there is a way to provide documentation for each of those compile options. There are a few illegal configurations, checking for which is making my makefiles bloated. We have faced a few scenarios where configurations were overridden (developers mistakes) towards the end of makefiles, and identifying it took a lot of time. – Forta

It seems to me that your testing is insufficient. Ideally, all changes submitted into source repository (CVS, Git, P4, SVN, whatever), must be regularly built (at least daily/nightly) and frequently tested (daily). Any build or test break then becomes relatively easy to identify by looking at the changes since the last successful test pass. Testing is a friend, not foe. – Sixgun

Answer 1

I have one microcontroller but several projects which get compiled from the same source code. I think my scenario is similar to yours, at least to some extent. My solution was inspired by Linux kernel, as well.

config.h

All source code which needs to get access to some configuration parameter simply includes an header file called config.h.

config.h consists of just one line:

#include <config/project.h>

project.h

I have several configuration header files, one per project. A project.h consists of macro definitions with values such as true, false, or constants:

#define CONFIG_FOO true
#define CONFIG_BAR false
#define CONFIG_TIME 100

check.c

This file checks configuration parameters for correctness: - all parameters must be defined, even if not used or meaningful for that project - unwanted parameter combinations are signalled - parameter values are constrained.

#if !defined(CONFIG_FOO)
        #error CONFIG_FOO not defined
#endif

#if !defined(CONFIG_BAR)
        #error CONFIG_BAR not defined
#endif

#if !defined(CONFIG_TIME)
        #error CONFIG_TIME not defined
#endif

#if !(CONFIG_FOO ^ CONFIG_BAR)
       #error either CONFIG_FOO or CONFIG_BAR should be se
#endif

#if CONFIG_TIME > 250
        #error CONFIG_TIME too big
#endif

Makefile

By instructing the compiler to output the preprocessor macros, it is possible (with a bit of sed expression) to feed the Makefile with the same parameter values gprovided for a given project.

Shrunk

Answer 2

If you don't find anything else, GNU autotools could make things a bit easier.

Durning

Upvoted -- though I would particularly suggest using autoconf and ignoring the rest. (And, for that matter, using a fairly limited amount of autoconf's power -- you probably don't need any of the automatic compiler probing, but the ability to use .in files throughout the codebase as patterns is pretty useful.) – Packet

Is autotools cross platform ? I guess its learning curve is pretty large :( – Forta

It is cross-platform. But the learning curve was and is a pain for me. – Durning

Can I use autotools with compiler other than GCC say mcc18 ? – Forta

@AUZKamath: autoconf learning was pain for me as well. autoconf is not compiler-dependent. It uses bash routines to perform some checks. To explore compiler options you will have to write these routines (macros in terms of autoconf) yourself in case there are not available in some autoconf collection of macros. – Corneous

Answer 3

When I was doing multi-platform development, I used a solution like the one in my answer here. Have a specific "platform_XXX.h" for each platform, and restrict the conditional compilation to a single master "platform.h" file which selects the right subfile.

Melodics