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.

First reason: no need to waste time painfully searching for some mistakes


Static code analysis == cheaper cost of testing 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 unclear where to look for it. If the programmer considers that the code is written correctly, then this can lead to long research involving circuit engineers and other colleagues responsible for the hardware part. It will be all the more unpleasant to return to the program code later 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 the next 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 surprised at how quickly he did everything, praising what I proudly declare "well, I am already a professional to write such things and in general everything is simple there." 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 executive electromechanical 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, then what if the machine does not work properly in a certain mode? In general, there are two rhetorical and real options:

  1. Accept and receive negative customer reviews on various sites, spoiling your reputation. You can, of course, release and send to the instructions the application “do not do it like this”, but also a weak option.
  2. Recall the 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, you just need to use every opportunity to additionally check the correctness of the code. Static analyzers can indicate a wide variety of errors that manage to remain 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 type time_t , which can lead to improper operation of the device after 2038 .

Another example is the indefinite behavior of a program that occurs due to the misuse of операторов сдвига <>. 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. At the same time, 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 another 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 away from the topic under discussion.

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 find and fix errors ( example );
  2. Reduce the likelihood of critical errors;
  3. Reduce the likelihood of firmware updates;
  4. Control 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 .