Comparison of embedded operating systems?

Question

I've been involved in embedded operating systems of one flavor or another, and have generally had to work with whatever the legacy system had. Now I have the chance to start from scratch on a new embedded project.

The primary constraints on the system are:

• It needs a web-based interface.
• Inputs are required to be processed in real-time (so a true RTOS is needed).
• The memory available is 32MB of RAM and FLASH.

The operating systems that the team has used previously are VxWorks, ThreadX, uCos, pSOS, and Windows CE.

Does anyone have a comparison or trade study regarding operating system choice?

Are there any other operating systems that we should consider? (We've had eCos and RT-Linux suggested).

Edit - Thanks for all the responses to date. A pity I can't flag all as "accepted".

Answer 1

I have been pretty happy with Windows CE, although it is 'heavier'.

Answer 2

I worked with QNX many years ago, and have nothing but great things to say about it. Even back then, QNX 4 (which is positively chunky compared to the Neutrino microkernel) was perfectly suited for low memory situations (though 32MB is oodles compared to the 1-2MB that we had to play with), and while I didn't explicitly play with any web-based stuff, I know Apache was available.

Answer 3

It all depends on how much time was allocated for your team has to learn a "new" RTOS.
Are there any reasons you don't want to use something that people already have experience with?

I have plenty of experience with vxWorks and I like it, but disregard my opinion as I work for WindRiver.

uC/OS II has the advantage of being fully documented (as in the source code is actually explained) in Labrosse's Book. Don't know about Web Support though.

I know pSos is no longer available.

You can also take a look at this list of RTOSes

Answer 4

I purchased some development hardware from netburner It has been very easy to work with and very well documented. It is an RTOS running uCLinux. The company is great to work with.

Answer 5

It might be a wise decision to select an OS that your team is experienced with. However I would like to promote two good open source options:

• eCos (has you mentioned)
• RTEMS

Both have a lot of features and drivers for a wide variety of architectures. You haven't mentioned what architecture you will be using. They provide POSIX layers which is nice if you want to stay as portable as possible.

Also the license for both eCos and RTEMS is GPL but with an exception so that the executable that is produced by linking against the kernel is not covered by GPL.

The communities are very active and there are companies which provide commercial support and development.

Answer 6

We've been very happy with the Keil RTX system....light and fast and meets all of our tight real time constraints. It also has some nice debugging features built in to monitor stack overflow, etc.

Answer 7

I think it would be wise to evaluate carefully what you mean by "RTOS". I have worked for years at a large company that builds high-performance embedded systems, and they refer to them as "real-time", although that's not what they really are. They are low-latency and have deterministic schedulers, and 9 times out of 10, that's what people are really after when they say RTOS.

True real-time requires hardware support and is likely not what you really mean. If all you want is low latency and deterministic scheduling (again, I think this is what people mean 90% of the time when they say "real-time"), then any Linux distribution would work just fine for you. You could probably even get by with Windows (I'm not sure how you control the Windows scheduler though...).

Again, just be careful what you mean by "Real-time".

Answer 8

Posting to agree with Ben Collins -- your really need to determine if you have a soft real-time requirement (primarily for human interaction) or hard real-time requirement (for interfacing with timing-sensitive devices).

Answer 9

Soft can also mean that you can tolerate some hiccups every once in a while.

What is the reliability requirements? My experience with more general-purpose operating systems like Linux in embedded is that they tend to experience random hiccups due to their smart average-case optimizations that try to avoid starvation and similar for individual tasks.