Embedded Systems

4. Programming Paradigms

© Lothar Thiele
Computer Engineering and Networks Laboratory
Where we are …

1. Introduction to Embedded Systems

2. Software Development
3. Hardware-Software Interface
4. Programming Paradigms
Software Hardware
5. Embedded Operating Systems
-
6. Real-time Scheduling
Software
7. Shared Resources
8. Hardware Components
Hardware 9. Power and Energy
10. Architecture Synthesis

4-2
Reactive Systems and Timing

4-3
Timing Guarantees
 Hard real-time systems can be often found in safety-critical applications. They
need to provide the result of a computation within a fixed time bound.
 Typical application domains:
 avionics, automotive, train systems, automatic control including robotics,
manufacturing, media content production

wing vibration of airplane,

sideairbag in car,
sensing every 5 ms
reaction after event in <10 mSec

4-4
Simple Real-Time Control System

A/D
Input Control-Law D/A
Computation
A/D

Sensor Environment Actuator

4-5
Real-Time Systems
In many cyber-physical systems (CPSs), correct timing is a matter of correctness, not
performance: an answer arriving too late is consider to be an error.

4-6
Real-Time Systems

4-7
Real-Time Systems

4-8
Real-Time Systems

4-9
Real-Time Systems

4 - 10
Real-Time Systems

start time deadline

4 - 11
Real-Time Systems
 Embedded controllers are often expected to finish the processing of data and
events reliably within defined time bounds. Such a processing may involve
sequences of computations and communications.

 Essential for the analysis and design of a real-time system: Upper bounds on the
execution times of all tasks are statically known. This also includes the
communication of information via a wired or wireless connection.

 This value is commonly called the Worst-Case Execution Time (WCET).

 Analogously, one can define the lower bound on the execution time, the Best-Case
Execution Time (BCET).

4 - 12
Distribution of Execution Times
Distribution of execution times

Unsafe:
Best Case Execution Time
Execution Time Measurement
Upper bound
Worst Case
Execution Time

Execution Time

4 - 13
Modern Hardware Features
 Modern processors increase the average performance (execution of tasks) by
using caches, pipelines, branch prediction, and speculation techniques, for
example.
 These features make the computation of the WCET very difficult: The
execution times of single instructions vary widely.
 The microarchitecture has a large time-varying internal state that is changed by
the execution of instructions and that influences the execution times of
instructions.
 Best case - everything goes smoothely: no cache miss, operands ready, needed
resources free, branch correctly predicted.
 Worst case - everything goes wrong: all loads miss the cache, resources needed
are occupied, operands are not ready.
 The span between the best case and worst case may be several hundred cycles.

4 - 14
Methods to Determine the Execution Time of a Task
execution time

Worst-Case

Best-Case

Real System Measurement Simulation Worst-Case

(correct model) Analysis
4 - 15
(Most of) Industry’s Best Practice
 Measurements: determine execution times directly by observing the execution
or a simulation on a set of inputs.
 Does not guarantee an upper bound to all executions unless the reaction to all
initial system states and all possible inputs is measured.
 Exhaustive execution in general not possible: Too large space of (input domain)
x
(set of initial execution states).
 Simulation suffers from the same restrictions.

 Compute upper bounds along the structure of the program:

 Programs are hierarchically structured: Instructions are “nested” inside
statements.
 Therefore, one may compute the upper execution time bound for a statement
from the upper bounds of its constituents, for example of single instructions.
 But: The execution times of individual instructions varies largely!
4 - 16
Determine the WCET
Complexity of determining the WCET of tasks:
 In the general case, it is even undecidable whether a finite bound exists.
 For restricted classes of programs it is possible, in principle. Computing accurate
bounds is simple for „old“ architectures, but very complex for new architectures with
pipelines, caches, interrupts, and virtual memory, for example.

Analytic (formal) approaches exist for hardware and software.

 In case of software, it requires the analysis of the program flow and the analysis of
the
hardware (microarchitecture). Both are combined in a complex analysis flow, see for
example www.absint.de and the lecture “Hardware/Software Codesign”.
 For the rest of the lecture, we assume that reliable bounds on the WCET are available,
for example by means of exhaustive measurements or simulations, or by analytic
formal analysis.

4 - 17
Different Programming Paradigms

4 - 18
Why Multiple Tasks on one Embedded Device?
 The concept of concurrent tasks reflects our intuition about the functionality of
embedded systems.

 Tasks help us manage the complexity of concurrent activities as happening in the

system environment:
 Input data arrive from various sensors and input devices.
 These input streams may have different data rates like in multimedia processing,
systems with multiple sensors, automatic control of robots

 The system may also receive asynchronous (sporadic) input events.

 These input event may arrive from user interfaces, from sensors, or from
communication interfaces, for example.

4 - 19
Example: Engine Control
Typical Tasks:
 spark control
 crankshaft sensing
 fuel/air mixture
 oxygen sensor
engine
 Kalman filter – control
controlle
algorithm
r

4 - 20
Overview
 There are many structured ways of programming an embedded system.
 In this lecture, only the main principles will be covered:
 time triggered approaches
 periodic
 cyclic executive
 generic time-triggered scheduler

 event triggered approaches

 non-preemptive
 preemptive – stack policy
 preemptive – cooperative scheduling
 preemptive - multitasking

4 - 21
Time-Triggered Systems
Pure time-triggered model:
 no interrupts are allowed, except by timers
 the schedule of tasks is computed off-line and therefore, complex sophisticated
algorithms can be used
 the scheduling at run-time is fixed and therefore, it is deterministic
 the interaction with environment happens through polling

interrupt polling

Timer
interfaces
CPU to
sensor/
actuator
set timer 4 - 22
Simple Periodic TT Scheduler
 A timer interrupts regularly with period P.
 All tasks have same period P.

T1 T2 T3 T1 T2 T3 T1 T2 T3
t
t(0)
P
 Properties:
 later tasks, for example T2 and T3, have unpredictable starting times
 the communication between tasks or the use of common resources is safe, as
there is a static ordering of tasks, for example T2 starts after finishing T1
 as a necessary precondition, the sum of WCETs of all tasks within a period is
bounded by the period P:

4 - 23
Simple Periodic Time-Triggered Scheduler
usually done offline
main:
determine table of tasks (k, T(k)), for k=0,1,…,m-1;
i=0; set the timer to expire at initial phase t(0);
while (true) sleep();
set CPU to low power mode;
Timer Interrupt: processing starts again after interrupt
k T(k)
i=i+1;
set the timer to expire at i*P + t(0); 0 T1
for (k=0,…,m-1){ execute task T(k); } 1 T2
return; 2 T3
3 T4
for example using a function pointer in C;
task(= function) returns after finishing. 4 T5
m=5

4 - 24
Time-Triggered Cyclic Executive Scheduler
 Suppose now, that tasks may have different periods.
 To accommodate this situation, the period P is partitioned into frames of length f.

T1 T3 T2 T2 T1 T2
T1 T4 T2 T1 t
0 2 4 12 14T1 16 18 20
6 8
10
f
P
 We have a problem to determine a feasible schedule, if there are tasks with a
long execution time.
 long tasks could be partitioned into a sequence of short sub-tasks
 but this is tedious and error-prone process, as the local state of the task must be
extracted and stored globally

4 - 25
Time-Triggered Cyclic Executive Scheduling
 Examples for periodic tasks: sensory data acquisition, control loops, action
planning and system monitoring.
 When a control application consists of several concurrent periodic tasks with
individual timing constraints, the schedule has to guarantee that each periodic
instance is regularly activated at its proper rate and is completed within its
deadline.
 Definitions:
 : denotes the set of all periodic tasks
 : denotes a periodic task
i i, j : denotes the jth instance of task i
: denote the release time and absolute deadline of the
ri, j , d i, j
jth instance of task i
i : phase of task i (release time of its first instance)
Di : relative deadline of task i

4 - 26
Time-Triggered Cyclic Executive Scheduling
 Example of a single periodic task  i :
 Ti
i
i
Di
ri,1 ri,2
Ci

 A set of periodic tasks task instances should execute in these intervals

:


4 - 27
Time-Triggered Cyclic Executive Scheduling
 The following hypotheses are assumed on the tasks:
 The instances of a periodic task are regularly activated at a constant rate. The
interval Ti between two consecutive activations is called period. The release times
satisfy
ri, j  i   j
1Ti
 All instances have the same worst case execution time Ci . The worst case
execution time is also denoted as WCET(i) .
 All instances of a periodic task have the same relative deadline D .
i
Therefore, the
absolute deadlines satisfy

di, j  i   j 1Ti  Di

4 - 28
 Time-Triggered Cyclic Executive Scheduling
Example with 4 tasks:
 requirement

schedule

0 4 8 12 16 20 24 28 32 36

not given as part of the requirement 4 - 29

Time-Triggered Cyclic Executive Scheduling
Some conditions for period P and frame length f:
 A task executes at most once within a frame:

 P is a multiple of f. period of task

 Period P is least common multiple of all periods
.
 Tasks start and complete within a single frame:
worst case execution time
of task
 Between release time and deadline of every task there is at least one full
frame:

relative deadline of task

4 - 30
Sketch of Proof for Last Condition

release times and

deadlines of
tasks

starting time latest finishing time frames

f

4 - 31
Example: Cyclic Executive Scheduling
Conditions:

4 4 1.0
5 5 1.8
20 20 1.0
possible solution: f = 2 20 20 2.0

Feasible solution (f=2):

t
0 2 4 6 8 10 12 14 16 18 20

f P
4 - 32
Time-Triggered Cyclic Executive Scheduling
Checking for correctness of schedule:
 denotes the number of the frame in which that instance j of task executes.
 Is P a common multiple of all periods ?
 Is P a multiple of f ?
 Is the frame sufficiently long?

 Determine offsets such that instances of tasks start after their release time:

 Are deadlines respected?

4 - 33
Generic Time-Triggered Scheduler
 In an entirely time-triggered system, the temporal control structure of all tasks is
established a priori by off-line support-tools.
 This temporal control structure is encoded in a Task-Descriptor List (TDL) that
contains the cyclic schedule for all activities of the node.
 This schedule considers the required precedence and mutual exclusion
relationships among the tasks such that an explicit coordination of the tasks by
the operating system at run time is not necessary.
 The dispatcher is activated by a
synchronized clock tick. It looks at the
TDL, and then performs the action
that has been planned for this
instant [Kopetz].

4 - 34
Simplified Time-Triggered Scheduler

main: usually done offline

determine static schedule (t(k), T(k)), for k=0,1,…,n-1;
determine period of the schedule P;
set i=k=0 initially; set the timer to expire at t(0);
while (true) sleep();
set CPU to low power mode; k t(k) T(k)
Timer Interrupt: processing continues after interrupt
k_old := k; 0 0 T1
i := i+1; k := i mod n; 1 3 T2
set the timer to expire at i/n * P +
2 7 T1
t(k); execute task T(k_old);
return; 3 8 T3
for example using a function pointer in C; 4 12 T2
task returns after finishing.
n=5, P = 16

4 - 35
Summary Time-Triggered Scheduler
Properties:
 deterministic schedule; conceptually simple (static table); relatively easy to
validate, test and certify
 no problems in using shared resources

 external communication only via polling

 inflexible as no adaptation to the environment
 serious problems if there are long tasks

Extensions:
 allow interrupts → be careful with shared resources and the WCET of
tasks!!
 allow preemptable background tasks
 check for task overruns (execution time longer than WCET) using a 4 - 36
Event Triggered Systems
The schedule of tasks is determined by the occurrence of external or internal events:
 dynamic and adaptive: there are possible problems with respect to timing, the use
of shared resources and buffer over- or underflow
 guarantees can be given either off-line (if bounds on the behavior of the
environment are known) or during run-time

interrupt interrupt or polling

Timer
interfaces
CPU to
sensor/
actuator
set timer
4 - 37
Non-Preemptive Event-Triggered Scheduling
Principle:
 To each event, there is associated a corresponding task that will be executed.
 Events are emitted by (a) external interrupts or (b) by tasks themselves.
 All events are collected in a single queue; depending on the queuing discipline, an
event is chosen for execution, i.e., the corresponding task is executed.
 Tasks can not be preempted.

Extensions:
 A background task can run if the event queue is empty. It will be preempted by
any event processing.
 Timed events are ready for execution only after a time interval elapsed. This
enables periodic instantiations, for example.

4 - 38
Non-Preemptive Event-Triggered Scheduling
main:
set the CPU to low power mode;
while (true) {
continue processing after interrupt
if (event queue is empty) {
sleep();
} else { for example using a function pointer in C;
extract event from event task returns after finishing.
queue;
execute task corresponding to event;
}
}
ISR
(interrupt service
Interrupt: routine) tasks
put event into event queue; event
return; interrupts
event

event queue extract event;

dispatch corresponding task

4 - 39
Non-Preemptive Event-Triggered Scheduling
Properties:
 communication between tasks does not lead to a simultaneous access to shared
resources, but interrupts may cause problems as they preempt running tasks
 buffer overflow may happen if too many events are generated by the
environment or
by tasks
 tasks
bufferwith
overflow
a longasrunning
no events
timeare
prevent
being processed
other tasks from running and may cause
during this time task with a long
 partition tasks into smaller ones execution time
 but the local context must be stored partition

subtask 1 subtask 2
save restore
context global memory
context
4 - 40
Preemptive Event-Triggered Scheduling – Stack Policy
 This case is similar to non-preemptive case, but tasks can be preempted by
others; this resolves partly the problem of tasks with a long execution time.
 If the order of preemption is restricted, we can use the usual stack-based context
mechanism of function calls. The context of a
function contains the necessary state such as local main memory
variables and saved registers. context of addresses
main()
main(){
…
context of
f1();
f1()
…

f1(){ context of
… f2()
f2();
…

4 - 41
Preemptive Event-Triggered Scheduling – Stack Policy
task T3
task
T2 task
T1 preemption t

 Tasks must finish in LIFO (last in first out) order of their instantiation.
 this restricts flexibility of the approach
 it is not useful, if tasks wait some unknown time for external events, i.e., they are
blocked
 Shared resources (communication between tasks!) must be protected, for
example by disabling interrupts or by the use of semaphores.

4 - 42
Preemptive Event-Triggered Scheduling – Stack Policy
main:
while (true) {
if (event queue is empty) {
set CPU to low power mode;
sleep();
processing continues after interrupt
} else {
select event from event queue;
execute selected task; for example using a function pointer
remove selected event from in C; task returns after finishing.
} queue;
}

InsertEvent: Interrupt:
put new event into event queue; InsertEvent(…);
select event from event queue; return;
if (selected task  running task) {
execute selected task; may be called by interrupt service
remove selected event from queue; routines (ISR) or tasks
}
return;

4 - 43
Thread
 A thread is a unique execution of a program.
 Several copies of such a “program” may run simultaneously or at different times.
 Threads share the same processor and its peripherals.

 A thread has its own local state. This state consists mainly of:
 register values;
 memory stack (local variables);
 program counter;

 Several threads may have a shared state consisting of global variables.

4 - 44
Threads and Memory Organization
 Activation record (also denoted as the thread context) contains the
thread local state which includes
registers and local data structures.
PC
thread 1
 Context switch:
 current CPU context registers
thread 2
goes out
 new CPU context ... CPU
goes in
memory

4 - 45
Co-operative Multitasking
 Each thread allows a context switch to another thread at a call to the
cswitch() function.
 This function is part of the underlying runtime system (operating system).
 A scheduler within this runtime system chooses which thread will run next.

 Advantages:
 predictable, where context switches can occur
 less errors with use of shared resources if the switch locations are chosen carefully

 Problems:
 programming errors can keep other threads out as a thread may never give up
CPU
 real-time behavior may be at risk if a thread runs too long before the next context
switch is allowed
4 - 46
Example: Co-operative Multitasking
Thread 1 Thread 2

if (x > 2) procdata(r,s,t);
sub1(y); cswitch();
else if (val1 == 3)
sub2(y); abc(val2);
cswitch(); rst(val3);
proca(a,b,c);

Scheduler

save_state(current);
p = choose_process();
load_and_go(p);

4 - 47
Preemptive Multitasking
 Most general form of multitasking:
 The scheduler in the runtime system (operating system) controls when contexts
switches take place.
 The scheduler also determines what thread runs next.

 State diagram corresponding to each single thread: terminate thread

 Run: A thread enters this state as it starts executing
on the processor run
wait
 Ready: State of threads that are ready to execute
but cannot be executed because the processor dispatch
blocked
is assigned to another thread.
preemption
 Blocked: A task enters this state when it waits
for an event. signal ready
activate thread

4 - 48