8/3/2019 Interrupt Disabling
1/19
1
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
8/3/2019 Interrupt Disabling
2/19
2
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 hasto get the memory without delay,
It is a heavy job for OS because memory has to be allocated, and lots ofdata structures and code segments must be copied/initialized.
the memory for a real-time task hasto be locked in mainmemory
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.
8/3/2019 Interrupt Disabling
3/19
3
RTOS/EOS Design Concept
Process and Thread
Starting a new process is a heavy job for OS: memory has to beallocated, 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 differentthreads 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.
8/3/2019 Interrupt Disabling
4/19
4
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 averagethroughput, RTOS: deterministicbehavior. EOS: smallmemory footprint and lowpower 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 overheadand non-productive.
complexityincreases exponentially with number of tasks and constraints. Complex algorithms are often error-prone.
8/3/2019 Interrupt Disabling
5/19
5
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 thispriority during the whole lifetime.
The scheduler is very simple, because it looks at all wait queues ateach 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 higherpriority than a task that runs every m milliseconds when n
8/3/2019 Interrupt Disabling
6/19
6
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.
8/3/2019 Interrupt Disabling
7/19
7
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 allthe application-registered ISRs (interrupt enabled)beforeuser tasks.
Top halfand Bottom half(softirq or tasklet)
RTLinux and RTAI allow only one ISR per IRQ, in order to be as deterministicas 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.
8/3/2019 Interrupt Disabling
8/19
8
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 ofallowed holdersof 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 anowner.
a semaphore can be waited for and signaled byanytask,
while only the task that has takena 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 byallprocessors.
Read/write locks: protect from concurrent write, while allow concurrent read
Manytasks can get a readlock; but only onetask can get a writelock.
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 allof them have reached a certain barrier.
8/3/2019 Interrupt Disabling
9/19
8/3/2019 Interrupt Disabling
10/19
10
Priority Inversion Problem
8/3/2019 Interrupt Disabling
11/19
11
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 themoment the high-priority task does the request.
So, the L-task wont be preempted by the M-task, and can finish itscritical 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-timeoverhead, 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-prioritytask that canuse the lock. This level is called ceiling priority.
when L-task enters the critical section, it immediatelygets ceiling priorityfrom the lock, so it will not be preempted by any M-task.
It generatescompile-timeoverhead only.
It may give rise to hiddenpriority inversion:
The priority is changed no matteranother task requests the lock or not.
That makes the L-task run at higher priority for longer time than needed.
8/3/2019 Interrupt Disabling
12/19
12
Priority Inheritance
8/3/2019 Interrupt Disabling
13/19
13
Priority Ceiling
8/3/2019 Interrupt Disabling
14/19
14
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
8/3/2019 Interrupt Disabling
15/19
15
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 .
Demand paging
Not recently-accessed pages are swapped outto make room for other pages. swapping is a non-deterministic thing (takes non-deterministic time).
MMU of an RTOS mustsupport page locking, i.e., tolock pages of real-time tasks in the physical RAM, to avoid the paging overhead.
POSIX provides mlock() and mlockall() for this.
8/3/2019 Interrupt Disabling
16/19
16
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 lockedin physical RAM. Memory sharing
One of the most efficient ways for tasks to communicate is throughshared 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 emulatea hard disk; i.e., somememory 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 aspossible.
8/3/2019 Interrupt Disabling
17/19
17
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 structureand 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.
8/3/2019 Interrupt Disabling
18/19
8/3/2019 Interrupt Disabling
19/19
19
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 savinguses of components?
Power-aware CPU Scheduler lower powerconsumption needs lower supplyvoltage which will
result in low freq./clock-rate and, thus, long executiontime.
Power Management Programming Interface provides an generic interface to access and set CPU/Device modes
Top Related