I was quoted (mostly accurately đ over at Embedded.com, in an analysis of the results of the 2007 survey of embedded system designers. There are some interesting year-on-year trends, including an increase in the use of C vs. C++ and a decrease in the use of both commercial and open-source operating systems such as VxWorks and Linux.
Posts Tagged ‘rtos’
Moving Targets
Monday, March 3rd, 2003 Michael BarrThere are currently so many interesting operating systems and alternatives that itâs hard to chooseâas we must for each projectâjust one. Within the priority-based preemptive category, you can choose based on worst-case latency, source code availability, upfront and/or recurring cost, memory usage, API/features, and numerous other criteria. Indeed, the realm of possible price/feature combinations has fragmented the market into many tiny niches.
Though there are a handful of well-known names that have the bulk of the market tied up, a sizeable number of smaller RTOS providers do quite a nice business on just a tiny fraction of total market share. And as the demand for embedded operating systems continues to accelerate, these smaller vendors need not even hold their market share numbers to continue to increase profits. Thatâs goodâbecause they will continue to lose market share.
There are a lot of forces that will shape the RTOS marketplace going forwardâas it goes even more toward the big guys. Not the least of these factors is that more of us will go off-the-shelf. Among subscribers to Embedded Systems Programming magazine, for example, the percentage using no OS or a proprietary alternative has fallen from 38% to about 18% in just the past five years. Extrapolating, perhaps weâll all be using off-the-shelf OS code by 2007.
Competition from âdesktop-liteâ operating systems has also picked up. There are a large number of embedded designs that look (or can look) an awful lot like a PC inside, benefit from the low component costs in that market, and no more than dabble in the realm of real-time. What used to be a small ROM-DOS market has morphed into todayâs WinCE/XP and Linux marketâalmost entirely in the last three years. In 2002, some 17% of you fell into that category; I suspect itâs not a coincidence that x86 architectures continued to dominate the list of 32-bit processor choices.
And then thereâs consolidation. Though the pace of consolidation has slowed with the business cycle, the effects continue to be felt. Mostly it was the vendors of 32-bit solutions that picked up 8- and 16-bit competitors and debugging tools when times were goodâso they could offer one-stop shopping. An up-and-coming Linux player even spent some of its paper wealth to acquire a commercial RTOS vendor for that same purpose. To compete, a large commercial vendor picked up an open source, though non-Linux, OS. When the buying resumes, as it surely will, where will it ultimately end?
Several of the technologies positioned to profit from these trends are not what we traditionally think of as âembedded.â Microsoft, whichâlove âem or hate âemâcorrectly understands they must make it in the embedded space to stay relevant in the coming decade, is trying hard to find the right combination of OS features and vertical markets. In many of these markets, theyâre competing directly against the open source alternativesâand apparently losing in some. According to a recent article in EE Times, Linux is also beating out traditional RTOSes in key markets like consumer electronics.
Of all the traditional vendors, Wind River is probably in the best position to compete with these market forces and survive. We are fortunate in the embedded space to have lots of choice when it comes to operating systems. But the future may hold far less technological alternatives. Itâs not clear to me that QNX, VxWorks, Nucleus, or any other RTOS is really distinguishable from another in the boardroomâor that the smaller players have enough to gain by staying in the business longer term. What do you think?
Beyond the RTOS
Thursday, December 12th, 2002 Michael BarrSelecting a plural form for RTOS is hard; there is no one right way. Some possibilities, listed in order of increasing popularity (on the Web), include RTOSâs, RTOSes, and RTOSs. The first implies a possessive aspect thatâs clearly not appropriate, so that variant is best avoided. Between the other two, the vast majority of trade journals have adopted RTOSes as their preferred style. Though, apparently, not everyone is yet convinced.
In addition to trying to standardize the language readers use to communicate with one another, an important role of trade journals is helping spread useful new techniques and best practices quickly. For example, numerous articles and columns in past issues of Embedded Systems Programming have helped popularize the use of RTOSes. Approximately half of that magazine’s subscribers now use a commercial RTOS to get the job done.
Unfortunately, however, most of the differentiation between the hundred or so RTOS vendors is on the price and support side, leaving embedded programmers to develop their own solutions when a preemptive priority-based scheduler doesnât fit the problem at hand. In fact, as RTOS vendors continue to argue against ârolling your ownâ and worry about lower-cost or no-cost competitors, I would argue that most are overlooking the technically obvious.
Static-priority preemptive schedulers, with priorities assigned rate or deadline monotonically, work very well in certain real time systems with high degrees of both parallelism and periodicity. Telecom and datacom products, with their many communication channels, are often of this type.
But the tradeoffs, including increased interrupt latency and potential priority inversions, are significant. Though it can be made to fit some, the static-priority preemptive solution just doesnât fit the needs of a large population of systems quite right. Some tasks are periodic, but many others are not. Some systems have hard deadlines, but many others do not (or can safely miss a few now and then). In such cases other types of multitasking (or even the lack thereof) may be preferable to the much-touted RTOS.
Alternative ways of structuring embedded software run the gamut from simple main()+ISR implementations to the use of dynamic priorities. For example, a simple executive is a low overhead technique that works quite well for hard real-time systems with harmonic deadline periods and a small number of things to get done. And state machines can be executed in a series of run-to-completion steps via a framework like that outlined in Miro Samekâs excellent book Practical Statecharts in C and C++ (CMP Books). Taking another approach, Java and Ada support threads natively, making the choice of a particular RTOS largely irrelevant.
My point? The hundred plus commercial RTOSes available today have too much in common technically. Not every embedded designer benefits from adding a static-priority preemptive scheduler; many software designs are, in fact, harder with preemption. RTOS vendors might do better to view themselves as providers of software frameworks for developing embedded software, and differentiate themselves by offering more than one technique. Just as there are currently various ways of pluralizing RTOS, there are also various ways of doing without one.
