A multitasking operating system has become essential to untangle the complex layers of software needed to drive the latest generation of interactive and networked embedded products. But before you pick the operating system software to be at the heart of your next design, take a look at the basic requirements and how they might affect overall product performance and the software development process.
As embedded devices continue to increase in complexity, the software development task has become the largest element of the typical project budget. Graphical interfaces, network protocols, and data security are just a few of the new requirements that design teams can find added on top of their custom application software. With this growing software burden along with customer demand for faster response times and instant data access, operating systems have become an essential element to organize and prioritize the software and hardware interaction routines. Unlike the desktop environment where only a few operating systems prevail, embedded designers have hundreds of options and the right choice depends on the special needs and requirements of each project.
The basic functions of an operating system are to manage the system’s peripherals and schedule software tasks to ensure that each program gets some processor time. A file system is also part of a standard OS to store software modules and boot instructions. Another big benefit of an OS is to provide networking software and drivers for common hardware peripherals, eliminating constant reinvention. However, an embedded OS is quite different from its desktop counterpart. Desktop systems assume a keyboard, a mouse, a display, a hard disk, and plenty of memory. However, there is no such standardization in embedded products. One embedded system might have no hard disk and limited memory while another has no user I/O at all. An embedded OS must also be modular, allowing components to be added or removed to adjust the memory footprint such as is possible with thefrom (see Figure 1). Before settling on an OS, designers should understand scheduling algorithms, memory requirements, latencies, tool support, and pricing models.
Hard or soft
As designers piece together the requirements for each new project, real-time performance is one of the early considerations. OS vendors use terms like “hard” and “soft” to describe the real-time operation of their systems. Hard real-time systems are scheduled so tasks are guaranteed to start within a precise length of time from an external event. Hard real-time systems are deterministic. Soft real-time systems generally list the average length of time to start the routine, but there is a small probability that the maximum time can be much longer. Mission-critical applications must be deterministic. For example, industrial actuators, airbag controllers, and even arcade games must react in a known time. Soft real-time applications usually respond within a few seconds but an occasional slow response is not critical.
The basic architecture of a real-time operating system includes a program interface, the kernel, device drivers, and optional service modules. The kernel is the core of the operating system and provides an interrupt handler, task scheduler, resource sharing flags, and memory management. The kernel’s services are requested by calls to its Application Program Interface (API). The kernel is active continuously during real-time operation and must remain memory resident. One of the kernel’s primary functions is to process interrupts caused by external or internal events. When an interrupt occurs, the processor transfers control to an interrupt service routine that logs in the interrupt, sends a message to the scheduler, and returns to the active code. The scheduler sets up the order of execution of individual tasks to ensure that a higher-priority task can preempt a lower-priority task to maintain a deterministic response. The most popular scheduling technique is preemptive, prioritized scheduling where tasks can interrupt a lower-priority task and continue execution until finished or until preempted by a higher-priority task.
The development tool chain is another big issue in the selection of an OS. Developers will spend most of their software design and debug efforts interacting with the Integrated Development Environment (IDE) to gain quick access to the editor, compiler, linker, downloader, and runtime tools. Most vendors provide a full IDE including the source code editor, the code manager, links to the compiler and linker, software to download code to the target platform, and one or more debuggers. Software vendors also supply software performance analysis tools to help developers profile and visualize the real-time activity in software. Many of these analysis tools are optional and will add to the overall tool cost.offers the (IDE) to support a variety of OSs. The IDE software tools include several C compiler options, editor, configuration manager, code browser, and debugger in a single package. MULTI also features , an integrated static analyzer that isolates bugs caused by complex interactions between code segments that might not be in the same source file.
Cost is obviously a major deciding factor when selecting an embedded operating system. Since there is essentially no cost of goods with software, vendors can adjust their pricing model to generate revenue from various sources. Vendors can charge for an initial license fee, development seats per engineer, development tools, per-unit royalties, continuing support, or major upgrades. To fairly compare prices, the overall cost of ownership must be computed for each OS being considered. The calculation must include the number of units planned for delivery over the life of the product. Although a commercial OS can be expensive, cost savings is an important reason to purchase an off-the-shelf product. If you can purchase and therefore eliminate the coding, debug, and documentation of the most complicated portion of the software, you should give it careful consideration. Vendors promote product technical support as a major benefit of a commercial OS. They are able to provide continuous support for the operating system portion of the software by spreading the cost over all customers.
After a life-cycle analysis and the “sticker shock” associated with the cost of a commercial OS, designers usually also consider “free” open source operating systems. Although open source software eliminates some initial cost problems, there are still significant issues that must be addressed. One problem voiced by potential open source users is the lack of a central resource to provide support similar to a commercial software vendor. Developers can often find answers to their questions through the Internet, but no one is on the hook to research and respond to a specific question. Open source products are generalized in order to fit the widest array of users and can force designers to modify the hardware configuration, resulting in higher recurring cost for the embedded device. Also, open source software is not in the public domain and users must adhere to specific rules set forth in individual licenses that may force designers to reveal the source code to proprietary software. Even with these hurdles, open source operating systems are widely used in embedded design.
An added consideration when selecting an OS is the trade-off between the initial hardware footprint required and the ability to add features when updates become necessary. The OS must be scalable so that users can select just those portions or features of the software system that they need. With constantly changing requirements and embedded technology, designers want to be able to download new software modules to add or revise features for future updates. Offering to reduce the bill of materials cost for embedded devices, thefrom allows developers to deploy a kernel as small as 2k on a wide selection of processor hardware. With the modular structure, designers can reduce the initial cost of the OS by selecting a subset of the available features and also the amount of ROM and RAM to support the system.
One of the favorite shortcuts of embedded designers is to start a project with a Commercial Off-the-Shelf (COTS) module to eliminate much of the hardware development and testing. This same shortcut can be extended to the software by selecting an operating system with a board support package for the target hardware. For example,offers for more than 150 COTS processor boards for their real-time operating system. These packages include ARM, PowerPC, x86, MicroBlaze, and MIPS processor boards. This approach can shorten the overall development schedule, allowing the design team to concentrate on the proprietary portion of the embedded project.
As customer demand for universal connectivity, faster response times, complex functionality, and instant data access spreads into more and more devices, designers can expect real-time operating system software as the norm in future embedded products. Fortunately, real-time vendors and open source collections offer plenty of off-the-shelf, ready-to-run software packages to fit most embedded configurations. The challenge will be to analyze your requirements to match an operating system to the application with ample room for growth while minimizing the cost and development effort.