Why embedded developers should use static code analysis

I decided to briefly formulate 3 reasons for which embedded developers are useful tools for static analysis of program code.

The first reason: do not waste time painfully searching for some mistakes

Static code analysis == cheapening the testing process and debugging the device. The earlier the error is found, the cheaper it is to fix it. Static analysis finds errors even at the stage of writing code, or at least during nightly launches on the server. As a result, finding and fixing many errors is much cheaper.

Static analysis can be especially useful when debugging embedded systems. In such projects, developers are faced not only with errors in the programs, but also with errors in the device itself or with poor-quality mock-ups (poor contact, etc.). As a result, the process of finding an error can drag on a lot, since it is often not clear where to look for it. If the programmer considers that the code is written correctly, then this can lead to long research involving circuit designers and other colleagues responsible for the hardware part. All the more unpleasant it will be later to return to the program code and finally find a stupid typo. A tremendously inefficient expenditure of time and energy. Great if a static analyzer finds such an error.

Here's how one friend described a similar situation to me:

“While still a master, I started working for a company manufacturing custom-made various small-scale devices. For example, the automation of greenhouses or the collection of information from sensors in an enterprise that nothing has leaked anywhere and has not overheated.

I am faced with another typical task, which I can cope with literally in a couple of hours and give it to two colleagues for firmware in the device they created. Colleagues are amazed at how quickly he did everything, praise what I proudly declare “well, I’m already a professional to write such things and in general everything is simple”. Colleagues are deleted with a flash drive, where I wrote them a binary file for microcontroller firmware.

And I forget about this thing. There are other larger and more interesting tasks. Moreover, since they did not come, then everything is fine.

And they came. But only after a week. They say we don’t understand anything. They broke my whole head. Our stand does not work. Rather, it works, but not quite as it should. We have already re-soldered it again and replaced the electromechanical executive parts. It doesn’t work ... Maybe you will look? Maybe, after all, something is wrong in the program ... I

open the code and immediately see an error in the spirit:

uchar A[3];
....
for (uchar i = 0; i != 4; i++)
  average += A[i];
average /= 3;

My other project was taken as a basis, and the code was largely written by the Copy-Paste method. In one place, I forgot to replace 4 with 3. I was so ashamed that I forced two people to work for a week. ”

The second reason: updating the program is expensive, impossible or late

Errors in embedded devices are extremely unpleasant in that they are impossible or almost impossible to fix if mass production has begun. If hundreds of thousands of washing machines have already been launched and they have gone shopping, what should we do if the machine does not work properly in a certain mode? In general, there are two rhetorical and real options:

1. Resign yourself and receive negative customer reviews on various sites, spoiling your reputation. You can, of course, release and send the “don't do it like this” application to the instructions, but also a weak option.
2. Recall a series and upgrade firmware. Expensive entertainment.

Moreover, regardless of whether the circulation of devices is large or small, error correction can be problematic or belated. The rocket fell , an error was detected, but late. Patients died , an error was found, but it will not return people. The missile defense system is beginning to miss , an error has been discovered, but there is nothing pleasant in this story. The cars did not slow down , errors were found, but there were no victims from this proc.

The conclusion is very simple. Embedded devices code should be tested as thoroughly as possible, especially if errors can lead to victims or serious material losses.

Static code analysis does not guarantee the absence of errors in the code. However, it is simply necessary to use every opportunity to additionally verify the correctness of the code. Static analyzers can point to a wide variety of errors that manage to stay in the code even after several Code-Review.

If there are fewer errors in the device due to static analysis, this is great. Perhaps, thanks to the discovery of these very errors, no one will die, or the company will not lose a lot of money or reputation due to claims from customers.

Third reason: the programmer may not know that he is doing something wrong

Errors in programs can be figuratively divided into two types. The programmer knows about errors of the first type, and they appear in the code randomly, by inattention. Errors of the second kind arise in a situation where the programmer simply does not know that it is impossible to write code like this. In other words, he can read such code as much as he wants, but still he won’t find an error.

Static analyzers have a knowledge base about various patterns, which under certain conditions lead to an error. Therefore, they can indicate to the programmer an error, the existence of which he himself would hardly have guessed. An example is the use of the 32-bit time_t type , which can lead to improper operation of the device after 2038 .

Another example is the indefinite behavior of a program, which occurs due to improper use of the shift operators <>. These operators are very widely used in microcontroller code. Unfortunately, programmers often use these operators extremely carelessly, making programs unreliable and dependent on the version and settings of the compiler. Moreover, the program can work for itself, but not at all because it is written correctly, but because it is lucky.

Using a static analyzer, programmers can secure themselves against many such unpleasant situations. Additionally, the analyzer can be used to control the quality of the code as a whole, which is important when the composition of project participants grows or changes. In other words, the analyzer helps to track if the beginner has started to write bad code.

Conclusion

There is one more reason to use a static code analyzer without fail. This is when the project must comply with a certain standard of software development in a language, for example, MISRA C. However, this is more likely to relate to administrative measures, and lies a bit off the topic.

I wanted to show that using a static analyzer is definitely advisable for any embedded project. Use this methodology and you will be able to:

1. Reduce time to search and eliminate errors ( example );
2. Reduce the likelihood of critical errors;
3. Reduce the likelihood of firmware updates;
4. Monitor the overall quality of the code (we recommend additionally looking towards SonarQube );
5. Monitor the quality of work of new team members;
6. Control the quality of the code of third-party modules / libraries.

There is no reason not to use static code analysis except laziness and the illusion of superiority.

Use static code analyzers! There are a lot of them .

Naturally, we suggest paying attention to our PVS-Studio code analyzer , which recently began to support a number of ARM compilers.

If you want to share this article with an English-speaking audience, then please use the link to the translation: Andrey Karpov. Why embedded developers should use static code analysis .