RT/embedded OS use poll

"David Brown" <david.brown@removethis.hesbynett.no> wrote in message 
news:jISdne_0BdsFGJLQnZ2dnUVZ8j-dnZ2d@lyse.net...
> On 20/12/10 15:41, larwe wrote:
>> would pick it up.
>
> There is also the point that this "John Doe OS" is a small-footprint RTOS, 
> while Linux is a large-footprint general-purpose OS with wildly varying 
> real-time functionality (depending on the distribution, configuration, 
> platform and add-ons).  In other words, they are totally different systems 
> for totally different applications.

Except that IME there IS a large set of uses of RT-Linux when "John Doe OS" 
would be more appropriate just because Linux is free to buy (and has a 
reasonably large base of experienced engineers to employ).

The users suffer the fact that its RT functionality is unpredictable because 
of the other benefits.  All to save about 50 cents per unit.

tim

Hi Vladimir,

On 12/20/2010 8:58 AM, Vladimir Vassilevsky wrote:
> Stargazer wrote:
>
>> 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.
>
> It doesn't matter.
> Whichever way you take, you will have to do everything yourself.

+42

At least if you want the product to be more than a
"throwaway product"

On 12/20/2010 6: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?

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?  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").

Are you sure you understand what an RTOS *is*?  (then why
are you mentioning Linux in the same breath)

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"?).

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!")

What PROBLEM are you SOLVING?

On 20/12/10 17:56, Chris H wrote:
> In message<ienog2$ksh$1@speranza.aioe.org>, Mel<mwilson@the-wire.com>
> writes
>> Chris H wrote:
>>> In message<ea6af706-c355-457b-ac76-727186955caf@v17g2000vbo.googlegroup
>>> s.com>, Stargazer<stargazer3p14@gmail.com>  writes
>>
>>>> Cons:
>>>>
>>>> * Worse support (supported only by John Doe Inc. and its distributors,
>>>> no match to Linux community)
>>>
>>> This is FUD RTOS support for the commercial RTOS I know if is much
>>> better than for Linux.
>>
>> We haven't met John Doe Inc. yet.  I think that's the OP's point.
>
> True but that does not mean it will be "no match to Linux community"

All we can be sure of is that it won't be /like/ the Linux community.

Whether it will be better or worse is as much dependent on the system 
used, the type of application, and the person/people developing the 
application as the company behind the RTOS or Linux distribution.

And don't forget that most serious embedded Linux development is done in 
conjunction with an embedded Linux vendor - including companies such as 
Wind River (now part of Intel), Monta Vista and Red Hat.  Support from 
such companies follows a similar pattern to support from all commercial 
companies - many are very good, some are very bad, and all depend on 
exactly what sort of support you are looking for.

On Mon, 20 Dec 2010 12:22:31 -0700, D Yuniskis
<not.going.to.be@seen.com> wrote:

><snip>
>What PROBLEM are you SOLVING?

This is of course the perennial question.

For those working in some medical areas, for example, the
ability to demonstrate that every possible fragment of
conditional code in the OS can be and is tested may also be a
requirement.  Designing an OS to make that easier isn't
necessarily the same thing as designing a general OS.

I often work on small micros and projects constrained on all
sides: cost, size, power, heat, precision, weight,
durability, and so on.  A common reason I use an O/S is to
help me cleanly organize and partition the application and to
provide reasonably handy sleep functions.  There are a few
other reasons, like semaphores or priorities, that crop up.

Usually, I need light weight processes that share static data
and have separate stacks (threads) and not full processes
with separate static data areas.  I often know in advance the
number of threads.  I often want part of a process node
stored in flash (any information known at compile time, at
least) and only some parts of it in precious ram.  I may even
require singly-linked lists if ram is particularly precious
and I'm willing to waste code space and execution time to get
there.  I may appreciate, but not always need, support for
exception handling on a thread basis.  (Usually, that is used
during initial testing and then disabled via a #define and
recompiled to eliminate the attending code and data.)

I almost NEVER require things like STL, ethernet, or 3D
graphics facilities.  The one I wrote will work on an 8031
with 128 bytes of ram or 8032 with 256 bytes of ram with
plenty left over for the application.

Of course, most folks creating an O/S for broader use aren't
addressing such needs.

Jon

On 20/12/10 18:12, Chris H wrote:
> In message<jISdne_0BdsFGJLQnZ2dnUVZ8j-dnZ2d@lyse.net>, David Brown
> <david.brown@removethis.hesbynett.no>  writes
>> On 20/12/10 15:41, larwe wrote:
>>> On Dec 20, 8:08 am, Stargazer<stargazer3...@gmail.com>   wrote:
>>>
>>>> The question is: would you give a try for John Doe's RT/embedded OS?
>>>
>>> Ignoring the usual rabid foamings that FOSS kicks off in this NG, your
>>> question cannot be answered because the answer depends on many other
>>> things:
>>>
>>> a) have I already a hardware platform (implication: have I already
>>> allowed for the system footprint of Linux and therefore don't care if
>>> JDOS would save some footprint)? is there already a Linux BSP for it?
>>> is there a John Doe BSP or must I develop it from scratch?
>>> b) is there third-party IP I need to integrate? have the third parties
>>> already supported Linux? Is there any hope in hell they will ever give
>>> a damn about John Doe OS? Note this has nothing to do with your
>>> comment "we ported libraries". This might be proprietary software that
>>> you cannot access.
>>> c) will John Doe be around in 2 years? 5? 20? We have hardware
>>> platforms still in use that are almost 22 years old, running the
>>> original software stack.
>>> d) does my hardware/software toolchain vendor have explicit support
>>> for John Doe OS? There's a bit more to it than just gcc.
>>> e) how hard will it be for me to move JDOS project on HW platform #1
>>> to HW platform #2?
>>>
>>> Particularly your answer to c) would determine how likely it is I
>>> would pick it up.
>>
>> There is also the point that this "John Doe OS" is a small-footprint
>> RTOS, while Linux is a large-footprint general-purpose OS with wildly
>> varying real-time functionality (depending on the distribution,
>> configuration, platform and add-ons).  In other words, they are totally
>> different systems for totally different applications.
>
> Yes I would have thought that Linux would have been head to head with
> Embedded Win XP not an RTOS.
>

I've never considered embedded windows to be worth putting head-to-head 
with anything else - the concept of embedded windows is just too 
oxymoronic for my mind.  But apart from that personal prejudice, I agree.

> That said if you have a lot of Linux experience and use it for other
> things  there are RT Linux about but it is hardly small for print.
>

Experience with desktop or server Linux doesn't translate directly into 
experience with embedded Linux.  Although the kernel may be basically 
the same, there is a lot of difference - you should consider embedded 
Linux as something in between a RTOS and a desktop-style OS.

Hi Jon,

On 12/20/2010 1:09 PM, Jon Kirwan wrote:
> On Mon, 20 Dec 2010 12:22:31 -0700, D Yuniskis
> <not.going.to.be@seen.com>  wrote:
>
>> What PROBLEM are you SOLVING?
>
> This is of course the perennial question.

The answer, of course, is "*blue*".

> For those working in some medical areas, for example, the
> ability to demonstrate that every possible fragment of
> conditional code in the OS can be and is tested may also be a

Yup.  "Eschew Dead Code" (actually, that isn't a strong enough
prohibition  :< )

> requirement.  Designing an OS to make that easier isn't
> necessarily the same thing as designing a general OS.
>
> I often work on small micros and projects constrained on all
> sides: cost, size, power, heat, precision, weight,
> durability, and so on.  A common reason I use an O/S is to
> help me cleanly organize and partition the application and to

Exactly.  An OS acts as a scaffolding onto which you can
"drape" your application.  It provides structure and helps
enforce disciplines.

> provide reasonably handy sleep functions.  There are a few
> other reasons, like semaphores or priorities, that crop up.
>
> Usually, I need light weight processes that share static data
> and have separate stacks (threads) and not full processes
> with separate static data areas.  I often know in advance the
> number of threads.  I often want part of a process node
> stored in flash (any information known at compile time, at
> least) and only some parts of it in precious ram.  I may even

Lately, I have taken to heavy use of zero-copy semantics
and algorithms designed to tolerate/exploit const-ness.
E.g., XIP vs. "load and execute" (I abhor keeping two copies
of anything -- two much chance for them to get out of
sync)

> require singly-linked lists if ram is particularly precious
> and I'm willing to waste code space and execution time to get
> there.  I may appreciate, but not always need, support for
> exception handling on a thread basis.  (Usually, that is used
> during initial testing and then disabled via a #define and
> recompiled to eliminate the attending code and data.)
>
> I almost NEVER require things like STL, ethernet, or 3D
> graphics facilities.  The one I wrote will work on an 8031

I find the traditional "display" is absent in probably 80-90%
of my designs.  It's an unnecessary expense, often decreases
reliability, is too tempting to resort to visual indications
that should often be "otherwise", etc.

> with 128 bytes of ram or 8032 with 256 bytes of ram with
> plenty left over for the application.

I have an MTOS that I often use on very small processors
(resource starved) that is blazingly fast (e.g., services
take handfuls of clock cycles).  But, it requires a LOT
of discipline to use -- because it *is* so skimpy on
resources!

> Of course, most folks creating an O/S for broader use aren't
> addressing such needs.

Exactly.  And, to encompass the widest range of potential
customers ^H^H^H er, *users* (:>) they adopt the "kitchen sink"
approach -- leading to something that is more bloated than it
needs to be.

Greetings,

thanks for the reply (and thanks to others who took time to respond
too!)

> > 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.

> Are you sure you understand what an RTOS *is*? =A0(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 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*?"

> With that in mind, what makes you think anything -- besides
> novelty -- that you come up with will be "attractive" to
> a potential "buyer"? =A0I don't see anything in your list
> of "Pros" that doesn't already exist, today. =A0Probably
> 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.

> It's one thing to release (FOSS) code you've already written
> in the hopes that others might find some use in it. =A0It'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". =A0Would
> you think many people would visit your "showroom" for anything
> more than curiosity factor? =A0("Oh, gee... it has four wheels!
> How novel!")

You're trying so hard to convince me that I can't "invent something
worthwhile"... projection?

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.

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.

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)?

[...]
> >* Worse support (supported only by John Doe Inc. and its distributors,
> >no match to Linux community)
>
> This is FUD RTOS support for the commercial RTOS I know if is much
> better than for Linux.
>
> Incidentally last time I looked on the list of Linux distributions over
> half were "obsolete/unsupported"

On Linux you have communities and support from hardware vendors in the
first place. E.g. if you ask MontaVista about "MontaVista Linux for
DaVinci" they won't have a clue. Its BSP, drivers and media packages
are written and supported by TI.

But this or that way for Linux you get support.

> >* Established bad reputation of dedicated RT/embedded OSes
>
> CRAP. Otherwise people would not be paying good money for commercial
> RTOS.

I could tell you real life cases about some of RTOS "market leaders"
dedicating support for brainwashing clients and getting sued at last,
but you may wish to call that CRAP too.

People are not paying for commercial RTOS. That's why RTOS market is
near-dead. 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.

> >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.

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.

Thanks for your response.
Daniel

> a) have I already a hardware platform (implication: have I already
> allowed for the system footprint of Linux and therefore don't care if
> JDOS would save some footprint)?

I think that if you are satisfied with existing Linux offer
(footprint, performance and responsiveness) you will decide in favor
of Linux (I would, anyway).

> is there already a Linux BSP for it?
> is there a John Doe BSP or must I develop it from scratch?

Let's assume there are ready BSPs for both.

> b) is there third-party IP I need to integrate? have the third parties
> already supported Linux? Is there any hope in hell they will ever give
> a damn about John Doe OS? Note this has nothing to do with your
> comment "we ported libraries". This might be proprietary software that
> you cannot access.

I think that closed-source third-party original IP won't be available
for JDOS, and decision here will go to Linux.

> c) will John Doe be around in 2 years? 5? 20? We have hardware
> platforms still in use that are almost 22 years old, running the
> original software stack.

Let's assume that John Doe will be available as long as Linux is
available. (There are sometimes shortings in Linux availability too,
e.g. TI's "MontaVista Linux" for DaVinci is stuck at 2.6.18, for some
reason they have trouble moving up). I want to compare cases of both
offers in "good shape".

> d) does my hardware/software toolchain vendor have explicit support
> for John Doe OS? There's a bit more to it than just gcc.

Yes (or the toolchain will be provided by JD).

> e) how hard will it be for me to move JDOS project on HW platform #1
> to HW platform #2?

About the same as compile Linux for another problem: reconfigure,
recompile.

Thanks for your response,
Daniel