Forums

OSS or Free RTOS recommendations?

Started by Marco October 15, 2006
"David Ashley" <dash@nowhere.net.dont.email.me> wrote in message
news:kPmdnUysudtk5K_YnZ2dnUVZ_smdnZ2d@adelphia.com...
> Marco wrote: > > I would like to see recommendations on existing OSS or free RTOS (with > > 32 bit ARM, PowerPC and x86 targets). I think it is important to > > have a free-as-in-beer license for training/trial purposes as well as > > possibly a commercial version to actually ship products and get > > support. Please discuss "performance" and ease of use. Not really > > interested in Linux (too big). > > > > 1) RTEMS http://www.rtems.org/ > > 2) FreeRTOS http://www.freertos.org/ > > 3) eCos http://www.ecoscentric.com/ > > > > > > any others? > > > > (duplicate of post at comp.realtime) > > > > 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. >
Not really. The real-time patch merely results in lower latency, it's not *hard* real time like the RTOS'es listed above. -- Posted via a free Usenet account from http://www.teranews.com
Don wrote:
> David Brown wrote: >> Marco wrote: >>> Bugman wrote: >>>> Neil a &#2013265929;crit : >>>> 5) Prex at http://prex.sourceforge.net/index.html >>> >>> 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? > > Are, perhaps, those "extensions" things as non-portable as > .asm? (likely to use in writing an OS)
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. http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/index.html#toc_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.
> >> 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.
David Brown wrote:
> Don wrote: >> David Brown wrote: >>> Marco wrote: >>>> Bugman wrote: >>>>> Neil a &#2013265929;crit : >>>>> 5) Prex at http://prex.sourceforge.net/index.html >>>> >>>> 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? >> >> Are, perhaps, those "extensions" things as non-portable as >> .asm? (likely to use in writing an OS) > > 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. > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/index.html#toc_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)) [I prefer the latter approach as I find the porting effort much more straightforward and less prone to error] --don
Marco <prenom_nomus@yahoo.com> wrote:

> 1) RTEMS http://www.rtems.org/ > 2) FreeRTOS http://www.freertos.org/ > 3) eCos http://www.ecoscentric.com/
> any others?
I've not used it, but I hear XMK is pretty good (http://www.shift-right.com/xmk) ttyl, --buddy