Chapter 3. Developing for Embedded Linux and Similar Systems

Small, SoC-based systems are everywhere these days, from smartphones, video game consoles, and smart television sets, to infotainment systems in cars and airplanes. Consumer devices relying on such systems are extremely common.

In addition to consumer devices, they're also found as part of industrial and building-level controller systems, where they monitor equipment, respond to input, and execute scheduled tasks for whole networks of sensors and actuators. Compared to MCUs, SoCs are not as resource-limited, usually running a full operating system (OS) such as a Linux-derived OS, VxWorks, or QNX.

In this chapter, we will cover the following topics:

• How to develop drivers for OS-based embedded systems
• Ways to integrate peripherals
• How to handle and implement real-time performance requirements
• Recognizing and dealing with resource limitations

Embedded operating systems

An OS is typically used with an embedded system when you're writing your application directly for the system's hardware, which is an unrealistic proposal. What an OS provides to the application is a number of APIs that abstract away the hardware and functionality implemented using this hardware, such as network communications or video output.

The trade-off here is between convenience and both code size and complexity.

 

Whereas a bare metal implementation ideally implements only those features it needs, an operating system comes with a task scheduler, along with functionality that the application being run may not ever need. For this reason, it's important to know when to use an OS instead of developing directly for the hardware, understanding the complications that come with either.

Good reasons to use an OS are if you have to be able to run different tasks simultaneously (multitasking, or multithreading). Implementing your own scheduler from scratch is generally...

Real-time OSes

The basic requirement for a real-time OS (RTOS) is that it can guarantee that tasks will be executed and finished within a certain time span. This allows one to use them for real-time applications where variability (jitter) between the execution times of a batch of the same task is not acceptable.

From this, we can draw the basic distinction between hard and soft real-time OSes: with low jitter, the OS is hard real-time, as it can guarantee that a given task will always be executed with practically the same delay. With higher jitter, the OS can usually but not always execute a task with the same delay.

Within these two categories, we can again distinguish between event-driven and time-sharing schedulers. The former switches tasks based on priority (priority scheduling), whereas the latter uses a timer to regularly switch tasks. Which design is better depends on what one uses the system for.

The main thing that time sharing has over event-driven schedulers is that since it gives...

Custom peripherals and drivers

A peripheral is defined as an ancillary device that adds I/O or other functionality to a computer system. This can be anything from an I2C, SPI, or SD card controller to an audio or graphics device. Most of those are part of the physical SoC, with others added via interfaces that the SoC exposes to the outside world. Examples of external peripherals would be RAM (via the RAM controller) and a real-time clock (RTC).

One issue that one will likely encounter when using cheaper SBCs such as the Raspberry Pi, Orange Pi, and countless similar systems is that they usually lack an RTC, meaning that when they are powered off, they no longer keep track of the time. The thought behind this is usually that those boards will be connected to the internet anyway, so the OS can use an online time service (Network Time Protocol, or NTP) to synchronize the system time, thus saving board space.

One might end up using an SBC in a situation where no internet connection is available...

Resource limitations

Even though SBCs and SoCs tend to be fairly powerful, they are still no direct comparison to a modern desktop system or server. They have distinct limits in terms of RAM, storage size, and lack of expansion options.

With wildly varying amounts of (permanently installed) RAM, you have to consider the memory needs of the applications one wishes to run on the system before even considering the relatively sluggish CPU performance.

As SBCs tend to not have any, or significant amounts of, storage with a high endurance rate (meaning it can be written to often without limited write cycles to take into account), they generally do not have swap space and keep everything in the available RAM. Without the fallback of swap, any memory leaks and excessive memory usage will rapidly lead to a non-functioning or constantly restarting system.

Even though CPU performance on SBCs has increased significantly over the years for commonly available models, it is generally still advisable to use...

Example – club room monitoring

In this section, we will be looking at a practical implementation of an SBC-based solution that performs the following functionality for a club room:

• Monitors the status of the club door's lock
• Monitors the club status switch
• Sends status change notifications over MQTT
• Provides a REST API for the current club status
• Controls status lights
• Controls the power in the club room

The basic use case here is that we have a club room for which we want to be able to monitor the status of its lock, and have a switch inside the club to regulate whether the non-permanent power outlets in the club are powered on or not. Turning the club status switch to on would provide power to those outlets. We also want to send out a notification over MQTT so that other devices in the club room or elsewhere can update their status.

MQTT is a simple, binary publish/subscribe protocol on top of TCP/IP. It offers a lightweight communication protocol, suitable for resource-restricted applications...

Example – basic media player

Another basic example of an SBC-based embedded system is a media player. This can involve both audio and audio-visual (AV) media formats. The difference between an SBC-based system being used to play back media with regular keyboard and mouse input, and an embedded SBC-based media player, is that in the latter's case the system can only ever be used for that purpose, with the software and user interface (physical- and software-wise) both optimized for media player use.

To this end, a software-based frontend has to be developed, along with a physical interface peripheral, using which the media player can be controlled. This could be something as simple as a series of switches connected to the GPIO pins, with a regular HDMI display for output. Alternatively, one could use a touch screen, although this would require a more complex driver setup.

Since our media player system stores media files locally, we want to use an SBC that supports external storage beyond the...

Summary

In this chapter, we looked at OS-based embedded systems, exploring the many operating systems available to us, with the most significant differences, especially those of real-time operating systems. We also saw how one would integrate an RTC peripheral into an SBC-based Linux system and explored user space- and kernel space-based driver modules, along with their advantages and disadvantages.

Along with the example project in this chapter, the reader should now have a good idea of how to translate a set of requirements into a functioning OS-based embedded system. The reader will know how to add external peripherals and use them from the OS.

In the next chapter, we will be looking at developing for resource-restricted embedded systems, including 8-bit MCUs and their larger brethren.