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.

Post Author

Posted December 12th, 2011, by

Post Tags

, , , , , ,

Post Comments


About The Colin Walls Blog

This blog is a discussion of embedded software matters - news, comment, technical issues and ideas, along with other passing thoughts about anything that happens to be on my mind. The Colin Walls Blog


4 comments on this post | ↓ Add Your Own

Commented on 13 December 2011 at 15:49
By Peter Bushell

When working, some years ago, for a client in Belgium, I wrote a Windows simulator for pSOS. It made full use of the Windows threading facilities. Of course, it didn’t run in proper “real time”, but the overall performance was surprisingly well correlated with that of the PowerQuicc target, after appropriately scaling the processor clock frequency – even though the processors were, of course, completely different!

The simulator allowed me to get on with much of my development debugging work, while others queued for the two hardware prototype systems to debug theirs. Once the other guys found out what I’d done, they all wanted a copy.

If you’d like a similar simulator for Nucleus, which you could offer to customers, I’d be glad to discuss it with you. Just email me at

    Commented on 14 December 2011 at 17:01
    By Colin Walls

    Thanks Peter. I will be doing a follow-up blog on this topic.

Commented on 15 December 2011 at 14:47
By Lee Riemenschneider

Hmmm. Maybe a virtual machine running the RTOS would be handier. Many product teams use Linux in a VM for software development targeting embedded Linux. The question is what do you use for your virtualized hardware? OTS VMs target a PC, but embedded users would probably rather have something closer to actual hardware. That can quickly turn into a real support nightmare.

    Commented on 16 December 2011 at 17:23
    By Colin Walls

    Lee: I will be publishing a follow-up post next week, which I hope will clarify this matter. I will be interested in your input after that.

Add Your Comment

You must be logged in to post a comment.