Suppose we are given the task of creating stepper motor driver software to drive a robotic hand to be used in robotic micro surgery. The processor that has been selected by the engineers is the PIC18F2520 manufactured by Microchip Corporation. This processor has 32KB of program memory. On a processor this small, it's common to use a mixture of 8, 16, and 32 bit data types in order to minimize memory footprint and program run time. The type int has 16 bits. It's programmed in C. Since this program is going to be running life critical function, it must be demonstrably correct. This implies that it needs to be verifiable and testable. Since the target micro processor is inconvenient for accomplishing these goals, we will build and test the code on the desktop.

A stepper motor controller emits a pulse which causes the motor to move one step. It seems simple, but in practice it turns out to be quite intricate to get right as one has to time the pulses individually to smoothly accelerate the rotation of the motor from a standing start until it reaches the some maximum velocity. Failure to do this will either limit the stepper motor to very low speed or result in skipped steps when the motor is under load. Similarly, a loaded motor must be slowly decelerated down to a stop.

This implies the the width of the pulses must decrease as the motor accelerates. That is the pulse with has to be computed while the motor is in motion. This is illustrated in the above drawing. A program to accomplish this might look something like the following: setup registers and step to zero position specify target position set initial time to interrupt enable interrupts On interrupt if at target position disable interrupts and return calculate width of next step change current winding according to motor direction set delay time to next interrupt to width of next step Already, this is turning it to a much more complex project than it first seemed. Searching around the net, we find a popular article on the operation of stepper motors using simple micro controllers. The algorithm is very well explained and it includes complete code we can test. The engineers are still debugging the prototype boards and hope to have them ready before the product actually ships. But this doesn't have to keep us from working on our code.

Inspecting this code, we find that it is written in a dialect of C rather than C itself. At the time this code was written, conforming versions of the C compiler were not available for PIC processors. We want to compile this code on the Microchip XC8 compiler which, for the most part, is standards conforming. So we made the following minimal changes: Factor into motor1.c which contains the motor driving code and motor_test1.c which tests that code. Include header <xc.h> which contains constants for the PIC18F2520 processor Include header <stdint.h> to include standard Fixed width integer types. Include header <stdbool.h> to include keywords true and false in a C program. The original has some anomalies in the names of types. For example, int16 is assumed to be unsigned. This is an artifact of the original C compiler being used. So type names in the code were altered to standard ones while retaining the intent of the original code. Add in missing make16 function. Format code to personal taste. Replaced enable_interrupts and disable_interrupts functions with appropriate PIC commands. The resulting program can be checked to be identical to the original but compiles on with the Microchip XC8 compiler. Given a development board, we could hook it up to a stepper motor, download and boot the code and verify that the motor rotates 5 revolutions in each direction with smooth acceleration and deceleration. We don't have such a board yet, but the engineers have promised a working board real soon now.

In order to develop our test suite and execute the same code on the desktop and the target system we factor out the shared code as a separate module which will used in both environments without change. The shared module motor2.c contains the algorithm for handling the interrupts in such a way as to create the smooth acceleration we require. motor_test2.c example92.cpp #include ... #include ... PIC typedefs ... desktop types ... \ / \ / #include motor2.c / \ / \ PIC test code desktop test code

Using the target environment to run tests is often very difficult or impossible due to limited resources. So software unit testing for embedded systems is very problematic and often skipped. The C language on our desktop is the same used by the PIC18F2520. So now we can also run and debug the code on our desktop machine. Once our code passes all our tests, we can download the code to the embedded hardware and run the code natively. Here is a program we use on the desktop to do that: Here are the essential features of the desktop version of the test program. Include headers required to support safe integers. Specify a promotion policy to support proper emulation of PIC types on the desktop. The C language standard doesn't specify sizes for primitive data types like int. They can and do differ between environments. Hence, the characterization of C/C++ as "portable" languages is not strictly true. Here we choose aliases for data types so that they can be defined to be the same in both environments. But this is not enough to emulate the PIC18F2520 on the desktop. The problem is that compilers implicitly convert arguments of C expressions to some common type before performing arithmetic operations. Often, this common type is the native int and the size of this native type is different in the desktop and embedded environment. Thus, many arithmetic results would be different in the two environments. But now we can specify our own implicit promotion rules for test programs on the development platform that are identical to those on the target environment! So unit testing executed in the development environment can now provide results relevant to the target environment. Define PIC integer type aliases to be safe integer types of he same size. Code tested in the development environment will use safe numerics to detect errors. We need these aliases to permit the code in motor2.c to be tested in the desktop environment. The same code run in the target system without change. Emulate PIC features on the desktop. The PIC processor, in common with most micro controllers these days, includes a myriad of special purpose peripherals to handle things like interrupts, USB, timers, SPI bus, I^2C bus, etc.. These peripherals are configured using special 8 bit words in reserved memory locations. Configuration consists of setting particular bits in these words. To facilitate configuration operations, the XC8 compiler includes a special syntax for setting and accessing bits in these locations. One of our goals is to permit the testing of the identical code with our desktop C++ compiler as will run on the micro controller. To realize this goal, we create some C++ code which implements the XC8 C syntax for setting bits in particular memory locations. include motor1.c Add test to verify that the motor will be able to keep track of a position from 0 to 50000 steps. This will be needed to maintain the position of out linear stage across a range from 0 to 500 mm. Our first attempt to run this program fails by throwing an exception from motor1.c indicating that the code attempts to left shift a negative number at the statements: denom = ((step_no - move) << 2) + 1; According to the C/C++ standards this is implementation defined behavior. But in practice with all modern platforms (as far as I know), this will be equivalent to a multiplication by 4. Clearly the intent of the original author is to "micro optimize" the operation by substituting a cheap left shift for a potentially expensive integer multiplication. But on all modern compilers, this substitution will be performed automatically by the compiler's optimizer. So we have two alternatives here: Just ignore the issue. This will work when the code is run on the PIC. But, in order to permit testing on the desktop, we need to inhibit the error detection in that environment. With safe numerics, error handling is determined by specifying an exception policy. In this example, we've used the default exception policy which traps implementation defined behavior. To ignore this kind of behavior we could define our own custom exception policy. change the << 2 to * 4. This will produce the intended result in an unambiguous, portable way. For all known compilers, this change should not affect runtime performance in any way. It will result in unambiguously portable code. Alter the code so that the expression in question is never negative. Depending on sizes of the operands and the size of the native integer, this expression might return convert the operands to int or result in an invalid result. Of these alternatives, the third seems the more definitive fix so we'll choose that one. We also decide to make a couple of minor changes to simplify the code and make mapping of the algorithm in the article to the code more transparent. With these changes, our test program runs to the end with no errors or exceptions. In addition, I made a minor change which simplifies the handling of floating point values in format of 24.8. This results in motor2.c which makes the above changes. It should be easy to see that these two versions are otherwise identical. Finally our range test fails. In order to handle the full range we need, we'll have to change some data types used for holding step count and position. We won't do that here as it would make our example too complex. We'll deal with this on the next version.

We can test the same code we're going to load into our target system on the desktop. We could build and execute a complete unit test suite. We could capture the output and graph it. We have the ability to make are code much more likely to be bug free. But: This system detects errors and exceptions on the test machine - but it fails to address and detect such problems on the target system. Since the target system is compiles only C code, we can't use the exception/error facilities of this library at runtime. Testing shows the presence, not the absence of bugs. Can we not prove that all integer arithmetic is correct? For at least some operations on safe integers there is runtime cost in checking for errors. In this example, this is not really a problem as the safe integer code is not included when the code is run on the target - it's only a C compiler after all. But more generally, using safe integers might incur an undesired runtime cost. Can we catch all potential problems at compiler time and therefore eliminate all runtime cost? Our first attempt consists of simply changing default exception policy from the default runtime checking to the compile time trapping one. Then we redefine the aliases for the types used by the PIC to use this exception policy. // generate compile time errors if operation could fail using trap_policy = boost::numeric::loose_trap_policy; ... typedef safe_t<int8_t, trap_policy> int8; ... When we compile now, any expressions which could possibly fail will be flagged as syntax errors. This occurs 11 times when compiling the motor2.c program. This is fewer than one might expect. To understand why, consider the following example: safe<std::int8_t> x, y; ... safe<std::int16_t> z = x + y; C promotion rules and arithmetic are such that the z will always contain an arithmetically correct result regardless of what values are assigned to x and y. Hence there is no need for any kind of checking of the arithmetic or result. The Safe Numerics library uses compile time range arithmetic, C++ template multiprogramming and other techniques to restrict invocation of checking code to only those operations which could possible fail. So the above code incurs no runtime overhead. Now we have 11 cases to consider. Our goal is to modify the program so that this number of cases is reduced - hopefully to zero. Initially I wanted to just make a few tweaks in the versions of example92.c, motor2.c and motor_test2.c above without actually having to understand the code. It turns out that one needs to carefully consider what various types and variables are used for. This can be a good thing or a bad thing depending on one's circumstances, goals and personality. The programs above evolved into example93.c, motor3.c and motor_test3.c. First we'll look at example93.c: Here are the changes we've made int the desktop test program Specify exception policies so we can generate a compile time error whenever an operation MIGHT fail. We've aliased this policy with the name trap_policy. The default policy of which throws a runtime exception when an error is countered is aliased as exception_policy. When creating safe types, we'll now specify which type of checking, compile time or runtime, we want done. Create a macro named "literal" an integral value that can be evaluated at compile time. "literal" values are instances of safe numeric types which are determined at compile time. They are constexpr values. When used along with other instances of safe numeric types, the compiler can calculate the range of the result and verify whether or not it can be contained in the result type. To create "literal" types we use the macro make_safe_literal(n, p, e) where n is the value, p is the promotion policy and e is the exception policy. When all the values in an expression are safe numeric values, the compiler can calculate the narrowest range of the result. If all the values in this range can be represented by the result type, then it can be guaranteed that an invalid result cannot be produced at runtime and no runtime checking is required. Make sure that all literal values are x are replaced with the macro invocation "literal(x)". It's unfortunate that the "literal" macro is required as it clutters the code. The good news is that is some future version of C++, expansion of constexpr facilities may result in elimination of this requirement. Create special types for the motor program. These will guarantee that values are in the expected ranges and permit compile time determination of when exceptional conditions might occur. In this example we create a special type c_t to the width of the pulse applied to the motor. Engineering constraints (motor load inertia) limit this value to the range of C0 to C_MIN. So we create a type with those limits. By using limits no larger than necessary, we supply enough information for the compiler to determine that the result of a calculation cannot fall outside the range of the result type. So less runtime checking is required. In addition, we get extra verification at compile time that values are in reasonable ranges for the quantity being modeled. We call these types "strong types". And we've made changes consistent with the above to motor3.c as well Define variables using strong types Surround all literal values with the "literal" keyword Re-factor code to make it easier to understand and compare with the algorithm as described in the original article. Rewrite interrupt handler in a way which mirrors the original description of the algorithm and minimizes usage of state variable, accumulated values, etc. Distinguish all the statements which might invoke a runtime exception with a comment. There are 12 such instances. Finally we make a couple minor changes in motor_test3.c to verify that we can compile the exact same version of motor3.c on the PIC as well as on the desktop.

The intent of this case study is to show that the Safe Numerics Library can be an essential tool in validating the correctness of C/C++ programs in all environments - including the most restricted. We started with a program written for a tiny micro controller for controlling the acceleration and deceleration of a stepper motor. The algorithm for doing this is very non-trivial and difficult prove that it is correct. We used the type promotion policies of the Safe Numerics Library to test and validate this algorithm on the desk top. The tested code is also compiled for the target micro controller. We used strong typing features of Safe Numerics to check that all types hold the values expected and invoke no invalid implicit conversions. Again the tested code is compiled for the target processor. What we failed to do is to create a version of the program which uses the type system to prove that no results can be invalid. I turns out that states such as ++i; c = f(c); can't be proved not to overflow with this system. So we're left with having to depend upon exhaustive testing. It's not what we hoped, but it's the best we can do.