Sign In
Forgot Password?
Sign In | | Create Account

The invisible RTOS continued

Colin Walls

Colin Walls

Posted Dec 19, 2011
1 Comment

Last week I wrote about a test harness for applications using an RTOS. The idea was to have a library of functions corresponding to the API calls of a particular RTOS. Specific tasks of an application, that are under test, would be linked to this library to enable the code to be executed on a desktop computer in a useful way.

I had some feedback on this posting from a couple of people, talking about RTOS simulation on a host computer …

The idea that my correspondents wrote about is actually very useful. In a similar way to my test harness, a library of functions is created that map onto the RTOS API. These functions 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 [including Nucleus]. 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.

The test harness, however, has a different purpose. It is used earlier in the development cycle for unit testing of single tasks and allows the logic around API calls to be thoroughly exercised in ways that running with a real OS cannot. For example, if you were using Nucleus and wanted to allocate a dynamic memory block, you might make an API call like this:

NU_Allocate_Partition(pool, &return_pointer, suspend);

The function verifies the first two parameters and returns NU_INVALID_POOL or NU_INVALID_POINTER, if either error is apparent.

If the test harness is set to allow this call to succeed, the function allocates some memory and returns a pointer to 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, NU_TIMEOUT or NU_POOL_DELETED.

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 with a real RTOS or simulator.

Debugging, API, RTOS, test harness, Nucleus

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 1

Post a Comment
Based on my experience, now its one of my practices to get the code working on a desktop computer. some issues are very time consuming and tedious to debug on the embedded platforms. So having this approach, the 90% of your application code can be debugged and tested on the pc platform quickly. In addition to that, new target support can be added later easily if the chosen target platform doesn't work out as per your needs. Thanks, Amit Mistry

amit mistry
7:17 PM Jan 19, 2012

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat