Sign In
Forgot Password?
Sign In | | Create Account

The invisible RTOS

Colin Walls

Colin Walls

Posted Dec 12, 2011
4 Comments

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.

Nucleus, test harness, Debugging, RTOS, API

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five 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, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments 4

Post a Comment
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.

Peter Bushell
2:49 PM Dec 13, 2011

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

Colin Walls
4:01 PM Dec 14, 2011

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.

Lee Riemenschneider
1:47 PM Dec 15, 2011

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.

Colin Walls
4:23 PM Dec 16, 2011

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

Tags

 
Online Chat