The average person interacts with hundreds of embedded processors every day in phones, automobiles, home appliances, toys, cash registers, entertainment electronics, security systems, environmental controls, and personal electronics. The common link among all of these products is their ability to react in real time to the user, external events, and the communications channel.

The software for these embedded devices can be divided into application software and Operating System (OS) software. Application software makes the product unique and contains the data collection, signal processing, and hardware control routines required to make the product perform to its specification. The OS allows the programmer to break up large application programs into smaller, individually developed processes or tasks.

At the heart of an OS is the kernel, which schedules programs for execution and manages shared resources. A Real-Time OS (RTOS) processes hardware requests or interrupts from timers or external events within a guaranteed maximum time. Programmers interact with the OS through an API and set up the priorities and data dependencies. During execution, the RTOS manages the application software with a flurry of external real-time activity.

In-house code

Even with the advantages of an RTOS, homegrown OSs still occupy a non-trivial percentage of embedded real-time products. Developers have multiple incentives for bypassing a commercial RTOS entirely and writing their own real-time routines. The biggest reason developers cite for not choosing a commercial OS is lack of need. With only one task running, designers think they can easily keep track of the required hardware interaction.

Special situations sometimes justify in-house software. For example, the design objectives of a portable health care device can include low cost, low power, and a one-year battery standby life without extra memory and processing power to support a commercial RTOS. Furthermore, if a new project is an upgrade of a previous project, developers likely will want to use as much legacy code as possible.

Components that aren’t invented at the same company might also be one reason why many developers write their own OSs. Installing software from a third party into their showpiece product is like admitting they are somehow not up to the task. In addition, developers might think they’ll lose the ability to make software adjustments to compensate for hardware changes or to correct bugs. The designer can easily adjust the order of execution or drop to assembly language to solve critical timing problems with in-house developed software. However, with a commercial RTOS, the scheduler handles many of the timing issues, so developers lose the perception of being in total control. And finally, programmers list sticker shock as another reason to write their own operating software. The initial license for a full commercial RTOS and associated tools can be in the $15,000 to $20,000 range for a single development seat, plus recurring royalties for every unit shipped.

Software shortcuts

As embedded systems grow in complexity and project schedules shrink, software has displaced hardware as the highest-priced item in most embedded development projects. If design teams can buy an RTOS and eliminate the coding, debug, and documentation of the most complicated portion of the software structure, then the purchase decision should receive careful consideration. Although a commercial RTOS can be expensive, a smaller development team and shorter project time frame might create more than enough savings to justify the purchase.

An RTOS allows programmers to write independent, reusable modules to reduce software complexity and shorten the development schedule. Programmers can write each software routine independently without getting bogged down with intertask timing problems. Most RTOS vendors provide a full interactive development environment including a source code editor, code manager, linker, downloader, runtime tools, and one or more debuggers. Software vendors also supply software performance analysis tools to help profile and visualize real-time activity in application routines. Programmers can monitor which tasks are running, observe the stream of data flow, and detect when and how often a task is interrupted by a higher-priority item. RTOS vendors agree that high-quality development tools can dramatically shorten debug time.

Along with the cost savings, RTOS vendors cite multiple technical reasons to justify their products. For example, if an application involves heavy data processing, many RTOSs can be scaled easily to spread tasks across several processors for a significant performance boost. The RTOS provides communication and synchronization services to make multiprocessing transparent. In addition, an off-the-shelf RTOS working alongside multicore processors simplifies legacy code integration within new designs or products updates.

A commercial RTOS is modular, so users can select only those portions or features of the OS that they need. Specifying a subset of the full-blown commercial RTOS can reduce acquisition costs and the required memory footprint. With the current connectivity trend, even the simplest embedded products might need to connect to and send data over the Internet. A graphical user interface could also become standard in small embedded systems, even if just for maintenance. These features are included or optionally available in most commercial RTOSs, but can be very expensive or impossible to add to a proprietary OS. Vendors also promote product on-demand technical support as a major benefit of a commercial RTOS.

Off-the-shelf platforms

Commercial RTOSs are constantly upgraded to add new features and keep up with changing technology. For example, the popular VxWorks OS from Wind River was recently revised to deliver 64-bit computing support along with improved multicore features. VxWorks includes a shell, debugging functions, memory management, performance monitoring, and support for multiprocessing. Real-time features include a kernel for preemptive multitasking, interrupt response, interprocess communication, and a file system (see block diagram in Figure 1). Software development is enabled by the Wind River Workbench development tools suite and Intel Integrated Performance Primitives for VxWorks.

The RTOS supports various multicore configurations in Symmetrical Multi-Processing (SMP) and Asymmetrical Multi-Processing (AMP) modes or as a guest OS on top of Wind River Hypervisor. VxWorks also has a configurable and tunable small memory footprint, allowing the user to control how much of the OS to employ for each project.

In addition to offering a multitude of commercial RTOS products, the embedded systems community maintains an open-source OS based on a real-time kernel that is free for use in commercial applications. The FreeRTOS Project is under continuous active development and is distributed under the GNU General Public License with an optional exception that allows users to keep their proprietary software confidential. Free source code and the lack of recurring royalties are popular features for small, low-budget embedded projects. FreeRTOS has been ported to multiple microcontroller platforms and has minimal ROM, RAM, and processing overhead, resulting in a typical kernel binary image in the 4 KB to 9 KB range. Although FreeRTOS source code for the kernel is contained in only three C code files, the zip file download includes numerous demonstration applications to help new users get started.

The biggest complaint among potential open-source software users is the lack of a central resource to provide support similar to that offered by a commercial software vendor; however, the FreeRTOS website has an active free support forum where developers can find answers to their technical questions. In support of the open-source platform, Microchip Technology offers the FreeRTOS Microchip PIC32 Education Kit (see Figure 2). This $95 kit includes a development board that enables users to develop USB embedded host, device, and On-The-Go applications on the PIC32 microcontroller family.

Real-time future

Although programmers might get excited when considering the challenge of developing an in-house OS, the “roll your own” days might be fading away. Designers can look forward to real-time software as the norm in future embedded products.

Customer demand for faster response times, complex functionality, and instant data access continues to increase the challenge of embedded design. Advancing technology also dictates that embedded products be capable of periodic software updates as requirements change, along with the possible transfer to the next-generation hardware platform.

Developers should take the time to analyze their system requirements, development schedule, software support, expandability, communications, scalability, and future growth before embarking on an in-house software development project. An off-the-shelf commercial RTOS or even an open-source operating system could be in your future.