The invisible RTOS
I was talking about OS-aware debuggers and someone asked me whether I could suggest a technique for unit testing of code for a multi-threaded application. It took me a while before I could fully understand what they were after, but it did become clear eventually. They were considering an environment where a number of engineers were working on an embedded application [using Nucleus]. Each guy was developing one or more tasks, which interact with one another and those written by other engineers. My questioner was wondering how these engineers could make some solid progress with testing and debugging ahead of building the complete system …
Obviously, the quickest and easiest way to test out some code is probably to compile and run it on a desktop computer. This is essentially a zero-cost, easy to use debug environment. However, it does not help so much when the code being tested interacts with an RTOS via a number of API calls, as obviously the code will not even link with these calls unresolved.
A trivial early step is comment out API calls or create dummy stubs that just allow the link to complete. This might enable basic program logic to be checked, but really does not allow too much progress, unless a program is largely comprised of complex algorithms. What is needed are API calls that respond sensibly. Normally, the only way to get “intelligent” responses from API calls is to actually link with an RTOS and run the code on a target system, or to use a complex [my questioner’s view] host-based simulation environment. The idea that came out of our discussion was for an RTOS test harness.
This test harness would simply be a library of functions corresponding to all [or most] of the API calls of the RTOS in use. These functions would accept the correct type and number of parameters and a call would result in a “sensible” response. Some basic parameter checking may result in an error return, otherwise a “success” response is likely. Where full API functionality can easily be simulated [e.g. dynamic memory allocation], the the API call can be even more intelligent and appear to respond just like the OS. A separate module, containing some global data structures, would enable the developer to tune the response of API calls so that they can test their code’s handling of API call responses, including various failure scenarios.
This approach has clear limitations, compared with running the code on a real RTOS, but would give the opportunity to check much more logic before introducing other complexities.
My questioner went away to consider the implementation of this test harness in his team. And I was left wondering whether such a “product” would be of interest to a wider body of users. I would be very interested to hear your thoughts by email or comment.
Posted December 12th, 2011, by Colin Walls
- malloc() – just say no
- What size drink would you like?
- Using an embedded Web server
- Row 13 – unlucky for some?
- Brillo – a brilliant OS or a scouring pad?
- How Mac and I are getting along – an interim report
- IPv6 – some guidance to the uninitiated
- Power outlets when traveling – and USB again
- Spotting the difference – subtleties of C code
- Shutting the Windows – moving to a Mac?