Lecture 1

Embedded Systems Overview RTOS/EOS Design Concept

Process Management Process Scheduling Interrupt IPC: Synchronization IPC: Data Exchanging Memory Management Device Drivers Power Management

RTOS/EOS Case Study

1

RTOS/EOS Design Concept

Task Management
tasks must be created and deleted while the system is running; tasks can change their priority levels, memory needs for the tasks
memory pages (in virtual memory and in physical RAM) for code, data, stack and heap, and for file and other descriptors;

Challenges for an RTOS

creating a real-time task, it has to get the memory without delay,
It is a heavy job for OS because memory has to be allocated, and lots of data structures and code segments must be copied/initialized.

the memory for a real-time task has to be locked in main memory

to avoid access latencies due to swapping;

changing run-time priorities is dangerous for an RTOS

It influences the run-time behavior and predictability of the whole system.
2

RTOS/EOS Design Concept

Process and Thread
Starting a new process is a heavy job for OS: memory has to be allocated, and lots of data structures and code must be copied.
memory pages (in virtual memory and in physical RAM) for code, data, stack, heap, and for file and other descriptors; registers in the CPU; queues for scheduling; signals and IPC; etc.

A thread is a lightweight process, in the sense that different threads share the same address space.
They share global and static variables, file descriptors, signal bookkeeping, code area, and heap, but they have own thread status, program counter, registers, signal mask, and stack.

Shorter creation and context switch times, and faster IPC.

to save the state of the currently running task (registers, stack pointer, PC, etc.), and to restore that of the new task.

Thread-safe function
The function called in a thread should not keep intermediate data in variables that are shared between the different threads.
3

RTOS/EOS Design Concept

Task Scheduling
OS is responsible for time-sharing of CPU among multiple tasks. A variety of scheduling algorithms have been explored and implemented. The general trade-off in scheduling algorithms
the simplicity and the optimality.

Challenges for an RTOS

Different performance criteria
GPOS: maximum average throughput, RTOS: deterministic behavior. EOS: small memory footprint and low power consumption.

A theoretically optimal schedule does not exist

Hard to get complete knowledge
task requirements and hard properties

the requirements can be dynamic (i.e., time varying).

Why RTOS and EOS prefer simplicity

The time spent on scheduling itself is pure overhead and non-productive. complexity increases exponentially with number of tasks and constraints. Complex algorithms are often error-prone.
4

RTOS/EOS Design Concept

Priority-based scheduling in RTOS static priority
A task is given a priority at the time it is created, and it keeps this priority during the whole lifetime. The scheduler is very simple, because it looks at all wait queues at each priority level, and starts the task with the highest priority to run.

dynamic priority
The scheduler becomes more complex because it has to calculate tasks priority on-line, based on dynamically changing parameters. Earliest-deadline-first (EDF) A task with a closer deadline gets a higher scheduling priority. The scheduler needs not only to know the deadline time of all tasks it has to schedule, but also their duration. rate-monotonic scheduling. A task gets a higher priority if it has to run more frequently. This is a common approach in case that all tasks are periodic. So, a task that has to run every n milliseconds gets a higher priority than a task that runs every m milliseconds when n<m.
5

RTOS/EOS Design Concept

Interrupt
Asynchronous (or hardware interrupt)
by hardware event (timer, UART, network card ) the interrupt handler does not run in the context of the interrupting task. Synchronous (or software interrupt, or a trap) by software instruction (swi in ARM, int in Intel 80x86), a divide by zero, a memory segmentation fault, etc. The interrupt handler runs in the context of the interrupting task

Challenges in RTOS
Interrupt latency
The time between the arrival of interrupt and the start of corresponding ISR. Modern processors with multiple levels of caches and instruction pipelines that need to be reset before ISR can start might result in longer latency.

Interrupt enable/disable
The capability to enable or disable (mask) interrupt individually.

Interrupt priority
to block a new interrupt if an ISR of a higher-priority interrupt is still running. the ISR of a lower-priority interrupt is preempted by a higher-priority interrupt. The priority problems in task scheduling also show up in interrupt handling.
6

RTOS/EOS Design Concept

Interrupt nesting
an ISR servicing one interrupt can itself be pre-empted by another interrupt coming from the same peripheral device. (The ISR must be re-entrant).

Interrupt sharing
allow different devices to be linked to the same hardware interrupt.
check a status register on each of the devices that share the interrupt calling in turn all ISRs that users have registered with this IRQ.

In Linux
Kernel registers one interrupt handler per IRQ. The handler runs first (interrupt disabled), and then invoke one-by-one all the application-registered ISRs (interrupt enabled) before user tasks. Top half and Bottom half (softirq or tasklet)

RTLinux and RTAI

allow only one ISR per IRQ, in order to be as deterministic as possible.

Priority space
ISR (Interrupt Service Routine): run with interrupt disabled. DSR (Deferred Service Routine, bottom half in Linux): interrupt enabled. Kernel tasks: can preempt any user space task User tasks: can have different priorities.
7

RTOS/EOS Design Concept

IPC: Synchronization
Synchronization primitives:
Semaphore: counting semaphore and binary semaphore
A semaphore is created with initial_count, which is the number of allowed holders of the semaphore lock. (initial_count=1: binary sem) Sem_wait will decrease the count; while sem_signal will increase it. A task can get the semaphore when the count > 0; otherwise, block on it. Mutex: similar to a binary semaphore, but mutex has an owner. a semaphore can be waited for and signaled by any task, while only the task that has taken a mutex is allowed to release it. Spinlock: lock mechanism for multi-processor systems, A task wanting to get spinlock has to get a lock shared by all processors. Read/write locks: protect from concurrent write, while allow concurrent read Many tasks can get a read lock; but only one task can get a write lock. Before a task gets the write lock, all read locks have to be released. Barrier: to synchronize a lot of tasks, they should wait until all of them have reached a certain barrier.
8

RTOS/EOS Design Concept

IPC Challenges for RTOS Critical section
critical section (data, service, code): protected by lock mechanism. In a RTOS, the maximum time a task can be delayed because of locks held by other tasks should be less than its timing constraints in system.

Race condition deadlock, livelock, starvation

Some deadlock avoidance/prevention algorithms are too complicate and indeterministic for real-time execution. Simplicity is preferred, like all tasks always take locks in the same order. allow each task to hold only one resource.

Signal: asynchronous notification

one task files a signal that can cause another task to start doing things. In most OS, signals are not good for synchronization due to are not queued and carry no data have no deterministic delivery time and no deterministic order

Priority inversion
using priority-based task scheduling and locking primitives should know the priority inversion danger: a medium-priority job runs while a highpriority task is ready to proceed.
9

Priority Inversion Problem

10

RTOS/EOS Design Concept

Priority inheritance: - to solve Priority Inversion
A low-priority task that holds the lock requested by a high-priority task temporarily inherits the priority of that high-priority task, from the moment the high-priority task does the request. So, the L-task wont be preempted by the M-task, and can finish its critical section without holding up H-task any longer than needed. When L-task releases the lock, its priority drops to its original level. It generates run-time overhead, because the scheduler has to check the priorities of all tasks that access a lock.

Priority ceiling: - to solve Priority Inversion

Every lock gets a priority level equal to the priority of the highest-priority task that can use the lock. This level is called ceiling priority. when L-task enters the critical section, it immediately gets ceiling priority from the lock, so it will not be preempted by any M-task. It generates compile-time overhead only. It may give rise to hidden priority inversion:
The priority is changed no matter another task requests the lock or not. That makes the L-task run at higher priority for longer time than needed.
11

Priority Inheritance

12

Priority Ceiling

13

RTOS/EOS Design Concept

IPC: Data Exchanging
Shared Memory: Two (or more) tasks can exchange information by reading and writing the same area in memory (zero copy). FIFO: character devices, data access in a specified linear sequence. Message and Mailbox: sending data in arbitrary chunks, containing some meta-info about the size and sender. Remote Procedure Calls (RPC): can invoke the execution of a task on a remote computer, as if that task ran on the same computer.
CORBA (Common Object Request Broker Architecture): This is a fully platform and vendor independent initiative. DCOM: controlled by Microsoft. RMI (Remote Method of Invocation): from the Java world.

Challenges for RTOS

Deterministic timing delay in handling data exchanging with limited available memory resource
14

RTOS/EOS Design Concept

Memory Management
Dynamic memory allocation/de-allocation Virtual memory system
Include physical RAM, MMU (hardware), Virtual Memory software of OS give a task the impression that memory is
(1) larger than physically available RAM (virtual address) (2) protected from access by other tasks (address space)

Challenges for RTOS

Fast and deterministic

Some small embedded systems even ask for no memory management .

Not recently-accessed pages are swapped out to make room for other pages. swapping is a non-deterministic thing (takes non-deterministic time).

Demand paging

MMU of an RTOS must support page locking, i.e., to lock pages of realtime tasks in the physical RAM, to avoid the paging overhead.
POSIX provides mlock() and mlockall() for this.
15

RTOS/EOS Design Concept

Dynamic allocation
Finer and variable-sized granularity implies more complex memory management (for memory fragmentation), and hence less determinism. To make dynamic allocation deterministic in a RTOS, the memory pages can be allocated from a pool of free pages locked in physical RAM.

Memory sharing
One of the most efficient ways for tasks to communicate is through shared memory. The OS has two major responsibilities for this:
(1) shared memory (de)allocation (2) access synchronization

RAM disks
hard disk access has non-deterministic overhead
part of the available RAM can used to emulate a hard disk; i.e., some memory is organized and accessed as a file system.

When the RAM disk should preserve data when the power is switched off, it is usually implemented as a flash disk.

Striped libraries
use stripped down version of libraries to save memory as much as possible.
16

RTOS/EOS Design Concept

Device Drivers
Transferring data between the devices and the kernel/applications

Challenges for RTOS

short and deterministic timing delays in the drivers
Some devices interact with software through hardware interrupts. Hence, their drivers include an ISR, and possibly also a DSR Some devices allow shared memory, or even DMA: the device and memory exchange data directly, without needing the processor.

various and complex devices

A good device driver provides mechanism, not policy
It is worthwhile to standardize the structure and the API

API: make all hardware looks the same to software (kernel/app)

e.g., use the same software interface with different parameters.

Structure: capable of handling complex devices

e.g., many devices have more than one layer of functionality Comedi Project ( http://stm.lbl.gov/comedi/ ) drivers, kernel module (to use it in real-time), user-space libraries.17

RTOS/EOS Design Concept

Power Management
Manage a system or a HW/SW component that offers different operational modes, functions, speeds, etc. in order to reduce power consumption. HW Low power circuit design Partition h/w blocks and turn on/off dynamically Provide different operation models SW Fully utilizes HW power modes features Design low-complexity algorithms Minimize activities (CPU/MEM/DEVs)

18

RTOS/EOS Design Concept

Challenges for EOS
Various Power Consumption Sources
CPU, Memory/Cache, Peripherals (LCD, Network interface, ), Each of them has different power consumption characteristics

Power Saving Strategies

Transition: When should a component switch from one mode to another? Load-change: How can a component be more often put into low power modes? Adaptation: How can software be modified to permit novel, power saving uses of components?

Power-aware CPU Scheduler

lower power consumption needs lower supply voltage which will result in low freq./clock-rate and, thus, long execution time.

Power Management Programming Interface

provides an generic interface to access and set CPU/Device modes
19