Embedded systems

Bernard Boigelot

E-mail : [email protected]
WWW : http://www.montefiore.ulg.ac.be/boigelot/
http://www.montefiore.ulg.ac.be/boigelot/courses/embedded/

References :

An Embedded Software Primer, David E. Simon, Addison-Wesley, 1999.

C/OS-III: The Real-Time Kernel, Jean J. Labrosse, Micrim Press, 2010.

Real-Time Systems, Jane W. S. Liu, Prentice Hall, 2000.

1
Chapter 1

Introduction

2
 Embedded systems

Definition: An embedded system is a computer system used as a component of a more

complex entity.

Typical applications:

multimedia players, radios, televisions, mobile phones, GPS receivers;

still and video cameras;

wristwatches, calculators, smart cards, RFID tags, remote controls;

home appliances;

computer peripherals;

measurement equipment, sensors;

cash dispensers, self-service machines;

medical devices, implants;

3
 elevators, intrusion-detection devices, domotic systems;

telephone switches, network routers;

automotive systems (ABS, ESP, injection controllers, parking assistance, . . . );

avionics (fly-by-wire controls, glass cockpits, navigation aids, TCAS, . . . );

industrial process controllers, robots;

artificial satellites, spatial probes;

...

4
 Advantages

Moving some functionalities from hardware to software makes electronic circuits

simpler,
cheaper to build,
more powerful.

Complex features can be implemented.

Software components can easily be updated during the lifetime of a product, as well as
reused in other projects.

5
 Developing embedded systems: Main difficulties

Low-performance hardware: Low computing power, small amount of memory . . .

Specificity to a particular application.

Concurrence: Several tasks operate in parallel.

Reactivity: The system must constantly be able to answer solicitations.

Real-time constraints.

High level of quality expected: Reliability, robustness and efficiency are critical.

Limited user interface.

Adverse exploitation environment.

Energy management is often necessary.

6
Chapter 2

Hardware

7
 Main components of an embedded system

One or several processor(s) (CPU):

Microcontrollers (MCU): 8051 (Intel), PIC (Microchip), AVR (Atmel), . . .

Digital Signal Processors (DSP): TMS320, C6000 (Texas Instruments), SHARC

(Analog Devices), MSC81 (Freescale), . . .

Microprocessors dedicated to embedded applications: ARM, XScale (Intel), OMAP

(Texas Instruments), ColdFire (Freescale), MIPS32&64, x86 (Intel), . . .

Generic microprocessors: PowerPC (IBM), Xeon, Core, Atom, Celeron (Intel), . . .

Special architectures: Java Card, multicore processors, reconfigurable processors,

...

8
 Memory:

Static or dynamic RAM, ROM (EEPROM, FLASH, . . . ).

Either internal to the microcontroller, external, or integrated in a System on Chip

(SoC).

Parallel or serial interface.

Possibility of addressing peripherals in memory.

Internal or external peripherals:

Timers,

Converters,

Communication controllers,

...

Communication buses.

9
 Interfaces with the circuit environment:

Point to point: RS-232, IrDA, . . .

Buses: I2C, CAN, SPI, USB, JTAG, . . .
Networks: Ethernet, WiFi, ZigBee. . .

Auxiliary components:

Power supply,
Clock generator,
Bus controllers,
...

10
 Example of embedded microcontroller: Microchip PIC16F716

Main features:

RISC architecture: Only 35 instructions.

Harvard memory model: 2048 words of (FLASH) program memory, 128 bytes of
(RAM) data memory, both internal.

Reprogrammable via a serial interface.

13 dynamically configurable general-purpose input/output pins.

Integrated peripherals: 3 timers, PWM controller, analog to digital converter, . . .

Computing power of 5.106 instructions per second.

Low power consumption: About 120 A (under 2V) at 1 MHz, 14 A at 32 kHz, 100 nA
in standby.

11
Pinout:
RA2 RA1
RA3 RA0
RA4 OSC1
MCLR OSC2
VSS VDD
RB0 RB7
RB1 RB6
RB2 RB5
RB3 RB4

Description:

VSS, VDD : Power supply (2.05.5 V).

OSC1, OSC2 : Oscillator crystal or external clock source.

MCLR : Operating mode selection (0 V: reset, VDD: program execution, 13 V:

programming mode).

RA0. . . RA4, RB0 . . . RB7 : General-purpose input/output pins (TTL/CMOS),

dynamically configurable and multiplexed with some peripherals. RB6 and RB7
alternatively provide a serial interface in programming mode.

12
 Example of application: Temperature alarm

1N4001
7805
10K
10F + 100nF VDD

22K 10K MCLR RB0

9V + Reset PIC 16F716 Test

RA0
220R
RA1 RB1
OSC1
LED
RB2
22K NTC 4MHz
OSC2
VSS

Piezo
33pF 33pF

13
 Example of embedded bus

Problem: Managing data transfers between several devices (CPU, memory, sensors,
peripherals, . . . ) using communication hardware that is as simple as possible.

Requirements:

Bus topology.

Small number of communication lines.

Flexible configuration.

Mechanisms for addressing devices, managing transactions, for performing arbitration

and flow control.

14
 Solution: I2C bus

Principles:

The bus consists of a pair of two-way lines: SDA (Serial DAta) and SCL (Serial Clock).

The value of each line stays high whenever it is unused.

Each device connected to the bus can read the value of SDA and SCL, but is only able
to force them down, i.e., to write a low value.

VCC

SDA
SCL

Device 1 Device 2

15
 I2C: Transactions

The master of a transaction is responsible for

generating a clock signal on SCL during the transaction.

signaling the beginning (Start, S) and the end (Stop, P) of the transaction. The signals
S and P correspond to the two possible transitions of SDA when SCL is high.

When a transaction is in progress (i.e., between S and P), transitions of SDA are only
allowed when SCL is low.

Illustration:
SDA

SCL S P

16
 I2C: Data transfers

During a transaction, the sender of data can either be the master or the slave.

The value of each bit of data sent on the bus corresponds to the value of SDA during a
low-to-high transition of SCL.

Data is exchanged in 8-bit groups, the most significant bit (MSB) being sent first.

Each group of 8 bits must be followed by an acknowledgment, represented by a low

value placed on SDA by the receiver.

If a group of bits is not acknowledged, then the master immediately aborts the
transaction, and the slave stops sending or receiving data.

17
 I2C: Addressing

When a transaction is initiated, the master has to specify which device is the other
participant.

Principles:

The first 8 bits exchanged in a transaction are always sent by the master.

The first 7 bits of this group correspond to the address of the intended slave.

The 8th bit then specifies the direction of the following data transfer:

0 : The master is the sender;

1 : The master is the receiver.

Remark: The first group of 8 bits must thus be acknowledged by the addressed slave,
regardless of the data transfer direction.

18
 I2C: Arbitration

It is possible to have several devices attempting to initiate transactions at the same time, by
generating simultaneous Start signals.

For detecting potential conflicts, each master constantly monitors the value of SDA when it
sends data. If the observed value differs from the sent one, then the master performing this
observation immediately and silently withdraws from the transaction.

Remarks:

A conflict can only be detected by the device that sends a high value.

Transmitting simultaneously two exactly identical frames does not lead to a conflict!

19
 I2C: Flow control

In some cases, the frequency of the clock signal generated is too high to be followed by the
slave.

In such situations, the slave can request the master to permanently or temporarily slow
down the clock. This can be done by stretching the low value of SCL until the slave is ready
again to send or receive data.

When the master releases SCL while the clock is stretched, it detects that the value of SCL
stays low, and pauses its operations until this line is released by the slave.

Illustration:
released by the master

SCL

released by the slave

20
 Multiplexed input/output pins

Most microcontrollers allow to dynamically configure input/output pins in software.

Examples of typical configurations:

Digital input

VCC
Three-state output

Open-drain output
Digital input with pull-up
GND
Schmitt trigger
D/A Analog output
A/D Analog input

This feature makes is possible to build simple circuits in which the processor can interact
with a large number of peripherals.

21
Example: Digital multimeter

The problem is to interface a microcontroller offering only 12 dynamically configurable

input/output pins with:

a screen composed of four 7-segment displays,

a keyboard organized as a 4 4 matrix,

4 analog input channels.

(Source: Microchip application note AN557)

22
Solution:

The screen and the keyboard are scanned: At a given time, one can only display a
single digit, or read a single column of keys.

An additional phase is inserted for reading input channels.

4 pins are associated to both an input channel and a screen digit. They are
alternatively configured as analog inputs (when reading channels) and digital outputs
(when displaying a digit or reading the keyboard).

The 8 remaining pins drive the screen segments during display and channel reading
phases (8 digital outputs), and are also able to the scan the keyboard (4 digital outputs
+ 4 digital inputs with pull-up).

23
Schematics:

MCU

24
Chapter 3

Interrupts

25
 Introduction

An interrupt is a signal that requests the processor to temporarily suspend program

execution, in order to execute an interrupt routine.

Advantages:

A very short response time to solicitations is achievable.

Urgent operations can be programmed independently from the main code.

Interrupts can be triggered either by an exterior component:

Interrupt ReQuest (IRQ), received from dedicated input pins,

change of logic value at digital input pins,

26
or by the processor itself:

timer expiration,

arithmetic or instruction exception,

software interrupt request,

...

27
 The interrupt mechanism

Upon receiving and accepting to service an interrupt request, the processor performs the
following operations:

1. The execution of the current instruction terminates.

2. A pointer to the next instruction to be executed is stored on the runtime stack.

3. The address of the interrupt routine is read from the appropriate interrupt vector
(according to the source of the interrupt request).

4. The interrupt routine is executed.

5. At the end of the interrupt routine, the processor resumes program execution, at the
address retrieved from the stack.

28
 Interrupt control

Some critical operations can never be interrupted. It is then necessary to temporarily

disable interrupts prior to their execution, and to enable them again afterwards.

Some processors allow to assign specific priorities to interrupts originating from different
sources. Such architectures generally provide a mechanism for disabling the interrupts
having a priority less than some specified threshold. Interrupt priorities are also used for
resolving simultaneous interrupt requests.

Enabling and disabling interrupts is performed by executing specific instructions, or by

setting the value of dedicated registers.

Notes:

At power-on, interrupts are disabled by default, in order to allow correct initialization of

the program.

29
 When an interrupt is triggered, some processors automatically disable all interrupts of
less or equal priority. They have to be explicitly reenabled in the interrupt routine if
needed.

When an interrupt request is received, the processor sets interrupt flags, in order to
trigger the interrupt as soon as it becomes enabled. Interrupt flags have to be cleared
explicitly by the interrupt routine.

Some architectures provide an interrupt source that cannot be disabled (Non

Maskable Interrupt, NMI). Its usage is limited to exceptional situations (e.g., backing
up critical data upon detecting an imminent power failure).

30
 Saving and restoring context

The correct operation of a program must not be influenced by interrupts triggered during its
execution.

It is thus mandatory for interrupt routines to leave the processor state unchanged: values of
registers and flags, interface configuration, status of peripherals, . . . , must not be modified.

This is achieved by saving the context at the beginning of interrupt routines, and restoring it
at the end.

Notes:

The context is either saved on the execution stack or in a specific memory area.

Some processors automatically save the context (either totally or in part) when an
interrupt is triggered.

31
 Context save and restore operations can sometimes be simplified by using dedicated
instructions.

The processors that automatically disable interrupts when branching to an interrupt

routine enable them again as a side effect of context restoration.

32
 Programming interrupts

The compilers aimed at embedded applications provide language extension mechanisms

for programming interrupts without going down to assembly language.

Some functions can be designated as being interrupt routines (e.g., interrupt

keyword, or #pragma interrupt compilation directive in C).

With some compilers, such mechanisms automatically insert context save and restore
instructions to interrupt routines, and take care of setting interrupt vectors.

Enabling and disabling interrupts is performed with the help of macros or specific
compilation directives (i.e., enable()/disable(), critical keyword).

It is sometimes necessary to inform the compiler than the value of a variable can be
modified by interrupt routines, in order to prevent incorrect optimizations (e.g.,
volatile keyword in C).

33
 Communicating with interrupt routines

Interrupt requests are by nature unpredictable. This complicates data exchange operations
between interrupt routines and the main code.

Example: Industrial controller. The alarm must sound if two temperature measurements
made by an interrupt routine differ.

Wrong solution:

static volatile int temp[2];

interrupt void measure(void)

{
temp[0] = !! first measurement ;
temp[1] = !! second measurement ;
}

void controller(void)
{
int temp0, temp1;
for (;;)
{
temp0 = temp[0];
temp1 = temp[1];
if (temp0 != temp1) !! sound the alarm;
}
}

34
Notes:

Carrying out the comparison between the two measurements in a single C instruction
does not solve the problem:

...
void controller(void)
{
for (;;)
if (temp[0] != temp[1]) !! sound the alarm;
}
...

(Indeed, such an instruction is generally compiled into several machine instructions.)

Even in programs written in assembly language, it is possible for the execution of

individual instructions to be interrupted before their completion.

This only happens with specific instructions, often repeatedly performing a simpler
operation (e.g., block copy instructions).

This type of bug can be very difficult to detect and to reproduce!

35
Correct solution:

The instructions that read the measurements sent by the interrupt routine to the controller
form a critical section, the execution of which cannot be interrupted.

static volatile int temp[2];

interrupt void measure(void)

{
temp[0] = !! first measurement ;
temp[1] = !! second measurement ;
}

void controller(void)
{
int temp0, temp1;
for (;;)
{
disable(); /* Disable interrupts */
temp0 = temp[0];
temp1 = temp[1];
enable(); /* Reenable interrupts */

if (temp0 != temp1) !! sound the alarm;

}
}

36
Other solution:

static volatile int temp_a[2], temp_b[2];

static int controller_uses_b = 0;

interrupt void measure(void)

{
if (controller_uses_b)
{
temp_a[0] = !! first measurement ;
temp_a[1] = !! second measurement ;
}
else
{
temp_b[0] = !! first measurement ;
temp_b[1] = !! second measurement ;
}
}

void controller(void)
{
for (;; controller_uses_b = !controller_uses_b)
if (controller_uses_b)
{
if (temp_b[0] != temp_b[1]) !! sound the alarm;
}
else
if (temp_a[0] != temp_a[1]) !! sound the alarm;
}

37
Notes:

This solution does not require to disable interrupts.

The main code must sometimes perform one useless iteration before sounding the
alarm.

38
Improved solution:
#define MAX_FIFO 10 /* Must be even ! */
static volatile int temp_fifo[MAX_FIFO];
static volatile int first = 0;
static int last = 0;

interrupt void measure(void)

{
/* If the buffer is not saturated */
if (!((first + 2 == last)
|| (first == MAX_FIFO - 2 && last == 0)))
{
temp_fifo[first] = !! first measurement ;
temp_fifo[first + 1] = !! second measurement ;
first += 2;
if (first == MAX_FIFO)
first = 0;
}
else !! discard measurements;
}

void controller(void)
{
int temp0, temp1;

for (;;)
if (first != last) /* If the buffer is not empty */
{
temp0 = temp_fifo[last];
temp1 = temp_fifo[last + 1];
last += 2;
if (last == MAX_FIFO)
last = 0;
if (temp0 != temp1) !! sound the alarm;
}
}

39
Note: For this solution to be correct, it is necessary that the instruction last += 2
executes atomically.

This kind of solution is thus very sensitive to implementation details!

In practice, disabling interrupts during communications with interrupt routines is acceptable

in most situations. The more complex solutions are used only when disabling interrupts is
impossible or forbidden.

40
 Interrupt latency

The delay between an interrupt request I and the end of execution of urgent operations in
an interrupt routine RI is called the response time, or latency of the interrupt.

This latency is influenced by four parameters:

1. The longest interval during which interrupts of priority larger or equal to I are disabled.

2. The time needed for executing the interrupt routines with a higher priority than RI .

3. The maximum delay between an interrupt trigger and the branch to the corresponding
interrupt routine.

4. The time spent in RI before having executed the urgent operations.

41
A good strategy is therefore to

disable interrupts for the shortest possible time (parameter 1);

make the interrupt routines quick and efficient (parameters 2 and 4).

Parameter 3 is a feature of the processor, and cannot be influenced by the programmer.

42
 Example

A system implements the following interrupt routines, sharing the same priority.

Name Description Execution time Period

I1 Temperature measurement 100 s 500 s
I2 Timer expiration 200 s 1000 s
I3 Network I/0 300 s > 1000 s

The main program disables interrupts during resp. 200 s and 250 s for exchanging
data with I1 and I2.

The time needed for triggering I3 and executing the corresponding urgent operations is
equal to 100 s.

Question: Is the latency of I3 smaller than 1000 s ?

43
Answer:

It is sufficient to study the system during an interval of length equal to 1000 s. The highest
possible latency is obtained with the following delays:

Interrupts disable time : 250 s.

Executing I1 : 2 100 s.

Executing I2 : 200 s.

Triggering and executing the urgent operations of I3 : 100 s.

Total: 750 s.

Notes:

Only the largest interval in which interrupts are disabled has to be taken into account!

44
 Example of scenario in which the maximum latency is reached:

urgent
operations
completed

IRQ1 IRQ1
IRQ2 enable()
IRQ3 I3
disable() I2
I1

Main program

0 100 200 300 400 500 600 700 800 900 1000 (s)

The execution of I3 always terminates before 1000 s.

45
 Chapter 4

Software architectures

46
 The round-robin architecture

Principles:

Interrupts are not used.

Tasks are invoked in turn, and run until their completion.

Illustration:
void main(void)
{
for (;;)
{
if (!! task 1 is ready )
{
!! operations of task 1;
}
if (!! task 2 is ready )
{
!! operations of task 2 ;
}
..
.

if (!! task n is ready )

{
!! operations of task n;
}
}
}

47
Advantages:

Simple solution, but sufficient for some applications.

Exchanging data between tasks is easy.

Drawbacks:

The worst-case latency of an external request is equal to the execution time of the
entire main loop.

Implementing additional features can adversely affect the correctness of a system, by

increasing latencies beyond acceptable bounds.

48
Example (multimeter):
#include "types.h"
#include "multimeter.h"
static UINT1 phase = 0; /* 03: display, 4: keyboard, 5: channels */
static UINT1 display_content[4];
static SINT4 measures[4];
static keyboard_state keys;
static multimeter_state parameters;
void main(void)
{
!! initialize global data ;
for (;;)
{
switch (phase)
{
case 4:
handle_keyboard();
if (keys.new_keypress)
{
keypress_action();
keys.new_keypress= 0;
}
break;
case 5:
handle_channels();
update_display_content();
break;
default:
handle_display();
}
if (++phase > 5)
phase = 0;
}
}

49
void handle_display(void)

{
UINT1 digit, segments;

!! PORTA: 4 digital outputs ;

!! PORTB: 8 digital outputs ;

digit = !! compute the digit to be displayed, from the

!! values of display_content and phase;
segments = !! pattern corresponding to digit;

out(PORTA, 1 < < phase);

out(PORTB, segments);

delay(DISPLAY_DELAY);
}

void handle_channels()
{
!! PORTA: 4 analog inputs ;
!! PORTB: 8 digital outputs ;

out(PORTB, 0);
delay(CHANNELS_DELAY);

!! read PORTA, and place the result in measures;

}

void handle_keyboard()
{
static UINT1 column = 0;
UINT1 row;

!! PORTA: 4 digital outputs ;

!! PORTB: 4 digital outputs (low nibble),
!! 4 digital inputs with pull-ups (high nibble) ;

50
 out(PORTA, 0);
out(PORTB, 1 < < column);
row = in(PORTB) > > 4;

!! update keys according to the content of row;

if (++column >= 4)
column = 0;
}

void keypress_action()
{
!! update parameters according to the key that has
!! been pressed (specified in keys) ;
}

void update_display_content()
{
!! update display_content according to the values in
!! measures and parameters;
}

Notes: The parameters DISPLAY_DELAY and CHANNELS_DELAY must be chosen

large enough to ensure an accurate conversion of analog samples, and a good

illumination of display segments.

small enough to avoid display flickering, as well as missing key presses.

51
 The round-robin with interrupts architecture

Principles: Tasks are invoked in round-robin fashion, but interrupt routines take care of
urgent operations.

Illustration:
volatile BOOL ready1 = 0, ready2 = 0, ...,
readyn = 0;

interrupt void urgent1(void)

{
!! urgent operations of task 1;
ready1 = 1;
}

interrupt void urgent2(void)

{
!! urgent operations of task 2 ;
ready2 = 1;
}
..
.

interrupt void urgentn(void)

{
!! urgent operations of task n;
readyn = 1;
}

52
void main(void)
{
for (;;)
{
if (ready1)
{
!! non-urgent operations of task 1;
ready1 = 0;
}
if (ready2)
{
!! non-urgent operations of task 2 ;
ready2 = 0;
}
..
.

if (readyn)
{
!! non-urgent operations of task n;
readyn = 0;
}
}
}

53
Advantage: The urgent operations take priority over the non-urgent ones.

Round-robin Round-robin with interrupts

priority

Urgent 1

Urgent 2

Urg. 1 Task 1 Urg. n Task n

Urgent n

Task 1 Task 2 Task n

Drawbacks:

The non-urgent tasks share the same effective priority. This yields high latencies when
at least one task has a large execution time (e.g., raster generation in laser printers).

Important note: Moving non-urgent operations from tasks to interrupt routines is

not a good solution!

54
 Indeed,

performing non-urgent operations in an interrupt routine increases the latency of

interrupts with a lower or equal priority;
interrupts do not offer flexible synchronization mechanisms.

Data exchange operations between interrupt routines and tasks have to be correctly
implemented (cf. Chapter 3).

55
Example: Serial filter

The goal is to develop a two-way filter connecting two serial lines.

UART CPU UART

Principles:

Incoming bytes are signaled by interrupt requests, which must be answered as soon
as possible (before the next received byte).

When a UART is ready to send a byte on its output line, it requests an interrupt. The
processor is then free to wait for an arbitrarily long time before providing this byte.

56
Solution:
#include "types.h"
#include "fifo.h"
#include "filter.h"

static volatile BOOL uart1_ready, uart2_ready;

static volatile fifo rx1, tx1,
rx2, tx2;

interrupt void uart1_rx(void)

{
char byte;

byte = !! reception from UART1;

fifo_put(rx1, byte);
}

interrupt void uart2_rx(void)

{
char byte;

byte = !! reception from UART2 ;

fifo_put(rx2, byte);
}

interrupt void uart1_ready_to_send(void)

{
uart1_ready = 1;
}

interrupt void uart2_ready_to_send(void)

{
uart2_ready = 1;
}

57
void main(void)
{
!! initialize global data ;
!! initialize interrupt vectors ;

enable();

for (;;)
{
if (fifo_content_size(rx1) >= FILTER_THRESHOLD)
{
!! remove data from rx1;
!! filter ;
!! add the result to tx2;
}

if (fifo_content_size(rx2) >= FILTER_THRESHOLD)

{
!! remove data from rx2;
!! filter ;
!! add the result to tx1;
}

if (uart1_ready && !fifo_is_empty(tx1))

{
char byte;

byte = fifo_get(tx1);
disable();
!! send byte to UART1;
uart1_ready = 0;
enable();
}

58
 if (uart2_ready && !fifo_is_empty(tx2))
{
char byte;

byte = fifo_get(tx2);
disable();
!! send byte to UART2 ;
uart2_ready = 0;
enable();
}
}
}

Notes:

Attempting to add data to a saturated FIFO buffer cannot be a blocking operation (i.e.,
it must instead discard data).

59
 The functions for handling FIFO buffers must execute correctly both in the interrupt
routines and in the main code.

Example of implementation:

void fifo_put(fifo q, char c)

{
BOOL intr_enabled;

...

intr_enabled = disable();
!! critical section;
if (intr_enabled)
enable();

...
}

60
 The waiting-queue architecture

Principles:

In the same way as the round-robin with interrupts architecture, the operations are
partitioned into urgent and non-urgent tasks.

Interrupt routines perform urgent operations, and then place in a waiting queue
requests for executing non-urgent tasks.

The main program retrieves execution requests from the queue and calls the
corresponding functions. These requests are not necessarily processed in FIFO order.
(For instance, different selection priorities can be assigned to non-urgent tasks.)

61
Illustration:
#include "queue.h"

static volatile queue waiting_queue;

interrupt void urgent1(void)

{
!! urgent operations of task 1;
!! add task1 to waiting_queue;
}

interrupt void urgent2(void)

{
!! urgent operations of task 2;
!! add task2 to waiting_queue;
}
..
.

interrupt void urgentn(void)

{
!! urgent operations of task n;
!! add taskn to waiting_queue;
}

62
void main(void)
{
!! initialize waiting_queue with an empty content ;

for (;;)
{
while (!queue_is_empty(waiting_queue))
{
!! extract a function from waiting_queue;
!! execute this function;
}
}
}

void task1(void)
{
!! non-urgent operations of task 1;
}

void task2(void)
{
!! non-urgent operations of task 2 ;
}
..
.

void taskn(void)
{
!! non-urgent operations of task n;
}

63
Advantage: The latency of a non-urgent high-priority task can become smaller than the
execution time of all the non-urgent operations.

Drawbacks:

The maximum latency of a non-urgent task is still at least as large as the execution
time of the slowest task.

Implementing the waiting-queue data structure can be tricky.

Example of application: A system monitors an industrial process by receiving data from an

array of sensors, processing this data, and displaying summarized results.

With the queue architecture, it is possible to ensure that the values produced by critical
sensors are always taken into account, even in the case of data saturation caused by a
malfunctioning low-priority sensor.

64
 The real-time operating system architecture

Principles:

Urgent operations are performed by interrupt routines. Those are able to signal to
other tasks that non-urgent operations are ready to be carried out.

The non-urgent tasks are invoked dynamically rather than in a predefined order. The
responsibility of calling tasks is assigned to the operating system, implemented as an
additional software component.

The operating system is able to suspend the execution of a task before its completion,
in order to transfer the processor to another task.

The signals exchanged between tasks are handled by the operating system, instead of
being implemented with shared variables.

65
Illustration: #include "signal.h"

interrupt void urgent1(void)

{
!! urgent operations of task 1;
!! send signal 1;
}

interrupt void urgent2(void)

{
!! urgent operations of task 2 ;
!! send signal 2 ;
}
..
.

void task1(void)
{
!! wait for signal 1;
!! non-urgent operations of task 1;
}

void task2(void)
{
!! wait for signal 2 ;
!! non-urgent operations of task 2 ;
}
..
.

void main(void)
{
!! initialize the operating system;
!! create and enable tasks;
!! start task sequencing ;
}

66
Advantages:

One can easily combine low-latency operations together with long computations.

Round-robin with interrupts Operating system

priority

Urgent 1

Urgent 2
Urgent 1

Urgent 2

Urgent n

Task 1
Urgent n
Task 2

Task 1 Task 2 Task n

Task n

67
 The system is efficient: When a non-urgent task is waiting for a signal, the processor
remains available for other computations.

The structure of the system is robust: New features can easily be added without
affecting the latencies of urgent operations or of high-priority tasks.

Operating systems tailored to embedded applications are commercially available.

68
Drawbacks:

The system is complex (but this complexity is mainly located in the operating system,
which can be reused over many projects).

Data exchange operations have to be coordinated between a task and an interrupt

routine, but also between tasks.

The operating system consumes some amount of system resources (a typical figure is
2 to 4 % of the instructions executed by the processor).

69
 Summary

Task priorities and latencies:

Architecture Available priorities Maximum latency

round-robin none total execution time

of all tasks

round-robin interrupt routines; total execution time

with all tasks share the of all tasks
interrupts same priority + interrupt routines

waiting queue interrupt routines, execution time of

then tasks the longest task
+ interrupt routines

operating interrupt routines, execution time of

system then tasks interrupt routines

70
Robustness and simplicity:

Architecture Robustness against Complexity

modifications

round-robin poor very simple

round-robin good for interrupt must handle data exchanges

with routines, poor for between tasks and interrupt
interrupts the tasks routines

waiting queue fair must handle data exchanges,

and implement the waiting
queue

operating very good quite complex

system

71
 Chapter 5

Real-time operating systems

72
 Introduction

An operating system (OS) is a software component responsible for coordinating the

concurrent execution of several tasks, by

managing the system resources (processor, memory, access to peripherals, . . . );

providing services (communication, synchronization, . . . ).

An OS is implemented by a kernel (an autonomous program), together with a library of

functions for accessing conveniently its services.

The real-time operating systems (RTOS) are operating systems specifically suited for
embedded applications:

They are usable on hardware with limited resources.

73
 The following features are precisely documented:

the scheduling strategy,

the maximum execution time of each service,
every internal mechanism that can influence the latencies (e.g., the longest interval
during which interrupts are disabled by the kernel).

The user can implement urgent operations as interrupt routines.

The OS provides time-oriented services: one-shot or periodic timers, periodic

execution of tasks, . . .

Complex protection mechanisms against invalid user code may be absent.

The kernel configuration can be parameterized in detail by the programmer.

74
 Execution levels

At a given time, the instruction currently executed by the processor can either be

a kernel operation (possibly located in an interrupt routine),

an instruction belonging to an interrupt routine programmed by the user, or

an instruction of a user task.

75
 The processes

Each task managed by an OS is represented by a process. At a given time, a process is in

one out of five possible states:

Dormant: The task is not scheduled (e.g., because it is not yet known to the OS).

Executable: The task is ready to execute instructions, but is not currently running.

Active: The instructions of the task are now being executed by the processor.

Blocked: The execution of the task is suspended while waiting for a signal, or for a
resource to become available.

Interrupted: The task is executing an interrupt routine programmed by the user.

76
Possible transitions between the states of a process:

Blocked

Dormant Executable Active

Interrupted

77
 The scheduler

The scheduler is the kernel component responsible for managing the state of the
processes, i.e., for assigning the processor to the processes.

Principles:

Each task is characterized by a priority (either constant or variable during its

execution).

The scheduler always assigns the processor to the non-dormant and non-blocked task
that has the highest priority.

If several tasks share the highest priority, then the conflict can be solved in several ways:

The time slicing approach consists in assigning the processor in turn to each of these
tasks, in order to execute a bounded sequence of instructions.

78
 One can alternatively assign the processor to a task that has been arbitrarily chosen.

Another solution is to forbid different tasks to share the same priority.

Note: With the first two strategies, computing the deadline of a task becomes difficult. Most
real-time operating systems thus implement the third solution.

79
 Preemption

If a task T 2 has a higher priority than the active task T 1 and switches from the blocked to
the executable state, then there are two possible scheduling strategies:

The task T 2 remains suspended (in executable state) until completion of T 1. The
scheduler is said to be non-preemptive.

T1
Interrupt
routine

The resource expected by

T 2 becomes available

T2

80
 Drawback: The latency of a task is influenced by the behavior of tasks with a lower
priority.

The scheduler turns the task T 1 executable, and assigns the processor to T 2. The
scheduler is said to be preemptive.

T1
Interrupt
routine

T2
The resource expected by
T 2 becomes available
Preemption

81
 Context switching

The scheduler performs a context switch when it transfers the processor from a process to
another.

Principles:

The suspended task must be able to resume its execution later. The state of the
processor thus has to be saved when the task is suspended.

The kernel memory maintains for each non-dormant process a context storage area
for this purpose.

82
Illustration:

Kernel T1

T2

T1
T2
..
t

83
 The working data of the suspended task has to be preserved until its execution can be
resumed.

This data is located on the runtime stack of the task, which contains

the context (return address, stack register values) of the active function calls, and
the arguments and local variables of these function calls.

84
Example:

..
f(int a, int b)
{ f call
int c; context
.. a, b
c = g(a);
.. c

} g call
context
g(int d)
d
{
int e, f; e, f
.. B g call
e = g(f); context
.. d
}
e, f
SP

85
Notes:

Since a task can be suspended at any time, it is necessary for each process to
manage its own stack.
In general the stack pointers (e.g., top of stack, base of current stack frame) are
particular processor registers. Those pointers are therefore saved, together with
the other registers, during a context switch.
The kernel also manages its own stack.

86
 Reentrancy

With a preemptive scheduler, calling the same function in different tasks can be
problematic.

Example:

static int aux;

void swap(int *p1, int *p2) swap(&x1, &y1)
{
aux = *p1; aux 1
*p1 = *p2;
*p2 = aux; x1 2
}
swap(&x2, &y2)
aux
aux 2
x1 1
x2 3
y1 2
y2 2
x2 2

y2 3 y1 2

87
Definition: A function is said to be reentrant if it can be simultaneously called by several
tasks without possibility of conflict.

Examples:
Reentrant function:
void swap(int *p1, int *p2)
{
int aux;

aux = *p1;
*p1 = *p2;
*p2 = aux;
}

Non-reentrant function:

volatile int is_new; /* modified by another task */

void display(int v)
{
if (is_new)
{
printf(" %d", v);
is_new = 0;
}
else
printf(" ---");
}

88
Note: The second function is non-reentrant for three reasons:

The test and assignment operations over the global variable is_new are performed
by different instructions.
The operations involving is_new are not necessarily atomic.
The function printf might not be reentrant.

89
 Communication between tasks

Organizing data transfers between processes is more difficult than between tasks and
interrupt routines:

Context switches can occur unpredictably at any time.

Context switches can only be disabled in software, by modifying the scheduling policy.

Solution: One can use services provided by the kernel, aimed at

synchronizing the operations of concurrent tasks, and

coordinating data transfers from a process to another.

Note: Using incorrectly communication or synchronization services can lead to deadlocks,

when every task is suspended waiting for resources that can only be provided by other
tasks.

90
 The semaphores

A semaphore s is an object that

has a value v(s) 0,

over which the two following operations can be performed:

wait(s):

if v(s) > 0, then v(s) v(s) 1;

if v(s) = 0, the task is suspended (in blocked state).

signal(s):

if at least one task is suspended as the result of an operation wait(s), make one
of them become executable;
otherwise, v(s) v(s) + 1.

91
Notes:

The operations that test and modify the value of a semaphore must be implemented
atomically.

Binary semaphores are semaphores with a value restricted to the set {0, 1}.

There are several possible strategies for selecting a task blocked on a semaphore in
order to make it executable again: arbitrary choice, FIFO policy, priorities, . . .

In most applications, acquiring a semaphore represents the access right to a resource.

Example: Mutual exclusion between two tasks (binary semaphore s initialized to 1).

void task1(void) void task2(void)

{ {
for (;;) for (;;)
{ {
wait(s); wait(s);
!! critical section; !! critical section;
signal(s); signal(s);
!! other operations ; !! other operations ;
} }
} }

92
 The message queues

A message queue is an object that implements synchronous or asynchronous data

transfers between tasks.

Principles:

The maximum capacity of a queue (i.e., the maximum number of messages that have
been written and not yet read) and the size of each message are fixed.

Send and receive operations are performed atomically.

A task that is waiting to receive data from a queue is suspended by the scheduler (in
blocked state).

Variants:

Several data access policies are possible: FIFO order, arbitrary selection, priority
mechanism.

93
 Sending data to a saturated message queue can either discard the new message,
block the sender, block the sender during a bounded amount of time, . . .

When a task is blocked waiting for data from an empty queue, a maximum suspension
delay (i.e., a timeout) can be specified.

The maximum capacity of a queue can be reduced to zero (rendez-vous

synchronization).

94
 Programming with interrupts

The scheduler and the interrupt mechanism are both able to move the control point from
one location in the program code to another. One must take care of avoiding conflicts
between those mechanisms.

First rule:

An interrupt routine is not allowed to call an OS service if this service can

suspend the current task (e.g., acquiring a semaphore (wait), receiving data from
a message queue, . . . ).

95
 Indeed, if this rule is not respected, then an interrupt routine can get suspended, which
amounts to assigning to this interrupt routine an effective priority smaller than the one
of a task.

Example:
T1
Interrupt
routine

T2

T 1 is suspended
T 1 is resumed
T3

T 1 becomes active

End of interrupt

96
 Moreover, the interrupt routine might get called again before its completion. If this
routine is not reentrant, then erroneous behaviors are possible (e.g., overwriting a
saved processor context).
T1
Interrupt
routine

T2

T 1 is suspended

Reentrant call

End of interrupt

T 1 is resumed

t End of interrupt

97
Second rule:

If an interrupt routine calls an OS service that can lead to a context switch, then
the scheduler must be informed that this service call is performed inside an
interrupt routine.

If this rule is not respected, then the scheduler can suspend the execution of an interrupt
routine.

Example:
T1 Interrupt
routine

T2

T 1 is preempted

End of interrupt

98
Solution: At the beginning and at the end of each interrupt routine programmed by the
user, special OS services must be called in order to inform the kernel that the processor is
currently executing an interrupt routine.

Notes:

In the case of many levels (i.e., priorities) of interrupts, those services must handle
correctly nested interrupt routine calls.

Some operating systems provide alternate versions of some services, intended to be

called from interrupt routines.

Interrupt latencies are increased by the time needed for executing the notification
services.

99
Example:
T1 Interrupt
Interrupt request routine
Kernel

Interrupt entering service

Service call

Possible preemption

Interrupt leaving service

T 1 is preempted
T2

Context switch

t
End of interrupt

100
Note: An interrupt routine containing explicit instructions for saving the processor state
must perform the corresponding restore operations before informing the kernel that the
interrupt routine is about to end.

101
 Time-oriented services

The real-time operating systems offer timed services, for instance for suspending a task for
a predefined amount of time.

Principles:

A dedicated component triggers periodic requests (clock, heartbeat) for an interrupt

that has
a higher priority than the interrupts programmed by the user, and
an interrupt routine implemented by the kernel.

The delay during which a task is suspended is expressed in the number of

occurrences of this interrupt request signal (ticks, beats).

102
Note: The precision is limited. Asking to suspend the task during k ticks only ensures that
the suspension delay is greater or equal to k 1 times the clock period.

Example:

Periodic interrupt

Periodic interrupt routine

Higher-priority tasks

Timed task

delay(1) delay(1)

103
 Chapter 6

Real-time operating systems:

Implementation issues

104
 Overview of the main problems

The following operations need to be efficient (i.e., ideally, to have a maximum execution
time that is independent from the number of tasks managed by the operating system):

Identifying the executable process with the highest priority in order to make it
active.
Performing a context switch.
Selecting the process that has to be unblocked following an operation over a
communication object.

For operations over communication or synchronization objects that can suspend a

process, it should be possible to specify a timeout (i.e., a maximum suspension delay).

One needs to be able to access all processor registers.

For some applications, the real-time operating system has to share the processor with
another operating system.

105
 Task control blocks

A Task Control Block (TCB) is a data structure that represents a non-dormant process
inside the kernel memory. This structure contains:

The current priority of the task.

Note: When the task priorities are fixed and unique, they can also be used as process
identifiers.

The context of the task, i.e., the state of the processor, saved when the task was last
suspended.

Notes:

This context contains, in particular, a pointer to the runtime stack of the process.
Some operating systems (e.g., COS-III) save the bulk of the context on this stack.

The current state of the process (executable, active, blocked, or interrupted).

106
 Information for managing a potential timeout.

A pointer to a data structure representing a communication object that the task is

(possibly) attempting to acquire.

Pointers linking the TCB to the global data structures of the kernel.

Auxiliary data aimed at speeding up some operations (e.g., values derived from the
task priority).

Additional information managed by the user (e.g., configuration data for a peripheral
controlled by the task).

107
 Global data structures of the kernel

The global information managed by the kernel essentially contains:

Sets of task control blocks corresponding to

the executable (or active) processes,

the processes suspended for a given delay,
the free blocks.

Those sets are organized as simply or doubly-linked lists, or by hash tables, in order to
be able to manipulate them in constant time.

A structure for identifying efficiently the executable process with the highest priority.

An index for accessing directly a task control block from its corresponding process
identifier.

Data structures representing the state of communication objects.

108
Example: COS-III

The maximum number of process priorities is a compile-time configuration parameter

of the kernel (OS_CFG_PRIO_MAX).

The set of executable processes is represented by

an array OSPrioTb[] of bit fields (with a width suited for the processor
architecture). Each set bit corresponds to a priority for which there exists at least
one executable (or active) process.
an array OSRdyList[] associating to each priority level a doubly-linked list of TCB
of executable processes.
Note: COS-III allows several processes to share the same priority. Such
processes are then scheduled by time slicing.
A pointer OSTCBCurPtr to the TCB of the currently active task.

The set of processes suspended for some delay is represented by a hash table
OSCfg_TickWheel[], indexed by their deadline.

109
 Keeping an index of all non-dormant tasks is not necessary, because process
identifiers are defined as pointers to the corresponding TCB.

Managing a list of free TCB is avoided by letting the user code allocate TCB when
tasks are created.

A global counter OSIntNestingCtr keeps tack of the current interrupt nesting level.

110
 Illustration (32-bit processor)

31 0

OSPrioTb[] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1

OSTCBCurPtr OSRdyList[] 0
1
2

14

42

OS TCB OS TCB OS TCB

(task 14-1) (task 14-2) (task 42)

14 14 42

stack of task 14-1 stack of task 14-2 stack of task 42

111
Note: Identifying quickly the executable process with the highest priority is achieved by

exploiting specific processor instructions (e.g., Count Leading Zeros, CLZ), or

tabulating the possible values of bit fields.

112
 The scheduler

The scheduler is implemented by a kernel function called after each operation that can
potentially influence the state of processes:

Creating or destroying a task, or modifying a task priority.

Acquiring or releasing a communication object.

Servicing the clock interrupt.

This function must be kept simple and efficient, and only performs the following operations:

1. Checking whether the scheduler is allowed to preempt tasks.

2. Identifying the executable task with the highest priority.

3. Performing a context switch in order to assign the processor to this task.

113
Note: The possibility of enabling or disabling preemption is offered because

preempting the current task should be prevented inside interrupt routines (cf.
Chapter 5).

it provides a simple mechanism for manipulating atomically shared variables or

communication objects (preemption locks). However, this mechanism

increases the latency of the tasks (by the duration of the longest interval during
which preemption is disabled), and
affects all the tasks of the system (not only those that need to be coordinated).

114
 Context switching

The main issue for implementing context switching is to be able to save and restore all the
processor registers.

For many processors, these operations are automatically performed (totally or in part)
during interrupts:

When an interrupt routine is called: The current value of the registers is saved on the
runtime stack of the interrupted task.

When an interrupt routine returns: The values extracted from the current stack are
loaded into the processor registers.

A simple solution (when allowed by the processor architecture) consists of performing

context switching in an interrupt routine, the corresponding interrupt request being
triggered by the scheduler.

115
The operations performed by this interrupt routine thus amount to

1. Saving the stack pointer of the suspended task into its associated TCB.

2. Loading the stack pointer of the task that becomes active from its associated TCB.

3. Executing a return from interrupt instruction.

Notes:

This approach avoids the need to store the entire state of the processor into a TCB.

Preserving the state of the processor between a kernel service call and the
subsequent context switch can be tricky.

The user can sometimes define a hook function that will be called at every context
switch (a typical application is to put a peripheral in sleep mode).

116
 Task creation and destruction

Creating or destroying a process essentially amounts to updating the data structures

managed by the kernel, and to then call the scheduler.

Notes:

The runtime stack of a new process is allocated by the task that asks this process to
be created.

The initial processor context of a new task, including its entry point, is built when its
stack is initialized.

A parameter can generally be passed to a newly created task, in order to make it

possible for several tasks sharing the same code to behave differently.

One must take care of removing references to a task that is destroyed from the
structures managing communication objects.

117
 The idle task(s)

Some operating systems systematically create one or many internal tasks, with a lower
priority than the processes instantiated by the user.

There are many advantages to this approach:

The scheduler can be more efficient, since it does not has to check whether there
exists at least one executable task.

Such tasks make it possible to measure the processor utilization.

Example: COS-III defines two idle tasks:

OS_IdleTask(), executing an infinite loop incrementing global counters.

OS_StatTask() (optional), computing at regular intervals the processor utilization
from the value of the counters.

In the case of a mobile system, an idle task can put the processor and some
peripherals in sleep mode in order to conserve energy.

118
 Time management

Quantitative time management is performed by the clock interrupt routine.

Principles: At each clock tick:

One computes the set of suspended tasks that must become executable again.

One increments a counter aimed at measuring elapsed time.

Notes:

The maximum execution time of the clock interrupt routine depends on the mechanism
used for waking up tasks.

With the help of suitable data structures, this time can become equal to the number of
tasks becoming executable.

It is often necessary to configure and calibrate the clock interrupt source during
initialization.

119
Example: COS-III

The time management operations are not directly performed in the clock interrupt
routine, but in an internal task OS_TickTask() woken up by this routine.

Advantage: Some user-defined tasks can have a higher priority than the time
management operations.

The deadline of the tasks suspended to a timeout is expressed with respect to a global
clock counter.

A hash table OSCfg_TickWheel[] stores pointers to the TCB of those tasks, indexed
by their deadline. Tasks sharing the same table entries are sorted in increasing
deadline order.

120
 Communication and synchronization objects

In the kernel memory, a communication or synchronization object is represented by a

structure containing:

The type of the object (semaphore, message queue, . . . ).

Data representing the state of the object (e.g., for a semaphore, an integer counter).

A set of suspended tasks, waiting to acquire the object.

In the case of a priority-based selection policy, such a set can be represented by a

doubly-linked list of TCB, sorted in decreasing priority order.

If necessary, the kernel also maintains a table of allocated objects.

Finally, the TCB of each task waiting for an object contains a pointer to the structure
managing this object.

Note: Implementing kernel services that update the state of objects does not require
specific instructions such as test and set, since it is sufficient to disable interrupts during
non-atomic operations.
121
 Combining a real-time and a non-real-time operating systems

It is possible to combine in a single application a real-time operating system (RTOS) with

another operating system (host OS). There are two possibilities:

The operations of the host operating system are suspended when the real-time OS is
started, and get the processor back when the RTOS terminates (e.g., COS-III).

The host operating system is seen as special task that has a lower priority than all the
tasks managed by the real-time OS (e.g., RTAI).

For implementing this approach, it is necessary to ensure that the host OS can never
disable the interrupts managed by the kernel or the real-time tasks.

122
 Chapter 7

Scheduling problems

123
 Priority inversion

Priority inversion happens when a task is suspended waiting for a resource controlled by
another task with a lower priority.

T1

Example: T 1 is preempted
wait( s)
T2
T 2 is preempted
T3

T 3 is suspended
wait( s)

T 2 terminates

T 3 is resumed
signal( s)

124
Problem:

In such a situation, the effective priority of T 3 becomes equal to the one of T 1.

Solution:

The priority of T 1 can be momentarily increased (becoming equal to that of T 3) during all
the time that T 3 is suspended waiting for the semaphore acquired by T 1.

This priority inheritance mechanism is automatically applied by some operating systems.

125
Illustration:
T1

wait( s)
T2

T3

wait( s)

signal( s) Priority = 3

126
 Periodic tasks scheduling

We consider a simplified programming environment satisfying the following hypotheses:

The number of tasks to be executed is fixed.

Each task is characterized by a distinct and constant priority.

The execution requests for each task occur periodically, i.e., with a constant delay
between two successive requests.

In particular, the timing of execution requests for a task cannot depend on operations
performed by other tasks.

The execution time of each task is constant.

127
 The following real-time constraint must be satisfied:

Each execution of a task must finish before or at the same time as the next
request for executing this task.

Context switches are instantaneous and preemptive.

128
 Critical instants and critical zones

In addition to its priority, each task i is characterized by

its period T i, and

its execution time (for each period) Ci.

Definitions:

The response time of an execution request for i is the delay between this request and
the end of the corresponding execution of this task.

A critical instant for the task i is an occurrence of an execution request for i that
leads to the largest possible response time for this task.

A critical zone for i is an interval of duration T i that starts at a critical instant (for i).

129
Theorem 1: A critical instant for i occurs when an execution request for this task coincides
with requests for executing all the tasks that have a higher priority than i.

Proof: Assume that an execution request for i occurs at t = t1, and that an execution
request for a higher-priority task j is received at t = t2.

t1 t2 t2 + C j t2 + T j t1 + T i
t

Ti

Advancing the request for j from t2 to t1 can never decrease the response time of i

The same reasoning can be applied to all the tasks that have a higher priority than i.

130
 Schedulable tasks

Definition: A set of tasks is schedulable (with respect to a given assignment of priorities) if

the response time of each task i is always less than or equal to its period T i.

Thanks to Theorem 1, checking whether a given set of tasks is schedulable reduces to

simulating the scheduling strategy in the particular case of simultaneous execution
requests for all tasks at t = 0.

Examples: Consider two tasks 1 and 2, with T 1 = 2, T 2 = 5, C1 = 1 and C2 = 1.

If 1 has a higher priority than 2.

t
1
0 1 2 3 4 5

t
2
0 1 2 3 4 5

Critical zone

131
 The tasks are schedulable, and remain schedulable even if the execution time of 2 is
increased by one time unit (C2 = 2):

t
1
0 1 2 3 4 5

t
2
0 1 2 3 4 5

Critical zone

If 2 has a higher priority than 1.

t
2
0 1 2 3 4 5

t
1
0 1 2 3 4 5

Critical zone

The tasks are schedulable.

Note: In this case, the execution time of 1 and 2 cannot be increased anymore.

132
 Rate-Monotonic Scheduling

In the previous example, the best strategy was to assign the highest priority to the task that
has the smallest period.

Definition: Given a set of tasks 1, 2, . . . , n with respective periods T 1, T 2, . . . , T n, the

Rate-Monotonic Scheduling (RMS) strategy consists in assigning distinct priorities
P1, P2, . . . Pn to the tasks, such that for all i, j:

T i < T j Pi > P j .

The following result establishes that the RMS strategy is optimal:

Theorem 2: If a set of tasks is schedulable with respect to some priorities assignment, then
it is schedulable as well with respect to priorities defined by the RMS strategy.

133
Proof: Consider a set of tasks 1, 2, . . . , n for which there exists a priorities assignment
P1, P2, . . . Pn that makes them schedulable.

Let i and j two tasks with adjacent priorities Pi and P j, such that Pi > P j.

If T i > T j, then the priorities of i and j can be swapped:

j
0 Tj Ti

t
i

The resulting set of tasks remains schedulable.

By performing repeatedly this operation, one eventually obtains a priorities assignment

corresponding to the RMS strategy.
134
 The processor load factor

Consider a set of tasks 1, 2, . . . , n with respective periods and execution times

T 1, T 2, . . . , T n and C1, C2, . . . , Cn.

The processor load factor U corresponding to this set of tasks represents the relative
amount of CPU time needed for executing them:
n
X C i
U= .
Ti
i=1

Definition: A set of tasks fully uses the processor if

this set of tasks is schedulable, and

any increase of the execution time of a task (and hence of the processor load factor)
yields a set of tasks that is not schedulable anymore.

135
Notes:

Thanks to Theorem 2, checking whether a set of tasks is schedulable or not can be

done by assigning RMS priorities to those tasks.

A set of tasks that has a processor load factor less than 1 is not necessarily
schedulable:

Example:
1 : T 1 = 5, C1 = 2
)
2 4
U= + 97%
2 : T 2 = 7, C2 = 4 5 7

t
1
0 1 2 3 4 5 6 7

t
2
0 1 2 3 4 5 6 7

136
 Classifying sets of tasks

The set of sets of tasks can be partitioned into three classes:

The non schedulable sets of tasks.

The sets of tasks that fully use the processor.

The schedulable sets of tasks that do not fully use the processor.

100%
Non schedulable sets of tasks

Sets of tasks that fullly use the CPU

UL

Schedulable sets of tasks

0%

137
The best lower bound U L on the processor load factor of the sets of tasks that fully use the
processor is such that:

If the processor load factor of a set of tasks is less than or equal to U L, then this set of
tasks is schedulable (regardless of the periods and execution times of the tasks!).

If the processor load factor of a set of tasks is greater than U L, then this set of tasks
may or may not be schedulable, depending on the details of the tasks.

138
 U L: Case of two tasks

Let 1 and 2 be two tasks with respective periods and execution times T 1, T 2 and C1, C2.
We assume T 1 < T 2. According to the RMS strategy, we assign a higher priority to 1.

lT m
During a critical zone of 2, the number of execution requests for 1 is equal to T 2 .
1

If all the executions of 1 in the interval [0, T 2] terminate earlier than or at t = T 2.

C1 C1
1

C2
t
2
0 T1 T2

The following condition is satisfied:

$ %
T
C1 T 2 T 1 2 .
T1

139
For a given value of C1, the largest possible value of C2 is given by
& '
T
C2 = T 2 C1 2 .
T1

It follows that the highest possible processor load factor is equal to

C1 C2
U = +
T1 T2
& '!
1 1 T2
= 1 + C1 .
T1 T2 T1
& '
1 1 T2
Note that we have 0.
T1 T2 T1
Therefore, for given values of T 1 and T 2, the maximum processor load factor
decreases with C1.
U
 l T m
1 + C1 1
T1 1
T2
2
T1
1

0
jT k C1
T2 T1 2
T1

140
 If an execution of 1 is still unfinished at t = T 2.
C1 C1
1

C2
t
2
0 T1 T2

The following condition is satisfied:

$%
T2
C1 > T 2 T 1 .
T1

For a given value of C1, the largest possible value of C2 is given by

$ %
T2
C2 = (T 1 C1) .
T1

Hence, the highest possible processor load factor is equal to

$ % $ %!
T1 T2 1 1 T2
U= + C1 .
T2 T1 T1 T2 T1

141
For given values of T 1 and T 2, this expression increases with C1, since
$ %
1 1 T2
0.
T1 T2 T1

U
jT k  j T k
T1
T2
2
T1 + C1 1
T1 1
T2
2
T1

0 jT k
T2 T1 2
T1 T1 C1

142
Summary:
U
jT k  j T k
T1
T2
2
T1 + C1 1
T1 1
T2 T1
2

0 jT k
T2 T1 2
T1 T1 C1

The smallest value of U corresponds to the boundary between the two cases, where we
have
$ %
T
C1 = T 2 T 1 2 .
T1

By introducing this value in the expression of U , one obtains

$ % $ %! $ %!
T1 T2 T 1 1 T2
U = + T2 T1 2
T2 T1 T1 T1 T2 T1
T1 T2 2
$ % $ % $ %
T1 T2 T2 T2
= + 2 + .
T2 T1 T1 T1 T2 T1

143
 $ % $ %
T2 T T
Let us define I = and f = 2 2 .
T1 T1 T1

The previous expression becomes

I I2
U = + (I + f ) 2I +
I+ f I+ f
1 f
= 1 f .
I+ f

The smallest possible value of U is obtained with I = 1. We then have

1 f
U =1 f ,
1+ f
and
dU f2 + 2f 1
= .
df (1 + f )2

The best lower bound U L on U is thus obtained with I = 1 and f = 1 + 2:



2 2
U L = 1 ( 2 1) = 2( 2 1) 0.83.
2

144
 Case of two tasks: Conclusions

Theorem 3: If a set of two periodic tasks has a processor load factor that is less than or

equal to 2( 2 1), then this set of tasks is schedulable.

Notes:

This sufficient criterion is independent from the periods and execution times of the
tasks.

In the particular case where T 2 is an integer multiple of T 1, one has f = 0, hence

U L = 1.

C1 C2
All pairs of tasks satisfying this condition (and such that + 1 !) are thus
T1 T2
schedulable.

145
 U L: Case of n tasks

The goal is now to compute the value of U L

for a given number n of tasks, and

for any number of tasks.

The first step is to establish an intermediate result:

Lemma 1: Let 1, 2, . . . , n be periodic tasks with the respective periods and execution
times T 1, T 2, . . . , T n and C1, C2, . . . , Cn, such that

This set of tasks fully uses the processor,

0 < T 1 < T 2 < < T n1 < T n < 2T 1,

The processor load factor of this set of tasks is minimum among all sets of tasks that
fully use the processor.

146
In this case, one has

C1 = T 2 T 1,
C2 = T 3 T 2,
...
Cn1 = T n T n1,
Cn = T n 2(C1 + C2 + Cn1)
= 2T 1 T n.

C1 C2 Cn1 Cn C1 C2 Cn1
t
0 T1 T2 T 3 T n1 Tn

147
Proof: By contradiction, let us show that we must have C1 = T 2 T 1.

If C1 = T 2 T 1 + , with > 0.

We modify the execution time of tasks in the following way:

C10 = C1 ,
C20 = C2 + ,
C30 = C3,
...
0
Cn1 = Cn1,
Cn0 = Cn.

T2 +

C1 C2 C1 C2
t
0 T1 T2
C10 C20 C10 C20

148
 After the modification, the new set of tasks still fully uses the processor. However, the
processor load factor now becomes

U0 = U + < U,
T1 T2
which contradicts the hypothesis that U is minimum.

If C1 = T 2 T 1 , with > 0.

We now modify the execution time of tasks as follows:

C100 = C1 + ,
C200 = C2,
C300 = C3,
...
00
Cn1 = Cn1,
Cn00 = Cn 2.

149
 T2

C1 C2 n C 1 n C 2 n n
t
0 T1 T2
C100 C200 n C100 C200

The resulting set of tasks fully uses the processor. The processor load factor becomes

0 2
U =U+ .
T1 Tn

Since we have by hypothesis T n < 2T 1, this property contradicts U 0 < U .

By similar reasoning, one obtains successively

C2 = T 3 T 2,
C3 = T 4 T 3,
...
Cn1 = T n T n1.

150
Since the processor is fully used, one finally gets

Cn = T n 2(C1 + C2 + Cn1).

Corollary: For each set of tasks that satisfies the hypotheses of Lemma 1, the processor
load factor is equal to

T2 T1 T3 T2 T n T n1
U = + + +
T1 T2 T n1
2T T n
+ 1
Tn
T T Tn T
= 2 + 3 + + + 2 1 n.
T1 T2 T n1 Tn

151
 T
For each i = 1, 2, . . . , n 1, let us define qi = i+1 . We then have
Ti
2
U = q1 + q2 + + qn1 + n,
q1q2 qn1
and thus for each i,
U q q qi1qi+1 qn1
=12 1 2 .
qi (q1q2 qn1) 2

The best lower bound U L of U therefore corresponds to

U
= 0
qi
1 2
1 . = 0.
qi q1q2 qn1

152
For each i, one has
2
qi = ,
q1q2 qn1
hence
1
q1 = q2 = = qn1 = 2 .
n

By introducing these values in the expression of U , one obtains

1 2
U L = (n 1)2 n + n1
n
2 n
1 1
= (n 1)2 n + 2n n
1
= n(2 n 1).

We thus have the following result:

Theorem 4: If the periods T 1, T 2, . . . , T n of a set of n tasks are such that

0 < T 1 < T 2 < < T n1 < T n < 2T 1,

1
with a processor load factor that is less than or equal to n(2 n 1), then this set of tasks is
schedulable.
153
In the hypotheses of Theorem 4, the constraint over the task periods is actually not
necessary:

Theorem 5: If a set of n periodic tasks has a processor load factor that is less than or equal
1
to n(2 1), then this set of tasks is schedulable.
n

Proof: Let 1, 2, . . . , n be tasks with respective periods and execution times T 1, T 2, . . . , T n

and C1, C2, . . . , Cn. We assume that this set of tasks fully uses the processor.
$ %
Tn
If there exists i {1, 2, . . . , n 1} such that 2T i T n, then we define q = and
Ti
r = T n qT i (we thus have q > 1 and r 0).

We modify the set of tasks in the following way:

We replace i by 0i with the period T i0 = qT i and the execution time Ci0 = Ci.

We replace n by 0n, with the period T n0 = T n and an execution time Cn0 chosen so as to
fully use the processor.

154
 Ci Ci Ci Ci
t
0 Ti 2T i (q 1)T i qT i Tn
Ci0 = Ci

T i0

In the critical zone of n, the amount of execution time used by i and leaved unused by 0i
is at most equal to (q 1)Ci. Therefore, one has

Cn0 Cn (q 1)Ci.
After modifying the set of tasks, the processor load factor U 0 becomes equal to
Ci0
C (q 1)Ci
U0 U + 0 i +
Ti Ti Tn
where U is the processor load factor of the initial set of tasks.

One then obtains

!
1 1 q 1
U 0 U + Ci + .
qT i T i Tn

155
Since we have qT i T n, this leads to

1 1 q1 1 1 q1
+ +
qT i T i Tn qT i T i qT i
0.

As a consequence, we have U 0 U . This implies that our modification of the set of tasks
did not increase the processor load factor.

By repeatedly performing such a modification, one eventually obtains a set of tasks to

which Theorem 4 can be applied.

156
 The limit processor load factor

The value of U L decreases with the number n of tasks. Indeed,

!
dU L ln 2 1
= 1 2n 1
dn n
= (1 x)e x 1,
ln 2
by defining x = . Let us show that we have
n
(1 x)e x < 1
dU L
for all x > 0 (which implies < 0 for all n > 0).
dn

x x2 x3
For all x > 0, we have e = 1 + x + + + , hence
2! 3!
x 2 x 3
(1 x)e x = (1 x) + (1 x)x + (1 x) + (1 x) +
! ! 2! 3!!
1 2 1 1 3 1 1 4
=1 1 x x x +
2! 2! 3! 3! 4!
< 1.

157
For an asymptotically large number of tasks, we obtain
1
lim U (n) = lim n(2 n 1)
n L n
1
2n 1
= lim 1
n
n
ln 2 2 1n
n2
= lim
n 1
n2
= ln 2
0.69

158
In summary, we have the following result:

Theorem 6: If a set of periodic tasks has a processor load factor that is less than or equal
to ln 2, then this set of tasks is schedulable.

Conclusion: The following algorithm can be used for checking efficiently whether a set of n
periodic tasks with a processor load factor equal to U is schedulable or not:

1. If U > 100%, then the set of tasks is not schedulable;

2. If U 69%, then the set of tasks is schedulable;

1
3. If U n(2 n 1), then the set of tasks is schedulable;

4. Otherwise, one performs an exact scheduling simulation, based on a RMS priorities

assignment.

159
 Notes

In situations where U 69% for the periodic tasks, the processor does not have to
remain unused during 31% of the time! One can instead run low-priority tasks that are
not bound by real-time constraints.

For some specific class of sets of tasks, one can obtain U L = 100%, which guarantees
that every set of tasks for which U 100% is schedulable.

Example: Let 1, 2, . . . , n be a set of tasks with respective periods and execution

times T 1, T 2, . . . , T n and C1, C2, . . . , Cn, such that
0 < T 1 T 2 T n,
i, j : i < j T j is an integer multiple of T i,
n
X C i
U= 1.
Ti
i=1

160
Let us show that this set of tasks is schedulable.
T
The critical zone of 2 contains 2 complete executions of 1:
T1

t
1
0 T1 2T 1 (k 1)T 1 kT 1
T2

Similarly, for each j {2, 3, . . . , n}, the critical zone of j contains

Tj
complete executions of 1,
T1
...
Tj
complete executions of j1.
T j1

The condition that must be satisfied in order to finish the execution of j before the end
of its critical zone is thus
Tj Tj Tj
C j T j C1 C2 C j1
T 1 T 2 T j1

161
After simplification, this condition becomes

C1 C2 Cj
+ + + 1,
T1 T2 Tj

which immediately follows from the hypothesis U 1.

162
 Chapter 8

Complex timed systems

163
 Introduction

In order to analyze the properties of a complex system, it is not always sufficient to study
the individual behavior of its components.

Example: An embedded system controlling a railroad crossing is composed of the following

elements:

Two sensors located on the tracks 1000 meters before and 100 meters after the
crossing, aimed at detecting (respectively) that a train approaches or has passed the
crossing.

A receiver that processes the signals emitted by the sensors, and sends orders to
open or close the gate.

receiver

1000 m 100 m

164
The following information is known:

The speed of the approaching trains is between 48 and 52 m/s. Then, after reaching
the first sensor, their speed is reduced to a value between 40 and 52 m/s.

After it receives a signal from a sensor, the receiver waits for at most 5 seconds before
sending an order to close or to open the gate. During this delay, the receiver ignores
incoming signals.

The gate is closed (resp. open) when its angle is equal to 0 (resp. 90) deg. The gate is
able to move at the rate of 20 deg/s.

Two successive trains are always separated by at least 1600 m.

Question: Is the gate always closed when a train passes the crossing?

165
 Modeling a system

In order to analyze the properties of a system, the first step consists in building a model,
i.e., an abstract representation of the system that describes its relevant properties without
any ambiguity.

For embedded applications, the modeling formalism must be able to express

operations on integer variables (used as counters, sequence numbers, identifiers, . . . ),

as well as on real variables (for representing positions, speeds, delays, . . . ).

discrete state transitions (e.g., incrementing a counter) as well as continuous evolution

laws (e.g., constant-speed movement).

composition of elementary systems into a more complex entity.

166
 Hybrid systems

Hybrid systems are a modeling formalism that meets those requirements.

Syntax:

A hybrid system is composed of:

a finite number p of processes P1, P2, . . . , P p,

a finite number n of variables x1, x2, . . . , xn, grouped together into a vector ~x Rn,

a finite set L of synchronization labels.

Each process Pi is represented by a graph (Vi, Ei), where

Vi est a finite set of control locations,

Ei Vi Vi is a finite set of transitions.

167
Each control location v Vi is associated with:

An activity dif (v), expressed as a conjunction of linear constraints over the variables
x1, x2, . . . , xn and their first temporal derivative x1, x2, . . . , xn.

An invariant inv (v), expressed as a conjunction of linear constraints over the variables
x1, x2, . . . , xn.

Each transition e Ei is associated with:

A guard guard (e), that represents a condition that must be satisfied in order to enable
this transition.

An action act (e), composed of constraints that specify how the values of the variables
are modified when this transition is followed.

In practice, the guard and the action can be combined into a conjunction of constraints
over the values of the variables before ( x1, x2, x3, . . . ) and after ( x10 , x20 , x30 , . . . )
following the transition.

168
 An optional label sync (e) L that makes it possible to synchronize this transition with
a transition belonging to another process.

Finally, one defines an initial control location for each process, and assigns a set of
possible initial values for each variable, specified as a conjunction of linear constraints.

169
Example: Process modeling the behavior of a train and the two sensors.

The distance between the train and the crossing is represented by a variable x1.

The signals emitted by the sensors are modeled by two synchronization labels app
and exit.

170
 [1] [2]
x1 1500 x1 = 1000
1000 x1 0 x1 1000
52 x1 48 app 52 x1 40

x1 = 100
exit x1 = 0
x10 1500

[3]
x1 100
40 x1 52

171
Process modeling the receiver:

The delay between receiving a sensor signal and sending an order to the gate is
represented by a variable x2.

The labels raise and lower model the orders sent to the gate.

172
 app app

exit exit

[2] [3]
0 x2 5 0 x2 5
x2 = 1 x2 = 1

app exit
x20 = 0 x20 = 0

lower raise

[1]
x2 = 0
x2 = 0

173
Process modeling the gate:

The variable x3 represents the angular position of the gate.

The labels raise and lower correspond to the orders received.

174
 raise raise

[1] [2]
x3 = 90 x3 = 90
0 x3 90 x3 = 90
x3 = 20 x3 = 0

lower
raise lower
raise

[3] [4]
x3 = 0
0 x3 90 x3 = 0
x3 = 20 x3 = 0

lower lower

175
Semantics:

At any given time, the current state of a hybrid system is characterized by

a control location for each process, and

a value for each variable.

The state of a system can evolve in two ways:

By letting time elapse (time steps). The control locations of processes stay
unchanged, and the values of the variables evolve according to the invariants and
activities associated to these locations.

By following transitions (transition steps). One can either

follow a single unlabeled transition, or

follow a pair of transitions belonging to different processes and sharing the same
synchronization label.

176
 In both cases, a transition can only be followed provided that its guard is satisfied by
the current variable values.

When a transition is followed, the variable values are modified according to the action
associated to the transition. The invariant of the destination location must be satisfied
by the new variable values (otherwise, the transition cannot be followed).

A state s2 is reachable from a state s1 if there exists a finite sequence of time steps and
transition steps that lead from s1 to s2.

A state s is reachable if it is reachable from an initial state.

177
Example: The state ([2], [2], [2], 800, 4, 90) of the railroad crossing controller model
corresponds to

the control location [2] for each process.

the respective values 800, 4 and 90 for the variables x1, x2 and x3.

This state is reachable. Indeed, one has

([1], [1], [2], 1500, 0, 90)
10
= ([1], [1], [2], 1000, 0, 90)
app
([2], [2], [2], 1000, 0, 90)
4
= ([2], [2], [2], 800, 4, 90),
where

= denotes a time step with a delay equal to ,
`
corresponds to following a pair of transitions sharing the synchronization label `.

178
 Executions of a hybrid system

An execution of a hybrid system is an infinite sequence s1, s2, s3, . . . of states such that:

s1 is an initial state of the system.

For each i, the state si+1 is reachable from the state si in a time i 0.

Note: A hybrid system generally admits several different executions (non-determinism).

Indeed,

The time spent at a control location may not be precisely constrained by the invariant.

A control location can have several outgoing transitions enabled at a given time.

An execution s1, s2, s3, . . . beginning at time t = 0 is said to be divergent if for every T > 0,
there exists i such that the state si is reached later than time t = T .

179
 Zeno hybrid systems

A hybrid system is said to have the Zeno property if it admits an execution in which at least
one finite prefix is not a prefix of a divergent execution.

In other words, in a Zeno hybrid system, there exists a reachable state from which no
execution is able to get past some time bound.

Example: Hybrid system modeling a bouncing ball.

x1 = 0
x20 = 0.8x2

x1 = 10
x1 0
x2 = 0
x1 = x2
x2 = g

180
 x1

Remarks:

Such models are inconsistent with physical reality and must be avoided!

For some restricted classes of hybrid systems, automatic methods have been
developed for transforming any given model into another one that does not have the
Zeno property, and admits the same divergent executions.

181
 State-space exploration

A large number of interesting properties of a hybrid system can be checked by computing

its reachable states.

This computation can be carried out by building, from every initial state, a tree in which
each node q represents a reachable state s(q), and the children of q correspond to the
states that are reachable from s(q) by

a time step, or

a transition step.

Problems:

The system may have infinitely many initial states.

The time spent at a control location may take an infinite number of possible values,
which leads to trees of infinite degree.

Since executions are infinite, the trees also have an infinite depth.

182
Solutions:

Sets of states sharing the same control locations and differing only in the elapsed time
in those locations can be grouped into regions. A tree can be built in which the nodes
are associated with regions instead of individual states.

At each exploration step, a first operation saturates the current region by letting time
elapse during all possible delays. Then, the enabled transitions are individually
followed, creating new branches.

The branches of the exploration tree that only contain already visited states can be
pruned.

Notes:

Several exploration strategies are possible: depth-first search (DFS), breadth-first

search (BFS), . . .

183
 For general hybrid systems, the region tree can still be infinite. It is however possible
to define restricted classes of models, for which a finite region tree can always be
computed.

Example: Timed automata are hybrid systems in which

the activities are of the form xi = 1,
all invariants, guards and actions are conjunctions of constraints of the form xi#c or
xi x j#c, where c is an integer number, and # {<, , =, , >}.

Some tools are available for exploring automatically the state space of hybrid systems
(e.g., HyTech) or timed automata (e.g., Uppaal).

Notes: These tools

represent and handle regions with the help of dedicated data structures, based on
logic formulas, convex polyhedra, difference matrices, . . .
are able to check properties that go beyond simple reachability.

184
 Example: Railroad crossing

([1], [1], [2]) : x1 1500, x2 = 0, x3 = 90.

= ([1], [1], [2]) : x1 1000,
x2 = 0, x3 = 90.
app
([2], [2], [2]) : x1 = 1000,
x2 = 0, x3 = 90.
5
= ([2], [2], [2]) : x1 1000 52,
x1 1000 40,
x2 = , x3 = 90,
0 5.
lower
([2], [1], [3]) : x1 1000 52,
x1 1000 40,
x2 = , x3 = 90,
0 5.
9/2
= ([2], [1], [3]) : x1 1000 52( + ),
x1 1000 40( + ),
x2 = , x3 = 90 20,
0 5, 0 9/2.

185
x3 =0
([2], [1], [4]) : x1 766 52,
x1 820 40,
x2 = , x3 = 0,
0 5.
= ([2], [1], [4]) : 0 x1 820 40,
x2 = , x3 = 0,
0 5.
x1 =0
([3], [1], [4]) : x1 = 0, x2 = ,
x3 = 0, 0 5.
5/2
= ([3], [1], [4]) : 0 x1 100,
x2 = , x3 = 0,
0 5.
exit
([1], [3], [4]) : x1 1500, x2 = 0,
x3 = 0.
5
= ([1], [3], [4]) : x1 1500 52,
x2 = , x3 = 0,
0 5.
raise
([1], [1], [1]) : x1 1500 52,
x2 = , x3 = 0,
0 5. 186
9/2
= ([1], [1], [1]) : x1 1500 52( + ),
x2 = , x3 = 20,
0 5, 0 9/2.
x3 =90
([1], [1], [2]) : x1 1266 52,
x2 = , x3 = 90,
0 5.
= ([1], [1], [2]) : x1 1000,
x2 = , x3 = 90,
0 5.
app
([2], [2], [2]) : x1 = 1000,
x2 = 0, x3 = 90
(already obtained).

187
Notes:

In this example, the regions correspond to the sets of states obtained after each
time-step operation (denoted by =).

Checking whether the gate is always closed when a train reaches the crossing
amounts to verifying that in each reachable region, x1 = 0 implies x3 = 0.

This particular system shows a very deterministic behavior: In each reachable state,
there is at most one transition (or a pair of synchronized transitions) that is enabled.

(This is generally not the case!)

188