The invisible RTOS continued

Last week I wrote about a test harness for applications using an RTOS. The idea was to have a library of functions corresponding to the API calls of a particular RTOS. Specific tasks of an application, that are under test, would be linked to this library to enable the code to be executed on a desktop computer in a useful way.

I had some feedback on this posting from a couple of people, talking about RTOS simulation on a host computer …

The idea that my correspondents wrote about is actually very useful. In a similar way to my test harness, a library of functions is created that map onto the RTOS API. These functions use the underlying host OS [Windows or Linux] to simulate the RTOS services. This can work very well and many commercial RTOS products have such a tool available [including Nucleus]. The code runs very fast – often faster than on a real target! The real time profile is not correct, because the instruction mix on a Pentium is different from, say, an ARM, but that does not stop such a tool being very useful for debugging complete [or near complete] multi-threaded applications without the need for target hardware.

The test harness, however, has a different purpose. It is used earlier in the development cycle for unit testing of single tasks and allows the logic around API calls to be thoroughly exercised in ways that running with a real OS cannot. For example, if you were using Nucleus and wanted to allocate a dynamic memory block, you might make an API call like this:

NU_Allocate_Partition(pool, &return_pointer, suspend);

The function verifies the first two parameters and returns NU_INVALID_POOL or NU_INVALID_POINTER, if either error is apparent.

If the test harness is set to allow this call to succeed, the function allocates some memory and returns a pointer to return_pointer and the function returns NU_SUCCESS.

If the test harness is set to cause the call to fail, the return value will be NU_NO_PARTITION, NU_TIMEOUT or NU_POOL_DELETED.

This enables almost every possible response to be simulated.

So, a test harness is not an alternative to a simulator. It enables, in conjunction with a standard debugger, detailed logic testing and exercising that would not be possible with a real RTOS or simulator.