This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: How does people think of ecos's future compare to so m any existing RTOS? eg.RT-Linux, Embedded Linux, VxWorks, etc.. Welcome to discuss


Hi All,

> We frequently
> would write abstraction layers on top of the OS with inline functions
> or macros so we could switch operating systems in midstream.  Nobody
> liked to be tied to a vendor.

We do exactly that, and I'd highly recommend it to other developers.  We
have an OS abstraction layer that provides standard kernel type
functionality such as thread scheduling and IPC in an OS independent manner.
I ported a 10K line embedded app from another OS to eCos in less than a day
using this technique. I've been using eCos for nearly two years now, but
none of my application code contains any direct calls to the eCos API...it's
all done through the abstraction layer.

The use of inline functions and macros ensures that the performance hit is
minimal. Also, it allows the development of extensions to operating system
facilities in a consistent manner.

And as was pointed out, most RTOS facilities are similar...you start
threads, pass messages, wait on semaphores etc. Whether you do it with pSOS,
vxWorks, eCos or TMBCOS (The Mind Boggling CEA OS) is kinda irrelevant. The
learning curve should be no more than a few days.


Cheers


Geoff


-----------------------------
Geoff Patch
Senior Software Engineer
CEA Technologies
Canberra Australia
02-6213-0141


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]