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