OSS or Free RTOS recommendations?

The linux 2.6 series just got the real-time patch incorporated into the standard kernel, so I guess linux can be included now as well.

-Dave

There are a number of packages purporting to be RTOS's. I won't get into a discussion of which truly fit *my* expectations of an RTOS -- your expectations may be entirely different.

Having said that, make sure you know *what* your expectations actually are -- what guarantees you expect from the OS -- and make sure the offering(s) you evaluate truly *have* those features.

Also, make sure you understand what an RTOS *is* (hint: it is not "just a fast MTOS") as well as what RT actually is! (I won't get drawn into *that* discussion, either :> )

You also have to decide what level of expertise *you* have with these concepts and how much hand-holding you'll need from the "vendor"/community. Many of the "full-featured" RTOS's have very little outright support -- though a great deal of licensing freedom! (if you are willing to "own it") Amusingly, the "toy" RTOS/MTOS's seem to have bigger followings (perhaps because they require less from their users?)

You may even opt for a "free for noncommercial use" package to cut your teeth on and then buy-in to a regular commercial license to get the level of support you desire.

There are several web sites/pages devoted to cataloging OS's of various types. I suggest spending a bit of time digging through these before fishing for suggestions. There is a LOT of information about a LOT of different offerings out there to browse. (been there, done that, T-shirt to prove it) It's easier if you can ask specific questions about a particular RTOS/MTOS that you have in mind instead of looking for broad-brush summaries -- since everyone's experiences, expectations, etc. vary widely.

--don

I also noticed that, but doesn't Linux have a much larger RAM and storage footprint compared to the options listed above ?

Simon.

looks very interesting BUT:

"Q. What is required to build Prex? GCC, GNU binutils and GNU Make. Since the source codes depend on GCC extension, it is difficult to use another compiler to build Prex."

Why use GCC extensions?

Why not ? GCC is the natural compiler for open source software.

BTW: difficult != impossible

Why not use them, if people are going to use gcc as their compiler? After all, there is a reason these extensions were added - they make the compiler more powerful, more flexible, and let you (in some cases) write more elegant code. Sometimes it's important to write your code as portable as possible, other times it's fine to decide to use extensions. For example, you might want to code to C99 standards, while many existing compilers don't support it.

Note also that many of the gcc extensions are precursors to future C standards, or inclusions of C++ features in C (or vice versa), and that other compilers often support at least some of the gcc extensions.

Are, perhaps, those "extensions" things as non-portable as .asm? (likely to use in writing an OS)

Not really. The real-time patch merely results in lower latency, it's not

Most gcc extensions are portable to different gcc targets (some are target-specific), and some are just mixing rules and features between different languages (C and C++) or different C standards - things like allowing // comments with old-fashioned C, or mixing statements and declarations as you can in C++.

Some extensions are for supporting things like interrupt functions (which are always specific to compiler and target combinations). Some are for optimisation hints (like specifying alignments), which again are always compiler-specific. Others are neat time and space savers, like case ranges, non-constant initialisers, and some array and struct tricks

- they let you write smaller, faster, more readable code and the cost of deviating from C standards. Sometimes it's worth that cost, sometimes not - that depends entirely on what you are writing. Other features, like nested functions and initialiser code come about because the gcc middle and back end support other languages with functionality unavailable in normal C, and these features have been "back-ported" as C extensions.

Every embedded compiler I have worked with has its own extensions, especially when you consider the library as part of the tool. You can make use of these extensions and non-standard library functions to get better or faster code, or less development effort, or you can stick to tight standards. It all depends on what you are writing.

Sorry, I guess I was being too *subtle* :>

My point was, you often need non-ANSI extensions to write the interface to the metal -- if you want to do it within a 'C' framework (though you *can* write an OS *without* them -- except you then need to rely on implementation-specific things like calling conventions (to interface to hooks written entirely -- and separately -- in ASM))

--don

I've not used it, but I hear XMK is pretty good

ttyl,

--buddy