RT/embedded OS use poll

On 12/21/2010 03:09 AM, Stargazer wrote:

> Do you know that Cisco adoted embedded Linux as one of basic reference
> platforms for their router plug-in cards and didn't even consider
> using an RTOS?
>
> Do you know that Avaya phased out VxWorks from their phone gateways in
> favor of embedded Linux?
>
> Do you know that TI based all their decision on introducing ARM-based
> DSPs on availability of embedded Linux and never considered an RTOS
> for them? (Now some RTOSes do support TI DSPs, but TI ignore them).
>
> Do you think all those guys (including Windriver and LynuxWorks) also
> don't "understand what an RTOS *is*?"

For many applications, a strict RTOS is not a requirement. A router that 
uses some best effort mechanism is good enough, as long as it has a 
decent amount of average speed. It's just a matter of stress testing the 
box with high load and see if you accept the delays.

For many other applications, the other side of the spectrum works fine 
too. Most of of my stuff uses a "big main loop" approach, combined with 
real-time stuff in ISRs, and it works fine. If possible, I prefer this 
way because it doesn't waste RAM for task stacks, and it generally makes 
things quite straightforward.

Of course, it all depends on your application.

On 12/20/2010 7:09 PM, Stargazer wrote:
>>> The question is: would you give a try for John Doe's RT/embedded OS?
>>
>> Why not turn the question around:
>>
>> It sure *feels* like you're thinking about writing "yet
>> another RTOS".  Have you looked at how *many* RTOS offerings
>> there are out there?  Even the "free" ones?
>
> Yes I know (VxWorks, long-dead pSOS, LynxOS, Integrity, ThreadX,
> Nucleus, TRON, QNX, uCOS, eCOS, ...)
>
>> Can you imagine
>> how many *more* exist "behind closed doors" (not that they
>> are "secret" but, rather, that companies just "write
>> something" for their particular use and never even consider
>> "making it available to others").
>
> Actually, not that many. Companies generally don't write OSes for
> their own use. I know of many projects that worked without an OS at
> all or with a simple interrupt-aided "big-loop" application, which
> could hardly be called "an OS". When they need something more of an
> OS, they pick from available offer.

I guess your experience differs from mine.  In 30+ years
designing real-time, embedded systems, I've yet to work
with a company that "purchased" an RTOS.  And, I've not
seen a "big loop" since the late 1970's (though I
imagine they exist -- people also try to use Windows
for RT work!).  I write another RTOS for virtually every
project I design (one size fits all *doesn't*  :> )

>> Are you sure you understand what an RTOS *is*?  (then why
>> are you mentioning Linux in the same breath)
>
> I am pretty sure I understand what an RTOS is. I mentioned embedded
> Linux because it's used where I would naturally expect to see RT/
> embedded OSes.
>
> Do you know that Windriver and LynuxWorks, two of RTOS "leaders"
> distribute their own embedded Linux distributions as "default" choice
> and their own RTOS only as "special-case handlers"?

Do you know what applications they are targeting with the Linux
distro?  I.e., is it really handling the RT aspects of the
product?  Or, some non-RT or SRT aspect of the product
riding atop something else that actually handles the RT work
(even "dedicated ISRs)?  or, maybe just allowing "remote access"
over a network?

> Do you know that Cisco adoted embedded Linux as one of basic reference
> platforms for their router plug-in cards and didn't even consider
> using an RTOS?

Cisco sells hardware.  It makes sense to cut their support costs
for software.  Especially since much of their hardware handles the
HRT aspects of their applications.  And, if Linux mimics the BSD
distros, "routing" is handled in the stack/kernel, not in userland.

> Do you know that Avaya phased out VxWorks from their phone gateways in
> favor of embedded Linux?

Again, what is Linux *doing* in those applications?  Are you
sure it's not serving a role that Windows does in similar
applications?  "Gee, if we use Linux, we can have a telnet
service *and* Apache to serve up web pages for the 'configuration
mode'..."

Lucent runs Inferno in their boxes.  Inferno has *no* RT guarantees.
(gee, what sort of application is that?)

> Do you know that TI based all their decision on introducing ARM-based
> DSPs on availability of embedded Linux and never considered an RTOS
> for them? (Now some RTOSes do support TI DSPs, but TI ignore them).

TI sells hardware.  Have you ever seen the quality of TI's
"software products"?

> Do you think all those guys (including Windriver and LynuxWorks) also
> don't "understand what an RTOS *is*?"

No, I think they are looking at how to sucker folks into their
camps who *think* the GUI, etc. is the meat of the project.  How
often have you seen someone say, "We can use a PC for that"
and, after you question the rationale for their suggestion,
realize that it all boils down to how "easily" they can
hook a screen onto their application?  Or, their lack of
familiarity with "remote hosted" development?  How often
have you seen someone design display *hardware* (and video
drivers, network drivers, etc.)?

>> With that in mind, what makes you think anything -- besides
>> novelty -- that you come up with will be "attractive" to
>> a potential "buyer"?  I don't see anything in your list
>> of "Pros" that doesn't already exist, today.  Probably
>> in a dozen different incarnations (what constitutes
>> "simpler programming"?).
>
> "Simpler programming" means: no user/kernel separation, no MMU
> implications, no user/group/other access control issues, no complex
> interfaces just because they must be the same as for some other
> desktop port etc.

IMO, the only thing speaking in favor of such a heavyweight approach
*is* the separation of userland from kernel, MMU protections, etc.
Otherwise, why not use a lean, generic FOSS RTOS?

(Ah, because most RTOS's don't have network stack, video subsystem,
full set of libraries, etc.)

>> It's one thing to release (FOSS) code you've already written
>> in the hopes that others might find some use in it.  It's
>> another to think you can produce something worthwhile in which
>> folks will WANT to invest *their* resources (time, money,
>> reputation).
>>
>> You can probably build a "means of transportation".  Would
>> you think many people would visit your "showroom" for anything
>> more than curiosity factor?  ("Oh, gee... it has four wheels!
>> How novel!")
>
> You're trying so hard to convince me that I can't "invent something
> worthwhile"... projection?

Ad hominem attacks.  A great way to earn folks' respect and
assistance.  :>

I changed my mind.  I am 1000% in favor of your idea.  Go spend
time and money pursuing it.  Lots of it!  Let us know how great
it works out for you -- I'm sure we'll all be cheering for you!
;-)

> At the same time you completely miss a point of comparison of "John
> Doe's RTOS" vs Linux. Yes, most of "John Doe's" advantages are offered
> by many commercial RTOS for 20-30 years and by free RTOS for 10+
> years. And with all that RTOS market is nearly dead and agonizing
> (people evidenced  it already in 2003-2004,
> http://www.linuxfordevices.com/c/a/News/GartnerDataquest-Embedded-Linux-now-number-one-in-Asia/,
> http://www.ganssle.com/rants/rtosupdate.htm). Some local success of
> ARM-dedicated RTOS or in closed military market doesn't change the
> global picture: Linux is a global winner of a market that it doesn't
> even belong too.

And before Linux, these same sorts of numbers were reflected by
folks using Windows platforms for exactly the wrong reasons I
outlined above.

Been there.  Watched people design $1,000,000 production systems
based on the mistaken belief that the display/GUI was the "hard
part".  Then wondered why their systems didn't quite work.

(I know of one firm that went through three revisions of a product
following this approach -- never selling *one* of them!)

You think *you* can offer something better?  How many thousands of
developers will be backing you (for no wages) in this endeavor?
Yet another Linux community??

> At the same time most (should I say "almost all"?) embedded projects
> don't need such Linux features as user-based access control, user/
> kernel division, address space separation and many don't even need
> filesystems. Many performance-demanding projects (video streaming,
> audio DSP processing, network filters) suffer from Linux'es
> limitations and ask for non-trivial system optimizations.

If you look at the numbers, you'll see most embedded systems
don't need the horsepower that Linux requires.  They aren't
the glamorous applications but they make lots of sales dollars.

> That's a problem I am trying to understand and solve. As you and
> others argue, there is a case for RT/embedded OSes, so shy did they
> fail? Was it just marketing failure, objective market difficulties or
> there's some other reason? Unreasonably high license costs, poor
> support, lack of sufficient middleware rise obviously, but why didn't
> they improve (and they had time)?

RTOS's cost money to support.  You don't hire a call center
overseas to talk folks through their problems with a canned
script.  You need knowledgeable professionals to answer
questions.  *Good* support requires those professionals to
get (slightly) involved in your application.  Those professionals
aren't cheap.  A few hours of support can cost you (the vendor)
$1,000 in direct costs plus opportunity costs (that professional
*could* be writing code to improve the product instead of
hand-holding).  If you absorb that cost, then you have to
raise your licensing fees to cover it.  If you pass those
costs on to the user, then the user has to go to his boss
and say, "We need to spend $X because I'm not smart enough
to do this without help".  "Um, then why did YOU recommend
this approach to us?"

Customers object to licensing costs.  For the same reason they
grumble at a $5,000 compiler (it's not rational but it's how people
think).

Most software engineers aren't particularly hardware literate.
So, if drivers for *their* hardware aren't available, their
eyes glaze over.  For fancier hardware (video, network, etc.)
most folks have little experience with the chip du jour and
surely won't get up to speed on *that* device in the time
allowed for the entire project (how many I/O devices does
VxWorks support?  If I want to add a 1394 controller to
my design (by cribbing an application note), will they have
a "drop in" driver that does the trick?

My "GUI" comment is a perfect example of this.  I'm going to give
you an RTOS that is free, supported by thousands of professionals,
has a POSIX API, runs on every CPU known to man... *BUT*, there
is no support for a display, keyboard or disk drive.  Are you
ready to undertake that development?  Do you think you have
the skills to get the hardware designed AND drivers written?

Consider how quickly people want to see something on a display
to reassure themselves that they are "making progress".  Even
if the heart of the product has nothing at all to do with that.

(e.g., I'm a bottom up implementer -- top down *designer*.  The
first thing I get working is the drivers.  And, I use a scope
or a logic analyzer to verify their operation.  Nothing that
I can sit back and point to as "Wow, look at the blinking text
on the screen!!"  New clients *freak* because they don't SEE
ANYTHING for a long time.  Then, *suddenly*, it's "done".
They're *used to* seeing silly little blobs on a screen and,
as long as they see more blobs each day, they think progress is
being made -- even though there is "nothing under the hood".)

Look at how many experimental OS's end up having to support
POSIX API's and user interfaces just to gain acceptance...

In message <2fd454aa-00aa-46a5-9b1a-239e569fea56@w2g2000yqb.googlegroups
.com>, Stargazer <stargazer3p14@gmail.com> writes
>[...]
>People are not paying for commercial RTOS. That's why RTOS market is
>near-dead.

That is not true

>A few cases when they get sold include projects that
>ultimately go to avionics or military and some sort of continuation of
>legacy projects that have been using the same RTOS for previous 25
>years.

That is not true either.

>> >The question is: would you give a try for John Doe's RT/embedded OS?
>>
>> Well as you said it has a whole load of pro's the con's you mention are
>> FOSS FUD and don't hold water.
>>
>> However.... you need to compere John Doe's RTOS against other RTOS that
>> are available. Also you have no said what the target hardware is or what
>> the application domain is.
>
>There is no point to compare John Doe's RTOS with other RTOS. You may
>think of it actually as THE SAME as any RTOS that you know, but
>without 20-year history.

Then all Linux distributions are the same... a more than 50% chance it
will become unsupported in the next 3 years, won't have support for your
target.  Generalisations are pointless.

>The RTOS is targeted where heavy processing would make Linux demand
>more expensive system than would otherwise be needed:

No, RTOS are used where real time is needed. Linux is not real time.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 21/12/2010 03:36, Stargazer wrote:

> The RTOS is targeted where heavy processing would make Linux demand
> more expensive system than would otherwise be needed: video streaming
> and compression / decompression, network filtering appliances and
> "budget" routers, DVR, motion motor control.
>

You are mixing a wide range of applications here.

DVR's, for example, are a market dominated by embedded Linux systems. 
Video streaming systems /often/ use Linux, but not necessarily.  Network 
filtering appliances also often use Linux these days, but many use 
dedicated systems (rather than general-purpose RTOSes).  Budget routers 
may or may not use Linux, depending on the features they have (Linux 
gives a cheap path to more features, but requires higher hardware costs 
for more memory).  Motor controllers, on the other hand, are seldom 
Linux-based - while you can get hard real-time Linux systems, it is not 
suitable for such systems.

On Dec 21, 9:18=A0am, D Yuniskis <not.going.to...@seen.com> wrote:
> On 12/20/2010 7:09 PM, Stargazer wrote:
>
> >>> The question is: would you give a try for John Doe's RT/embedded OS?
>
> >> Why not turn the question around:
>
> >> It sure *feels* like you're thinking about writing "yet
> >> another RTOS". =A0Have you looked at how *many* RTOS offerings
> >> there are out there? =A0Even the "free" ones?
>
> > Yes I know (VxWorks, long-dead pSOS, LynxOS, Integrity, ThreadX,
> > Nucleus, TRON, QNX, uCOS, eCOS, ...)
>
> >> Can you imagine
> >> how many *more* exist "behind closed doors" (not that they
> >> are "secret" but, rather, that companies just "write
> >> something" for their particular use and never even consider
> >> "making it available to others").
>
> > Actually, not that many. Companies generally don't write OSes for
> > their own use. I know of many projects that worked without an OS at
> > all or with a simple interrupt-aided "big-loop" application, which
> > could hardly be called "an OS". When they need something more of an
> > OS, they pick from available offer.
>
> I guess your experience differs from mine. =A0In 30+ years
> designing real-time, embedded systems, I've yet to work
> with a company that "purchased" an RTOS. =A0And, I've not
> seen a "big loop" since the late 1970's (though I
> imagine they exist -- people also try to use Windows
> for RT work!). =A0I write another RTOS for virtually every
> project I design (one size fits all *doesn't* =A0:> )

Well, I saw a "big loop" as a part of quite nice network filtering
project in 2004-2005. Guess what - it was made of Linux kernel: they
patched the kernel causing it to enter the big loop instead of
mounting root fs and runninig /sbin/init; however they got all Linux h/
w support inside at the same price.

Actually, I am seeing another "big loop" right now. And no, it was not
my idea or recommendation, but in both cases the "big loop" works
suprisingly well. I guess that embedded needs and designs are very
different, one lifetime is not enough even to imagine all the
possibilities.

> > Do you know that Windriver and LynuxWorks, two of RTOS "leaders"
> > distribute their own embedded Linux distributions as "default" choice
> > and their own RTOS only as "special-case handlers"?
>
> Do you know what applications they are targeting with the Linux
> distro? =A0I.e., is it really handling the RT aspects of the
> product? =A0Or, some non-RT or SRT aspect of the product
> riding atop something else that actually handles the RT work
> (even "dedicated ISRs)? =A0or, maybe just allowing "remote access"
> over a network?

They offer embedded Linux distros as base support for evaluation
boards / SBCs for everything, unless you ask for specific features or
certifications.

> > Do you know that Cisco adoted embedded Linux as one of basic reference
> > platforms for their router plug-in cards and didn't even consider
> > using an RTOS?
>
> Cisco sells hardware. =A0It makes sense to cut their support costs
> for software. =A0Especially since much of their hardware handles the
> HRT aspects of their applications. =A0And, if Linux mimics the BSD
> distros, "routing" is handled in the stack/kernel, not in userland.

A natural but wrong guess. They don't allow open routing protocols
(for mostly security reasons) in their routers at all, Linux is used
as platform basis (along with their IOS). Cisco likes to have all the
knowledge inside, it helps them ultimately predict their deliveries
almost in hours precision. One of the most amazing organizations in
this aspect that I ever saw. They would never make themselves
dependent on unreliable support from third party, which in turn is not
willing to disclose all the knowledge.

> > Do you know that Avaya phased out VxWorks from their phone gateways in
> > favor of embedded Linux?
>
> Again, what is Linux *doing* in those applications? =A0Are you
> sure it's not serving a role that Windows does in similar
> applications? =A0"Gee, if we use Linux, we can have a telnet
> service *and* Apache to serve up web pages for the 'configuration
> mode'..."

Linux is used as complete replacement for VxWorks (I prepared for them
a bunch of Linux BSPs for their effort). All hardware and
communication management, application etc. There is no display or
keyboard in their devices. And telnet/web server is not an issue,
VxWorks and friends have them too.

> Lucent runs Inferno in their boxes. =A0Inferno has *no* RT guarantees.
> (gee, what sort of application is that?)

Actually, there were RT patches for Linux that allowed 10-30 ms
guaranteed responce times. Single-address space RTOS may offer sub-
microsecond responce times, which was always marketed as a definite
advantage. Now how many applications need sub-microsecond
responsiveness? (This is a real question, projects that I did in
video, networking, motion control, surveillance, unmanned flight
control never required that high responsiveness).

> > Do you know that TI based all their decision on introducing ARM-based
> > DSPs on availability of embedded Linux and never considered an RTOS
> > for them? (Now some RTOSes do support TI DSPs, but TI ignore them).
>
> TI sells hardware. =A0Have you ever seen the quality of TI's
> "software products"?

TI actually doesn't make "software products" of marketable quality.
They do BSP and dirvers set, video and audio interface libraries and
video and codecs tested and suitable for specific DSPs. I am not a fan
of their software, but so far it does what it was intended for. It is
not generally usable as just software product without connection to
their specific DSP and it may be hard time to deploy it even on their
DSPs other than intended.

> > Do you think all those guys (including Windriver and LynuxWorks) also
> > don't "understand what an RTOS *is*?"
>
> No, I think they are looking at how to sucker folks into their
> camps who *think* the GUI, etc. is the meat of the project. =A0How
> often have you seen someone say, "We can use a PC for that"
> and, after you question the rationale for their suggestion,
> realize that it all boils down to how "easily" they can
> hook a screen onto their application?

Well, I think here again our experiences differ. I don't remember
dealing with people who din't understand difference between PC and
embedded platforms.

> Or, their lack of familiarity with "remote hosted" development?

I thought that was common knowledge for years... no?

> How often have you seen someone design display *hardware* (and video
> drivers, network drivers, etc.)?

Actually I worked on projects that included display hardware
(including joint project with Samsung), but display hardware doesn't
need video drivers. It's either VGA or analog video provided by video
encoder chip, for which there is a need in driver. Video decoder
(grabber) and encoder and network drivers are required quite a lot.

> > "Simpler programming" means: no user/kernel separation, no MMU
> > implications, no user/group/other access control issues, no complex
> > interfaces just because they must be the same as for some other
> > desktop port etc.
>
> IMO, the only thing speaking in favor of such a heavyweight approach
> *is* the separation of userland from kernel, MMU protections, etc.
> Otherwise, why not use a lean, generic FOSS RTOS?
>
> (Ah, because most RTOS's don't have network stack, video subsystem,
> full set of libraries, etc.)

Usable RTOS do have a network stack and commonly known sockets API
with optional "zero-copy" / "copy-saving" API. (Except for TRON, which
deliberately decided not to support sockets API). Besides that, I
think that you have a hit here - lack of video subsystem and in
general poor third-party software availability (even open source is
not easy to port to them).

> > That's a problem I am trying to understand and solve. As you and
> > others argue, there is a case for RT/embedded OSes, so shy did they
> > fail? Was it just marketing failure, objective market difficulties or
> > there's some other reason? Unreasonably high license costs, poor
> > support, lack of sufficient middleware rise obviously, but why didn't
> > they improve (and they had time)?
>
> RTOS's cost money to support. =A0You don't hire a call center
> overseas to talk folks through their problems with a canned
> script. =A0You need knowledgeable professionals to answer
> questions. =A0*Good* support requires those professionals to
> get (slightly) involved in your application. =A0Those professionals
> aren't cheap. =A0A few hours of support can cost you (the vendor)
> $1,000 in direct costs plus opportunity costs (that professional
> *could* be writing code to improve the product instead of
> hand-holding). =A0If you absorb that cost, then you have to
> raise your licensing fees to cover it. =A0If you pass those
> costs on to the user, then the user has to go to his boss
> and say, "We need to spend $X because I'm not smart enough
> to do this without help". =A0"Um, then why did YOU recommend
> this approach to us?"

There is the other downside with support model, even when it's
ordered. Suppose that the engineer *is* smart enough to make the OS do
what's needed. Now the RTOS is used in a way that the vendor never
imagined. Our user then hits something that proves to be a bug in OS.
Now he calls support, complains and asks how can that be fixed. The OS
comes without source code; what the support would say? "Uhm... try to
change this build script and that makefile". - "But this doesn't help,
there's a problem in OS handling of interrupts. Here is a setup to
reproduce". - The party is unreachable.

OK, some of support failures may be compensated by provision of source
code and just fixed with support attitude by the vendor. But some core
problems remain: every customer will have its own unique use case. How
in hell support all this? (I don't know the answer. Any ideas are
welcomed).

> My "GUI" comment is a perfect example of this. =A0I'm going to give
> you an RTOS that is free, supported by thousands of professionals,
> has a POSIX API, runs on every CPU known to man... *BUT*, there
> is no support for a display, keyboard or disk drive. =A0Are you
> ready to undertake that development? =A0Do you think you have
> the skills to get the hardware designed AND drivers written?

You are write, hardware support availability is an immediate stopper.
But this is solvable for RTOS case.

> Look at how many experimental OS's end up having to support
> POSIX API's and user interfaces just to gain acceptance...

I think POSIX API is a must. RTOSes used proprietary interfaces in
order to stick customers to their OS (once they invested in learning
and preparing non-portable code), but that's a very wrong and
ultimately losing practice. POSIX interface is not performance costly,
and there is no excuse for not implementing it, causing the customers
unnecessary learning costs, HR availability problems etc.

Thanks,
Daniel

On 12/20/2010 05:08 AM, Stargazer wrote:
> Greetings,
>
> I am examining a case for a new RT/embedded OS in today's situation. I
> would like to get a simple YES/NO answer from embedded developers.
>
> Suppose that you are starting a new project. You are considering to
> use embedded Linux and you offered an RT/embedded OS by a vendor John
> Doe Inc. The RTOS is proposed in complete source code, uses GNU
> toolchain to build and development license is free. Production license
> cost is negligible for your purpose and support costs the same as
> support from embedded Linux vendors. In other words, John Doe's offer
> comes even to embedded Linux with regard to source code, development
> and license costs.
>
> Let's also suppose that John Doe's RTOS offers come even with Linux in
> ready code availability (John Doe Inc. ported to its OS open-source
> libraries that you need).
>
> Now you have to consider pros and cons of the new RTOS option compared
> to Linux (we assume that you know Linux pros and cons pretty well).
>
> Pros:
>
> * Smaller footprint, better configurability
> * More system resources left free
> * Better performance of OS kernel and services
> * Real-time responsiveness
> * Simpler build and maintenance
> * Simpler programming
>
> Cons:
>
> * Worse support (supported only by John Doe Inc. and its distributors,
> no match to Linux community)
> * Established bad reputation of dedicated RT/embedded OSes
>
> The question is: would you give a try for John Doe's RT/embedded OS?

I think your cons apply to embedded Linux as well, at least somewhat. 
There's a lot more enthusiasm surrounding open software support, but to 
some extent that means that you get a lot of poor advise.  It's like 
figuring out how to fix a car by talking to your friends around the 
water cooler -- it often works, but it often leads to you pouring money 
down a rat hole.

Ditto reputation.  Linux as a _desktop_ app has a solid rep, but Linux 
as an RTOS hasn't developed much of a rep yet -- and RT Linux is a 
different critter from 'regular old' Linux.

For me I think it'd be a wash, if the system were big enough to need a 
"big box" OS.  I think it'd depend on things you hadn't mentioned, like 
what the other members of my team thought (including management, who 
will be writing checks for either Linux consultants or OS licenses) and 
whether one or the other had a demonstrable ability to work on the 
hardware that I was building.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

On 12/21/2010 7:23 AM, Stargazer wrote:

Great!  Looks like you've got all the answers!
Now, go *do* it.  Please keep us informed.  We'd *all*
like to make our next million writing an RTOS...

On Tue, 21 Dec 2010 06:23:33 -0800, Stargazer wrote:

> Actually, there were RT patches for Linux that allowed 10-30 ms
> guaranteed responce times. Single-address space RTOS may offer sub-
> microsecond responce times, which was always marketed as a definite
> advantage. Now how many applications need sub-microsecond
> responsiveness? (This is a real question, projects that I did in video,
> networking, motion control, surveillance, unmanned flight control never
> required that high responsiveness).

I once made a 802.11 WiFi protocol stack where all radio timing was done 
in software using various interrupts. Some states had a periodic timer 
interrupt that ran every 9 usec, with <= 500 ns latency requirement. 

The same CPU was running a Linux OS. 

The trick we used was to divide the interrupts in two levels, with the 
highest priority interrupts used for the RT stuff, and the lower priority 
assigned to Linux. 

On 2010-12-20, Stargazer <stargazer3p14@gmail.com> wrote:
> Greetings,
>
> Yes I know (VxWorks, long-dead pSOS, LynxOS, Integrity, ThreadX,
> Nucleus, TRON, QNX, uCOS, eCOS, ...)
>

[snip]

>
> "Simpler programming" means: no user/kernel separation, no MMU
> implications, no user/group/other access control issues, no complex
> interfaces just because they must be the same as for some other
> desktop port etc.
>

If that's the kind of thing you are thinking of, have you looked at RTEMS ?
(I don't see it in the above list.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On Tue, 21 Dec 2010 09:36:12 -0800, Tim Wescott wrote:

> Ditto reputation.  Linux as a _desktop_ app has a solid rep, but Linux
> as an RTOS hasn't developed much of a rep yet 

Well my Samsung BlueRay player, and my TV, and my smartphone, and both 
wireless routers are all running Linux inside. They are all realtime in 
the sense that they manage to do what they  need to do, in time for when 
it needs to be done. Linux did become ubiquitous in the smart electronics 
area.

> and RT Linux is a
> different critter from 'regular old' Linux.

That is definitely true; just because Samsung has a successful product 
doesn't mean that anyone can bring it up---just that there are foundations
(kernel, drivers, protocol stacks, application libraries) to build upon.