Why embedded developers should use static code analysis

I decided to briefly formulate 3 reasons why embedded developers can use static code analysis tools.

The first reason: you do not need to spend time on the painful search for some errors

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



Especially useful static analysis can be 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 production of the layout (poor contact, etc.). As a result, the process of finding an error can be very long, as it is often not clear where to look for it. If the programmer thinks that the code is written correctly, then this may entail long searches 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 to find a silly typo. Colossally inefficient expenditure of time and effort of the team. Great if such an error is found by a static analyzer.



Here is how one friend described this situation to me:

')

“Even as a master, I began working in a company engaged in the manufacture of various small-scale devices to order. For example, the automation of greenhouses or the collection of information from sensors in the enterprise, that nothing has leaked anywhere and has not overheated.



I have another typical task, which I can cope with in just a couple of hours and give it to my two colleagues for flashing to the device they have created. Colleagues are surprised how quickly everything is done, they praise me, to which I proudly declare “well, I am already a professional writing such things and generally everything is just there”. Colleagues are removed from the flash drive, where I wrote them a binary file for the microcontroller firmware.



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



And they came. But only in a week. They say we do not understand anything. The whole head was broken. Our booth does not work. Rather, it works, but not quite as it should. We have re-soldered it again and the executive electromechanical parts replaced. Does not work ... Maybe you look? Maybe, after all, there is something 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; 

The basis was taken by my other project, 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 in vain for a week. ”

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

Errors in embedded devices are extremely unpleasant because they can not or almost impossible to fix if mass production began. If hundreds of thousands of washing machines have already been released and they have gone shopping, what to do if the machine works inadequately in a certain mode? In general, the question is rhetorical and there are two real options:

1. To accept and receive negative customer reviews on various sites, spoiling their reputation. You can, of course, release and send to the instructions the application "do not do this," but also a weak option.
2. Revoke the series and start updating the firmware. Expensive entertainment.

Moreover, irrespective of the fact that the circulation of devices is large or small, the correction of errors may 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 anti-missile complex begins to miss , an error has been detected, but there is nothing pleasant in this story. Machines did not slow down , errors were found, but there are no victims with this software.



The conclusion is very simple. Embedded device 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 any opportunity to additionally check the correctness of the code. Static analyzers can indicate a lot of various errors that manage to remain in the code even after several Code-Review.



If the device, due to static analysis, will be a few less errors, it is great. Perhaps, thanks to the discovery of these errors, no one will die, or the company will not lose big money or reputation due to customer complaints.

Third reason: the programmer may not know what is doing something wrong.

Errors in the programs can be figuratively divided into two types. The programmer knows about errors of the first type, and they appear in the code randomly, through 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, it can read such code as much as it wants, but still it will not find an error.



Static analyzers have a knowledge base of various patterns that, under certain conditions, lead to an error. Therefore, they can point the programmer to 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 incorrect operation of the device after 2038 .



Another example is the undefined behavior of a program, which arises 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 the programs unreliable and dependent on the compiler version and settings. At the same time, the program itself can work quite well, but not at all because it is written correctly, but because it carries it.



Using a static analyzer, programmers can insure themselves against a variety of such unpleasant situations. Additionally, the analyzer can be used to control the quality of the code as a whole, which is important when the list of project participants is growing or changing. In other words, the analyzer helps to track whether the beginner has started writing bad code.

Conclusion

There is one more reason to use a static code analyzer without fail. This is when a project must conform to a certain standard for developing software in a language, for example, MISRA C. However, this is rather an administrative measure, and lies a little away from the topic under discussion.



I wanted to show that the use of a static analyzer is definitely appropriate for any embedded project. Use this methodology and you can:

1. Reduce the time to find and fix errors ( example );
2. Reduce the likelihood of critical errors;
3. Reduce the likelihood of updating firmware;
4. Monitor the overall quality of the code (we recommend that you additionally look towards the SonarQube );
5. Monitor the quality of work of new team members;
6. Monitor the quality of the code of third-party modules / libraries.

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

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



Naturally, we suggest paying attention to our code analyzer PVS-Studio , 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 .