"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
RT/embedded OS use poll
Started by ●December 20, 2010
Reply by ●December 20, 20102010-12-20
Reply by ●December 20, 20102010-12-20
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"
Reply by ●December 20, 20102010-12-20
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?
Reply by ●December 20, 20102010-12-20
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.
Reply by ●December 20, 20102010-12-20
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
Reply by ●December 20, 20102010-12-20
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.
Reply by ●December 20, 20102010-12-20
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 aYup. "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 toExactly. 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 evenLately, 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 8031I 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.
Reply by ●December 20, 20102010-12-20
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)?
Reply by ●December 20, 20102010-12-20
[...]> >* 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
Reply by ●December 20, 20102010-12-20
> 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