Embedded Software

TI2726‐B

5. Software architectures

Koen Langendoen
Embedded Software Group
Lec.2: Interrupts & data sharing
volatile static long int lSecondsToday;

void interrupt vUpdateTime()

{
lSecondsToday - previous
++lSecondsToday;
}

long lGetSeconds() lSecondsToday - current

{
long lReturn;

lReturn = lSecondsToday; lReturn - desired

while (lReturn!=lSecondsToday)
lReturn = lSecondsToday;
lReturn - bad
return (lReturn);
}

2
Challenge
static int cErrors;

void interrupt testint(void)

{
++cErrors;
}

void test(void)
{
++cErrors;
}

Does this code suffer from the data-sharing bug?

… on an 8-bit microcontroller?

3
++cErrors;
 Intel 80x86
INC (cErrors)
RET

 8051 controller
MOVE DPTR, #cErrors+01H
MOVX A, @DPTR
INC A
MOVX @DPTR, A
JNZ noCarry
MOVE DPTR, #cErrors
MOVX A,@DPTR
INC A
MOVX @DPTR, A
noCarry:
RET

4
Exercise
static int cErrors;

void interrupt testint(void)

{
++cErrors;
}

int test(void)
{
return (++cErrors);
}

Modify this code to remove the shared-data bug

… without disabling interrupts

5
Answer
static int cErrors;
static volatile int busy = FALSE;
static int pending = 0;

void interrupt testint(void)

{
++pending;
if (!busy) {
cErrors += pending;
pending = 0;
}
}

int test(void)
{
busy = TRUE;
int val = ++cErrors;
busy = FALSE;
return val;
} 6
Answer
static int cErrors;
static volatile int busy = FALSE;

void interrupt testint(void)

{
static int pending = 0;
++pending;
if (!busy) {
cErrors += pending; Signals global variable with
pending = 0; local scope, initialized once
}
}

int test(void)
{
busy = TRUE;
int val = ++cErrors;
busy = FALSE;
return val;
} 7
Outline

 Embedded system architectures
 Examples of architectures:
 Round‐Robin
 Round‐Robin with Interrupts
 Function‐Queue
 Real‐Time Operating Systems

8
 Achitectures – the book
 Problem (in the book): system response time 
 Solution: software architectures
 Simple: systems with low load and few constraints
 Complex: systems with high load and many constraints
 Complex architectures introduce additional costs

 Additional information (compulsory reading)
Edward A. Lee ‐ Embedded software, 
Advances in computers, vol. 56, 2002, p. 55‐95

http://ptolemy.eecs.berkeley.edu/publications/papers/02/embsoft/embsoftwre.pdf 9
Embedded software
 Just software on small computers?
 Well…
 Timeliness (software takes time, physical processes)
 Concurrency (network of sensors and actuators, tools)
 Liveness (vs. Turing machines)
 Interfaces (temporal properties, combination of objects)
 Heterogeneity (programming languages)
 Reactivity (data streaming processing, adaptive)

10
Models of computation
 Definition: the laws governing component interactions
 Recommended model supporting concurrency = ?
 Sequential computation – Von Neumann architecture
 Successive transformation of the system state
 Distributed systems – system state unknown
 System/modules can be expressed in various languages
 VHDL + FPGA – reconfigurable components
 Java – portability + security
 C – efficient execution

11
Examples of models
 Dataflow
 LabView; synchronous,  boolean, dynamic …
 Time triggered
 clock, time triggered architecture, discrete time models, SystemC
 Synchronous/reactive
 Signals can have no value at various moments
 Token ring protocol for media access control
 Discrete events
 Events (value, time stamp)
 Process networks
 Components = processes, asynchronous communication
 Publish/subscribe mechanisms
 Connections are event streams
 Others: finite state machines, rendevous, continuous time…
12
Publish‐subscribe mechanisms

 Each component C1

 Create data from a set of data types
C2
 Consume data from a set of data types
 Central entity C3
Blackboard
 Data type associations with components
 Buffers and distributed data to them …

 Architectures can be dynamically changed
 ROS C4

13
Round‐Robin architecture
void main(void)
{
while(TRUE)
{
if ( !! I/O device A needs attention )
{
!! Take care of device A and handle its data
}

if ( !! I/O device B needs attention )

{
!! Take care of device B and handle its data
}
…
if (!! I/O device Z needs attention)
{
!! Take care of device Z and handle its data
}
}
14
RR Examples
 Digital multimeter
 Measure: resistance, current and potential
 For each situation select the right scale
 Washing machine
 Airbag controller
 Anything that displays information
…

15
Round‐Robin Evaluation

 Simplicity!
 No priorities, no interrupts, no data‐sharing bugs
 Suited for systems with no latency concerns
 Worst response time of task code = sum of all task code
 Alternative design: interleaving devices
 Fragile design: timing in future versions?

A B C D A B A C A D
16
Round‐Robin with Interrupts
bool flagA=FALSE, flagB=FALSE, …, flagZ=FALSE;

void interrupt handleA (void)

{
!! Take care of the I/O device A
flagA = TRUE;
}
…
void interrupt handleZ (void)
{
!! Take care of the I/O device Z
flagZ = TRUE;
}

void main(void)
{
while(TRUE)
{
if (flagA) {
flagA = FALSE
!! Handle data from device A
}
if (flagB)
…
}
}
17
RR‐ISR Characteristics
 Splits the work between interrupts and main
 Interrupts handle I/O of devices
 Main function deals with processing data
 Why use interrupts?
 Allow fast response time for handling I/O buffers
(event‐based design vs. polling design)
 Set flags to indicate work has to be done
 Take advantage of the interrupt‐priority system
 Often the most appropriate architecture!

18
RR‐ISR Examples
 Systems with few components needing fast response time 
(limited processing needed)
 Most likely to be found in:
 Stopwatches
 Modern washing machines
 Coffee machines
 Microwave ovens
 Central heating units
 Traffic light controllers
 Other: data‐bridge devices and barcode scanners
19
RR‐ISR Evaluation
 Leads to a simple design (still…)
 Data‐sharing problem introduced
 All task codes have the same priority  ‐ no long tasks!!!
 Worst response time = sum of all task code + ISR times
 Alternative designs:
 Move code in interrupts
 Interleaving devices in main()
 Fragile design: timing in future versions?
 Changing code or ISR priority for one device…

20
Function‐Queue Architecture
!! Queue of function pointers

void interrupt handleA(void)

{
!! Take care of I/O device A
!! Put functionA on queue of function pointers
}
!! ISR for devices B…Z

void functionA(void)
{
!! Handle actions required by A
}
!! Functions for devices B…Z

void main(void)
{
while(TRUE)
{
while (!! Queue of function pointers is empty) {};
!! Call first function on the queue
}
}
21
FQ Evaluation
 Splitting of responsibilities similar to RR‐ISR
 Interrupts handle I/O of devices
 Main function deals with processing data (via functions)
 Insert operation for the queue was not specified!
 FIFO queue leads to RR‐ISR (not really!)
 Priority queue leads to task priorities
 FQ architecture gives the basis for “non‐preemptive OSes”
 Worst response time = longest task + tasks with higher 
priority + ISR routines

22
Non‐preemptive scheduling

 First‐in First‐out scheduling algorithm
 Shortest‐Job‐First scheduling
 Shortest‐Remaining‐Time Scheduling
 Priority scheduling
 Multilevel queue scheduling

23
Performance comparison
RR RR-ISR FQS

High priority Dev. A ISR

Dev. B ISR
Dev. A ISR
…
Dev. B ISR
Dev. Z ISR
everything …
Task code A
Dev. Z ISR
Task code B
Task code
…
Low priority Task code Z

24
Question

 Which software architecture (RR, RRI, FQS) is best suited 
for implementing an FSM?

 And why?

25
Real Time OS Architecture
 Characteristics
 Evolved from the FQ Architecture
 Contains a set of ISR (dealing with fast events from devices)
 Contains a set of tasks (one or more for each device)
 Signaling between ISRs and tasks is part of the OS
 No more while(1) loops in the main code –> OS scheduler
 OS can stop a task to run another one (preemption)

 Terminology!

26
RTOS Evaluation
 System response is relatively stable
 Changing a piece of code has a reduced effect 
(changing lower‐priority tasks does not matter)
 RTOSes consume time themselves
 Synchronization mechanisms
 Task preemption
 Better response time vs. throughput
 Large number of RTOSes developed
 They come with an increasing  set of tools

27
Task Synchronization
 Global data ( data sharing problem)
 Semaphores
 pend   block task
 post    unblock task
 Queues, Mailboxes, and Pipes 
 Synchronization + data communication
 No shared data problems 
 unless you pass pointer to the original data in other task (cf. Fig. 7.4)
 Same pitfalls as semaphores (deadlock, etc.)

28
FIFO Queue
 Must be initialized
#define MSGQ_SIZE 10 // max no of messages
OS_EVENT* myMsgQ; // msg‐Queue
void* myMsgQdata[MSGQ_SIZE]; // storage for msgs
…
myMsgQ = OSQCreate (myMsgQdata, MSGQ_SIZE);
… 
 Can be used by the reading task
msg = (char*) OSQPend(myMsgQ, WAIT_FOREVER, &err);
 Can be used by the writing task
OSQPost(myMsgQ, (void*)msg);

(uC/OS, book pp. 333) 29

Mailbox
 Similar to queue
 Create, write, read
 But also check, destroy
 Some RTOS provide priorities in mailboxes
 But, …
 No blocking on the reader side (Queue WAIT_FOREVER 
timeout)
void* OSMboxAccept (OSEvend* mbox);
 Blocking
OSMboxPend ( … )

30
Pipe

 Similar to queue and mailbox
 But, …
 Variable length messages

31
Queue vs. Mailbox vs. Pipe
 Queues for
 FIFO communication
 Mailboxes for 
 non‐blocking communication
 Communication according to priorities
 Pipes for
 Variable length messages

 Huge overhead compared with global variables!

32
Task Synchronization Pitfalls
 Typically no protection of queues, mailboxes, pipes
 Any task can use them any time
 Is the right task writing to/reading from the right communication channel?
 Pointer problems
 Passing pointers to a communication channel can create data sharing 
problems
 Type and length of messages
 Write an integer/read a byte!
 Potential memory leaks
 Malloc/free 
 Space problems
 What if queue is full?  some recovery mechanism!

33
Choosing the right architecture

 Select the simplest one! Think of the model first…
 Writing code for ES is complicated enough
 Remember: customers will want more features in version 2!
 Use an RTOS if the system needs real time response
 Make use of the offered tools rather than reinventing them
 Your system will most likely require a hybrid architecture

34