Embedded Software

Koen LangendoenEmbedded Software Group

TI2726‐B

5. Software architectures

Lec.2: Interrupts & data sharingvolatile static long int lSecondsToday;

void interrupt vUpdateTime(){

++lSecondsToday;}

long lGetSeconds(){

long lReturn;

lReturn = lSecondsToday;while (lReturn!=lSecondsToday)

lReturn = lSecondsToday;

return (lReturn);}

2

lReturn - desired

lSecondsToday - current

lSecondsToday - previous

lReturn - bad

Challengestatic 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 controllerMOVE DPTR, #cErrors+01HMOVX A, @DPTRINC AMOVX @DPTR, AJNZ noCarryMOVE DPTR, #cErrorsMOVX A,@DPTRINC AMOVX @DPTR, A

noCarry:RET

4

Exercisestatic 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

Answerstatic 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

Answerstatic int cErrors;static volatile int busy = FALSE;

void interrupt testint(void){static int pending = 0;++pending;if (!busy) {

cErrors += pending;pending = 0;

}}

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

} 7

Signals global variable with local scope, initialized once

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

9http://ptolemy.eecs.berkeley.edu/publications/papers/02/embsoft/embsoftwre.pdf

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 Create data from a set of data types Consume data from a set of data types

Central entity Data type associations with components Buffers and distributed data to them

Architectures can be dynamically changed ROS

13

Blackboard

C1

C2

C3

C4

…

Round‐Robin architecturevoid 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 CA A D16

Round‐Robin with Interruptsbool flagA=FALSE, flagB=FALSE, …, flagZ=FALSE;

void interrupt handleA (void){

!! Take care of the I/O device AflagA = TRUE;

}…void interrupt handleZ (void){

!! Take care of the I/O device ZflagZ = 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 comparisonRR RR-ISR FQS

High priority

Low priority

everything

Dev. A ISR

Dev. B ISR

…

Dev. Z ISR

Task code

Dev. A ISR

Dev. B ISR

…

Dev. Z ISR

Task code A

Task code B

…

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 messagesOS_EVENT* myMsgQ; // msg‐Queuevoid* myMsgQdata[MSGQ_SIZE]; // storage for msgs

…myMsgQ = OSQCreate (myMsgQdata, MSGQ_SIZE);

… 

Can be used by the reading taskmsg = (char*) OSQPend(myMsgQ, WAIT_FOREVER, &err);

Can be used by the writing taskOSQPost(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);

BlockingOSMboxPend ( … )

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