While the bare-metal, single-thread approach is still the most popular when designing embedded solutions, many systems can benefit from multitasking scheduling, centralized resource management, and a safer environment; several existing implementations are available to select an operating system that works well with the specific design.
Building a scheduler tailored to a custom solution from scratch is not impossible and, if done properly, would provide the closest approximation of the desired architecture, while focusing on the specific characteristics offered by the target hardware. In a real-life scenario, however, it is advisable to consider one of the many open source embedded operating systems available and ready to be integrated in the architecture, among those supporting the selected hardware platform. Some of the available kernels are in a healthy development state, deserving their well-established role in the embedded market, and sufficiently tested to provide a foundation to build reliable embedded multitasking applications.
On many 32-bit microcontrollers, hardware features are provided to facilitate the design of multithreaded systems. As we saw Chapter 10, Parallel Tasks and Scheduling, carefully selecting which optional feature to implement is a critical aspect that might impact the safety of the system and its performance figures. The design choice depends on the compromises that the OS developers may decide to implement, such as latency versus performance, and code size versus safety. For this reason, no system is the same as another, and each one has peculiar characteristics that make it usable for a specific purpose rather than others, depending most of the time on the platform and the use cases the system had been originally designed for.
The API offered to applications is often customized to reflect the characteristics of the system. In some cases, this means that applications must be written using the provided API in order to run on a specific system. Operating systems in personal computers and mobile devices follow interface standards, such as POSIX, which can be implemented in embedded systems, taking into account the restriction on resources and physical memory mapping.
Selecting the operating system that best fits the purpose and the platform under development is a delicate task that impacts the overall architecture, may have consequences on the whole development model, and may introduce API lock-ins in the application code base. The criteria for selection vary according to the hardware characteristics, the integration with the other components, such as third-party libraries, the facilities offered to interact with peripherals and interfaces, and, most importantly, the range of use cases that the system is designed to cover.
With a few exceptions, operating systems include, alongside the scheduler and the memory management, a set of integrated libraries, modules, and tools. Depending on the purpose, an embedded system may provide:
- Platform-specific hardware abstraction layers
- Device drivers for common peripherals
- TCP/IP stack integration for connectivity
- Filesystems and file abstractions
- Integrated power-management systems
Depending on the implementation of the thread model in the scheduler, some systems are expected to run with a fixed amount of predefined tasks, configured at compile time, while others opt for more complex processes and thread hierarchies that allow us to create new threads at runtime, and terminate them at any point in the execution.
More complex systems introduce some overhead due to the additional logic in the system exceptions code, and are less fit for critical real-time operations, which is the reason why most successful RTOSes nowadays maintain their simple architecture, providing the bare minimum to run multiple threads with a flat-memory mode that is easy to manage and does not require additional context switches to manage the privilege of the operations, keeping the latency low for real-time tasks.
While these solutions are designed to provide support to build devices with a specific purpose, such as integrated signal processing systems, the increasing popularity of connected and low-power devices has encouraged the development of new operating systems that integrate connectivity features, low-power management APIs, device drivers, and specific system support for their reference platforms.
High-end microcontrollers also offer the means to build complete development platforms, flexible and reusable for different purposes, often just by loading new application software to improve and extend their functionalities with little or no downtime. In the recent history of microcontrollers, high-end platforms available in the market have become more powerful than the average personal computer of just 20 years ago, and have started to offer more and more support to run operating systems. A 32-bit microcontroller has enough features to run an operating system in kernel mode, thanks to privilege separation, multiple stack pointers, memory protection, and supervisor calls, despite the restricted amount of resources and the lack of an MMU.
Following the direction of general-purpose systems, some research has been conducted to develop operating systems implemented according to the POSIX standards, to encourage the development of portable application software, which also shares many similarities with modern UNIX-like systems. Adopting POSIX standards introduces a number of benefits on many levels.
In other scenarios, it is important to detect and counter the effects of defects in the application software, which may impact the integrity or the stability of the system.
Running systems with a flat-memory model and without any privilege separation or memory segmentation may increase the risk of critical issues in the system that are also difficult to identify on those systems running a higher number of applications. A safe system provides the mechanisms needed to isolate the processes and supervise all the operations involving any critical part of the system, denying direct access to resources and reserved memory areas. New software technologies are available to build safe operating systems, providing more effective strategies for process isolation.
In this chapter, we'll analyze some of the most popular open source operating systems through their features and design choices, and we'll discuss the approach taken by different communities on features such as power management, connectivity, communication security, and system safety.
We have put a few open source systems in groups, based on the similarities of their design choices and their field of application. The sections covered in this chapter are:
- Real-time application platforms
- Low-power IoT systems
- POSIX-compliant systems
- The future of safe embedded systems