EmbeddedRelated.com
Forums

RT/embedded OS use poll

Started by Stargazer December 20, 2010
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?

Thanks,
Daniel
In message <ea6af706-c355-457b-ac76-727186955caf@v17g2000vbo.googlegroup
s.com>, Stargazer <stargazer3p14@gmail.com> writes
>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)
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"
>* Established bad reputation of dedicated RT/embedded OSes
CRAP. Otherwise people would not be paying good money for commercial RTOS.
>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 are no simple Yes/No answers. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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. Mel.
On Dec 20, 8:08=A0am, 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.
Stargazer wrote:
> Pros: > > * Smaller footprint, better configurability > * More system resources left free > * Better performance of OS kernel and services > * Real-time responsiveness
This all gives a nice "it depends". This will be valid for an RTOS built from the ground up to be an RTOS, and if you're using it as an RTOS and nothing more. But nowadays you probably want a GUI, a network interface, a USB port, etc. For example, if the RTOS comes with a NetBSD network/filesystem stack, and you want to use it, it will obviously not use less resources than real NetBSD. (Which was enough reason for me to make my own filesystem stack at half the size and thrice the important features, but that's another story.)
> * Simpler build and maintenance > * Simpler programming
Depends on where you get your developers from. There are probably many more people who can program in a POSIX environment than people who know the John Doe API.
> 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
Again "it depends". Linux has the big problem that it's a very diverse project. There will be drivers, libraries, etc. which run on thousands of computers 24/7. And there will be code originating in a student project, running on an obscure platform (maybe the one you're planning to use?). A coworker occasionally talks about his nightmares with one such network driver: probably the student passed his seminar at the moment ping worked, case closed, next student please. So nobody notices that this driver leaks memory for each packet received. And you have the same problem with a commercial RTOS. Support quality will always vary. Support for core components will typically be magnitudes better than for more obscure "add-on" components which have three users world-wide, which are there just for a new bullet point in the glossy brochures. The problem is: you don't see from the code which kind it is. So you have to dive into its internals anyway.
> The question is: would you give a try for John Doe's RT/embedded OS?
Yes. Stefan

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. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
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. Either the OP has no idea what he is talking about, or he is trolling in some way.
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" -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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. 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. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
In message <5f50c89a-47c3-4eea-8f85-aeec0258e2e2@j32g2000prh.googlegroup
s.com>, larwe <zwsdotcom@gmail.com> writes
>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.
>Particularly your answer to c) would determine how likely it is I >would pick it up.
This is important. However it is not as obvious as it seems Last time this came up and some one mentioned obsolete commercial SW within an hour it transpired all of the list of half a dozen commercial systems that had been obsolete for 5-10 years could easily be supplied. Ironically a few weeks later some one actually needed an obsolete Franklin 8051 compiler from 14 years ago. IT was supplied in 4 days. On the other hand, last time I looked of the 450+ named distributions on the linux org site half were obsolete/unsupported. Open Source does not always mean a long or easy supply route and commercial does not always mean that the item will disappear even if the company producing it does. All of the commercial RTOS I know are supplied in source form anyway. I know about 10 years ago a company did try and drop an RTOS (to move the users to another one it had) but as the customers had the source they mainly carried on, and AFAIK still do to this day. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/