By John A. Carbone, Express Logic Inc.
While the use of Linux continues to sail along at a nice clip, the number of people kicking the tires is shrinking, for all the right reasons.
The Linux operating system (OS) has earned strong interest and adoption from those in the embedded software development community who are looking for cost-effective OS support for their latest embedded devices. In parallel, proprietary real-time OSs (RTOSs) offering robust arrays of services that are comparable to those in Linux have gained attention for safety-critical systems and large-scale telecommunications networks. In such applications, these complex RTOSs provide the capabilities that are needed, often including virtual memory, multiple independent levels of security (MILS), and volumes of middleware for security, communications protocols, and support for an array of development systems.
While Linux and complex RTOS products offer such attractive capabilities, they're also correspondingly difficult to learn and use due to these robust arrays of services. Linux includes hundreds of system services, virtual memory, and tens of millions of lines of open-source code. High-end commercial RTOSs also include many features and lots of code, making them (and Linux) a challenge to master.
Linux's complexity has created an industry dedicated to configuring and supporting it for use in embedded applications. These companies, most notably Wind River Systems and MontaVista, charge for their services, and their fees are well justified. Likewise, complex commercial RTOSs with hundreds of services, are generally expensive to license, often burdened with run-time royalties, and are relatively difficult to learn and use. For many high-end applications in defense and telecommunications, these complex OSs are necessary, and serve those needs well.
But what about the majority of applications where low-cost development and fast time-to-market are the primary goals and the system's technical requirements are relatively modest? Many companies developing electronic devices staff such projects with a few engineers in the hopes of containing cost. In these cases, there may be no room in the budget for commercial Linux support or in-house Linux gurus, nor for expensive proprietary solutions. Achieving fast time-to-market and low-cost development demand a simpler approach. There's little time to sort out configuration complexities, or to learn which of the many services are actually needed.
While Linux and complex RTOSs with similar features deliver abundant capabilities, they also occupy a fair bit of memory. If available memory is limited by physical footprint, cost, or power consumption constraints, or if low overhead and a rapid real-time response are needed, then it may be time to take an alternate approach. In such circumstances, a large Linux image or a complex RTOS might not cut it. What might be better is a smaller, simpler, more efficient solution, one that still meets the needs of the application, but doesn't impose unnecessary complexity on top. For such needs, a small-footprint, low-overhead, simpler RTOS might very well be more suitable.
One of the newer trends in embedded software involves designing simpler solutions for applications that don't need all the features. This concept applies to many embedded systems as they may not require virtual memory or hundreds of system services. Instead, many embedded real-time applications need just a few basic capabilities, such as priority-based preemptive scheduling, dynamic memory allocation and recovery, inter-task message passing, interrupt management, resource-locking semaphores, and timers.
Addressing these basic needs enables a simple RTOS to satisfy a large number of applications in consumer electronics, medical devices, industrial automation, test and measurement equipment, and wireless networking devices. Developers of these systems can minimize development time by choosing an RTOS that addresses their needs without excess complexity. Shortening development time pays additional dividends in lower development costs, faster time to market, and greater market share. For these applications, "less" actually is better, and delivers "more" for the developer.