Embedded software handy tips

From time to time, I like to post some useful [hopefully!] tips for embedded software developers. Often, they are not the “last word” – there is room for discussion – so do feel free to comment or contact me by email or social media. Just three tips today …

Never comment out code; always use preprocessor directives

It is quite a common situation, when performing code maintenance [or sometimes also during development], that you might want to replace some code with something new, but want to keep the old code just in case it is needed. An apparently easy way to do this is to “comment out” the old code using the normal /* … */ sequence. However, this has two distinct downsides. Firstly, C comments are not nestable [at least, they have not been so traditionally]. So commenting out code which itself contains comments is problematic. Second, unless the code sequence is very short, readability is affected.

Although the modern rest of line “//“ notation is an improvement [it is nestable and more readable], it is better to use pre-processor directives, thus:

#if 0 // commenting out code
// (commented out code)
#endif

Although #ifdef is another option that enables you to “switch on” a number of pieces of code.

When planning on using free software, figure out who is actually paying for it

I am a strong advocate of the TANSTAAFL principle [“There Ain’t No Such Thing As A Free Lunch”]. Nothing is ever truly free – there is always a price/cost. So, if you are going to use some software with a $0.00 ticket, you should think about who might actually be paying and whether that affects you. Some possibilities:

• Shareware – software with an option to pay. The people who do pay are financing it. If it is truly useful to you, then you should be one of them.
• Standard/Premium – software with basic functionality, and extra features at a price. Easy to consider.
• Adware – software with built-in adverts. The advertisers pay in $$$; you pay in being distracted and/or networking bandwidth.
• Open source – software that is freely available to use, but with license terms. This is more subtle, as there are several possibilities. Sometimes, the license demands that the user share their work; that could be a high price to pay. Companies who offer open source support [for a price] commonly help develop the software; buying that support means you are paying. Software that supports a specific chip [family] may be funded by the semiconductor vendor; good support encourages use of their devices, so buying the chips pays for the software.

When deploying a new RTOS, consider using an API wrapper to make your code more portable

Having selected a real-time operating system, you have committed yourself to its Application Program Interface [API], which, typically, is unique to the RTOS in question. The incorporation of the service calls in your code locks you in – to some extent – to the RTOS vendor. This may not be a problem, but many developers would like the option to change RTOS when it suits them. To make that somewhat simpler, there are two options: choose an RTOS that supports a standardized API, like POSIX; define your own API, that supports the facilities that you need and create a “wrapper” to interface to the chosen RTOS.

A wrapper is a set of pre-processor macros [or maybe small functions] that map from one API to another. So, a call to your defined API becomes a call to the selected RTOS API. If you change the RTOS later, or use a different one on another project on which you are reusing some application code, it is only a matter of rebuilding the wrapper appropriately. This is a little effort, but much less arduous that changing every API call in the application.