RT/embedded OS use poll

In message , Stargazer writes

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"

CRAP. Otherwise people would not be paying good money for commercial RTOS.

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

We haven't met John Doe Inc. yet. I think that's the OP's point.

Mel.

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.

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

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.

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.

Yes.

Stefan

It doesn't matter. Whichever way you take, you will have to do everything yourself.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

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.

True but that does not mean it will be "no match to Linux community"

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

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 , larwe writes

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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

+42

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

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?

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.

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

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.

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.

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

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

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

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)

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.

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!

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

Yes I know (VxWorks, long-dead pSOS, LynxOS, Integrity, ThreadX, Nucleus, TRON, QNX, uCOS, eCOS, ...)

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 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*?"

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

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,

-number-one-in-Asia/,

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

[...]

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.

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.

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

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

Let's assume there are ready BSPs for both.

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

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

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

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

Thanks for your response, Daniel