#include
Embedded Machismo
Just the mention of Jean Labrosse’s µ/COS on these pages has been known to make a few real-time operating system vendors squirm. Not all of them, mind you. The president
of one popular RTOS company shrugs and says, “Hey, an RTOS isn’t that tough to write.” But some vendors fear losing potential customers who choose to develop their own proprietary RTOSes, rather than buying one of the many fine products available on the market.
Perhaps RTOS vendors have reason for concern. In the universe of systems that require RTOSes, the single most widely used RTOS is the one called “proprietary,” according to data we’ve collected. This fact has always
perplexed me. While vertical integration has its merits (for example, when large hamburger franchises raise their own cattle), a company that tries to do everything is liable to find its engineering resources spread way too thin. Maintaining a proprietary RTOS in addition to doing product development is a perfect way to overextend. The use of commercially available RTOSes, as well as other off-the-shelf components, such as communications protocols, or even embedded PCs, can quell a lot of headaches. So the
question is, why would anyone want to write an RTOS when so many commercial versions are available?
Although some engineering groups may do it just because they can or to avoid the not-invented-here syndrome, most have legitimate reasons based on economics. They may find themselves in the position of having to stick with a proprietary RTOS because the cost of maintaining it is less onerous than starting from scratch with an unfamiliar commercial OS and having to rewrite a lot of legacy code.
Sooner or
later though, the need to add features or computing power will lead most companies to consider a new architecture and tools. At that point, why would anyone stick with a proprietary RTOS? Any part of your system that you can buy off the shelf rather than build will get you to market faster and eliminate a lot of maintenance headaches down the road.
Not only can you get tools off-the-shelf, but you can get design services as well. Outsourcing has become common for both hardware and software development, to
meet the challenges of increasingly complex, more highly integrated systems and shorter design cycles. Like commercially available components, outsourcing is a way of hedging your bets in the face of these challenges. It helps you get products to market that contain a wide range of features that can’t all be designed in house. For example, a company may not have expertise in both wireless and multimedia. Outsourcing some of the job lets the company focus on what it does best.
Recognizing this need,
Cadence Design Systems, a giant in the chip design tool and service business, has extended its service organization to encompass embedded software development (see “Cadence Ventures into Embedded Software” in the News Vectors section on p. 11). This step is an acknowledgement of the reality that developers can’t do it all themselves. Finding success means that companies must concentrate on what most directly affects their end product, use commercially available development tools and components,
and farm out some of the development.
If real men roll their own RTOSes, they do so at their own peril.
Return to Embedded.com
Send comments to:
Webmaster
All material on this site Copyright © 2000
CMP Media Inc. All rights reserved.
|
