For many applications, a strict RTOS is not a requirement. A router that uses some best effort mechanism is good enough, as long as it has a decent amount of average speed. It's just a matter of stress testing the box with high load and see if you accept the delays.
For many other applications, the other side of the spectrum works fine too. Most of of my stuff uses a "big main loop" approach, combined with real-time stuff in ISRs, and it works fine. If possible, I prefer this way because it doesn't waste RAM for task stacks, and it generally makes things quite straightforward.
I guess your experience differs from mine. In 30+ years designing real-time, embedded systems, I've yet to work with a company that "purchased" an RTOS. And, 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!). I write another RTOS for virtually every project I design (one size fits all *doesn't* :> )
Do you know what applications they are targeting with the Linux distro? I.e., is it really handling the RT aspects of the product? Or, some non-RT or SRT aspect of the product riding atop something else that actually handles the RT work (even "dedicated ISRs)? or, maybe just allowing "remote access" over a network?
Cisco sells hardware. It makes sense to cut their support costs for software. Especially since much of their hardware handles the HRT aspects of their applications. And, if Linux mimics the BSD distros, "routing" is handled in the stack/kernel, not in userland.
Again, what is Linux *doing* in those applications? Are you sure it's not serving a role that Windows does in similar applications? "Gee, if we use Linux, we can have a telnet service *and* Apache to serve up web pages for the 'configuration mode'..."
Lucent runs Inferno in their boxes. Inferno has *no* RT guarantees. (gee, what sort of application is that?)
TI sells hardware. Have you ever seen the quality of TI's "software products"?
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. How 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? Or, their lack of familiarity with "remote hosted" development? How often have you seen someone design display *hardware* (and video drivers, network drivers, 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.)
Ad hominem attacks. A great way to earn folks' respect and assistance. :>
I changed my mind. I am 1000% in favor of your idea. Go spend time and money pursuing it. Lots of it! Let us know how great it works out for you -- I'm sure we'll all be cheering for you! ;-)
formatting link
And before Linux, these same sorts of numbers were reflected by folks using Windows platforms for exactly the wrong reasons I outlined above.
Been there. Watched people design $1,000,000 production systems based on the mistaken belief that the display/GUI was the "hard part". Then wondered why their systems didn't quite work.
(I know of one firm that went through three revisions of a product following this approach -- never selling *one* of them!)
You think *you* can offer something better? How many thousands of developers will be backing you (for no wages) in this endeavor? Yet another Linux community??
If you look at the numbers, you'll see most embedded systems don't need the horsepower that Linux requires. They aren't the glamorous applications but they make lots of sales dollars.
RTOS's cost money to support. You don't hire a call center overseas to talk folks through their problems with a canned script. You need knowledgeable professionals to answer questions. *Good* support requires those professionals to get (slightly) involved in your application. Those professionals aren't cheap. A 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). If you absorb that cost, then you have to raise your licensing fees to cover it. If 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". "Um, then why did YOU recommend this approach to us?"
Customers object to licensing costs. For the same reason they grumble at a $5,000 compiler (it's not rational but it's how people think).
Most software engineers aren't particularly hardware literate. So, if drivers for *their* hardware aren't available, their eyes glaze over. For fancier hardware (video, network, etc.) most folks have little experience with the chip du jour and surely won't get up to speed on *that* device in the time allowed for the entire project (how many I/O devices does VxWorks support? If I want to add a 1394 controller to my design (by cribbing an application note), will they have a "drop in" driver that does the trick?
My "GUI" comment is a perfect example of this. I'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. Are you ready to undertake that development? Do you think you have the skills to get the hardware designed AND drivers written?
Consider how quickly people want to see something on a display to reassure themselves that they are "making progress". Even if the heart of the product has nothing at all to do with that.
(e.g., I'm a bottom up implementer -- top down *designer*. The first thing I get working is the drivers. And, I use a scope or a logic analyzer to verify their operation. Nothing that I can sit back and point to as "Wow, look at the blinking text on the screen!!" New clients *freak* because they don't SEE ANYTHING for a long time. Then, *suddenly*, it's "done". They're *used to* seeing silly little blobs on a screen and, as long as they see more blobs each day, they think progress is being made -- even though there is "nothing under the hood".)
Look at how many experimental OS's end up having to support POSIX API's and user interfaces just to gain acceptance...
Then all Linux distributions are the same... a more than 50% chance it will become unsupported in the next 3 years, won't have support for your target. Generalisations are pointless.
No, RTOS are used where real time is needed. Linux is not real time.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
DVR's, for example, are a market dominated by embedded Linux systems. Video streaming systems /often/ use Linux, but not necessarily. Network filtering appliances also often use Linux these days, but many use dedicated systems (rather than general-purpose RTOSes). Budget routers may or may not use Linux, depending on the features they have (Linux gives a cheap path to more features, but requires higher hardware costs for more memory). Motor controllers, on the other hand, are seldom Linux-based - while you can get hard real-time Linux systems, it is not suitable for such systems.
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.
They offer embedded Linux distros as base support for evaluation boards / SBCs for everything, unless you ask for specific features or certifications.
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.
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.
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).
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.
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.
I thought that was common knowledge for years... no?
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.
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).
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).
You are write, hardware support availability is an immediate stopper. But this is solvable for RTOS case.
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.
I think your cons apply to embedded Linux as well, at least somewhat. There's a lot more enthusiasm surrounding open software support, but to some extent that means that you get a lot of poor advise. It's like figuring out how to fix a car by talking to your friends around the water cooler -- it often works, but it often leads to you pouring money down a rat hole.
Ditto reputation. Linux as a _desktop_ app has a solid rep, but Linux as an RTOS hasn't developed much of a rep yet -- and RT Linux is a different critter from 'regular old' Linux.
For me I think it'd be a wash, if the system were big enough to need a "big box" OS. I think it'd depend on things you hadn't mentioned, like what the other members of my team thought (including management, who will be writing checks for either Linux consultants or OS licenses) and whether one or the other had a demonstrable ability to work on the hardware that I was building.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
I once made a 802.11 WiFi protocol stack where all radio timing was done in software using various interrupts. Some states had a periodic timer interrupt that ran every 9 usec, with
Consolidation is a natural part of the free market system - it doesn't me= an that RTOSes (or probably more correct 'embedded OS' will all disappear -= that's why having the source code is important if you need long term maint= enance for your embedded project
Well my Samsung BlueRay player, and my TV, and my smartphone, and both wireless routers are all running Linux inside. They are all realtime in the sense that they manage to do what they need to do, in time for when it needs to be done. Linux did become ubiquitous in the smart electronics area.
That is definitely true; just because Samsung has a successful product doesn't mean that anyone can bring it up---just that there are foundations (kernel, drivers, protocol stacks, application libraries) to build upon.
Ooh, big asterisk on that though. I don't know what's in the Blu-Ray player, but in the case of the cellphone, the baseband processor is almost certainly a separate core running dedicated (non-Linux) code. The code running on the Linux core(s) is app code, not much realtimishness.
Similarly, the TV set likely does much of the "really RT" stuff in hardware in an ASIC.
My favorite realtime story told by someone who's been in business forever. Long, long ago he had military customers with a new mysterious project and were asking about the capabilities of his product: "It absolutely has to be real-time: the maximum allowable latency cannot be exceeded". He asked for the value of the latency, and was told it was a couple hundred seconds. The bottom line is, real time doesn't have to be fast---it has to be fast enough for the job.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.