[home] :: Make your embedded system safer
0 products in your
Make your embedded system safer
Embedded systems are now spreading in our world, they are becoming more and more common. However, as the spread goes, some questions are being raised. One, maybe the most important one, of these questions is: How can we ensure that our embedded systems are safe?
 By saying a program is safe we mean it does not only run exactly as the programmer expected, but also run without problem when it is ported to another environment. In addition, its source code is clear enough to other people.
In this article, we are going to present several rules for ensuring a safe embedded project, which are not checked by a compiler.
Rule 1:
Do not directly use basic types such as char, int, float, etc. Instead specific-length equivalents should be typedefed for the specific compiler, and the name of these types should be used in the code. The reason of doing this is that different compilers could use different underlying representation for the basic types. The most common case is the type int, which could be seen as 16 bit wide by one compiler while 32 bit wide by another.
So whenever you need to represent something that would never be negative, you should use something like uint 16_t instead of int
Rule 2: Make all declarations at file scope static
Once a variable or a function was declared static, it cannot be seen or used directly by other modules in the application.
This rule:
* Prevents you from unintentionally exposing internal help functions and file-local variables
* Forces you to really design the interface of new modules
* Makes the interface more clear, something that is really important as applications grow older and the person who wrote the code may not be around any more.
Rule 3: The right hand side of a "&&" or "||" operator should not contain side effects.
Take the following code for example:
To get rid of such side-effect, the example above can be rewritten into:
In this article, we are going to present several rules for ensuring a safe embedded project, which are not checked by a compiler.
Rule 1:
Do not directly use basic types such as char, int, float, etc. Instead specific-length equivalents should be typedefed for the specific compiler, and the name of these types should be used in the code. The reason of doing this is that different compilers could use different underlying representation for the basic types. The most common case is the type int, which could be seen as 16 bit wide by one compiler while 32 bit wide by another.
So whenever you need to represent something that would never be negative, you should use something like uint 16_t instead of int
Rule 2: Make all declarations at file scope static
Once a variable or a function was declared static, it cannot be seen or used directly by other modules in the application.
This rule:
* Prevents you from unintentionally exposing internal help functions and file-local variables
* Forces you to really design the interface of new modules
* Makes the interface more clear, something that is really important as applications grow older and the person who wrote the code may not be around any more.
Rule 3: The right hand side of a "&&" or "||" operator should not contain side effects.
Take the following code for example:
if ((x == y) || (*p++ == z))
{
/* do something */
}
In this example, the right hand side of the || operator would be only evaluated (and its side-effects executed) if the expression on the left-hand side is false—that is, if x and y are not equal. In this example, the side-effect is to increase the pointer p.{
/* do something */
}
To get rid of such side-effect, the example above can be rewritten into:
int doSomething = 0;
if (x == y)
{
doSomething = 1;
}
else if (*p++ == z)
{
if (x == y)
{
doSomething = 1;
}
else if (*p++ == z)
{
doSomething = 1;
}
}
if (doSomething)
{
/* do something */
}
