Embedded Systems & RTOS

The intelligence embedded in the processors of Real-time and Embedded systems has embedded into all fields of our lives including airborne computers, medical instruments and communication systems. Embedded systems, not recognizable as computers, being hidden inside everyday objects, typically do not interface with the outside world through familiar PC interface devices such as mouse, keyboard or graphic user interface. Instead, they interface with the outside world through unusual interfaces such as sensors, actuators and specialized communication links and are designed for controlling devices in common use today to help us in our lives. Simply these are computers on a single chip. Embedded systems are designed to do some specific task. The Heart of the Embedded system contains processing core(s) that are either microcontrollers or digital signal processors (DSP). Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and network. The programme instructions written for embedded systems are referred to as firmware, and are stored in read-only memory or Flash memory chips.

 

Kernel & Firmware

Firmware is a programme that like the BIOS of your PC, runs every time you turn it on and scans/communicates with your CPU, RAM, video card, hard drives, floppy drives, USB controller, etc. Because Firmware is a combination of read-only memory and programme code or software embedded in ROMs (read-only memory), PROMs (programmable read-only memory) and EPROMs (erasable programmable read-only memory), it is called "firm" ware, whereas "soft" ware is loaded from a flexible source (a hard drive) and typically run on a general purpose processor (your computer's CPU). Kernel is the main component of most computer operating systems; it is a bridge between applications and the actual data processing done at the hardware level e.g CPU and memory. It's not as low-level as firmware; nor is it a high-level programme like a user programme (word processor, spreadsheet app, browser, etc). Unlike firmware, the Kernel is software and when a PC boots from the hard drive (it's one of the first things to get loaded and executed), it gets loaded into memory and it remains there for the entire duration of the computer session because its services are required continuously. BIOS is NOT Kernel but a firmware. The firmware in the BIOS does the very basic setup that allows the Kernel to load drivers, etc. and boot the computer. The Kernel has complete control over everything that occurs in the system. An operating system Kernel is pieces of software that is responsible for services resource request for the application and management resources. A Kernel is like a collection of drivers and it operates wifi, your radios, bluetooth, the CPU, et cetera. But it operates at a lower level than the OS and is the foundation on which the OS is allowed to operate. Windows also has a Kernel.

 

Embedded systems are characterized by limited processor memory, limited processing power and unusual interfaces to the outside world, providing logically correct result within deadline required. The real-time performance constraints must be met for safety and usability. Since the embedded system is dedicated to specific task, design engineers can optimize it to reduce its size and cost and also increase its reliability and performance. Along with little memory, they also run with limited computer hardware resources, small or no user interface at all — dedicated only to one task — to Complex graphical user interfaces. Simple embedded devices use buttons, LEDs, graphic or character LCDs  with a simple menu system or/and user interface remotely with the help of a serial (e.g. RS-232, USB, I²C, etc.) or network (e.g. Ethernet) connection. This approach gives several advantages like extending  the capabilities of embedded system, avoiding  the cost of a display, simplifying BSP(Board Support Package), allowing  us to build rich user interface on the PC. A good example of this is the combination of an embedded web server running on an embedded device (such as an IP camera) or a network router. The user interface is displayed in a web browser on a PC connected to the device.

 

Need for OS

Strictly speaking, an Operating System is not required to run a computer as programmes could be directly loaded and executed on the "bare metal" machine as was done in the 1960s and is still done today on some video game consoles. We can write programme code for a microcontroller to enable it to perform various control and/or monitoring functions, e.g. a washing machine control system, without any Operating System. So, why would one be needed for a microcontroller system? Whereas an Operating System such as MS Windows has a complete graphical user interface and sophisticated functions for printing, disk handling, networking, etc., an embedded microcontroller system may need only some of them. The Operating Systems used in real time embedded systems, supporting only multitasking may vary in size from 300 bytes to 10Kb, small enough to fit inside on-chip ROMs. In 1969 the RC 4000 Multiprogramming System introduced the system design philosophy of a small nucleus "upon which Operating Systems for different purposes could be built in an orderly manner", what would be called the “microKernel” approach. An Operating System generally consists of two parts: Kernel space (Kernel mode) and User space (user mode). Kernel is the smallest and central component of an Operating System. Its services include managing memory and devices and also to provide an interface for software applications to use the resources. Additional services such as managing protection of programmes and multitasking may be included depending on architecture of Operating System.

 

Real-Time OS

“Real-Time Operating System (RTOS) is a multitasking Operating System intended for real-time applications.” RTOS is implemented in products all around us, ranging from military and consumer to scientific applications. It is not a mandatory component of all real-time applications in embedded systems, e.g. an embedded system in a simple electronic rice cooker does not require RTOS, but as the Complexity of applications expands beyond simple tasks, benefits of having an RTOS far outweigh the associate costs. Embedded systems are becoming more Complex hardware-wise with every generation and as more features are put into them, application programmes running on the embedded system platforms, will become increasingly Complex to be managed as they strive to meet the system response requirements.

‘Real-Time’, in the name, indicates an expectant response or reaction to an event on the instant of its evolution. The expectant response depicts the logical correctness of the result produced. The instant of the events’ evolution depicts deadline for producing the result. ‘Operating System’ (OS), in the name, is a system programme that provides an interface between hardware and application programmes. RTOS is therefore an Operating System that supports real-time applications and embedded systems by providing logically correct result within the deadline required. Such capabilities define its deterministic timing behavior and limited resource utilization nature.

Complexity of the application for an embedded system can get simpler by dividing the project into more manageable pieces (or threads). Applications can be divided into different threads with or without the use of an RTOS. For example, one thread can be responsible for reading the keyboard, another for checking temperature, a third for printing messages on a LCD screen, and so on. With an RTOS you not only get the tool to create threads, but also tools to communicate between the threads, and tools to ensure that threads that are time critical are executed within their real-time constraints. Since the interface between the different threads becomes very clean when using an RTOS, time is saved both in development and in maintenance of the application. Each thread is then responsible for some part of the application and with such a system you would be able to specify that some thread is more important than others, i.e. some threads have real-time requirements and they have to respond quickly and correctly. In addition to thread prioritization, a clean and well-tested API eases communication between different threads. Real-time requirements impose stringent time deadlines for delivering the results of embedded processing. Real-time and embedded systems also operate in little memory along with speed and timing constraints that dictate the use of real-time Operating Systems in embedded software.

 

The key difference between general-computing Operating Systems and Real Time Operating Systems is the   "deterministic" timing behavior in RTOS, which means that Operating System services consume only known and expected amounts of time. In theory, these service times could be expressed as mathematical formulas and do not include any random timing components. Being non-deterministic, general-computing non-real-time Operating Systems can inject random delays into application software and thus cause slow responsiveness of an application at unexpected times and cause the application randomly miss real-time deadlines – a scenario clearly unacceptable for a Real-Time Embedded System. These Operating Systems offer constant load-independent timing: In other words, the mathematical formula is as simple as: T(message send) = constant , irrespective of the length of the message to be sent, or other factors such as the numbers of tasks and queues and messages being managed by the RTOS. Examples: the non-real-time Operating System are Windows, Unix or Linux.

RTOS Kernel is commonly equipped with features like: Task Management, with/without priority-based Preemptive Scheduling, Multitasking, Synchronization & Communication, Interrupt and Event Handling, Input/ Output, Timers and Clocks and Memory Management to fulfill its primary role of managing the hardware resources to meet the demands of application programmes. In addition to the five main categories of basic services to application software, many RTOSes also offer a number of optional add-on operating system components for such high-level services as file system Organisation, network communication, network management, database management, user-interface graphics, etc.

 

The design of an RTOS is essentially a balance between providing a reasonably rich feature set for application development and deployment and not sacrificing predictability and timeliness. A basic RTOS will be equipped with the following features:

i. Multitasking and Preemptibility

An RTOS must be multi-tasked and preemptible to support multiple tasks running concurrently in real-time applications. The scheduler should be able to preempt any task in the system and allocate the resource to the task that needs it most even at peak load.

ii. Task Priority

Preemption defines the capability to identify the task that needs a resource the most and allocates it the control to obtain the resource. In RTOS, such capability is achieved by assigning individual task with the appropriate priority level.  A scheduler should determine which task should run at any point and have ability to preempt a running task.

iii. Reliable and Sufficient Inter Task Communication Mechanism

For multiple tasks to communicate in a timely manner and to ensure data integrity among each other, reliable and sufficient inter-task Synchronization & Communication and mechanisms are required.

iv. Priority Inheritance

To allow applications with stringent priority requirements to be implemented, RTOS must have a sufficient number of priority levels when using priority scheduling.

v. Predefined Short Latencies

An RTOS needs to have accurately defined short timing of its System Calls. The behavior metrics are:

• Task switching latency: The time needed to save the context of a currently executing task and switching to another task is desirable to be short.

• Interrupt latency: The time elapsed between execution of the last instruction of the interrupted task and the first instruction in the interrupt handler.

• Interrupt dispatch latency. The time from the last instruction in the interrupt handler to the next task scheduled to run.

vi. Control of Memory Management

To ensure predictable response to an interrupt, an RTOS should provide way for task to lock its code and data into real memory.