Standalone Operating Systems

Choosing the Right Type of Operating System

There are a number of possibilities when determining the type of OS to use on an embedded system. Such examples include a simple standalone OS, a RTOS or specialised embedded OS such as the numerous variations of embedded Linux.

Before that choice can be made, however, we should consider the type of embedded OSs that are available.

Standalone Operating Systems

A standalone OS, also known as a bare metal OS, is a simple OS that aims to provides a very low-level of software modules that the system can use to access processor-specific functions.

Regarding the Zynq platform specifically, Xilinx provides a standalone OS platform that provides functions such as configuring caches, setting up interrupts and exceptions and other hardware related functions. The standalone platform sits directly below the OS layer and is used whenever an application requires to access processor features directly [8].

A standalone OS enables close control over code execution but is fairly limited in terms of functionality. It should only be used for applications where the software functions are straightforward and repetitive. The number of tasks being carried out by a standalone OS should be relatively small, as adding further tasks can increase the task management required by the standalone rapidly

Real-Time Operating Systems (RTOS)

The defining feature of a RTOS is the degree of determinism that is guaranteed by the scheduler; the purpose of a RTOS is not to achieve a high throughput, but instead to respond both quickly and predictably for a given task.

The function of many embedded systems demand that the software responds to events within a short, defined response time. Given this requirement, real-time systems can be categorised as one of three types: soft real-time, hard real-time or firm real-time [3].

A soft real-time system is one in which the meeting of a response deadline is preferred but not critical. A failure to meet the specified response time will not destroy the performance of the system, but may degrade it.

A hard real-time system, however, is one in which the missing of a response time is unacceptable and could lead to the overall failure of the system.

Firm real-time systems are a middle ground between hard or soft systems; a small number of missed response deadlines will not lead to the overall failure of the system, but a larger number of missed deadlines may result in total failure of the system [3].

Most modern RTOS systems include a set of high-level functions that complement the real-time kernel. Such functions can include a GUI, communications protocol stacks and a certain degree of peripheral device management. In an embedded system, the RTOS controls the device and is responsible for providing the required level of responsiveness. Software tasks are controlled by the RTOS which schedules the CPU time allocated to each of the tasks accordingly[1].

Other Embedded Operating Systems

While a RTOS is suitable for the management of real-time applications on embedded systems, they do not generally offer the highest system throughput or performance. For applications that require high system performance, another type of OS is usually required.

Traditionally, the preferred option would be an embedded Linux solution but, with the recent developments in mobile OSs such as Android, there are more options capable of delivering high system performance for an embedded system.

Linux

Linux and the Linux kernel are covered in detail in Chapter 22 and Chapter 23 respectively, so we shall skip over it for now.

Android

Android is an OS which is mainly intended for use on touchscreen mobile devices, i.e. mobile phones and tablet computers. Originally created by Android, Inc. — a company financially backed by Google — Android was later bought, and is now developed and maintained, by Google. Due to its open source status, Android has since been customised for use on non-mobile devices such as smart TVs, cameras, media players, laptop computers, and wrist watches.

Google released the source code for Android under the Apache V2 open source license which means that anyone, be it a mobile phone manufacturer or a smart TV developer, who innovates using the Android platform has no requirement to share those additions with the open source community [4]. This makes Android a very commercially-friendly platform to work with.

The Android OS comprises of a kernel derived from the Linux kernel v2.6 for all versions up to and including Android 3.2, after which Android 4.0 and onwards are based on Linux kernel 3.x [12]. The Android software architecture, however, is largely different from that of a traditional Linux system, including some changes to the fundamental kernel functionality. Due to Android initially being targeted at mobile devices, a number of aggressive power management policies were introduced to minimise power consumption

by forcing the kernel to go into sleep mode whenever possible. This is in contrast to the traditional desktop Linux variations which largely tend to never allow the kernel to enter sleep mode. Other changes include the introduction of timed GPIOs, alarm timers, paranoid network security, and the binder Inter-Process Communication (IPC), amongst others. The overall software architecture of Android is detailed in Figure 21.1.

Android OS architecture.png

It is the more recent adoption of Android for non-mobile devices that is of interest here. There are a number of reasons — aside from its open source status — which make Android an appealing platform on which to build embedded systems. We will now take a look at few of those.

One of the things that makes Android desirable for developers is the fully featured SDK which provides a regular framework to work with through the use of a standardised API. Although Android is an ever-evolving platform, that has gone through a large number of releases in recent years, the API remains generally constant across releases; this allows developers to make a reasonably safe long-term investment as they can make savings by only designing and compiling applications once for multiple targets [12].

Android has out-of-the box support for a wide array of sensors (including GPS, accelerometer and camera), networking (WiFi, Bluetooth, NFC, 2G/3G) and also a large number of common multimedia formats. If your embedded application needs to make use of one or more of these features, then choosing Android could well improve your development time. Furthermore, due to its widespread use in mobile phones and tablets, the Android user interface is familiar to many potential users, thus reducing the learning curve.

Further Considerations

Other questions to consider when choosing an embedded OS:

• How much does it cost?

• How experienced is your design team in its use?

• How secure is it?

TABLE OF CONTENTS