Seeking open-source operating system abstraction

Op Fri, 24 Apr 2009 04:26:40 +0200 schreef Baron Samedi :

For the classic ones, yes.

Standard C/C++, SUS, POSIX, Java.

Stubbing. Or having an RTOS kernel that can alos run on the host platform (soft kernel).

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Look into Apache Portable Runtime (APR) and Netscape Portable Runtime (NSPR). These are intended to provide cross-platform portability between Unix, Windows and MacOSX. They may or may not be suitable for an embedded environment.

I'm not exactly sure what you are wanting -

• Provide an RTOS abstraction layer so you can implement a wrapper to enable you to switch between RTOSes in your embedded application, or

• Provide an implementation of your RTOS API calls in your favoured desktop environment, so your embedded application will compile and run on your desktop.

I think you are asking for the second option, right?

I have done both in various ways over the years. For example there is a (third party provided) WIN32 simulator for FreeRTOS (see the "Win32 Simulator" menu item under the "More Advanced" menu on the FreeRTOS WEB site. I have used this successfully to develop uIP/lwIP/FreeRTOS integration using a WIN32 host and compiler (note the simulator does not run real time though).

--
Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.  More than 7000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.

Thanks very much the reply.

What am I looking for for ... flexibility, I guess.

I recent years I have been coding for VxWorks on an ARM processor. The company was not very open to the idea of unit testing on PC first, before throwing the full build onto the hardware (with predictable results).

What I am looking for is as close as I can get to saying something like "I want a full abstraction layer/set of #defines/whatever which lets me write one copy of the application code with no extra flags or conditional compilation so that I can unit test on Windows or Linux and then compile exactly the same application code to run on target under VxWroks/FreeRTOS/eCos/whatever".

I hope that I managed to explain it more clearly this time.

1) I want to unit test on PC 2) I want to build all of the unit tested s/w and integration test it on PC (stubbing out the h/w) 3) I want to test and eventually release the application software which I wrote, but it must be totally unchanged. The only changes can be in the "abstraction layer".

Thanks again for your reply. In now looks like I am moving from Windows to Linux for host (but would like to keep my options open), I will probably move away from VxWorks too, on cost grounds. I had been looking at eCos, but will have a close look into FreeRtos.

Hi Most widely used is proberly POSIX and OSEK solutions .. Though I think I did read an ISO/IEEE standard also covering these aspects (some month ago) ...

/johnk

Baron Samedi skrev:

That's not realistic. The native OS (and CPU) semantics always leak out to some extent.

A simple example: all ANSI C "hosted" implementations have the remove() function. On Unix, this function will remove both files and directories, and can remove files which are open (the filename will be removed immediately, the data will remain until the last process closes the file). On Windows, remove() only removes files, and you get an error if the file is open in any process.

The situation is much worse in multi-threaded code, as a function's atomicity and re-entrancy are visible aspects of its behaviour. Sure, you could just implement locking on all platforms, but if you forget, your code will work on one and fail on the other.

If you implement, test, and fix the bugs on e.g. Linux, when it comes time to test on the embedded system you will find new bugs which don't manifest under Linux.

Also, an abstraction layer only deals with OS differences, not hardware differences. E.g. x86 doesn't have alignment requirements, but most other chips require "int"s to be aligned to 16- or 32-bit boundaries. If you overlook alignment constraints, it will work fine on x86 but fail on other platforms.

Certainly if you are talking about a large-scale abstraction, there are many differences such as you describe. There is a reason why cross-platform libraries such as wxwidgets or QT are so big (even if you just look at the multitasking, timers, and files libraries). And even with their size and scope, they don't come close to a completely platform independent abstraction.

However, the OP is talking about, amongst other systems, FreeRTOS, and in his first post he only mentions messages, timers, mutexes, semaphores and threads. He is therefore only looking for a much smaller set of features to abstract, and it might then be practical to eliminate most differences. In particular, if he can avoid Windows altogether, then he might have an easier job (most non-Windows systems tend to gravitate towards posix for complex interfaces, such as file access).

IOW, all of the hard cases ;)

However, while they may provide POSIX "syntax" (function prototypes), there can be non-trivial differences in semantics, especially with regard to concurrency issues (the original Linux pthreads implementation differed significantly with regard to signal delivery).

Also, some platforms may go beyond POSIX, e.g. providing re-entrancy when it isn't mandated, so passing a test suite on one platform doesn't guarantee that it will do so on another. And whether race conditions manifest depends upon relative timings, which could vary a great deal between a PC and an embedded target.

If the OP actually wanted portability, the solution is to read the fine print in the platform's API documentation and be meticulous about coding to spec, particularly for multi-threaded code. But it looks like he just wants to minimise the amount of time spent using the actual target platform. IMHO, that's likely to be a mistake.

he

We are doing exactly what you discuss here. We have a port of uCos-II that runs on top of Linux. It is obviously a simulator and does not run in real-time. On that platform we perform unit testing, and code coverage testing that could not be performed on our embedded target. We have been able to stub out all of our hardware interfaces so that they are simulated on Linux.

It has been an excellent platform for testing. However it is no replacement for testing a on the hardware. We perform unit level (white box) and code coverage testing on the Linux box, and functional testing (black box) on the embedded platform. There are minor differences between the platforms that need to be addressed in the Application Software which we do at compile time. Ultimately the advantage of being able to automate our unit test and perform code coverage outweighed the added complexity supporting another platform.