Delkin Blog

Real Time Embedded Systems generally consist of Hardware and Software (More often referred to as Firmware). These systems include at a minimum:

Hardware:

• CPU – Various types such as RISC or CISC, single core or multi-core, fully integrated ASIC type controllers. Executes a set of instructions in a program (process or application) created by the system programmer.
• Ram Memory and Controller– Usually DRAM, used to run programs and for transient data storage. The controller for the DRAM is usually part of the CPU, Flash Memory or ROM. This usually holds the initial low level boot code, loader code, and sometimes the Basic IO System (BIOS). You will see this in every PC based design where the BIOS does all the initial hardware scanning and aids in low level HW initialization. PC BIOS also holds code to handle software interrupt calls from, main code, as well providing low level, device driver hooks.
• Interrupt controller– which usually is part of the CPU.
• System HW timer– which is usually part of the CPU. Acts as the system tick counter for all timing events. The finer the resolution the more accurate the timing.
• Parallel and Serial I/O
• Power Monitor – Usually included in the CPU, generates an interrupt and Reset at voltage drops.
• Optional, but becoming more and more mandatory, are Mass Storage interfaces – SATA, MSATA, SD card, Micro SD card, CFAST card, USB. Generally, these are now part of the many highly integrated CPU ASIC devices. Also, high speed Ethernet is required if networking is involved, and possibly wireless communication capabilities as well.

Real Time System Definition

What distinguishes a Real Time System from an ordinary system, such as your PC? A Real Time System must respond to external stimuli, within a predetermined time. The response time must be deterministic, meaning repeatable and verifiable. Easy to say, not so easy to do. We usually break Real Time into 2 categories. Hard Real Time and Soft Real Time.

Hard Real Time systems present catastrophic, or even fatal consequences if the requirement is not met. Some examples of these are airbag deployment time after the sensor presents to the system, or a heart defibrillator activating after detection of an arrhythmia. Another is full application of brakes in a vehicle upon detection of an obstacle in the way, or sudden full pressure on brake pedal by the driver.

Soft Real Time systems face penalties for missing the timing requirement, but do not cause such bad effects. These systems have built in tolerances and are easier to implement. An example is a display warning for low fuel in a vehicle, or a moderate loss of tire pressure.

Where Hard Real Time requirements are numerous, such as in modern automobiles, use of multiple CPU based modules are linked by a bus topology such as optical, fast Ethernet, or in some vehicles CAN bus. Requirements cannot be met with one CPU module.

Firmware and the Operating System (OS) (RTOS)

Is programming a system possible without the use of an OS? It is, and for non-critical applications this the way it has been done for years.  Especially when memory is scarce and there are cost constraints. Even hard real time requirements can be met if one uses interrupts properly. This is true in cases where there is no requirement for supporting heavy storage access or high speed communications.

This practice has largely been abandoned because of several factors. The cost of memory is much lower these days, thus, supporting an OS is cost efficient in most cases. Add to this the fact that there are many low cost RTOS available today, many having a very small footprint regarding memory requirements, and many are Hard Real Time as well.

There are other reasons for using an OS or RTOS. It simply makes the development task easier and forces modular programming, which is always the way to handle complex requirements. I/O is reduced in high level system calls, and the underlying low level operations are taken care of by a device driver. The requirement can be broken down into separate processes, tasks and threads. The processes and tasks communicate with each other using the RTOS inter-task communication facilities.

Real Time Operating System

To be considered a Real Time system, it usually implies the use of a real-time operating system (RTOS). An RTOS is an (OS) intended to serve applications that process data as it comes in, including interrupts, typically without buffer delays. Processing time requirements (including any OS delay) are measured in milliseconds or shorter increments of time. An RTOS is either event driven (usually by an interrupt) or time slicing or both.  Event driven systems switch between tasks based on their priorities while time slicing systems switch the task based on clock interrupts (from the hardware timer via the OS kernel). Time slicing is also referred to as Round Robin scheduling. Each tasks gets a time slice to execute.

A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application’s task. The variability is referred to as jitter. As mentioned before a Hard Real Time operating system has less jitter than a Soft Real Time operating system. The chief design goal is not high speed, but rather a guarantee of a soft or hard performance category. An RTOS that can usually meet a deadline is a Soft Real Time OS, but if it can meet a deadline deterministically it’s a Hard Real Time OS.

A RTOS has an advanced algorithm for scheduling.  Scheduler flexibility enables a wider, computer-system orchestration of process priorities, but a Real Time OS is more frequently dedicated to a narrow set of applications. Key factors in a Real Time OS are minimal Interrupt latency and minimal thread/task switching latency. A Real Time OS is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.

The Architecture of an RTOS

The heart of an RTOS is the called the Kernel. This contains the manager for scheduling tasks/threads. This is referred to as the scheduler. Its function is task coordination, like to invoke tasks based on factors such as the tasks priority and status.

The Kernel also contains memory management and inter ask messaging facilities, as well as facilities for resource sharing, interrupt management, and timer management.

Hooked to the Kernel are optional services:

• Device I/O
• File System
• Networking Stacks
• Device Drivers
• Debugging facilities

The most used RTOS are those that use priority based pre-emptive task scheduling. Tasks are run by priority, and a higher priority task preempts a lower priority one. The Kernel suspends the low priority task and invokes the high priority task. The context of the low priority task is saved, and context for the higher priority task is loaded and the task executes. The context of a task is all the information and memory space it needs to execute as a program, usually pushed on the stack. This is referred to as context switching, and is used in all Kernels. So, an RTOS can vary in size if services are added. This can be decided when you build the RTOS.

Some Popular RTOS 

By far, Linux variants share the market with Windows Embedded variants. Linux is popular because it’s “open Source”. This means it has device drivers, kernels, communication stacks, and mass storage support etc. can be obtained for free, including source code, however, support can become an issue. Some companies have stepped up to provide support contracts for certain variants of Linux.

Both Windows and Linux are RTOS that support multi-processing and multi-tasking/threading. A Process in Windows is referred to an application program. This results in multiple programs (processes) running under control of the Kernel Scheduler, with possibly multiple tasks running within each program (process). Realize that this concurrency doesn’t mean 2 process or tasks run at the same time. They are rather switched in and out by the scheduler, based on its algorithm. They appear to be concurrent.

In many instances, only one process (application) is running, but inside the process, many tasks are running under scheduler control. These tasks can communicate with each other via the messaging facilities of the Kernel.

Choosing a RTOS should be done carefully. Consider your application’s target goals and consider if the RTOS is Hard Real Time or Soft Real Time, and which you need. Consider its compliance to POSIX standards, and if it’s certified, if required. Make sure source code is provided for the Kernel and services. Consider the memory footprint of the RTOS. If you are using a handheld device, with limited memory, you would lean toward a micro-Kernel. Linux itself is compact.

However, Linux was not designed to be a real time OS, same goes for Windows. However, there are variants such a RTLinux and Windows Embedded that are. Some RTOS we like are:

• QNX
• QNX Neutrino – Very small footprint.
• Timesys – Open Source development tools and support. Linux Development portal. Good company.
• RTLinux – Wonderful Hard Real-Time MicroKernel
• Windows Embedded Compact 7.0 – Small Footprint Kernel, Real Time – Great tools
• LynxOS, LynxOS – 178, LynxSECURE
• FreeRTOS – Good for non-critical projects and it’s free.

Mass Storage Requirements for Embedded Systems (SSD)

As mentioned prior in this document, an Embedded System (all but the simplest ones), require some type of mass storage device to contain the file system, storage of the system image, and boot code. In many more complicated systems, such as a data logging system, or data base, with or without encryption, a disk is required. In almost all cases a Solid State Drive (SSD) based on NAND Flash is used, instead of mechanical drives. This can be a single device such as one or more USB sticks, SATA Drives, MSATA drives, CF card, CFAST card, SD/MMC card or a combination of such devices.

In many cases, these devices must be of industrial quality, since mechanical drives may not meet the physical or life cycle requirements of the system.

A very popular device used in many cases, such as routers, are embedded MMC (eMMC) devices. Most often these have a proprietary physical format, containing NAND Flash and a Flash controller device.  These are used to hold the RTOS image, for booting and logging data to router tables contained on the drive. They must be robust, tolerate random power failures during read/write cycles, have a long lifecycle, and high speeds, especially for random writes and reads.

Ultimately the system is responsible for disk activities during power fails. However, to make this task easier and more effective, the SSD should not present corrupted data at power-up. This would at least make it easier to resume data writing when the power is restored.

From a system level, as power drops below a preset level, a power fail interrupt is generated. In an event driven RTOS, the Kernel invokes this task. The power fail task should be the highest priority. This task would have the responsibility to complete as much of the write in progress as possible.

The SSD must have fast read and write speeds as well. Generally, the SSD is a shared resource, used by multiple tasks. It’s not suitable for long latencies, since these could affect system performance if one task is writing to the drive and another is blocked waiting to read the drive. The logical to physical mapping scheme of the FTL is very critical. Since NAND flash is written at page level and erased at the block level, block based mapping is inefficient. Write amplification is large, and this kills random writes. Page based mapping promotes speed and is the preferred mapping method.

Long product lifecycle is essential. so the choice of Flash used is critical. Generally, SLC Flash is used for these devices. Efficient wear leveling is also an essential consideration, especially when STATIC wear leveling is used. This type of wear leveling moves data in all parts of the SSD, even areas that are rarely written to. This ensures the boot area data, files, and system tables are refreshed and moved around.

The disk should have protection against read disturb and program disturb errors, and an excellent Error Detection and Correction (ECC) algorithm.

In conclusion, the SSD is a critical part of the embedded system, and a very careful choice of an SSD is required. Only manufacturers using the best Flash controllers and Flash should be chosen.

 Article Contributor:

Carmine C. Cupani, MSEE

CTech Electronics LLC