Embedded Operating Systems - Part 1: Process implementation
CHAPTER 9. Embedded Operating Systems
An operating system (OS) is an optional part of an embedded device’s system software stack, meaning that not all embedded systems have one. OSs can be used on any processor (Instruction Set Architecture (ISA)) to which the OS has been ported. As shown in Figure 9-1, an OS either sits over the hardware, over the device driver layer, or over a BSP (Board Support Package, which will be discussed in Section 9.7).
Figure 9-1. OSs and the Embedded Systems Model.
The OS is a set of software libraries that serves two main purposes in an embedded system: providing an abstraction layer for software on top of the OS to be less dependent on hardware, making the development of middleware and applications that sit on top of the OS easier, and managing the various system hardware and software resources to ensure the entire system operates efficiently and reliably. While embedded OSs vary in what components they possess, all OSs have a kernel at the very least. The kernel is a component that contains the main functionality of the OS, specifically all or some combination of features and their interdependencies, shown in Figures 9-2a–e, including:
- Process Management: how the OS manages and views other software in the embedded system (via processes—more in Section 9.2, Multitasking and Process Management). A subfunction typically found within process management is interrupt and error detection management. The multiple interrupts and/or traps generated by the various processes need to be managed efficiently, so that they are handled correctly and the processes that triggered them are properly tracked.
- Memory Management: the embedded system’s memory space is shared by all the different processes, so that access and allocation of portions of the memory space need to be managed (more in Section 9.3, Memory Management). Within memory management, other subfunctions such as security system management allow for portions of the embedded system sensitive to disruptions that can result in the disabling of the system, to remain secure from unfriendly, or badly written, higher-layer software.
- I/O System Management: I/O devices also need to be shared among the various processes and so, just as with memory, access and allocation of an I/O device need to be managed (more in Section 9.4, I/O and File System Management). Through I/O system management, file system management can also be provided as a method of storing and managing data in the forms of files.
Figure 9-2a. General OS model.
Figure 9-2b. Kernel subsystem dependencies.
Figure 9-2c. Kernel subsystem dependencies.
Figure 9-2d. Kernel subsystem dependencies.
Figure 9-2e. Kernel subsystem dependencies.
Because of the way in which an OS manages the software in a system, using processes, the process management component is the most central subsystem in an OS. All other OS subsystems depend on the process management unit.
Since all code must be loaded into main memory (random access memory (RAM) or cache) for the master CPU to execute, with boot code and data located in non-volatile memory (read-only memory (ROM), Flash, etc.), the process management subsystem is equally dependent on the memory management subsystem.
I/O management, for example, could include networking I/O to interface with the memory manager in the case of a network file system (NFS).
Outside the kernel, the Memory Management and I/O Management subsystems then rely on the device drivers, and vice-versa, to access the hardware.
Whether inside or outside an OS kernel, OSs also vary in what other system software components, such as device drivers and middleware, they incorporate (if any). In fact, most embedded OSs are typically based upon one of three models, the monolithic, layered, or microkernel (client/server) design. In general, these models differ according to the internal design of the OS’s kernel, as well as what other system software has been incorporated into the OS. In a monolithic OS, middleware and device driver functionality is typically integrated into the OS along with the kernel. This type of OS is a single executable file containing all of these components (see Figure 9-3).
Figure 9-3. Monolithic OS block diagram.
Monolithic OSs are usually more difficult to scale down, modify, or debug than their other OS architecture counterparts, because of their inherently large, integrated, cross-dependent nature. Thus, a more popular algorithm, based upon the monolithic design, called the monolithic- modularized algorithm, has been implemented in OSs to allow for easier debugging, scalability, and better performance over the standard monolithic approach. In a monolithic- modularized OS, the functionality is integrated into a single executable file that is made up of modules, separate pieces of code reflecting various OS functionality. The embedded Linux OS is an example of a monolithic-based OS, whose main modules are shown in Figure 9-4. The Jbed RTOS, MicroC/OS-II, and PDOS are all examples of embedded monolithic OSs.
Figure 9-4. Linux OS block diagram.