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.

Want to stay up to date on news from Siemens Digital Industries Software? Click here to choose content that's right for you

Comments

0 thoughts about “The invisible RTOS
  • 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 peter.bushell@software-integrity.com.

  • 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.

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/embedded-software/2011/12/12/the-invisible-rtos/