Testing code that uses an RTOS API
Implementing a Test Harness
A test harness allows the logic around API calls to be thoroughly exercised in ways that running with a real OS cannot. The implementation is, obviously, totally RTOS specific, but it does not require any knowledge of the RTOS internal workings. It would be expected that the API documentation would give enough information about each call to write the necessary harness function. The approach is best illustrated by example.
If you were using Nucleus RTOS and wanted to allocate a dynamic memory block, you might make an API call like this:
NU_Allocate_Partition(pool, &return_pointer, suspend);
Where the parameters have the following meanings:
pool is a pointer to a memory partition pool (which has previously been created with a call to NU_Create_Memory_Pool).
return_pointer is a pointer which will point to the allocated partition; a pointer to this variable is passed to the API function.
suspend indicates whether the task should be suspended (and, if so, how) if no partition is currently available.
The function verifies the first two parameters and returns:
NU_INVALID_POOL if the first parameter is not a valid memory pool descriptor; it must have a value that corresponds to the return from an earlier call to NU_Create_Memory_Pool.
NU_INVALID_POINTER if return_pointer is NULL.
If the test harness is set to allow this call to succeed, the function allocates some memory and returns a pointer the location indicated by 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 if the call did not specify a suspend and there are no partitions available.
NU_TIMEOUT if a timeout on suspend was specified and no partition had become available.
NU_POOL_DELETED if the specified pool was deleted during the task suspend.
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 (or, at least, be difficult) with a real RTOS or simulator.
Using the Host OS
After using the test hardness approach, a next step is to have a library of functions that map onto the RTOS API, which 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. 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.
Eventually, it becomes necessary to bite the bullet and test on an actual target. The software is then built for the target device instead of for the host. But even at this stage, there may be two options: debugging may proceed on a virtual platform, which enables code execution on a detailed hardware simulation of the target; or, of course, real target hardware may be deployed.
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor Embedded [the Mentor Graphics Embedded Software Division], and is based in the UK. His regular blog is located at: http://blogs.mentor.com/colinwalls and he may be reached by email at email@example.com
Join over 2,000 technical professionals and embedded systems hardware, software, and firmware developers at ESC Boston May 6-7, 2015, and learn about the latest techniques and tips for reducing time, cost, and complexity in the development process.
Passes for the ESC Boston 2015 Technical Conference are available at the conference's official site, with discounted advance pricing until May 1, 2015. Make sure to follow updates about ESC Boston's other talks, programs, and announcements via the Destination ESC blog on Embedded.com and social media accounts Twitter, Facebook, LinkedIn, and Google+.
The Embedded Systems Conference, EE Times, and Embedded.com are owned by UBM Canon.