You are on page 1of 233

Certified ‘Embedded C’ Programmer:

Training materials

Course notes to accompany


training seminars

Michael J. Pont

Copyright © 2009-2011 TTE Systems Ltd


Copyright © 2009-2011 TTE Systems Ltd

Version 3.2

Release date: 2011-11-09

This document may be distributed freely for non-commercial purposes


provided that it is not altered in any way.

Page 2
Day 1: Introduction

Michael J. Pont,

MSc in Reliable Embedded Systems


Module EG7510 (“A1a”)

Introduction and overview

Copyright © 2009-2011 TTE Systems Ltd


2 Licensed to University of Leicester

Page 3
Embedded systems

An embedded system is an application that contains at least one


programmable computer (typically in the form of a microcontroller, a
microprocessor or digital signal processor chip) and which is used
by individuals who are, in the main, unaware that the system is
computer-based.
Source: Pont, M.J., “Patterns for Time-Triggered Embedded Systems”, (Addison-Wesley, 2001)

Copyright © 2009-2011 TTE Systems Ltd


3 Licensed to University of Leicester

Embedded systems

Copyright © 2009-2011 TTE Systems Ltd


4 Licensed to University of Leicester

Page 4
Embedded systems

Copyright © 2009-2011 TTE Systems Ltd


5 Licensed to University of Leicester

“Deeply embedded” systems


 Our focus: “deeply embedded” systems
 Techniques discussed are appropriate for …
– Aerospace
– Automotive
– Medical
– Railways
– Telecomms
– Industrial / factory control, CMFD …
– Defence …
– Agriculture …
– White goods;
– Brown goods …
– Sports …
– …

 Techniques may be less appropriate for …


– Applications in which users add / remove programs

Copyright © 2009-2011 TTE Systems Ltd


6 Licensed to University of Leicester

Page 5
Developing software for reliable embedded systems

 This 5-day course is intended to introduce you to a range of


programming techniques which will help you to create
embedded systems which are reliable.

 For safety-related or safety-critical systems (e.g. medical


devices) the need for such reliability is obvious:
if the system fails, people may be injured or killed.
 For more general “deeply embedded” systems, we believe
that the introduction of the techniques discussed in this course
in your organisation is likely to lead to:
– Reduced testing times
– Reduced warranty costs

Copyright © 2009-2011 TTE Systems Ltd


7 Licensed to University of Leicester

Structure of this course


 This course is divided into five individual seminars (this is the
first), plus associated practical sessions.
 On most days, we will begin with a seminar (with breaks as
required), then run lab exercises for the rest of the day.

 If you are studying for an MSc:


– The exercises that you will be given will contribute up to 40 credits
towards your mark for Module EG7510.
– There will be an exam at the start of the next module.

Copyright © 2009-2011 TTE Systems Ltd


8 Licensed to University of Leicester

Page 6
Structure of this course
 Day 1: Introduction and motivation
 Day 2: Key software architectures
 Day 3: Exploring modern hardware platforms
 Day 4: Working with multiple tasks and distributed systems
 Day 5: Case study

Copyright © 2009-2011 TTE Systems Ltd


9 Licensed to University of Leicester

Software and hardware


 The programming exercises in this module will use ‘C’

 Our main hardware targets will be:


 A COTS 8051 microcontroller (hardware simulation)
 A 32-bit “soft” microcontroller running on an FPGA

 The techniques discussed can be adapted easily for use with


any embedded system platform.

Copyright © 2009-2011 TTE Systems Ltd


10 Licensed to University of Leicester

Page 7
The world before embedded processors …

Copyright © 2009-2011 TTE Systems Ltd


11 Licensed to University of Leicester

Taking control (without an embedded processor)


 Use discrete components
(transistors, etc) to create
your design

 Control systems (etc)


created by “hardware”
designers

 New hardware design for


each project Photo by Per Anders

Copyright © 2009-2011 TTE Systems Ltd


12 Licensed to University of Leicester

Page 8
Taking control (with an embedded processor)
 Hardware design is still
required – but we may not
require a new hardware
design for each project

 Software used to
distinguish behaviour
(feature set) of different
products

[Sometimes the hardware


engineers still create the
software …]

Copyright © 2009-2011 TTE Systems Ltd


13 Licensed to University of Leicester

Taking control (with an embedded processor)

This is a pretty impressive spec. –


but feedback from our customers
suggests that this product would
be even more popular if we could
just make a couple of small
changes to the …

Software changes are thought to be easy …


… we need to create robust designs
which can withstand subsequent changes

Copyright © 2009-2011 TTE Systems Ltd


14 Licensed to University of Leicester

Page 9
Our first target:
the “8051” microcontroller

Copyright © 2009-2011 TTE Systems Ltd


15 Licensed to University of Leicester

Meet the 8051


 Developed by Intel in 1980 for embedded applications
 Available in various sizes and forms 1 P1.0 VCC 40
2 P1.1 P0.0 39
3 P1.2 P0.1 38
4 P1.3 37
 Why start with the 8051? 5 P1.4
P0.2
P0.3 36
6 P1.5 P0.4 35
– A simple “starter processor” 7 P1.6 P0.5 34

– Significant resource constraints 8 P1.7 P0.6 33


‘8051’

9 RST P0.7 32
– Significant performance constraints 10 P3.0 / EA 31
11 P3.1 ALE 30
12 P3.2 / PSEN 29
13 P3.3 P2.7 28
14 P3.4 P2.6 27
15 P3.5 P2.5 26
16 P3.6 P2.4 25
17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
20 VSS P2.0 21

Copyright © 2009-2011 TTE Systems Ltd


16 Licensed to University of Leicester

Page 10
Is the 8051 still useful?

From Infineon
design brochure
(March 2009)

Copyright © 2009-2011 TTE Systems Ltd


17 Licensed to University of Leicester

Meet the 8051


 8-bit microcontroller
1 P1.0 VCC 40
 128 / 256* bytes on-chip RAM 2 P1.1 P0.0 39
3 P1.2 P0.1 38

 Up to 64 kbytes on-chip ROM 4


5
P1.3

P1.4
P0.2

P0.3
37
36

 4 x 8-bit bi-directional I/O ports 6


7
P1.5
P1.6
P0.4

P0.5
35
34

 1 x UART 8 P1.7 P0.6 33


‘8051’

9 RST P0.7 32
10 31
 2 / 3* x 16-bit Counter/timers 11
P3.0

P3.1
/ EA

ALE 30
12 P3.2 29
 9 interrupt sources 13 P3.3
/ PSEN
P2.7 28
14 P3.4 P2.6 27
 Two-level interrupt priority 15 P3.5 P2.5 26
16 P3.6 P2.4 25
 Low-power Idle and power-down modes 17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
20 21
* 8052 specification. VSS P2.0

Copyright © 2009-2011 TTE Systems Ltd


18 Licensed to University of Leicester

Page 11
Minimal circuit for the 8051

Copyright © 2009-2011 TTE Systems Ltd


19 Licensed to University of Leicester

Clock frequency and performance


 Standard 8051: 12 oscillator cycles = 1 machine cycle
 Higher clock frequency → Higher performance
 Higher clock frequency → Higher power usage

Why limit performance?


 Not all applications require maximum clock rates
 Using the lowest frequency reduces the power requirement.
 When accessing low-speed peripherals, programming and
hardware design can be simplified.
 The electromagnetic interference (EMI) generated by a circuit
increases with clock frequency.

Copyright © 2009-2011 TTE Systems Ltd


20 Licensed to University of Leicester

Page 12
Adding external memory
 16 bit address bus: up to 64kB of external RAM and ROM
28
P 2.7 (A15)
27
P 2.6 (A14)
26
P 2.5 (A13)
25
P 2.4 (A12) 8-bit (upper) address byte
24
P 2.3 (A11)
23
P 2.2 (A10)
22
P 2.1 (A9)
P 2.0 (A8) 21 16-bit
address
‘Standard 8051’

30
ALE
bus
8-bit
Latch (lower)
address
byte

32
P 0.7 (AD7)
33
P 0.6 (AD6)
P 0.5 (AD5) 34
P 0.4 (AD4) 35
36
P 0.3 (AD3)
37
8-bit data bus
P 0.2 (AD2)
P 0.1 (AD1) 38
P 0.0 (AD0) 39

17
P 3.7 (/ RD)
16
P 3.6 (/ WR)
Timing and control lines
/ PSEN 29

Copyright © 2009-2011 TTE Systems Ltd


21 Licensed to University of Leicester

I/O Pins
 Standard 8051 has 4 ports (Port 0, Port 1, Port2 and Port3)
 Port 0 and Port 2 are used for data / address bus if external
memory is connected
 Port 3 pins are shared by the on-board peripherals
– External interrupts
– Serial Transmit and Receive
– Timer gate / counter count control
– External memory read/write control
 Port 1 pins do not have any alternate functions
 Port 0 pins are open collector
 All ports are quasi bi directional*
* If a pin is set high by software, external circuits can pull it low

Copyright © 2009-2011 TTE Systems Ltd


22 Licensed to University of Leicester

Page 13
Timers
 Typically two or three 16-bit timers / counters
In timer mode:
 Incremented every machine cycle (12 oscillator cycles)
 Use to measure time intervals between two events
 Use to generate precise hardware delays
 Use to generate ‘time out’ facilities
 Use to generate regular ‘ticks’
In counter mode:
 Incremented on the detection of external events
 Use to count number of pulses coming from outside circuitry /
sensor

Copyright © 2009-2011 TTE Systems Ltd


23 Licensed to University of Leicester

Interrupts
 Hardware mechanism to notify a
processor of an ‘event’
Background Foreground

 Up to 7 interrupt sources: Time

– 2 to 3 timer interrupts Function 1

– 2 external interrupts
t1
– 2 serial interrupts (shared vector) ISR 1

t2
 Provide a mechanism for creating Function 1

multitasking applications t3
Function 2
t4
ISR 2

t5
Function 2

Copyright © 2009-2011 TTE Systems Ltd


24 Licensed to University of Leicester

Page 14
Serial Interface
 Serial port compatible with RS-232 communication protocol

Possible uses:
 Debugging embedded applications using a PC
 Communicating with another embedded processor or PC
using RS-232
 Load code into the FLASH memory using a serial port
(“In System Programming”)

Copyright © 2009-2011 TTE Systems Ltd


25 Licensed to University of Leicester

Power down modes

Device Normal Idle Power Down


Intel 8051 160 mA - -
Atmel 89S53 11 mA 2 mA 60 uA
Dallas 87C520 15 mA 8 mA 50 µA
Intel 80C51 16 mA 4 mA 50 µA
*12 MHz clock source
Idle Mode
 Only the peripherals are kept running (active clock)
 CPU state and contents of RAM are preserved
 Exit by an enabled interrupt or a hardware reset
Power Down Mode
 Oscillator is stopped
 Contents of RAM are preserved
 Exit by hardware reset only

Copyright © 2009-2011 TTE Systems Ltd


26 Licensed to University of Leicester

Page 15
Special Function Registers
 SFRs are used to interface with the peripherals in the 8051
 SFRs are mapped in a special area of the memory
(address 0x80-0xFF)
– Example: Port 2 SFR is at 0xA0
 To use the peripherals, the software needs to read from /
write to the corresponding SFRs
– Examples
To read the Timer 1 value, we read the TH1 and TL1 SFRs
To write to Port 1, we write to the P1 SFR

 Some SFRs are bit addressable

Copyright © 2009-2011 TTE Systems Ltd


27 Licensed to University of Leicester

Why use the C language?

Copyright © 2009-2011 TTE Systems Ltd


28 Licensed to University of Leicester

Page 16
Why use the ‘C’ language?
 It is a ‘mid-level’ language, with ‘high-level’ features (such as support for
functions and modules), and ‘low-level’ features (such as good access to
hardware via pointers);
 It is very efficient, popular and well understood;
 Even desktop developers who have used only Java or C++ can soon
understand C syntax;
 Good, well-proven compilers are available for every embedded processor
(8-bit to 32-bit or more);
 Experienced staff are available;
 Books, training courses, code samples and WWW sites discussing the use
of the language are all widely available.
 Overall, C may not be a perfect language for developing embedded
systems - but it is a good choice (and it is unlikely that a ‘perfect’ language
will ever be created).

Copyright © 2009-2011 TTE Systems Ltd


29 Licensed to University of Leicester

Using the C language (Simple example)

int Sum_of_Squares1(int a, int b)


{
/* No checking … */
int Square1 = a*a;
int Square2 = b*b;

return Square1 + Square2;


}

Copyright © 2009-2011 TTE Systems Ltd


30 Licensed to University of Leicester

Page 17
Using the C language (Simple example)

int Sum_of_Squares1(const int A, const int B)


{
/* No checking … */
int Square1 = A*A;
int Square2 = B*B;

return Square1 + Square2;


}

Copyright © 2009-2011 TTE Systems Ltd


31 Licensed to University of Leicester

Using the C language (Simple example)

void Sum_of_Squares1(const int A, const int B, int* sum_PTR)


{
/* No checking … */
int Square1 = A*A;
int Square2 = B*B;

*sum_PTR = Square1 + Square2;


}

Copyright © 2009-2011 TTE Systems Ltd


32 Licensed to University of Leicester

Page 18
Using the C language (Simple example)

void Sum_of_Squares1(const int A, const int B, int* const sum_PTR)


{
/* No checking … */
int Square1 = A*A;
int Square2 = B*B;

*sum_PTR = Square1 + Square2;


}

Copyright © 2009-2011 TTE Systems Ltd


33 Licensed to University of Leicester

Using the C language (Simple example)

uint8_t Test(void(* pFunction)())


{
uint8_t index = 0;

...

SCH_tasks[index].pTask = pFunction;

...

(*SCH_tasks[index].pTask)();

...

Copyright © 2009-2011 TTE Systems Ltd


34 Licensed to University of Leicester

Page 19
Software architecture for a
simple embedded system

Copyright © 2009-2011 TTE Systems Ltd


35 Licensed to University of Leicester

Typical software architecture for a “desktop” processor

Word Processor
OS provides ‘common code’ for:
• Graphics
Operating System
• Printing
• File storage
• Sound
BIOS
• ...

Hardware

Copyright © 2009-2011 TTE Systems Ltd


36 Licensed to University of Leicester

Page 20
Typical code structure for desktop processor

Desktop code

Function
Function 4
2 Function
Function 5
1
Function Function
3 6

Copyright © 2009-2011 TTE Systems Ltd


37 Licensed to University of Leicester

Basic software architecture for deeply-embedded processor

Temperature
sensor
Central
heating Boiler
controller
Temperature
dial

int main(void)
{
C_HEAT_Init();// Init the system

while(1) // 'for ever' (Super Loop)


{
C_HEAT_Get_Required_Temperature(); // Get input from the user

C_HEAT_Get_Actual_Temperature(); // Find out current room temperature

C_HEAT_Control_Boiler(); // Adjust the gas burner


}

return 1;
}

Copyright © 2009-2011 TTE Systems Ltd


38 Licensed to University of Leicester

Page 21
Task-oriented software engineering?

void C_HEAT_Get_Required_Temperature(void);

 This can be viewed as a task, implemented as a C function


 We will use a range of different operating systems and
schedulers to call these functions (or “release” these tasks)

 More specifically:
– Most of our systems will be built from “void void” functions;
– Data transfer between tasks will be carried out using global variables

Copyright © 2009-2011 TTE Systems Ltd


39 Licensed to University of Leicester

Task-oriented software engineering?

Embedded code

Task 1 Task 2 Task 3 Task 4

Function Function
1 2

Copyright © 2009-2011 TTE Systems Ltd


40 Licensed to University of Leicester

Page 22
Example:
Working with switches

Copyright © 2009-2011 TTE Systems Ltd


41 Licensed to University of Leicester

Switches and embedded systems


 Input from a user:
On Off 1 2 3 Start Engage AP

4 5 6 Temporary Manual

1 2 3 4 5 Disengage AP
7 8 9
STOP

0 Enter < > Up and Around

 Other information from the operating environment:

Copyright © 2009-2011 TTE Systems Ltd


42 Licensed to University of Leicester

Page 23
Working with 8051 port pins
 The I/O ports are controlled using the specific Special
Function Registers (SFR) for the individual ports
// Ports
sfr P0 = 0x80;
sfr P1 = 0x90;
sfr P2 = 0xA0;
sfr P3 = 0xB0;

 Write 1s to the pins of a port that you want to use as input


 External logic should be designed to pull a pin low
Note: if a pin is set to “low” by software and pulled “high” by
external hardware, you can damage the microcontroller
P1 = 0xFF; // Prepare port for input
Port_data = P1; // Store the state of the pins in the variable

Copyright © 2009-2011 TTE Systems Ltd


43 Licensed to University of Leicester

Writing to the port pins

/* Port SFRs */
sfr P1 = 0x90;

/* Write 11111111 */
P1 = 0xFF;

/* Write 00001111 */
P1 = 0x0F;

Copyright © 2009-2011 TTE Systems Ltd


44 Licensed to University of Leicester

Page 24
Review: “Hex”

Hexadecimal (base 16) Binary (base 2) Decimal (base 10)

0x00 00000000 0

0xFF 11111111 255

0x0F 00001111 15

0xF0 11110000 240

0xAA 10101010 170

0xFFFF 1111111111111111 65535

0xFFAA 1111111110101010 65450

See “Embedded C”, Chapter 2

Copyright © 2009-2011 TTE Systems Ltd


45 Licensed to University of Leicester

Reading bytes

/*---------------------------------------------------------*-
Bytes.C (v1.00)
----------------------------------------------------------
Reads from P1 and copies the value to P2.
-*---------------------------------------------------------*/

#include <reg52.H>

void main (void)


The input port
{
unsigned char Port1_value; The output port

// Must set up P1 for reading


P1 = 0xFF;

while(1)
{
// Read the value of P1
Port1_value = P1;

// Copy the value to P2


P2 = Port1_value;
}
}

Copyright © 2009-2011 TTE Systems Ltd


46 Licensed to University of Leicester

Page 25
Reading bits (8051)
/*------------------------------------------------------------------*-
Bits1.C (v1.00)
------------------------------------------------------------------
Reading and writing individual port pins.
NOTE: Both pins on the same port
-*------------------------------------------------------------------*/
#include <Reg52.H>

sbit Switch_pin = P1^0; “sbit” variable declaration. The symbol ‘^’ is used,
sbit LED_pin = P1^1; but the XOR bitwise operator is NOT involved

void main (void)


{
bit x;

// Set switch pin for reading


Switch_pin = 1;

while(1)
{
x = Switch_pin; // Read Pin 1.0
LED_pin = x; // Write to Pin 1.1
}
}

Copyright © 2009-2011 TTE Systems Ltd


47 Licensed to University of Leicester

Reading bits - Generic

Operator Description Example: (x = 11111110)

& Bitwise AND x & 0x0f = 00001110


| Bitwise OR (inclusive OR) x | 0x0f = 11111111
^ Bitwise XOR (exclusive OR) x ^ 0x0f = 11110001
<< Left shift x <<= 1 = 11111100
>> Right shift x >>= 4 = 00001111
~ One’s complement ~x = 00000001

Copyright © 2009-2011 TTE Systems Ltd


48 Licensed to University of Leicester

Page 26
Reading bits - Generic

#include <reg52.H>

// Function prototypes
void Write_Bit_P1(const unsigned char, const bit);
bit Read_Bit_P1(const unsigned char);

int main (void)


{
bit x;

while(1)
{
x = Read_Bit_P1(0); // Read Port 1, Pin 0
Write_Bit_P1(1,x); // Write to Port 1, Pin 1
}

return 0;
}

Copyright © 2009-2011 TTE Systems Ltd


49 Licensed to University of Leicester

Reading bits – Generic


void Write_Bit_P1(const unsigned char PIN, const bit VALUE)
{
unsigned char p = 0x01; // 00000001
// Left shift appropriate number of places
p <<= PIN;
// If we want 1 output at this pin
if (VALUE == 1)
{
P1 |= p; // Bitwise OR
return;
}
// If we want 0 output at this pin
p = ~p; // Complement
P1 &= p; // Bitwise AND
}

/* --------------------------------------------------------------- */

bit Read_Bit_P1(const unsigned char PIN)


{
unsigned char p = 0x01; // 00000001
// Left shift appropriate number of places
p <<= PIN;
// Write a 1 to the pin (to set up for reading)
Write_Bit_P1(PIN, 1);
// Read the pin (bitwise AND) and return
return (P1 & p);
}

Copyright © 2009-2011 TTE Systems Ltd


50 Licensed to University of Leicester

Page 27
Need for switch de-bouncing
 Upon press or release, all mechanical switch contacts bounce

+5v

Voltage

+5v

t1 t2 Time

 This creates challenges for the software design


– Counting the number of times that a switch is pressed gets tricky (e.g.
Rather than reading ‘A’ from a keypad, we may read ‘AAAAA’)
– If a switch is depressed once, and then released some time later, the
‘bounce’ could make the release seem like a second press.
Copyright © 2009-2011 TTE Systems Ltd
51 Licensed to University of Leicester

ASIDE: Which type of switch should you use?

On Off

Copyright © 2009-2011 TTE Systems Ltd


52 Licensed to University of Leicester

Page 28
Basic software for switch debouncing
 Creating some simple software to check for a valid switch
input is straightforward:

1. We read the relevant port pin.


2. If we think we have detected a switch depression, we wait for
debounce period* (usually 20ms to 50ms) and then read the
pin again.
3. If the second reading confirms the first reading, we assume
the switch really has been depressed.

* Debounce period ≥ mechanical bounce period of the switch

Copyright © 2009-2011 TTE Systems Ltd


53 Licensed to University of Leicester

Code for switch state check with debouncing


/*------------------------------------------------------------------*-
SWITCH_Get_Input()
Reads and debounces a mechanical switch as follows:
1. If switch is not pressed, return SWITCH_NOT_PRESSED.
2. If switch is pressed, wait for DEBOUNCE_PERIOD (in ms).
a. If switch is not pressed, return SWITCH_NOT_PRESSED.
b. If switch is pressed, return SWITCH_PRESSED
See Switch_Wait.H for details of return values.
-*------------------------------------------------------------------*/
bit SWITCH_Get_Input(const unsigned char DEBOUNCE_PERIOD)
{
bit Return_value = SWITCH_NOT_PRESSED;
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_LOOP_Wait(DEBOUNCE_PERIOD);
// Check switch again
if (Switch_pin == 0)
{
Return_value = SWITCH_PRESSED;
}
}
// Now return switch value
return Return_value;
}

Copyright © 2009-2011 TTE Systems Ltd


54 Licensed to University of Leicester

Page 29
Implications of this code
 Can be used to check the state of a switch
(is the switch pressed?)

 Problems can arise whenever a switch is pressed for a period


longer than the debounce interval (typical switch presses are
at least 500ms or until user gets feedback from the system)
 A user typing “Hello” on a keypad may see:
– “HHHHHHHHHeeeeeeeeellllllllllllllllooooooooooo” appear on the
screen.

Copyright © 2009-2011 TTE Systems Ltd


55 Licensed to University of Leicester

Using switches in real systems:


Counting goats …

Copyright © 2009-2011 TTE Systems Ltd


56 Licensed to University of Leicester

Page 30
Counting goats

Mechanical sensor
at goat body
height

Sensor

Goat detected

Copyright © 2009-2011 TTE Systems Ltd


57 Licensed to University of Leicester

Counting goats
/*------------------------------------------------------------------*-
Switch_count.C (v1.00)
------------------------------------------------------------------
A 'goat counting' program for the 8051...
-*------------------------------------------------------------------*/

#include <Reg52.h>

// Connect switch to this pin


sbit Switch_pin = P1^0;

// Display count (binary) on this port


#define Count_port P3

// Return values from Switch_Get_Input()


#define SWITCH_NOT_PRESSED (bit) 0
#define SWITCH_PRESSED (bit) 1

// Function prototypes
void SWITCH_Init(void);
bit SWITCH_Get_Input(const unsigned char DEBOUNCE_PERIOD);
void DISPLAY_COUNT_Init(void);
void DISPLAY_COUNT_Update(const unsigned char);
void DELAY_LOOP_Wait(const unsigned int DELAY_MS);

Copyright © 2009-2011 TTE Systems Ltd


58 Licensed to University of Leicester

Page 31
Counting goats
/* ---------------------------------------------------------------- */
void main(void)
{
unsigned char Switch_presses = 0;

// Init functions
SWITCH_Init();
DISPLAY_COUNT_Init();
while(1)
{
if (SWITCH_Get_Input(30) == SWITCH_PRESSED)
{
Switch_presses++;
}
DISPLAY_COUNT_Update(Switch_presses);
}
}

/*------------------------------------------------------------------*-
SWITCH_Init()
Initialisation function for the switch library.
-*------------------------------------------------------------------*/
void SWITCH_Init(void)
{
Switch_pin = 1; // Use this pin for input
}

Copyright © 2009-2011 TTE Systems Ltd


59 Licensed to University of Leicester

Counting goats
/*------------------------------------------------------------------*-
SWITCH_Get_Input()
Reads and debounces a mechanical switch as follows:
1. If switch is not pressed, return SWITCH_NOT_PRESSED.
2. If switch is pressed, wait for DEBOUNCE_PERIOD (in ms).
a. If switch is not pressed, return SWITCH_NOT_PRESSED.
b. If switch is pressed, wait (indefinitely) for
switch to be released, then return SWITCH_PRESSED
-*------------------------------------------------------------------*/
bit SWITCH_Get_Input(const unsigned char DEBOUNCE_PERIOD)
{
bit Return_value = SWITCH_NOT_PRESSED;
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_LOOP_Wait(DEBOUNCE_PERIOD);
// Check switch again
if (Switch_pin == 0)
{
// Wait until the switch is released.
while (Switch_pin == 0);
Return_value = SWITCH_PRESSED;
}
}
// Now (finally) return switch value
return Return_value;
}

Copyright © 2009-2011 TTE Systems Ltd


60 Licensed to University of Leicester

Page 32
Counting goats
/*------------------------------------------------------------------*-
Initialisation function for the DISAPLY COUNT library.
-*------------------------------------------------------------------*/
void DISPLAY_COUNT_Init(void)
{
Count_port = 0x00;
}
/*------------------------------------------------------------------*-
Simple function to display data (COUNT) on LEDs connected to Count_Port
-*------------------------------------------------------------------*/
void DISPLAY_COUNT_Update(const unsigned char COUNT)
{
Count_port = COUNT;
}
/*------------------------------------------------------------------*-
DELAY_LOOP_Wait()
Delay duration varies with parameter.
Parameter is, *ROUGHLY*, the delay, in milliseconds, on 12MHz 8051
-*------------------------------------------------------------------*/
void DELAY_LOOP_Wait(const unsigned int DELAY_MS)
{
unsigned int x, y;
for (x = 0; x <= DELAY_MS; x++)
{
for (y = 0; y <= 120; y++);
}
}

Copyright © 2009-2011 TTE Systems Ltd


61 Licensed to University of Leicester

Counting goats (simulation)

The number of goats (in binary)

The switch input (Pin 1.0)

Copyright © 2009-2011 TTE Systems Ltd


62 Licensed to University of Leicester

Page 33
Switch hardware

Copyright © 2009-2011 TTE Systems Ltd


63 Licensed to University of Leicester

Switches and pull-up resistors


Vcc
 When the switch is open, pin is at logic level high.
An external (Port 0) or internal resistor (other ports)
10KΩ
‘pulls up’ the pin to the supply voltage of the
To pin on:
microcontroller (typically 5V). Port 0.

On reading the pin, we will see the value ‘1’.

 When the switch is closed (pressed), the pin voltage


To pin on:
will be 0V. Port 1,
Port 2,
or
Port 3.
On reading the pin, we will see the value ‘0’

Copyright © 2009-2011 TTE Systems Ltd


64 Licensed to University of Leicester

Page 34
Switches and pull-up resistors
 With pull up resistors:
Vcc Vcc

Switch released: Switch pressed:


Reads ‘1’ Reads ‘0’

 Without pull up resistors:


Vcc Vcc

Switch released: Switch pressed:


Reads ‘0’ Reads ‘0’

Copyright © 2009-2011 TTE Systems Ltd


65 Licensed to University of Leicester

Adding structure to your code

Copyright © 2009-2011 TTE Systems Ltd


66 Licensed to University of Leicester

Page 35
Adding structure to your code
To stay competitive in today’s environment:
1. Reuse code as much as possible
2. Write code easy to understand now and in the future

Outline
 Benefits of Object Oriented (O-O) programming
 O-O and C?
 Project header file
 Port header file
 Look at case studies

Copyright © 2009-2011 TTE Systems Ltd


67 Licensed to University of Leicester

Views on object-oriented code

“[The phrase] ‘object-oriented’ has become almost synonymous


with modernity, goodness and worth in information technology
circles.” – Graham

“One main claimed advantage of using object orientation is that


an OO model closely represents the problem domain, which
makes it easier to produce and understand designs.” – Jalote

Graham, I. (1994) “Object-Oriented Methods,” (2nd Ed.) Addison-Wesley. Page 1.


Jalote, P. (1997) “An Integrated Approach to Software Engineering”, (2nd Ed.) Springer-
Verlag. Page 273.

Copyright © 2009-2011 TTE Systems Ltd


68 Licensed to University of Leicester

Page 36
Comparison of regular C and O-O C++

int Xyz; class cClass


{
// Assigning a value public:
Xyz = 3; int Get_Xyz(void) const;
void Set_Xyz(int);
// Displaying the value of the variable private:
printf(“%d”, Xyz); int _Xyz; // Encapsulated data
};

// Creating an instance of the class


cClass abc;

// Assigning a value
abc.Set_Xyz(3);

// Displaying the value of the object


cout << abc.Get_Xyz();

Copyright © 2009-2011 TTE Systems Ltd


69 Licensed to University of Leicester

Comparison of regular C and O-O C++


 _Xyz is accessible only through the class (member) functions
 Xyz in C is not protected

 Protection provided O-O languages may result in higher


overheads (either in CPU time for “normal” functions
or in code size for “inline” functions).

Copyright © 2009-2011 TTE Systems Ltd


70 Licensed to University of Leicester

Page 37
Object Oriented C?
Modular file based classes
// BEGIN: File XYZ.C
Header file
// Define “file global” variable
static int Xyz; Serial.C
Serial.C
Xyz = 3; All
All
program
program
...
code Header file
code
printf(“%d”, Xyz); in
in aa
single Switch.C
Switch.C
// END: File XYZ.C single
source
source
file
file Header file
 “File global” variables and
functions, like the variable Xyz, sEOS.C
sEOS.C
are visible only inside the XYZ.C
file.

Copyright © 2009-2011 TTE Systems Ltd


71 Licensed to University of Leicester

Example: PC_IO library


Please concentrate on the library structure only!
 Public ‘member’ functions, (e.g. PC_LINK_IO_Write_String_To_Buffer())
have their prototypes in the H file.
 Private ‘member’ functions, (e.g. PC_LINK_IO_Send_Char()) have their
prototypes in the C file.
 A public constant (e.g. PC_LINK_IO_NO_CHAR), with a value which must
be accessed by the rest of the program is in the H file.
 A limited number of public variables (e.g. In_read_index_G), are defined in
the C file (without the static keyword) – to access these variables in
another file, the keyword extern is added before their declaration in the
other C file (e.g. extern tByte In_read_index_G;).
 Numerous private constants and private variables (e.g.
RECV_BUFFER_LENGTH) are defined / declared in the C file and are
‘invisible’ outside this file.

Copyright © 2009-2011 TTE Systems Ltd


72 Licensed to University of Leicester

Page 38
PC_IO.H
/*------------------------------------------------------------------*-
PC_IO.H (v1.00)
------------------------------------------------------------------
- see PC_IO.C for details.
-*------------------------------------------------------------------*/
#ifndef _PC_IO_H
#define _PC_IO_H

// ------ Public constants -----------------------------------------


// Value returned by PC_LINK_Get_Char_From_Buffer if no character is
// available in buffer
#define PC_LINK_IO_NO_CHAR 127

// ------ Public function prototypes -------------------------------


void PC_LINK_IO_Write_String_To_Buffer(const char* const);
void PC_LINK_IO_Write_Char_To_Buffer(const char);
char PC_LINK_IO_Get_Char_From_Buffer(void);

// Must call this function frequently ...


void PC_LINK_IO_Update(void);

#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


73 Licensed to University of Leicester

PC_IO.C
/*------------------------------------------------------------------*-
PC_IO.C (v1.00)
------------------------------------------------------------------
Core files for simple PC link library for 8051 family
Uses the USART, and Pins 3.1 (Tx) and 3.0 (Rx)
[INCOMPLETE - STRUCTURE ONLY - see Chap 9 for complete library]
-*------------------------------------------------------------------*/
#include "Main.H"
#include "PC_IO.H"

// ------ Public variable definitions ------------------------------


tByte In_read_index_G; // Data in buffer that has been read
tByte In_waiting_index_G; // Data in buffer not yet read

tByte Out_written_index_G; // Data in buffer that has been written


tByte Out_waiting_index_G; // Data in buffer not yet written

// ------ Private function prototypes ------------------------------


static void PC_LINK_IO_Send_Char(const char);

// ------ Private constants ----------------------------------------


// The receive buffer length
#define RECV_BUFFER_LENGTH 8
// The transmit buffer length
#define TRAN_BUFFER_LENGTH 50
#define XON 0x11
#define XOFF 0x13

Copyright © 2009-2011 TTE Systems Ltd


74 Licensed to University of Leicester

Page 39
PC_IO.C
// ------ Private variables ----------------------------------------
static tByte Recv_buffer[RECV_BUFFER_LENGTH];
static tByte Tran_buffer[TRAN_BUFFER_LENGTH];

/*------------------------------------------------------------------*/
void PC_LINK_IO_Update(...)
{
...
}

/*------------------------------------------------------------------*/
void PC_LINK_IO_Write_Char_To_Buffer(...)
{
...
}

/*------------------------------------------------------------------*/
void PC_LINK_IO_Write_String_To_Buffer(...)
{
...
}

Copyright © 2009-2011 TTE Systems Ltd


75 Licensed to University of Leicester

PC_IO.C
/*------------------------------------------------------------------*/
char PC_LINK_IO_Get_Char_From_Buffer(...)
{
...
}

/*------------------------------------------------------------------*/
void PC_LINK_IO_Send_Char(...)
{
...
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


76 Licensed to University of Leicester

Page 40
Project Header - MAIN.H
 Groups the key information about the device you have used,
along with other key parameters (e.g. Oscillator frequency)

‘Do not duplicate information in numerous files; place the


information in one place, and refer to it where necessary’ (Date)

Advantages
 Easier to read code
 Easier to port to other devices

Date, C.J. (1999) “An Introduction to Database Systems,” (7th Ed.). Addison-Wesley.

Copyright © 2009-2011 TTE Systems Ltd


77 Licensed to University of Leicester

Example MAIN.H
/*------------------------------------------------------------------*-
Main.H (v1.00)
------------------------------------------------------------------
'Project Header' for project HELLO2 (see Chap 5)
-*------------------------------------------------------------------*/

#ifndef _MAIN_H
#define _MAIN_H

//------------------------------------------------------------------
// WILL NEED TO EDIT THIS SECTION FOR EVERY PROJECT
//------------------------------------------------------------------
// Must include the appropriate microcontroller header file here
#include <reg52.h> Device specific header file with all SFR declarations
// Oscillator / resonator frequency (in Hz) e.g. (11059200UL)
#define OSC_FREQ (12000000UL)
Clock frequency used for the project
// Number of oscillations per instruction (12, etc)
// 12 - Original 8051 / 8052 and numerous modern versions
// 6 - Various Infineon and Philips devices, etc.
// 4 - Dallas 320, 520 etc.
// 1 - Dallas 420, etc.

#define OSC_PER_INST (12) Core’s machine cycle length (Device dependent)

Copyright © 2009-2011 TTE Systems Ltd


78 Licensed to University of Leicester

Page 41
Example MAIN.H
//------------------------------------------------------------------
// SHOULD NOT NEED TO EDIT THE SECTIONS BELOW
//------------------------------------------------------------------

// Typedefs (see Chap 5)


typedef unsigned char tByte;
typedef unsigned int tWord; Type definitions
typedef unsigned long tLong;

// Interrupts (see Chap 7)


#define INTERRUPT_Timer_0_Overflow 1
#define INTERRUPT_Timer_1_Overflow 3
#define INTERRUPT_Timer_2_Overflow 5

#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


79 Licensed to University of Leicester

Port header file (PORT.H)


 Groups all the pin allocations to a single file for the project.
 Avoids potential conflicts
// ----- Port.H -----
// File A // Port access for File B
... #define Port_B = P0;

sbit Pin_A = P3^2; // Port access for File A


sbit Pin_A = P3^2;
...
// Port access for File C
sbit Pin_C = P2^7;
// File B
...
...
#define Port_B = P0; // File A
#include “port.h”
... ...

// File C // File B
... #include “port.h”
...
sbit Pin_C = P2^7;
// File C
... #include “port.h”
...

Copyright © 2009-2011 TTE Systems Ltd


80 Licensed to University of Leicester

Page 42
Case study

Copyright © 2009-2011 TTE Systems Ltd


81 Licensed to University of Leicester

O-O version of goat counting


List of files
 main.h
 port.h
 main.c
 switch_wait.h
 switch_wait.c
 display_count.h
 display_count.c
 delay_loop.h
 delay_loop.c

Copyright © 2009-2011 TTE Systems Ltd


82 Licensed to University of Leicester

Page 43
O-O goat counting (MAIN.H)
/*------------------------------------------------------------------*-
Main.H (v1.00)
------------------------------------------------------------------
'Project Header' for project HELLO2 (see Chap 5)
-*------------------------------------------------------------------*/

#ifndef _MAIN_H
#define _MAIN_H

//------------------------------------------------------------------
// WILL NEED TO EDIT THIS SECTION FOR EVERY PROJECT
//------------------------------------------------------------------
// Must include the appropriate microcontroller header file here
#include <reg52.h>

// Oscillator / resonator frequency (in Hz) e.g. (11059200UL)


#define OSC_FREQ (12000000UL)

// Number of oscillations per instruction (12, etc)


// 12 - Original 8051 / 8052 and numerous modern versions
// 6 - Various Infineon and Philips devices, etc.
// 4 - Dallas 320, 520 etc.
// 1 - Dallas 420, etc.

#define OSC_PER_INST (12)

Copyright © 2009-2011 TTE Systems Ltd


83 Licensed to University of Leicester

O-O goat counting (MAIN.H – Cont.)


//------------------------------------------------------------------
// SHOULD NOT NEED TO EDIT THE SECTIONS BELOW
//------------------------------------------------------------------

// Typedefs (see Chap 5)


typedef unsigned char tByte;
typedef unsigned int tWord;
typedef unsigned long tLong;

// Interrupts (see Chap 7)


#define INTERRUPT_Timer_0_Overflow 1
#define INTERRUPT_Timer_1_Overflow 3
#define INTERRUPT_Timer_2_Overflow 5

#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


84 Licensed to University of Leicester

Page 44
O-O goat counting (PORT.H)
/*------------------------------------------------------------------*-
Port.H (v1.00)
------------------------------------------------------------------
'Port Header' for project GOATS2 (see Chap 5)
-*------------------------------------------------------------------*/

#ifndef _PORT_H
#define _PORT_H

// ------ Switch_Wait.C -----------------------------------------------


// Connect switch to this pin
sbit Switch_pin = P1^0;

// ------ Display_count.C -----------------------------------------------


// Display count (binary) on this port
#define Count_port P3

#endif

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


85 Licensed to University of Leicester

O-O goat counting (MAIN.C)


/*------------------------------------------------------------------*-
Main.C (v1.00)
------------------------------------------------------------------
A 'switch count' program for the 8051.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Switch_wait.H"
#include "Display_count.H"
/* ---------------------------------------------------------------- */
void main(void)
{
tByte Switch_presses = 0;
// Init functions
SWITCH_Init();
DISPLAY_COUNT_Init();
while(1)
{
if (SWITCH_Get_Input(30) == SWITCH_PRESSED)
{
Switch_presses++;
}
DISPLAY_COUNT_Update(Switch_presses);
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


86 Licensed to University of Leicester

Page 45
O-O goat counting (SWITCH_WAIT.H)
/*------------------------------------------------------------------*-
Switch_wait.H (v1.00)
------------------------------------------------------------------
- See Switch_wait.C for details.
-*------------------------------------------------------------------*/

#ifndef _SWITCH_WAIT_H
#define _SWITCH_WAIT_H

// ------ Public constants -----------------------------------------


// Return values from Switch_Get_Input()
#define SWITCH_NOT_PRESSED (bit) 0
#define SWITCH_PRESSED (bit) 1

// ------ Public function prototype --------------------------------


void SWITCH_Init(void);
bit SWITCH_Get_Input(const tByte DEBOUNCE_PERIOD);

#endif

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


87 Licensed to University of Leicester

O-O goat counting (SWITCH_WAIT.C)


/*------------------------------------------------------------------*-
Switch_Wait.C (v1.00)
------------------------------------------------------------------
Simple library for debouncing a switch input.
NOTE: Duration of function is highly variable!
-*------------------------------------------------------------------*/

#include "Main.H"
#include "Port.H"

#include "Switch_wait.h"
#include "Delay_loop.h"

/*------------------------------------------------------------------*-
SWITCH_Init()
Initialisation function for the switch library.
-*------------------------------------------------------------------*/
void SWITCH_Init(void)
{
Switch_pin = 1; // Use this pin for input
}

Copyright © 2009-2011 TTE Systems Ltd


88 Licensed to University of Leicester

Page 46
O-O goat counting (SWITCH_WAIT.C – Cont.)
/*------------------------------------------------------------------*-
SWITCH_Get_Input()
Reads and debounces a mechanical switch
See Switch_Wait.H for details of return values.
-*------------------------------------------------------------------*/
bit SWITCH_Get_Input(const tByte DEBOUNCE_PERIOD)
{
bit Return_value = SWITCH_NOT_PRESSED;
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_LOOP_Wait(DEBOUNCE_PERIOD);
// Check switch again
if (Switch_pin == 0)
{
// Wait until the switch is released.
while (Switch_pin == 0);
Return_value = SWITCH_PRESSED;
}
}
// Now (finally) return switch value
return Return_value;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


89 Licensed to University of Leicester

O-O goat counting (DISPLAY_COUNT.H)


/*------------------------------------------------------------------*-
Display_count.H (v1.00)
------------------------------------------------------------------
- See Display_count.C for details.
-*------------------------------------------------------------------*/

#ifndef _DISPLAY_COUNT_H
#define _DISPLAY_COUNT_H

// ------ Public function prototypes -------------------------------


void DISPLAY_COUNT_Init(void);
void DISPLAY_COUNT_Update(const tByte);

#endif

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


90 Licensed to University of Leicester

Page 47
O-O goat counting (DISPLAY_COUNT.C)
/*------------------------------------------------------------------*-
Display_count.C (v1.00)
------------------------------------------------------------------
Display an unsigned char on a port.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Display_Count.H"
/*------------------------------------------------------------------*-
DISPLAY_COUNT_Init()
Initialisation function for the DISPLAY COUNT library.
-*------------------------------------------------------------------*/
void DISPLAY_COUNT_Init(void)
{
Count_port = 0x00;
}
/*------------------------------------------------------------------*-
DISPLAY_COUNT_Update()
Simple function to display tByte data (COUNT)
on LEDs connected to port (Count_Port)
-*------------------------------------------------------------------*/
void DISPLAY_COUNT_Update(const tByte COUNT)
{
Count_port = COUNT;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


91 Licensed to University of Leicester

O-O goat counting (DELAY_LOOP.H)


/*------------------------------------------------------------------*-

Delay_Loop.H (v1.00)

------------------------------------------------------------------

- See Delay_Loop.C for details.

-*------------------------------------------------------------------*/

#ifndef _DELAY_LOOP_H
#define _DELAY_LOOP_H

// ------ Public function prototype --------------------------------


void DELAY_LOOP_Wait(const tWord DELAY_MS);

#endif

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


92 Licensed to University of Leicester

Page 48
O-O goat counting (DELAY_LOOP.C)
/*------------------------------------------------------------------*-
Delay_Loop.C (v1.00)
------------------------------------------------------------------
Create a simple software delay using a loop.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Delay_loop.h"

/*------------------------------------------------------------------*-
DELAY_LOOP_Wait()
Delay duration varies with parameter.
Parameter is, *ROUGHLY*, the delay, in milliseconds,
on 12MHz 8051 (12 osc cycles).
You need to adjust the timing for your application!
-*------------------------------------------------------------------*/
void DELAY_LOOP_Wait(const tWord DELAY_MS)
{
tWord x, y;

for (x = 0; x <= DELAY_MS; x++)


{
for (y = 0; y <= 120; y++);
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


93 Licensed to University of Leicester

What does “real time” really mean?

Copyright © 2009-2011 TTE Systems Ltd


94 Licensed to University of Leicester

Page 49
Real-time systems vs. embedded systems
“A real-time computer system is a computer system in which the
correctness of the system behaviour depends not only on the logical results
of the computations, but also on the physical instant at which these results
are produced.

A real-time computer system is always part of a larger system – this larger


system is called a real-time system.”
Source: Kopetz, H., “Real-Time Systems: Design Principles for Distributed Embedded Applications”, (Kluwer
Academic Publishers, 2002)

Copyright © 2009-2011 TTE Systems Ltd


95 Licensed to University of Leicester

Real-time systems vs. embedded systems


 One way of classifying real-time systems:
– Hard real-time: we guarantee that the processing will meet all deadlines
 If this specification is not met, then the system is considered useless.
 Example: autopilot system in an aircraft

– Soft real-time systems: we can tolerate some missed deadlines


 Example: live audio-video systems where a delay in processing may result in
degraded quality but not a catastrophe

Copyright © 2009-2011 TTE Systems Ltd


96 Licensed to University of Leicester

Page 50
The importance of real-time systems
x, y, z = position coordinates
q υ, β, ϖ = velocity cordinates
p = roll rate
q = pitch rate
y,β Rudder
r = yaw rate
δr

Elevator
δe

Aileron
x,υ δa
Yaw (rate)
sensor
p

Pitch z,ϖ
(rate) Rudder
sensor

Roll r
(rate) Elevator
sensor Aircraft
Autopilot
System
Main
pilot Aileron
controls

Position Main engine


sensors (fuel)
(GPS) controllers

Velocity
sensors
(3 axes)

Copyright © 2009-2011 TTE Systems Ltd


97 Licensed to University of Leicester

Requirements
 Software running “as fast as possible” not good enough!
 Need guarantees in operation (timing).

 Failure to meet timing requirements makes the


system useless

Copyright © 2009-2011 TTE Systems Ltd


98 Licensed to University of Leicester

Page 51
Thinking allowed …
 Suppose you are creating a real-time embedded system.
 In the following list, which is the most important design goal?
– Minimal BCET (best-case execution time)?
– Minimal WCET (worst-case execution time)?
– BCET = WCET?

Copyright © 2009-2011 TTE Systems Ltd


99 Licensed to University of Leicester

Meeting real-time constraints

Copyright © 2009-2011 TTE Systems Ltd


100 Licensed to University of Leicester

Page 52
Problems with the code we have written till now

bit SWITCH_Get_Input(const unsigned char DEBOUNCE_PERIOD)


{
bit Return_value = SWITCH_NOT_PRESSED;
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_LOOP_Wait(DEBOUNCE_PERIOD); Software delay is not precise.
// Check switch again
if (Switch_pin == 0)
{
// Wait until the switch is released.
while (Switch_pin == 0); Blocks the system until the switch is released
Return_value = SWITCH_PRESSED;
}
}
// Now (finally) return switch value
return Return_value;
}

Copyright © 2009-2011 TTE Systems Ltd


101 Licensed to University of Leicester

Creating “hardware delays”

Copyright © 2009-2011 TTE Systems Ltd


102 Licensed to University of Leicester

Page 53
Generating precise delays
8051 timer operation recap:
 16-bit timers.
 Incremented periodically based on the oscillator frequency
 On a standard 8051/8052 (12 MHz clock), timers are
incremented every 1 µs and have a maximum period of
65.536ms (1 µs x 216).

 Sets a flag when timer rolls over


 Can be used to trigger an interrupt (more on Day 2)
 Shorter periods can be obtained starting the timer from a
value greater than 0

Copyright © 2009-2011 TTE Systems Ltd


103 Licensed to University of Leicester

Timer 0 and 1 SFRs


Bit 7 (MSB) 6 5 4 3 2 1 0 (LSB)
TCON
NAME TF1 TR1 TF0 TR0

Timer 0 run control


Timer 0 overflow flag
Timer 1 run control
Timer 1 overflow flag

Bit 7 (MSB) 6 5 4 3 2 1 0 (LSB)


TMOD Timer 1 Timer 1 Timer 1 Timer 1 Timer 0 Timer 0 Timer 0 Timer 0
NAME Gate Mode 0 Gate C/T Mode 0
C/T Mode 1 Mode 1

Gate If 0, timer runs when TRx bit is set. If 1, timer runs when external gate pin
is active and TRx bit is set.
Counter / Timer If 0, timer increments every machine cycle. If 1, timer counts pulses on
external pin
Mode 1 & 0 Sets one of the four timer modes (including 16 bit timer / counter and 8 bit
auto reload)

Copyright © 2009-2011 TTE Systems Ltd


104 Licensed to University of Leicester

Page 54
Timer 0 and 1 SFRs
TH0, TL0, TH1 and TL1
 Timer high (TH0, TH1) and low byte (TL0, TL1) SFRs are
used to access the high and low bytes of the timer counter.
 Timer 0 can be set to overflow after 15ms by writing the
following value to the timer counter registers:

Timer interrupt enable bits


 The timer interrupts are enables and disabled by setting or
clearing the ET0 and ET1 bits in the IE SFR.

Copyright © 2009-2011 TTE Systems Ltd


105 Licensed to University of Leicester

Hardware Delay – 50 ms
/*------------------------------------------------------------------*-
DELAY_HARDWARE_50ms()
Hardware delay of 50ms.
*** Assumes 12MHz 8051 (12 osc cycles) ***
-*------------------------------------------------------------------*/
void DELAY_HARDWARE_50ms(void)
{
// Configure Timer 0 as a 16-bit timer
TMOD &= 0xF0; // Clear all T0 bits (T1 left unchanged)
TMOD |= 0x01; // Set required T0 bits (T1 left unchanged)

ET0 = 0; // No interrupts

// Values for 50 ms delay


TH0 = 0x3C; // Timer 0 initial value (High Byte)
TL0 = 0xB0; // Timer 0 initial value (Low Byte)

TF0 = 0; // Clear overflow flag


TR0 = 1; // Start timer 0

while (TF0 == 0); // Loop until Timer 0 overflows (TF0 == 1)

TR0 = 0; // Stop Timer 0


}

Copyright © 2009-2011 TTE Systems Ltd


106 Licensed to University of Leicester

Page 55
Hardware Delay – 1 s
 Delays longer that the maximum period of the timers can be
achieved by multiple calls to a delay less than this period.
/*------------------------------------------------------------------*-
DELAY_HARDWARE_One_Second()
Hardware delay of 1000 ms.
*** Assumes 12MHz 8051 (12 osc cycles) ***
-*------------------------------------------------------------------*/
void DELAY_HARDWARE_One_Second(void)
{
unsigned char d;

// Call DELAY_HARDWARE_50ms() twenty times


for (d = 0; d < 20; d++)
{
DELAY_HARDWARE_50ms();
}
}

Copyright © 2009-2011 TTE Systems Ltd


107 Licensed to University of Leicester

Creating “timeout” mechanisms

Copyright © 2009-2011 TTE Systems Ltd


108 Licensed to University of Leicester

Page 56
The need for timeout mechanisms
Looping wait structures From goat
while (Switch_pin == 0); // Loop until switch is released counting
example
From app
// Wait until AD conversion finishes (checking ADCI)
note for
while ((ADCON & ADCI) == 0);
8Xc552

Dangers of these structures:


 Unpredictable behaviour if peripheral is configured incorrectly
 Unpredictable behaviour if peripheral is damaged

Copyright © 2009-2011 TTE Systems Ltd


109 Licensed to University of Leicester

Loop timeout mechanism


tWord Timeout_loop = 0;((ADCON & ADCI) == 0);

...

// Wait for test condition with built in timeout


while (((Test condition) == 0) && (++ Timeout_loop != 0));

 Assuming 16-bit variables, the loop will run a maximum of


65535 times before the timeout logic causes the loop to exit.
 The exact maximum time of the loop has to be tested, but
ensures that loop eventually exits.
 The timeout duration can be changed by using different
starting values for the timeout variable.

Copyright © 2009-2011 TTE Systems Ltd


110 Licensed to University of Leicester

Page 57
Switch timeout code (example)

if (Switch_pin == 0)
{
// Switch is pressed

// Debounce - just wait...


DELAY_T0_Wait(DEBOUNCE_PERIOD);
// Check switch again
if (Switch_pin == 0)
{
// Wait until the switch is released.
// (WITH TIMEOUT LOOP - 10 seconds)
while ((Switch_pin == 0) && (++Timeout_loop != 0));

Copyright © 2009-2011 TTE Systems Ltd


111 Licensed to University of Leicester

Hardware loop timeout

// Define Timer 0 / Timer 1 preload values for ~10 msec delay


#define PRELOAD_10ms (65536 - (tWord)(OSC_FREQ / (OSC_PER_INST * 100)))
#define PRELOAD_10ms_H (PRELOAD_10ms / 256)
#define PRELOAD_10ms_L (PRELOAD_10ms % 256)

...

// Configure Timer 0 as a 16-bit timer


TMOD &= 0xF0; // Clear all T0 bits (T1 left unchanged)
TMOD |= 0x01; // Set required T0 bits (T1 left unchanged)

ET0 = 0; // No interrupts

// Simple timeout feature - approx 10 ms


TH0 = PRELOAD_10ms_H; // See Timeout.H for PRELOAD details
TL0 = PRELOAD_10ms_L;
TF0 = 0; // Clear flag
TR0 = 1; // Start timer

while (((ADCON & ADCI) == 0) && !TF0);

Copyright © 2009-2011 TTE Systems Ltd


112 Licensed to University of Leicester

Page 58
“Balanced code” and “sandwich delays”

Copyright © 2009-2011 TTE Systems Ltd


113 Licensed to University of Leicester

Example: Sandwich Delay


Problem
You are running two activities, one after the other. How can we ensure that
the interval between release times of the two activities is known and fixed?

Solution
// Execute Do_X() in a ‘Sandwich Delay’ – BEGIN
Set_Sandwich_Timer_Overflow(5); // Set timer to overflow after 5 ms

Do_X(); // Execute Do_X - WCET approx. 4 ms

Wait_For_Sandwich_Timer_Overflow(); // Wait for timer to overflow


// Execute Do_X() in a ‘Sandwich Delay’ - END

Do_Y();

Source: Adapted from Sandwich Delay in Pont, M.J. et al., “Meeting real-time constraints using “Sandwich Delays””,
Presented at EuroPLoP 2006 (Irsee, Germany), July 2006.
Please note that this pattern is described in much more detail in the original text.

Copyright © 2009-2011 TTE Systems Ltd


114 Licensed to University of Leicester

Page 59
Example

int main(void)
{ A simple “cyclic executive”

// Super Loop
while(1)
{
X();
Delay(); // Software delay?
Y();
Delay();
}

// No OS to return to …
return 1;
}

Copyright © 2009-2011 TTE Systems Ltd


115 Licensed to University of Leicester

Example

int main(void)
{ Better control over timing …

while(1)
{
Start_Timer();
X(); // Task runs in “sandwich delay”
Wait_For_Timer(10);

Start_Timer()
Y();
Wait_For_Timer(10);
}

return 1;
}

Copyright © 2009-2011 TTE Systems Ltd


116 Licensed to University of Leicester

Page 60
Example

int main(void)
{ Fixed delay
X();
X() Y()

Delay(); Time

System
Y(); reset

Power_Down();
while(1); // Safety net

return 1;
}

E.g. Garage doors

Copyright © 2009-2011 TTE Systems Ltd


117 Licensed to University of Leicester

Conclusion
 We’ve covered a lot of ground in this first seminar:
– Introduction to embedded systems
– Introduction to super loops
– Introduction to the 8051
– A first look at software architectures for embedded systems
– A first look at some coding guidelines
– A first look at techniques required to meet RT constraints

 Now it’s time to try out some of these ideas in the first lab
session …

Copyright © 2009-2011 TTE Systems Ltd


118 Licensed to University of Leicester

Page 61
All my own work
 The following individuals contributed to the material and slides
presented in this session:
– Musharraf Hanif (University of Leicester)
– Devaraj Ayavoo (TTE Systems Ltd)
– Zemian Hughes (TTE Systems Ltd)
– Peter Vidler (TTE Systems Ltd)
– Muhammad Waqas Raza (TTE Systems Ltd)
– Keith Athaide (TTE Systems Ltd)
– Anjali Das (TTE Systems Ltd)
– Michael Short (Teesside University)

Copyright © 2009-2011 TTE Systems Ltd


119 Licensed to University of Leicester

Page 62
Day 2: Key software architectures

Michael J. Pont

MSc in Reliable Embedded Systems


Module EG7510 (“A1a”)

Introduction and review

Copyright © 2009-2011 TTE Systems Ltd


2 Licensed to University of Leicester

Page 63
The story so far …
 We covered a lot of ground in Seminar 1:
– Introduction to embedded systems
– Introduction to super loops
– Introduction to the 8051
– A first look at software architectures for embedded systems
– A first look at some coding guidelines
– A first look at techniques required to meet RT constraints

Copyright © 2009-2011 TTE Systems Ltd


3 Licensed to University of Leicester

Day 2 Outline
 On the agenda today:
– Creating and using a “simple embedded operating system”;
– Creating multi-state systems;
– Executing sequences of functions;
– Dealing with “long tasks” in reliable embedded systems
– A first look at MISRA C

Copyright © 2009-2011 TTE Systems Ltd


4 Licensed to University of Leicester

Page 64
Time, time, time …

Copyright © 2009-2011 TTE Systems Ltd


5 Licensed to University of Leicester

Super loops revisited void main(void)


{
Pros Init_System();

while(1) // (Super Loop)


 Very easy to understand {
X();
 Minimal resource requirements }
}
 Suitable for some “soft RT” systems

Cons
 Difficult to execute functions with a known period
 Not suitable for “hard RT” systems

Copyright © 2009-2011 TTE Systems Ltd


6 Licensed to University of Leicester

Page 65
The need for accurate timing
Most embedded applications require tasks to be performed
periodically:
 Generating sound from stored samples.
 Measuring the speed of a vehicle every 0.5 seconds.
 Refreshing a display 40 times per second.
 Logging vibration data from sensor at a rate of 1000 Hz.
 Scanning a keypad every 200 ms.

Copyright © 2009-2011 TTE Systems Ltd


7 Licensed to University of Leicester

Inserting a delay into the super loop


 If task timings do not vary at run time, it is possible to use a
super loop to call a task periodically
 E.g. Call function X every 60ms:
void main(void)
{

Init_System();

while(1) // 'for ever' (Super Loop)


{
X(); // Call the function (10 ms duration)
Delay_50ms(); // Delay for 50 ms
}
}

 Unfortunately, task timings often vary considerably


- interrupts provide an effective solution …

Copyright © 2009-2011 TTE Systems Ltd


8 Licensed to University of Leicester

Page 66
Creating and using a “simple embedded
operating system” (sEOS)

Copyright © 2009-2011 TTE Systems Ltd


9 Licensed to University of Leicester

What is an interrupt?
 “A signal informing a program that an event has occurred.
When a program receives an interrupt signal, it takes a
specified action (which can be to ignore the signal). Interrupt
signals can cause a program to suspend itself temporarily to
service the interrupt” (Webopedia computer dictionary)

 From a programmer’s perspective, interrupts can be seen as a


way of linking hardware events to function calls
– In an “event triggered” design, we often have multiple “interrupt service
routines” (ISRs), all associated with different hardware events. In
most cases, we don’t know when these events will occur
– In a “time triggered” design, we usually have one ISR, linked to a
timer (e.g., the ISR may be triggered by a periodic timer overflow)

Copyright © 2009-2011 TTE Systems Ltd


10 Licensed to University of Leicester

Page 67
Basis of a “simple embedded operating system” (sEOS)

Update() Update() Update() ...


Time
System ‘ticks’

BACKGROUND FOREGROUND
Tasks (functions)
PROCESSING PROCESSING Called from here:
E.g. a long “switch”
statement
while(1) Update();
{
Go_To_Sleep(); (Interrupt)
}

1 ms timer
A simple
time-triggered system with
co-operative tasks
(TTC)

Copyright © 2009-2011 TTE Systems Ltd


11 Licensed to University of Leicester

Basis of a “simple embedded operating system” (sEOS)

Water void WASHER_Update(void)


Valve
{
Water
Heater switch (System_state_G)
Start {
Switch
Water case INIT:
Pump
Selector
Dial case START:
Washing Drum
Machine Motor
Water Controller case FILL_DRUM:
Level
Sensor
LED
indicators case HEAT_WATER:
Temperature
Sensor
Door
case WASH_01:
lock

...
Detergent }
Hatch
}

(Interrupt)

1 ms timer

Copyright © 2009-2011 TTE Systems Ltd


12 Licensed to University of Leicester

Page 68
Basis of a “simple embedded operating system” (sEOS)

 Needs to be able to run “tasks” (functions) at specified rates


 Timer interrupt service routine (ISR) provides a good starting
point:
– Set up a timer to generate an interrupt periodically
– Use code placed in the ISR to run the tasks at the desired rates

 Interrupts are easy to manage in a high-level language

Copyright © 2009-2011 TTE Systems Ltd


13 Licensed to University of Leicester

Timer ISR framework


/*------------------------------------------------------------------*-
Main.c
------------------------------------------------------------------
Simple timer ISR demonstration program.
-*------------------------------------------------------------------*/
#include <reg52.H>

#define INTERRUPT_Timer_2_Overflow 5 IE index for Timer 2 overflow interrupt


// Function prototype
// NOTE: ISR is not explictly called and does not require a prototype
void Timer_2_Init(void);
/* --------------------------------------------------------------- */
void main(void)
{
Timer_2_Init(); // Set up Timer 2
EA = 1; // Globally enable interrupts
while(1); // An empty Super Loop
}
/* --------------------------------------------------------------- */
void X(void) interrupt INTERRUPT_Timer_2_Overflow
Compiler keyword to link the function to
{
// This ISR is called every 1 ms the interrupt vector

// Place required code here...


}

Copyright © 2009-2011 TTE Systems Ltd


14 Licensed to University of Leicester

Page 69
Timer ISR framework
void Timer_2_Init(void)
{
// Timer 2 is configured as a 16-bit timer,
// which is automatically reloaded when it overflows
//
// This code (generic 8051/52) assumes a 12 MHz system osc.
// The Timer 2 resolution is then 1.000 µs
//
// Reload value is FC18 (hex) = 64536 (decimal)
// Timer (16-bit) overflows when it reaches 65536 (decimal)
// Thus, with these setting, timer will overflow every 1 ms
T2CON = 0x04; // Load Timer 2 control register
TH2 = 0xFC; // Load Timer 2 high byte
RCAP2H = 0xFC; // Load Timer 2 reload capt. reg. high byte
TL2 = 0x18; // Load Timer 2 low byte
RCAP2L = 0x18; // Load Timer 2 reload capt. reg. low byte

// Timer 2 interrupt is enabled, and ISR will be called


// whenever the timer overflows - see below.
ET2 = 1;

// Start Timer 2 running


TR2 = 1;
}

Copyright © 2009-2011 TTE Systems Ltd


15 Licensed to University of Leicester

The Simple Embedded Operating System (sEOS)


 Formalisation of the “timer ISR” based system.
 Provides a framework to ease the development process of
embedded systems.
 Puts the processor “to sleep” between tasks:
– To conserve power;
– To reduce task jitter.

Copyright © 2009-2011 TTE Systems Ltd


16 Licensed to University of Leicester

Page 70
sEOS Listing
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
------------------------------------------------------------------
Main file for Simple Embedded Operating System (sEOS) for 8051.
Demonstration version with dummy task X().
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Simple_EOS.H"
// Header for dummy task
#include "X.H"
/*------------------------------------------------------------------*-
sEOS_ISR()
Invoked periodically by Timer 2 overflow:
see sEOS_Init_Timer2() for timing details.
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
// Must manually reset the T2 flag
TF2 = 0;

//===== USER CODE - Begin =======================================

// Call user task here

//===== USER CODE - End =========================================


}

Copyright © 2009-2011 TTE Systems Ltd


17 Licensed to University of Leicester

sEOS Listing
/*------------------------------------------------------------------*-
sEOS_Init_Timer2()
Sets up Timer 2 to drive the simple EOS.
Parameter gives tick interval in MILLISECONDS.
Max tick interval is ~60ms (12 MHz oscillator).
Note: Precise tick intervals are only possible with certain
oscillator / tick interval combinations. If timing is important,
you should check the timing calculations manually.
-*------------------------------------------------------------------*/
void sEOS_Init_Timer2(const tByte TICK_MS)
{
tLong Inc;
tWord Reload_16;
tByte Reload_08H, Reload_08L;
// Timer 2 is configured as a 16-bit timer,
// which is automatically reloaded when it overflows
T2CON = 0x04; // Load Timer 2 control register

// Number of timer increments required (max 65536)


Inc = ((tLong)TICK_MS * (OSC_FREQ/1000)) / (tLong)OSC_PER_INST;

// 16-bit reload value


Reload_16 = (tWord) (65536UL - Inc);

// 8-bit reload values (High & Low)


Reload_08H = (tByte)(Reload_16 / 256);
Reload_08L = (tByte)(Reload_16 % 256);

Copyright © 2009-2011 TTE Systems Ltd


18 Licensed to University of Leicester

Page 71
sEOS Listing
TH2 = Reload_08H; // Load Timer 2 high byte
RCAP2H = Reload_08H; // Load Timer 2 reload capt. reg. high byte
TL2 = Reload_08L; // Load Timer 2 low byte
RCAP2L = Reload_08L; // Load Timer 2 reload capt. reg. low byte

// Timer 2 interrupt is enabled, and ISR will be called


// whenever the timer overflows.
ET2 = 1;

// Start Timer 2 running


TR2 = 1;

EA = 1; // Globally enable interrupts


}
/*------------------------------------------------------------------*-
sEOS_Go_To_Sleep()
This operating system enters 'idle mode' between clock ticks
to save power. The next clock tick will return the processor
to the normal operating state.
-*------------------------------------------------------------------*/
void sEOS_Go_To_Sleep(void)
{
PCON |= 0x01; // Enter idle mode (generic 8051 version)
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


19 Licensed to University of Leicester

sEOS design features


Tasks and scheduling
 sEOS can schedule a single task (function in C) to be run
periodically

Tick interval
 The control of the tick interval has been largely automated
(sEOS_Init_Timer2())
 Using the 12 MHz oscillator, precise timing can be achieved in
the range from 1 ms to 65 ms ticks
 Using “odd” frequency oscillators (like 11.0592 MHz for
precise serial communication) limits the precision of the tick
period being generated.
Copyright © 2009-2011 TTE Systems Ltd
20 Licensed to University of Leicester

Page 72
sEOS design features
Power saving
 sEOS reduces the power consumption by putting the
processor into idle mode between task executions.
Idle Idle Idle

Task Task Task ...


Time
System ‘ticks’

Portability to other devices


 Most of the processors used in embedded applications have
at least one timer for generating operating system ticks.

Copyright © 2009-2011 TTE Systems Ltd


21 Licensed to University of Leicester

What about Timer 0 or Timer 1?


 It is possible to use a timer without automatic reload to run the
scheduler by manually reloading the timer in every tick to
ensure proper tick periods.
 These tick periods will not be very accurate as the time
between the timer overflow and the moment when the timer is
reloaded is not taken into consideration during reloads.

Copyright © 2009-2011 TTE Systems Ltd


22 Licensed to University of Leicester

Page 73
Simple sEOS example

Copyright © 2009-2011 TTE Systems Ltd


23 Licensed to University of Leicester

Simple sEOS example


 We’ll use sEOS to call “Task X” (a function) every 60 ms.

 Unlike the super loop with delay, the Task X will be run every
60 ms by sEOS even if the execution time varies.

 If we assume that X takes 10 ms to run the average


consumption is 3.5 mA (cf. 11 mA at “full power”).
10ms × 11mA + 50ms × 2mA
Average Current Consumption = = 3.5mA
60ms

Copyright © 2009-2011 TTE Systems Ltd


24 Licensed to University of Leicester

Page 74
Simple sEOS example
/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Demonstration of sEOS running a dummy task.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Simple_EOS.H"

#include "X.H"
/* --------------------------------------------------------------- */
void main(void)
{
// Prepare for dummy task
X_Init();

// Set up simple EOS (60 ms tick interval)


sEOS_Init_Timer2(60);

while(1) // Super Loop


{
// Enter idle mode to save power
sEOS_Go_To_Sleep();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


25 Licensed to University of Leicester

Simple sEOS example


/*------------------------------------------------------------------*-
X.C (v1.00)
------------------------------------------------------------------
Dummy task to introduce sEOS.
-*------------------------------------------------------------------*/
#include "X.H"

/*------------------------------------------------------------------*-
X_Init()
Dummy task init function.
-*------------------------------------------------------------------*/
void X_Init(void)
{
// Dummy task init...
}

/*------------------------------------------------------------------*-
X()
Dummy task called from sEOS ISR.
-*------------------------------------------------------------------*/
void X(void)
{
// Dummy task...
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


26 Licensed to University of Leicester

Page 75
Simple sEOS example
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
------------------------------------------------------------------
Main file for Simple Embedded Operating System (sEOS) for 8051.
Demonstration version with dummy task X().
-*------------------------------------------------------------------*/
...

/*------------------------------------------------------------------*-
sEOS_ISR()
Invoked periodically by Timer 2 overflow:
see sEOS_Init_Timer2() for timing details.
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
// Must manually reset the T2 flag
TF2 = 0;

//===== USER CODE - Begin =======================================

// Call user task here


X();

//===== USER CODE - End =========================================


}

...

Copyright © 2009-2011 TTE Systems Ltd


27 Licensed to University of Leicester

Creating useful TTC tasks

Copyright © 2009-2011 TTE Systems Ltd


28 Licensed to University of Leicester

Page 76
Creating useful tasks for sEOS
 “Embedded C” gives a number of examples of tasks for use
with TTC architectures
 “Patterns for Time-Triggered Embedded Systems” also has
many relevant examples

Copyright © 2009-2011 TTE Systems Ltd


29 Licensed to University of Leicester

Example: Reading switch state (PTTES, Ch. 19)


/*------------------------------------------------------------------*-

SWIT_A.C (v1.00)

------------------------------------------------------------------

Simple switch interface code, with software debounce.

-*------------------------------------------------------------------*/

#include "Main.h"
#include "Port.h"

#include "Swit_A.h"

// ------ Public variable definitions ------------------------------

bit Sw_pressed_G = 0; // The current switch status

// ------ Private constants ----------------------------------------

// Allows NO or NC switch to be used (or other wiring variations)


#define SW_PRESSED (0)

// SW_THRES must be > 1 for correct debounce behaviour


#define SW_THRES (3)

Copyright © 2009-2011 TTE Systems Ltd


30 Licensed to University of Leicester

Page 77
Example: Reading switch state (PTTES, Ch. 19)
/*------------------------------------------------------------------*-

SWITCH_Init()

Initialisation function for the switch library.

-*------------------------------------------------------------------*/
void SWITCH_Init(void)
{
Sw_pin = 1; // Use this pin for input
}

Copyright © 2009-2011 TTE Systems Ltd


31 Licensed to University of Leicester

Example: Reading switch state (PTTES, Ch. 19)


void SWITCH_Update(void)
{
static tByte Duration;
The key task
if (Sw_pin == SW_PRESSED) Usually schedule this to run every 10 ms
{ (slower rates are possible)
Duration += 1;

if (Duration > SW_THRES)


{
Duration = SW_THRES;

Sw_pressed_G = 1; // Switch is pressed...


return;
}

// Switch pressed, but not yet for long enough


Sw_pressed_G = 0;
return;
}

// Switch not pressed - reset the count


Duration = 0;
Sw_pressed_G = 0; // Switch not pressed...
}

Copyright © 2009-2011 TTE Systems Ltd


32 Licensed to University of Leicester

Page 78
Case study

Copyright © 2009-2011 TTE Systems Ltd


33 Licensed to University of Leicester

Case study: Milk pasteurisation


Determine flow rate from pulse stream
 Design a system to monitor
the rate of liquid (milk) flow
through a pasteurisation
system. Milk
Milkpasteurisation
pasteurisationsystem
system

 The rate of flow is measured


using a flow rate sensor.
Optical
 Desired outputs: sensor

– Bar graph giving a representation


of rate of flow To ‘counter’ input

– Audible alarm when rate falls Rotating


shaft
below a threshold.

Copyright © 2009-2011 TTE Systems Ltd


34 Licensed to University of Leicester

Page 79
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Port.H (v1.00)
------------------------------------------------------------------
Port Header file for the milk pasteurization example (Chapter 7)
-*------------------------------------------------------------------*/

// ------ Pulse_Count.C -------------------------------------------------


// Connect pulse input to this pin - debounced in software
sbit Sw_pin = P3^0;
// Connect alarm to this pin (set if pulse is below threshold)
sbit Alarm_pin = P3^7;

// ------ Bargraph.C -----------------------------------------------


// Bargraph display on these pins
// The 8 port pins may be distributed over several ports if required
sbit Pin0 = P1^0;
sbit Pin1 = P1^1;
sbit Pin2 = P1^2;
sbit Pin3 = P1^3;
sbit Pin4 = P1^4;
sbit Pin5 = P1^5;
sbit Pin6 = P1^6;
sbit Pin7 = P1^7;

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


35 Licensed to University of Leicester

Milk pasteurisation: Code listing


/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Milk pasteurization example.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Simple_EOS.H"
#include "Bargraph.H"
#include "Pulse_Count.H"
/* --------------------------------------------------------------- */
void main(void)
{
PULSE_COUNT_Init();
BARGRAPH_Init();
// Set up simple EOS (30ms tick interval)
sEOS_Init_Timer2(30);
while(1) // Super Loop
{
// Enter idle mode to save power
sEOS_Go_To_Sleep();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


36 Licensed to University of Leicester

Page 80
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
------------------------------------------------------------------
Main file for Simple Embedded Operating System (sEOS) for 8051.
-- This version for milk-flow-rate monitoring.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Simple_EOS.H"

#include "Pulse_count.H"
/*------------------------------------------------------------------*-
sEOS_ISR()
Invoked periodically by Timer 2 overflow:
see sEOS_Init_Timer2() for timing details.
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
// Must manually reset the T2 flag
TF2 = 0;

//===== USER CODE - Begin =======================================


// Call 'Update' function here
PULSE_COUNT_Update();
//===== USER CODE - End =========================================
}
...
...

Copyright © 2009-2011 TTE Systems Ltd


37 Licensed to University of Leicester

Milk pasteurisation: Code listing


/*------------------------------------------------------------------*-
Pulse_Count.C (v1.00)
------------------------------------------------------------------
Count pulses from a mechanical switch or similar device.
Responds to falling edge of pulse: |___
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Bargraph.H"
#include "Pulse_Count.H"
// ------ Private function prototypes ------------------------------
void PULSE_COUNT_Check_Below_Threshold(const tByte);

// ------ Public variable declarations -----------------------------


// The data to be displayed
extern tBargraph Data_G;

// ------ Public variable definitions -------------------------------


// Set only after falling edge is detected
bit Falling_edge_G;

// ------ Private variable definitions ------------------------------


// The results of successive tests of the pulse signal
// (NOTE: Can't have arrays of bits...)
static bit Test4, Test3, Test2, Test1, Test0;
static tByte Total_G = 0;
static tWord Calls_G = 0;

Copyright © 2009-2011 TTE Systems Ltd


38 Licensed to University of Leicester

Page 81
Milk pasteurisation: Code listing
// ------ Private constants ----------------------------------------
// Allows changed of logic without hardware changes
#define HI_LEVEL (0)
#define LO_LEVEL (1)

/*------------------------------------------------------------------*-
PULSE_COUNT_Init()
Initialisation function for the switch library.
-*------------------------------------------------------------------*/

void PULSE_COUNT_Init(void)
{
Sw_pin = 1; // Use this pin for input

// The tests (see text)


Test4 = LO_LEVEL;
Test3 = LO_LEVEL;
Test2 = LO_LEVEL;
Test1 = LO_LEVEL;
Test0 = LO_LEVEL;
}

Copyright © 2009-2011 TTE Systems Ltd


39 Licensed to University of Leicester

Milk pasteurisation: Code listing


/*------------------------------------------------------------------*-
PULSE_COUNT_Check_Below_Threshold()
Checks to see if pulse count is below a specified
threshold value. If it is, sounds an alarm.
-*------------------------------------------------------------------*/
void PULSE_COUNT_Check_Below_Threshold(const tByte THRESHOLD)
{
if (Data_G < THRESHOLD)
{
Alarm_pin = 0;
}
else
{
Alarm_pin = 1;
}
}
/*------------------------------------------------------------------*-
PULSE_COUNT_Update()
This is the main switch function.
It should be called every 30 ms
(to allow for typical 20ms debounce time).
-*------------------------------------------------------------------*/
void PULSE_COUNT_Update(void)
{
// Clear timer flag
TF2 = 0;
<Continued>

Copyright © 2009-2011 TTE Systems Ltd


40 Licensed to University of Leicester

Page 82
Milk pasteurisation: Code listing
<PULSE_COUNT_Update() – Continued>
// Shuffle the test results
Test4 = Test3;
Test3 = Test2;
Test2 = Test1;
Test1 = Test0;

// Get latest test result


Test0 = Sw_pin;

// Required result:
// Test4 == HI_LEVEL
// Test3 == HI_LEVEL
// Test1 == LO_LEVEL
// Test0 == LO_LEVEL
if ((Test4 == HI_LEVEL) && (Test3 == HI_LEVEL) &&
(Test1 == LO_LEVEL) && (Test0 == LO_LEVEL))
{
// Falling edge detected
Falling_edge_G = 1;
}
else
{
// Default
Falling_edge_G = 0;
}

Copyright © 2009-2011 TTE Systems Ltd


41 Licensed to University of Leicester

Milk pasteurisation: Code listing


<PULSE_COUNT_Update() – Continued>
// Calculate average every 45 calls to this task
// - maximum count over this period is 9 pulses
// if (++Calls_G < 45)

// 450 used here for test purposes (in simulator)


// [Because there is a limit to how fast you can simulate pulses
// by hand...]
if (++Calls_G < 450)
{
Total_G += (int) Falling_edge_G;
}
else
{
// Update the display
Data_G = Total_G; // Max is 9
Total_G = 0;
Calls_G = 0;
PULSE_COUNT_Check_Below_Threshold(3);
BARGRAPH_Update();
}
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


42 Licensed to University of Leicester

Page 83
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Bargraph.h (v1.00)
------------------------------------------------------------------
- See Bargraph.c for details.
-*------------------------------------------------------------------*/
#include "Main.h"

// ------ Public data type declarations ----------------------------


typedef tByte tBargraph;

// ------ Public function prototypes -------------------------------


void BARGRAPH_Init(void);
void BARGRAPH_Update(void);

// ------ Public constants -----------------------------------------


#define BARGRAPH_MAX (9)
#define BARGRAPH_MIN (0)

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


43 Licensed to University of Leicester

Milk pasteurisation: Code listing


/*------------------------------------------------------------------*-
Bargraph.c (v1.00)
------------------------------------------------------------------
Simple bargraph library.
-*------------------------------------------------------------------*/
#include "Main.h"
#include "Port.h"
#include "Bargraph.h"

// ------ Public variable declarations -----------------------------


// The data to be displayed
tBargraph Data_G;

// ------ Private constants ----------------------------------------


#define BARGRAPH_ON (1)
#define BARGRAPH_OFF (0)

// ------ Private variables ----------------------------------------


// These variables store the thresholds
// used to update the display
static tBargraph M9_1_G;
static tBargraph M9_2_G;
static tBargraph M9_3_G;
static tBargraph M9_4_G;
static tBargraph M9_5_G;
static tBargraph M9_6_G;
static tBargraph M9_7_G;
static tBargraph M9_8_G;

Copyright © 2009-2011 TTE Systems Ltd


44 Licensed to University of Leicester

Page 84
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
BARGRAPH_Init()
Prepare for the bargraph display.
-*------------------------------------------------------------------*/
void BARGRAPH_Init(void)
{
Pin0 = BARGRAPH_OFF;
Pin1 = BARGRAPH_OFF;
Pin2 = BARGRAPH_OFF;
Pin3 = BARGRAPH_OFF;
Pin4 = BARGRAPH_OFF;
Pin5 = BARGRAPH_OFF;
Pin6 = BARGRAPH_OFF;
Pin7 = BARGRAPH_OFF;

// Use a linear scale to display data


// Remember: *9* possible output states
// - do all calculations ONCE
M9_1_G = (BARGRAPH_MAX - BARGRAPH_MIN) / 9;
M9_2_G = M9_1_G * 2;
M9_3_G = M9_1_G * 3;
M9_4_G = M9_1_G * 4;
M9_5_G = M9_1_G * 5;
M9_6_G = M9_1_G * 6;
M9_7_G = M9_1_G * 7;
M9_8_G = M9_1_G * 8;
}

Copyright © 2009-2011 TTE Systems Ltd


45 Licensed to University of Leicester

Milk pasteurisation: Code listing


/*------------------------------------------------------------------*-
BARGRAPH_Update()
Update the bargraph display.
-*------------------------------------------------------------------*/
void BARGRAPH_Update(void)
{
tBargraph Data = Data_G - BARGRAPH_MIN;

Pin0 = ((Data >= M9_1_G) == BARGRAPH_ON);


Pin1 = ((Data >= M9_2_G) == BARGRAPH_ON);
Pin2 = ((Data >= M9_3_G) == BARGRAPH_ON);
Pin3 = ((Data >= M9_4_G) == BARGRAPH_ON);
Pin4 = ((Data >= M9_5_G) == BARGRAPH_ON);
Pin5 = ((Data >= M9_6_G) == BARGRAPH_ON);
Pin6 = ((Data >= M9_7_G) == BARGRAPH_ON);
Pin7 = ((Data >= M9_8_G) == BARGRAPH_ON);
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


46 Licensed to University of Leicester

Page 85
Pros and cons of “TTC” architectures

Copyright © 2009-2011 TTE Systems Ltd


47 Licensed to University of Leicester

sEOS characterisation
The sEOS is a time-triggered co-operative (TTC) scheduling
architecture:
 The co-operative environment avoids the overheads and
potential problems (e.g. systems with shared resources) of
multitasking environments.
 The workload of a time-triggered system can be ensured to be
evenly distributed at design time: in most cases, the same
cannot be said about a system in which multiple interrupts are
enabled.

 We’ll consider these matters in greater detail in later seminars.

Copyright © 2009-2011 TTE Systems Ltd


48 Licensed to University of Leicester

Page 86
The “one interrupt per microcontroller” rule

 In theory:
When saying that an embedded system has a
time-triggered (TT) architecture we mean that we can
determine in advance – before the system begins
executing – exactly what it will do at every moment of
time during which it is running.

 In practice, TT usually means:


– One interrupt source per CPU
– The interrupt is often (not always) a “timer tick”
– Peripherals are ‘polled’

Copyright © 2009-2011 TTE Systems Ltd


49 Licensed to University of Leicester

Limitations of co-operative multitasking systems


 As the active task has control of the system and cannot be
stopped or interrupted by the scheduler, a task overrunning its
allotted time can cause problems.
Tick Interval
Execution time

Task ...

System ‘ticks’ Time

 It is up to the designer to ensure that the worst case execution


time (WCET) of any task is less that the tick interval.
Task ...
Time
System ‘ticks’

Copyright © 2009-2011 TTE Systems Ltd


50 Licensed to University of Leicester

Page 87
Multi-state systems and function sequences

Copyright © 2009-2011 TTE Systems Ltd


51 Licensed to University of Leicester

Multiple state in systems


 Most embedded systems can be modelled in terms of their
various operating states.
 Transition between states may result in the execution of a
particular sequence of functions.
 Transitions may depend on passage of time and / or inputs.

Some examples
 Auto pilot system
 Industrial robots
 Traffic lights
 Automatic washing machine

Copyright © 2009-2011 TTE Systems Ltd


52 Licensed to University of Leicester

Page 88
Classification based on transition rules
 Time-dependent, multi-state systems
– Basic traffic light control system
 Time- and input-dependent, multi-state systems
– Washing machine
 Input-dependent, multi-state systems (less common?)

Copyright © 2009-2011 TTE Systems Ltd


53 Licensed to University of Leicester

Case study

Copyright © 2009-2011 TTE Systems Ltd


54 Licensed to University of Leicester

Page 89
Case Study: Basic traffic light
 Timed four-state system
1. Red (for 20 seconds)
2. Red and amber (for 5 seconds)
3. Green (for 30 seconds)
4. Amber (for 5 seconds)
 No inputs to the system

Copyright © 2009-2011 TTE Systems Ltd


55 Licensed to University of Leicester

Case Study: Basic traffic light – Code listing


/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Traffic light example.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Simple_EOS.H"
#include "T_Lights.H"
/* --------------------------------------------------------------- */
void main(void)
{
// Prepare to run traffic sequence
TRAFFIC_LIGHTS_Init(RED);

// Set up simple EOS (50 ms ticks)


sEOS_Init_Timer2(50);

while(1) // Super Loop


{
// Enter idle mode to save power
sEOS_Go_To_Sleep();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


56 Licensed to University of Leicester

Page 90
Case Study: Basic traffic light: Code listing
/*------------------------------------------------------------------*-
T_Lights.H (v1.00)
------------------------------------------------------------------
- See T_Lights.C for details.
-*------------------------------------------------------------------*/

#ifndef _T_LIGHTS_H
#define _T_LIGHTS_H

// ------ Public data type declarations ----------------------------


// Possible system states
typedef enum {RED, RED_AND_AMBER, GREEN, AMBER} eLight_State;

// ------ Public function prototypes -------------------------------


void TRAFFIC_LIGHTS_Init(const eLight_State);
void TRAFFIC_LIGHTS_Update(void);

#endif

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


57 Licensed to University of Leicester

Case Study: Basic traffic light – Code listing


/*------------------------------------------------------------------*-
T_lights.C (v1.00)
------------------------------------------------------------------
Traffic light control program (Test Version 1.0)
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "T_lights.H"
// ------ Private constants ----------------------------------------
// Easy to change logic here
#define ON 0
#define OFF 1

// Times in each of the (four) possible light states


// (Times are in seconds)
#define RED_DURATION 20
#define RED_AND_AMBER_DURATION 5
#define GREEN_DURATION 30
#define AMBER_DURATION 5

// ------ Private variables ----------------------------------------


// The state of the system
static eLight_State Light_state_G;
// The time in that state
static tLong Time_in_state;
// Used by sEOS
static tByte Call_count_G = 0;

Copyright © 2009-2011 TTE Systems Ltd


58 Licensed to University of Leicester

Page 91
Case Study: Basic traffic light – Code listing
/*------------------------------------------------------------------*-
TRAFFIC_LIGHTS_Init()
-*------------------------------------------------------------------*/
void TRAFFIC_LIGHTS_Init(const eLight_State START_STATE)
{
Light_state_G = START_STATE; // Decide on initial state
}
/*------------------------------------------------------------------*-
TRAFFIC_LIGHTS_Update()
Must be called once per second.
-*------------------------------------------------------------------*/
void TRAFFIC_LIGHTS_Update(void)
{
switch (Light_state_G)
{
case RED:
{
Red_light = ON;
Amber_light = OFF;
Green_light = OFF;
if (++Time_in_state == RED_DURATION)
{
Light_state_G = RED_AND_AMBER;
Time_in_state = 0;
}
break;
}
<Continued>

Copyright © 2009-2011 TTE Systems Ltd


59 Licensed to University of Leicester

Case Study: Basic traffic light – Code listing


<TRAFFIC_LIGHTS_Update() - Continued>
case RED_AND_AMBER:
{
Red_light = ON;
Amber_light = ON;
Green_light = OFF;
if (++Time_in_state == RED_AND_AMBER_DURATION)
{
Light_state_G = GREEN;
Time_in_state = 0;
}
break;
}

case GREEN:
{
Red_light = OFF;
Amber_light = OFF;
Green_light = ON;
if (++Time_in_state == GREEN_DURATION)
{
Light_state_G = AMBER;
Time_in_state = 0;
}
break;
}

Copyright © 2009-2011 TTE Systems Ltd


60 Licensed to University of Leicester

Page 92
Case Study: Basic traffic light – Code listing
<TRAFFIC_LIGHTS_Update() - Continued>
case AMBER:
{
Red_light = OFF;
Amber_light = ON;
Green_light = OFF;

if (++Time_in_state == AMBER_DURATION)
{
Light_state_G = RED;
Time_in_state = 0;
}

break;
}
}
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


61 Licensed to University of Leicester

Case study

Copyright © 2009-2011 TTE Systems Ltd


62 Licensed to University of Leicester

Page 93
Case study: Washing machine controller
Water void WASHER_Update(void)
Valve
{
Water
Heater switch (System_state_G)
Start
Switch
{
Water case INIT:
Pump
Selector
Dial case START:
Washing Drum
Machine
Controller Motor
Water case FILL_DRUM:
Level
Sensor
LED
indicators case HEAT_WATER:
Temperature
Sensor
Door
case WASH_01:
lock

...
Detergent }
Hatch
}

(Interrupt)

1 ms timer

Copyright © 2009-2011 TTE Systems Ltd


63 Licensed to University of Leicester

Case study: Washing machine controller


 Example of time- and Water
Valve
input-dependent, multi-
state system. Water
Heater

 Machine has multiple Start


Switch

preset programs. Water


Pump
Selector
Dial
Washing Drum
Machine Motor
Water Controller
Level
Sensor
LED
indicators
Temperature
Sensor
Door
lock

Detergent
Hatch

Copyright © 2009-2011 TTE Systems Ltd


64 Licensed to University of Leicester

Page 94
Washing machine controller: Code listing
/*------------------------------------------------------------------*-
Washer.C (v1.01)
------------------------------------------------------------------
Multi-state framework for washing-machine controller.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Washer.H"

// ------ Private data type declarations ---------------------------


// Possible system states
typedef enum {INIT, START, FILL_DRUM, HEAT_WATER,
WASH_01, WASH_02, ERROR} eSystem_state;

// ------ Private function prototypes ------------------------------


tByte WASHER_Read_Selector_Dial(void);
bit WASHER_Read_Start_Switch(void);
bit WASHER_Read_Water_Level(void);
bit WASHER_Read_Water_Temperature(void);

void WASHER_Control_Detergent_Hatch(bit);
void WASHER_Control_Door_Lock(bit);
void WASHER_Control_Motor(bit);
void WASHER_Control_Pump(bit);
void WASHER_Control_Water_Heater(bit);
void WASHER_Control_Water_Valve(bit);

Copyright © 2009-2011 TTE Systems Ltd


65 Licensed to University of Leicester

Washing machine controller: Code listing


// ------ Private constants ----------------------------------------
#define OFF 0
#define ON 1

#define MAX_FILL_DURATION (tLong) 1000


#define MAX_WATER_HEAT_DURATION (tLong) 1000

#define WASH_01_DURATION 30000

// ------ Private variables ----------------------------------------


static eSystem_state System_state_G;

static tWord Time_in_state_G;

static tByte Program_G;

// Ten different programs are supported


// Each one may or may not use detergent
static tByte Detergent_G[10] = {1,1,1,0,0,1,0,1,1,0};

// Each one may or may not use hot water


static tByte Hot_Water_G[10] = {1,1,1,0,0,1,0,1,1,0};
/* --------------------------------------------------------------- */
void WASHER_Init(void)
{
System_state_G = INIT;
}

Copyright © 2009-2011 TTE Systems Ltd


66 Licensed to University of Leicester

Page 95
Washing machine controller: Code listing
/* --------------------------------------------------------------- */
void WASHER_Update(void) // Call once per second
{
switch (System_state_G)
{
case INIT:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;

// Set up initial state


WASHER_Control_Motor(OFF); // Motor is off
WASHER_Control_Pump(OFF); // Pump is off
WASHER_Control_Water_Heater(OFF); // Heater is off
WASHER_Control_Water_Valve(OFF);

// Wait (indefinitely) until START is pressed


if (WASHER_Read_Start_Switch() != 1)
{
return;
}

// Start switch pressed...


Program_G = WASHER_Read_Selector_Dial(); // Read the selector dial
System_state_G = START; // Change state
break;
}

Copyright © 2009-2011 TTE Systems Ltd


67 Licensed to University of Leicester

Washing machine controller: Code listing


case START:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;

// Lock the door


WASHER_Control_Door_Lock(ON);

// Start filling the drum


WASHER_Control_Water_Valve(ON);

// Release the detergent (if any)


if (Detergent_G[Program_G] == 1)
{
WASHER_Control_Detergent_Hatch(ON);
}

// Ready to go to next state


System_state_G = FILL_DRUM;
Time_in_state_G = 0;

break;
}

Copyright © 2009-2011 TTE Systems Ltd


68 Licensed to University of Leicester

Page 96
Washing machine controller: Code listing
case FILL_DRUM:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;
// Remain in this state until drum is full
// NOTE: Timeout facility included here
if (++Time_in_state_G >= MAX_FILL_DURATION)
{
System_state_G = ERROR; // Should have filled the drum by now...
}
// Check the water level
if (WASHER_Read_Water_Level() == 1)
{
// Drum is full
if (Hot_Water_G[Program_G] == 1) // Does the program require hot water?
{
WASHER_Control_Water_Heater(ON);
System_state_G = HEAT_WATER; // Ready to go to next state
Time_in_state_G = 0;
}
else
{
System_state_G = WASH_01; // Ready to go to next state
Time_in_state_G = 0;
}
}
break;
}

Copyright © 2009-2011 TTE Systems Ltd


69 Licensed to University of Leicester

Washing machine controller: Code listing


case HEAT_WATER:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;

// Remain in this state until water is hot


// NOTE: Timeout facility included here
if (++Time_in_state_G >= MAX_WATER_HEAT_DURATION)
{
// Should have warmed the water by now...
System_state_G = ERROR;
}

// Check the water temperature


if (WASHER_Read_Water_Temperature() == 1)
{
// Water is at required temperature
// Ready to go to next state
System_state_G = WASH_01;
Time_in_state_G = 0;
}

break;
}

Copyright © 2009-2011 TTE Systems Ltd


70 Licensed to University of Leicester

Page 97
Washing machine controller: Code listing
case WASH_01:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;

// All wash program involve WASH_01


// Drum is slowly rotated to ensure clothes are fully wet
WASHER_Control_Motor(ON);

if (++Time_in_state_G >= WASH_01_DURATION)


{
System_state_G = WASH_02;
Time_in_state_G = 0;
}

break;
}

// REMAINING WASH PHASES OMITTED HERE ...

case WASH_02:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;

break;
}

Copyright © 2009-2011 TTE Systems Ltd


71 Licensed to University of Leicester

Washing machine controller: Code listing


case ERROR:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;

break;
}
}
}

/* --------------------------------------------------------------- */
tByte WASHER_Read_Selector_Dial(void)
{
// User code here...

return 0;
}

Copyright © 2009-2011 TTE Systems Ltd


72 Licensed to University of Leicester

Page 98
Washing machine controller: Code listing
/* --------------------------------------------------------------- */
bit WASHER_Read_Start_Switch(void)
{
// Simplified for demo ...

if (Start_pin == 0)
{
// Start switch pressed
return 1;
}
else
{
return 0;
}
}

/* --------------------------------------------------------------- */
bit WASHER_Read_Water_Level(void)
{
// User code here...

return 1;
}

Copyright © 2009-2011 TTE Systems Ltd


73 Licensed to University of Leicester

Washing machine controller: Code listing


/* --------------------------------------------------------------- */
bit WASHER_Read_Water_Temperature(void)
{
// User code here...

return 1;
}

/* --------------------------------------------------------------- */
void WASHER_Control_Detergent_Hatch(bit State)
{
bit Tmp = State;
// User code here...
}

/* --------------------------------------------------------------- */
void WASHER_Control_Door_Lock(bit State)
{
bit Tmp = State;
// User code here...
}

/* --------------------------------------------------------------- */
void WASHER_Control_Motor(bit State)
{
bit Tmp = State;
// User code here...
}

Copyright © 2009-2011 TTE Systems Ltd


74 Licensed to University of Leicester

Page 99
Washing machine controller: Code listing
/* --------------------------------------------------------------- */
void WASHER_Control_Pump(bit State)
{
bit Tmp = State;
// User code here...
}

/* --------------------------------------------------------------- */
void WASHER_Control_Water_Heater(bit State)
{
bit Tmp = State;
// User code here...
}

/* --------------------------------------------------------------- */
void WASHER_Control_Water_Valve(bit State)
{
bit Tmp = State;
// User code here...
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


75 Licensed to University of Leicester

Dealing with long tasks in TTC designs

Copyright © 2009-2011 TTE Systems Ltd


76 Licensed to University of Leicester

Page 100
Simple TTC designs: The “long task problem” …

It’s easy to think up task sets which can’t be scheduled using a TTC architecture …

A A A A ...
Time

B ...
Time

Copyright © 2009-2011 TTE Systems Ltd


77 Licensed to University of Leicester

Example: Using an appropriate task structure (RS-232)

printf(“Current core temperature is 36.678 degrees”);

Assume:
- Using RS-232 to send data to a PC (or similar)
- 9600 baud

Takes ~ 42 ms to send these data

Copyright © 2009-2011 TTE Systems Ltd


78 Licensed to University of Leicester

Page 101
Example: Using an appropriate task structure (RS-232)

Current core temperature All characters copied to buffer


is 36.678 degrees (fast operation)

Buffer (character array)

Schedule a task to send one character


from the buffer every 10 ms (for example)

Copyright © 2009-2011 TTE Systems Ltd


79 Licensed to University of Leicester

What is RS-232?
 Recommended Standard 232 first appeared in 1960s and
defines:
– The protocol to be used for data transmission
– The voltages to be used on the signal lines
– The connectors to be used to link equipment together
 Widely used at data rates up to around 115 or 330 kbits /
second (k baud).
 Used to communicate with devices at 15 meters or more.

Copyright © 2009-2011 TTE Systems Ltd


80 Licensed to University of Leicester

Page 102
Is it still significant?
 Used by some derivatives of the 8051 and most of the newer
microcontrollers (e.g. C166, ARM7, Cortex, etc) for in system
programming (ISP) or in circuit programming (ICP).
 Provides a link between a PC and the microcontroller that can
be used for:
– Testing and debugging
– Data acquisition
 Does not have the complexities of USB or Bluetooth and is still
used in some of the recent devices (e.g. GPS sensors, TV
boxes for updating the device configuration, etc.)

Copyright © 2009-2011 TTE Systems Ltd


81 Licensed to University of Leicester

The basics of RS-232


 Asynchronous data transmission
 +3V to +15V for bit value of 0
 -3V to -15V for bit value of 1
 Quiescent (idle) state: (1, indefinite duration)
 Start bit: (0, 1 x bit duration)
 Data: (typically 7-8 data bits, with optional parity bit)
 Stop bit(s): (0, duration of 1, 1.5 or 2 bits)

Source: Wikipedia (http://en.wikipedia.org/wiki/File:Rs232_oscilloscope_trace.svg)

Copyright © 2009-2011 TTE Systems Ltd


82 Licensed to University of Leicester

Page 103
Transmission rates and flow control
 Operates in a restricted band of speeds, for example:
– 75, 110, 300, 1200, 2400, 4800, 9600, 14400, 19200, 28800, 33600,
56000, 115000, 330000, 460800 (some new machines) baud
 9600 is a very safe choice
 Hardware handshaking possible but requires extra connections
 Software based “Xon / Xoff” control is possible on half or full
duplex links:
– The receiver uses the “Xon” (Control q) and “Xoff” (Control s) commands
to pace the data flow to it
– Transmitter sends data bytes until it receives “Xoff” command. It resumes
transmission when it receives the “Xon” command

Copyright © 2009-2011 TTE Systems Ltd


83 Licensed to University of Leicester

On-chip UART SFRs


SCON
Bit # 7 6 5 4 3 2 1 0
Name SM0 SM1 SM2 REN TB8 RB8 TI RI
Function Mode bit 0 Mode bit 1 Multi Receiver 8th bit for 9 8th bit for 9 Transmit Receive
processor enable bit data TX bit data interrupt interrupt
comm. mode RX mode flag flag

SM0 SM1 Mode # Description Baud rate


0 0 0 8-bit shift register Oscillator derived
0 1 1 8-bit UART Timer 1 overflow derived
1 0 2 9-bit UART Oscillator derived
1 1 3 9-bit UART Timer 1 overflow derived

Copyright © 2009-2011 TTE Systems Ltd


84 Licensed to University of Leicester

Page 104
On-chip UART SFRs
SBUF
 The SBUF SFR links to separate internal registers based on
the operation being performed

 Reading SBUF accesses the receiver’s buffer and returns the


received byte. The receive buffer retains the last value
received while another byte is being received

 Writing to SBUF accesses the transmitter’s buffer and starts


transmission of the byte just written. Writing to the SBUF
while transmission is in progress corrupts the process

Copyright © 2009-2011 TTE Systems Ltd


85 Licensed to University of Leicester

On-chip UART Mode 1 baud rates


 Baud rate in mode 1 is controlled by the rate of Timer 1
overflow and given by the following formula:

2 SMOD × Frequencyoscillator
Baud rate ( Mode 1) =
32 × Instructionscycle × (256 − TH 1)
SMOD - the ‘double baud rate’ bit in the PCON register.
Frequency oscillator - the oscillator / resonator frequency.
Instructions cycle - the number of oscillator cycles per machine cycle
(12 for standard 8051)
TH1 - the reload value for Timer 1

 To generate precise baud rates, clock sources are required to


have non-integer frequencies (e.g. 11.0592 MHz)

Copyright © 2009-2011 TTE Systems Ltd


86 Licensed to University of Leicester

Page 105
On-chip UART Mode 1 baud rates
 Calculating the reload values for Timer 1 for 9600 baud
(xtal = 11.0592 MHz / 12 MHz, SMOD = 0 in both cases):

11059200 12000000
9600 = 9600 =
32 × 12 × (256 − TH 1) 32 ×12 × (256 − TH 1)
11059200 12000000
TH 1 = 256 − TH 1 = 256 −
9600 × 384 9600 × 384
TH 1 = 253 TH 1 = 252.7447916667

 Using 253 reload value with a 12 MHz oscillator, the resulting


baud rate achieved would be 10417 (off by more than 8%)
 In practice the error in the baud rate should be ±2.5%.

Copyright © 2009-2011 TTE Systems Ltd


87 Licensed to University of Leicester

Case study

Copyright © 2009-2011 TTE Systems Ltd


88 Licensed to University of Leicester

Page 106
Case study: Displaying elapsed time
 Send time elapsed since system power on over a serial link at
9600 baud (using 11.0592 MHz clock)

Copyright © 2009-2011 TTE Systems Ltd


89 Licensed to University of Leicester

Displaying elapsed time – Code listing


/*------------------------------------------------------------------*-
Port.H (v1.01)
------------------------------------------------------------------
'Port Header' (see Chap 5) for the project TIME (see Chap 9)
-*------------------------------------------------------------------*/

#ifndef _PORT_H
#define _PORT_H

// ------ PC_O.C -----------------------------------------------

// Pins 3.0 and 3.1 used for RS-232 interface

#endif

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


90 Licensed to University of Leicester

Page 107
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
RS-232 (Elapsed Time) example - sEOS.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Simple_EOS.H“
#include "PC_O_T1.h"
#include "Elap_232.h“
/* --------------------------------------------------------------- */
void main(void)
{
// Set baud rate to 9600
PC_LINK_O_Init_T1(9600);
// Prepare for elapsed time measurement
Elapsed_Time_RS232_Init();
// Set up simple EOS (5ms tick)
sEOS_Init_Timer2(5);
while(1) // Super Loop
{
sEOS_Go_To_Sleep(); // Enter idle mode to save power
}
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


91 Licensed to University of Leicester

Displaying elapsed time: Code listing


/*------------------------------------------------------------------*-
Elap_232.C (v1.00)
------------------------------------------------------------------
Simple library function for keeping track of elapsed time
Demo version to display time on PC screen via RS232 link.
-*------------------------------------------------------------------*/
#include "Main.h"
#include "Elap_232.h"
#include "PC_O.h"

// ------ Public variable definitions ------------------------------


tByte Hou_G = 0;
tByte Min_G = 0;
tByte Sec_G = 0;

// ------ Public variable declarations -----------------------------


// See Char_Map.c
extern const char code CHAR_MAP_G[10];

/*------------------------------------------------------------------*-
Elapsed_Time_RS232_Init()
-*------------------------------------------------------------------*/
void Elapsed_Time_RS232_Init(void)
{
char Time_Str[] = "Elapsed time";
//PC_LINK_O_Write_String_To_Buffer(Time_Str);
}

Copyright © 2009-2011 TTE Systems Ltd


92 Licensed to University of Leicester

Page 108
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
Elapsed_Time_RS232_Update()
*** Must be called once per second ***
-*------------------------------------------------------------------*/
void Elapsed_Time_RS232_Update(void)
{
char Time_Str[30] = "\rElapsed time: ";

if (++Sec_G == 60)
{
Sec_G = 0;
if (++Min_G == 60)
{
Min_G = 0;
if (++Hou_G == 24)
{
Hou_G = 0;
}
}
}

Time_Str[15] = CHAR_MAP_G[Hou_G / 10];


Time_Str[16] = CHAR_MAP_G[Hou_G % 10];

Time_Str[18] = CHAR_MAP_G[Min_G / 10];


Time_Str[19] = CHAR_MAP_G[Min_G % 10];

Copyright © 2009-2011 TTE Systems Ltd


93 Licensed to University of Leicester

Displaying elapsed time: Code listing


<Elapsed_Time_RS232_Update() – Continued>
Time_Str[21] = CHAR_MAP_G[Sec_G / 10];
Time_Str[22] = CHAR_MAP_G[Sec_G % 10];

// We don't display seconds in this version.


// We simply use the seconds data to turn on and off the colon
// (between hours and minutes)
if ((Sec_G % 2) == 0)
{
Time_Str[17] = ':';
Time_Str[20] = ':';
}
else
{
Time_Str[17] = ' ';
Time_Str[20] = ' ';
}

PC_LINK_O_Write_String_To_Buffer(Time_Str);
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


94 Licensed to University of Leicester

Page 109
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
PC_O_T1.C (v1.00)
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_O_T1.h"
// ------ Public variable declarations -----------------------------
extern tByte Out_written_index_G;
extern tByte Out_waiting_index_G;
/*------------------------------------------------------------------*-
PC_LINK_O_Init_T1()
-*------------------------------------------------------------------*/
void PC_LINK_O_Init_T1(const tWord BAUD_RATE)
{
PCON &= 0x7F; // Set SMOD bit to 0 (don't double baud rates)
// 8-bit data, 1 start bit, 1 stop bit, variable baud rate, receiver disabled
SCON = 0x42;
TMOD |= 0x20; // T1 in mode 2, 8-bit auto reload
TH1 = (256 - (tByte)((((tLong)OSC_FREQ / 100) * 3125)
/ ((tLong) BAUD_RATE * OSC_PER_INST * 1000)));
TL1 = TH1;
TR1 = 1; // Run the timer
TI = 1; // Send first character (dummy)
// Set up the buffers for reading and writing
Out_written_index_G = 0;
Out_waiting_index_G = 0;
// Interrupt *NOT* enabled
ES = 0;
}

Copyright © 2009-2011 TTE Systems Ltd


95 Licensed to University of Leicester

Displaying elapsed time: Code listing


/*------------------------------------------------------------------*-
PC_O.C (v1.00)
------------------------------------------------------------------
Core files for simple write-only PC link library for 8051 family
[Sends data to PC - cannot receive data from PC]
Uses the UART, and Pin 3.1 (Tx)
-*------------------------------------------------------------------*/

#include "Main.h"
#include "PC_O.h"
#include "Elap_232.h"

// ------ Public variable definitions ------------------------------


tByte Out_written_index_G; // Data in buffer that has been written
tByte Out_waiting_index_G; // Data in buffer not yet written

// ------ Private constants ----------------------------------------


// The transmit buffer length
#define TRAN_BUFFER_LENGTH 20

// ------ Private variables ----------------------------------------


static tByte Tran_buffer[TRAN_BUFFER_LENGTH];
static tByte Time_count_G = 0;

Copyright © 2009-2011 TTE Systems Ltd


96 Licensed to University of Leicester

Page 110
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
PC_LINK_O_Update()
Sends next character from the software transmit buffer
NOTE: Output-only library (Cannot receive chars)
Uses on-chip UART hardware.
-*------------------------------------------------------------------*/
void PC_LINK_O_Update(void)
{
// Deal with transmit bytes here
// Are there any data ready to send?
if (Out_written_index_G < Out_waiting_index_G)
{
PC_LINK_O_Send_Char(Tran_buffer[Out_written_index_G]);
Out_written_index_G++;
}
else
{
// No data to send - just reset the buffer index
Out_waiting_index_G = 0;
Out_written_index_G = 0;
}
}

Copyright © 2009-2011 TTE Systems Ltd


97 Licensed to University of Leicester

Displaying elapsed time: Code listing


/*------------------------------------------------------------------*-
PC_LINK_O_Write_String_To_Buffer()
Copies a (null terminated) string to the character buffer.
-*------------------------------------------------------------------*/
void PC_LINK_O_Write_String_To_Buffer(const char* const STR_PTR)
{
tByte i = 0;

while (STR_PTR[i] != '\0')


{
PC_LINK_O_Write_Char_To_Buffer(STR_PTR[i]);
i++;
}
}
/*------------------------------------------------------------------*-
PC_LINK_O_Write_Char_To_Buffer()
Stores a character in the 'write' buffer, ready for later transmission
-*------------------------------------------------------------------*/
void PC_LINK_O_Write_Char_To_Buffer(const char CHARACTER)
{
// Write to the buffer *only* if there is space
// (No error reporting in this simple library...)
if (Out_waiting_index_G < TRAN_BUFFER_LENGTH)
{
Tran_buffer[Out_waiting_index_G] = CHARACTER;
Out_waiting_index_G++;
}
}

Copyright © 2009-2011 TTE Systems Ltd


98 Licensed to University of Leicester

Page 111
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
PC_LINK_O_Send_Char()
-*------------------------------------------------------------------*/
void PC_LINK_O_Send_Char(const char CHARACTER)
{
tLong Timeout1 = 0;
if (CHARACTER == '\n')
{
Timeout1 = 0;
while ((++Timeout1) && (TI == 0));
if (Timeout1 == 0)
{
// usart did not respond - error
return;
}
TI = 0;
SBUF = 0x0d; // Output CR
}
Timeout1 = 0;
while ((++Timeout1) && (TI == 0));
if (Timeout1 == 0)
{
// UART did not respond - error
return;
}
TI = 0;
SBUF = CHARACTER;
}

Copyright © 2009-2011 TTE Systems Ltd


99 Licensed to University of Leicester

Displaying elapsed time: Code listing


/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
-*------------------------------------------------------------------*/
#include ...

// ------ Private variable definitions -----------------------------


static tByte Call_count_G = 0;

/*------------------------------------------------------------------*-
sEOS_ISR()
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
TF2 = 0; // Must manually reset the T2 flag
//===== USER CODE - Begin =======================================
// Call RS-232 update function every 5ms
PC_LINK_O_Update();
// This ISR is called every 5 ms
// - only want to update time every second
if (++Call_count_G == 200)
{
// Time to update time
Call_count_G = 0;
// Call time update function
Elapsed_Time_RS232_Update();
}
//===== USER CODE - End =========================================
}

Copyright © 2009-2011 TTE Systems Ltd


100 Licensed to University of Leicester

Page 112
Case study

Copyright © 2009-2011 TTE Systems Ltd


101 Licensed to University of Leicester

Serial menus – Alternative to switch based UI


 Display a menu over a serial link
 Change system operation based on input from user

Copyright © 2009-2011 TTE Systems Ltd


102 Licensed to University of Leicester

Page 113
Menu-based data acquisition – Code Listing
/*------------------------------------------------------------------*-
Main.c (v1.01)
------------------------------------------------------------------
Data acquisition example.
-*------------------------------------------------------------------*/
#include "Main.h"
#include "Simple_EOS.H"
#include "PC_IO_T1.h"

/* ............................................................... */
void main(void)
{
// Set baud rate to 9600: generic 8051 version
PC_LINK_IO_Init_T1(9600);

// Set up sEOS (5ms tick)


sEOS_Init_Timer2(5);

while(1) // Super Loop


{
sEOS_Go_To_Sleep(); // Enter idle mode to save power
}
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


103 Licensed to University of Leicester

Menu-based data acquisition: Code listing


/*------------------------------------------------------------------*-
Menu_Data.C (v1.00)
------------------------------------------------------------------
Simple framework for menu-driven data acquisition.

Use 'Hyperterminal' (under Windows 95, 98, 2000) or similar


terminal emulator program on other operating systems.

Terminal options:
- Data bits = 8
- Parity = None
- Stop bits = 1
- Flow control = Xon / Xoff
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"

#include "Menu_Data.h"
#include "PC_IO.h"

// ------ Public variable declarations -----------------------------


// See Char_Map.c
extern const char code CHAR_MAP_G[10];

// ------ Private variables ----------------------------------------


static bit First_time_only_G;

Copyright © 2009-2011 TTE Systems Ltd


104 Licensed to University of Leicester

Page 114
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
MENU_Command_Processor()
This function is the main menu 'command processor' function.
Schedule this (say) once every 10 ms (approx.).
-*------------------------------------------------------------------*/
void MENU_Command_Processor(void)
{
char Ch;

if (First_time_only_G == 0)
{
First_time_only_G = 1;
MENU_Show_Menu();
}

// Check for user inputs


PC_LINK_IO_Update();
Ch = PC_LINK_IO_Get_Char_From_Buffer();

if (Ch != PC_LINK_IO_NO_CHAR)
{
MENU_Perform_Task(Ch);
MENU_Show_Menu();
}
}

Copyright © 2009-2011 TTE Systems Ltd


105 Licensed to University of Leicester

Menu-based data acquisition: Code listing


/*------------------------------------------------------------------*-
MENU_Show_Menu()
Display menu options on PC screen (via serial link)
-*------------------------------------------------------------------*/
void MENU_Show_Menu(void)
{
PC_LINK_IO_Write_String_To_Buffer("Menu:\n");
PC_LINK_IO_Write_String_To_Buffer("a - Read P1\n");
PC_LINK_IO_Write_String_To_Buffer("b - Read P2\n\n");
PC_LINK_IO_Write_String_To_Buffer("? : ");
}

Copyright © 2009-2011 TTE Systems Ltd


106 Licensed to University of Leicester

Page 115
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
MENU_Perform_Task()
Perform the required user task
-*------------------------------------------------------------------*/
void MENU_Perform_Task(char c)
{
// Echo the menu option
PC_LINK_IO_Write_Char_To_Buffer(c);
PC_LINK_IO_Write_Char_To_Buffer('\n'); // Perform the task
switch (c)
{
case 'a':
case 'A':
{
Get_Data_From_Port1();
break;
}

case 'b':
case 'B':
{
Get_Data_From_Port2();
break;
}
}
}

Copyright © 2009-2011 TTE Systems Ltd


107 Licensed to University of Leicester

Menu-based data acquisition: Code listing


/*------------------------------------------------------------------*-
Get_Data_From_Port1()
-*------------------------------------------------------------------*/
void Get_Data_From_Port1(void)
{
tByte Port1 = Data_Port1;
char String[11] = "\nP1 = XXX\n\n";
String[6] = CHAR_MAP_G[Port1 / 100];
String[7] = CHAR_MAP_G[(Port1 / 10) % 10];
String[8] = CHAR_MAP_G[Port1 % 10];
PC_LINK_IO_Write_String_To_Buffer(String);
}
/*------------------------------------------------------------------*-
Get_Data_From_Port2()
-*------------------------------------------------------------------*/
void Get_Data_From_Port2(void)
{
tByte Port2 = Data_Port2;
char String[11] = "\nP2 = XXX\n\n";
String[6] = CHAR_MAP_G[Port2 / 100];
String[7] = CHAR_MAP_G[(Port2 / 10) % 10];
String[8] = CHAR_MAP_G[Port2 % 10];
PC_LINK_IO_Write_String_To_Buffer(String);
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


108 Licensed to University of Leicester

Page 116
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_IO_T1.C (v1.00)
------------------------------------------------------------------
PC link library. Bidirectional. T1 used for baud rate generation.
Uses the USART, and Pins 3.1 (Tx) and 3.0 (Rx)
-*------------------------------------------------------------------*/

#include "Main.h"
#include "PC_IO_T1.h"

// ------ Public variable declarations -----------------------------

extern tByte In_read_index_G;


extern tByte In_waiting_index_G;

extern tByte Out_written_index_G;


extern tByte Out_waiting_index_G;

/*------------------------------------------------------------------*-
PC_LINK_IO_Init_T1()
This (generic) version uses T1 for baud rate generation.
-*------------------------------------------------------------------*/
void PC_LINK_IO_Init_T1(const tWord BAUD_RATE)
{
PCON &= 0x7F; // Set SMOD bit to 0 (don't double baud rates)

<Continued>

Copyright © 2009-2011 TTE Systems Ltd


109 Licensed to University of Leicester

Menu-based data acquisition: Code listing


<PC_LINK_IO_Init_T1() - Continued>
// Receiver enabled.
// 8-bit data, 1 start bit, 1 stop bit,
// Variable baud rate (asynchronous)
// Receive flag will only be set if a valid stop bit is received
// Set TI (transmit buffer is empty)
SCON = 0x72;

TMOD |= 0x20; // T1 in mode 2, 8-bit auto reload


TH1 = (256 - (tByte)((((tLong)OSC_FREQ / 100) * 3125)
/ ((tLong) BAUD_RATE * OSC_PER_INST * 1000)));
TL1 = TH1;
TR1 = 1; // Run the timer
TI = 1; // Send first character (dummy)

// Set up the buffers for reading and writing


In_read_index_G = 0;
In_waiting_index_G = 0;
Out_written_index_G = 0;
Out_waiting_index_G = 0;
// Interrupt *NOT* enabled
ES = 0;
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Menu based data acquision
Copyright © 2009-2011 TTE Systems Ltd
110 Licensed to University of Leicester

Page 117
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_IO.C (v1.00)
------------------------------------------------------------------
Core files for simple PC link library for 8051 family
Uses the USART, and Pins 3.1 (Tx) and 3.0 (Rx)
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_IO.h"

// ------ Public variable definitions ------------------------------


tByte In_read_index_G; // Data in buffer that has been read
tByte In_waiting_index_G; // Data in buffer not yet read
tByte Out_written_index_G; // Data in buffer that has been written
tByte Out_waiting_index_G; // Data in buffer not yet written

// ------ Private function prototypes ------------------------------


static void PC_LINK_IO_Send_Char(const char);

// ------ Private constants ----------------------------------------


// The receive buffer length
#define RECV_BUFFER_LENGTH 8
// The transmit buffer length
#define TRAN_BUFFER_LENGTH 50

#define XON 0x11


#define XOFF 0x13

Copyright © 2009-2011 TTE Systems Ltd


111 Licensed to University of Leicester

Menu-based data acquisition: Code listing


// ------ Private variables ----------------------------------------
static tByte Recv_buffer[RECV_BUFFER_LENGTH];
static tByte Tran_buffer[TRAN_BUFFER_LENGTH];

/*------------------------------------------------------------------*-
PC_LINK_IO_Update()
Checks for character in the UART (hardware) receive buffer
Sends next character from the software transmit buffer
-*------------------------------------------------------------------*/
void PC_LINK_IO_Update(void)
{
// Deal with transmit bytes here

// Is there any data ready to send?


if (Out_written_index_G < Out_waiting_index_G)
{
PC_LINK_IO_Send_Char(Tran_buffer[Out_written_index_G]);

Out_written_index_G++;
}
else
{
// No data to send - just reset the buffer index
Out_waiting_index_G = 0;
Out_written_index_G = 0;
}
<Continued>

Copyright © 2009-2011 TTE Systems Ltd


112 Licensed to University of Leicester

Page 118
Menu-based data acquisition: Code listing
<PC_LINK_IO_Update() – Continued>
// Only dealing with received bytes here
if (RI == 1)
{
// Flag only set when a valid stop bit is received,
// -> data ready to be read into the received buffer

// Want to read into index 0, if old data has been read


// (simple ~circular buffer)
if (In_waiting_index_G == In_read_index_G)
{
In_waiting_index_G = 0;
In_read_index_G = 0;
}

// Read the data from USART buffer


Recv_buffer[In_waiting_index_G] = SBUF;

if (In_waiting_index_G < RECV_BUFFER_LENGTH)


{
// Increment without overflowing buffer
In_waiting_index_G++;
}

RI = 0; // Clear RT flag
}
}

Copyright © 2009-2011 TTE Systems Ltd


113 Licensed to University of Leicester

Menu-based data acquisition: Code listing


/*------------------------------------------------------------------*-
PC_LINK_IO_Write_Char_To_Buffer()
Stores a character in the 'write' buffer, ready for
later transmission
-*------------------------------------------------------------------*/
void PC_LINK_IO_Write_Char_To_Buffer(const char CHARACTER)
{
// Write to the buffer *only* if there is space
// - No error reporting in this simple library...
if (Out_waiting_index_G < TRAN_BUFFER_LENGTH)
{
Tran_buffer[Out_waiting_index_G] = CHARACTER;
Out_waiting_index_G++;
}
}

Copyright © 2009-2011 TTE Systems Ltd


114 Licensed to University of Leicester

Page 119
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_LINK_IO_Write_String_To_Buffer()
Copies a (null terminated) string to the character buffer.
(The contents of the buffer are then passed over the serial link)
STR_PTR - Pointer to the NULL-TERMINATED string.
-*------------------------------------------------------------------*/
void PC_LINK_IO_Write_String_To_Buffer(const char* const STR_PTR)
{
tByte i = 0;

while (STR_PTR[i] != '\0')


{
PC_LINK_IO_Write_Char_To_Buffer(STR_PTR[i]);
i++;
}
}

Copyright © 2009-2011 TTE Systems Ltd


115 Licensed to University of Leicester

Menu-based data acquisition: Code listing


/*------------------------------------------------------------------*-

PC_LINK_IO_Get_Char_From_Buffer()

Retrieves a character from the (software) buffer, if available

The character from the buffer is returned, or - if no


data are available - PC_LINK_IO_NO_CHAR is returned.

-*------------------------------------------------------------------*/
char PC_LINK_IO_Get_Char_From_Buffer(void)
{
char Ch = PC_LINK_IO_NO_CHAR;

// If there is new data in the buffer


if (In_read_index_G < In_waiting_index_G)
{
Ch = Recv_buffer[In_read_index_G];

if (In_read_index_G < RECV_BUFFER_LENGTH)


{
In_read_index_G++;
}
}

return Ch;
}

Copyright © 2009-2011 TTE Systems Ltd


116 Licensed to University of Leicester

Page 120
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_LINK_IO_Send_Char()
Based on Keil sample code, with added (loop) timeouts.
Implements Xon / Off control.
-*------------------------------------------------------------------*/
void PC_LINK_IO_Send_Char(const char CHARACTER)
{
tLong Timeout1 = 0;
tLong Timeout2 = 0;
if (CHARACTER == '\n')
{
if (RI)
{
if (SBUF == XOFF)
{
Timeout2 = 0;
do {
RI = 0;
// Wait for uart (with simple timeout)
Timeout1 = 0;
while ((++Timeout1) && (RI == 0));
if (Timeout1 == 0)
{
// USART did not respond - error
return;
}
} while ((++Timeout2) && (SBUF != XON));
< Continued>

Copyright © 2009-2011 TTE Systems Ltd


117 Licensed to University of Leicester

Menu-based data acquisition: Code listing


< PC_LINK_IO_Send_Char() – Continued>
if (Timeout2 == 0)
{
// UART did not respond - error
// No error reporting in this simple library...
return;
}

RI = 0;
}
}

Timeout1 = 0;
while ((++Timeout1) && (TI == 0));

if (Timeout1 == 0)
{
// UART did not respond - error
// No error reporting in this simple library...
return;
}

TI = 0;
SBUF = 0x0d; // Output CR
}

<Continued>

Copyright © 2009-2011 TTE Systems Ltd


118 Licensed to University of Leicester

Page 121
Menu-based data acquisition: Code listing
< PC_LINK_IO_Send_Char() – Continued>
if (RI)
{
if (SBUF == XOFF)
{
Timeout2 = 0;

do {
RI = 0;

// Wait for USART (with simple timeout)


Timeout1 = 0;
while ((++Timeout1) && (RI == 0));

if (Timeout1 == 0)
{
// UART did not respond - error
// No error reporting in this simple library...
return;
}

} while ((++Timeout2) && (SBUF != XON));

RI = 0;
}
}
<Continued>

Copyright © 2009-2011 TTE Systems Ltd


119 Licensed to University of Leicester

Menu-based data acquisition: Code listing


< PC_LINK_IO_Send_Char() – Continued>
Timeout1 = 0;
while ((++Timeout1) && (TI == 0));

if (Timeout1 == 0)
{
// UART did not respond - error
// No error reporting in this simple library...
return;
}

TI = 0;

SBUF = CHARACTER;
}

/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Copyright © 2009-2011 TTE Systems Ltd


120 Licensed to University of Leicester

Page 122
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
------------------------------------------------------------------
Main file for Simple Embedded Operating System (sEOS) for 8051.
- This version for project DATA_ACQ (Chapter 9).
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Simple_EOS.H"
#include "Menu_Data.H"

/*------------------------------------------------------------------*-
sEOS_ISR()
Invoked periodically by Timer 2 overflow:
see sEOS_Init_Timer2() for timing details.
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
TF2 = 0; // Must manually reset the T2 flag

//===== USER CODE - Begin =======================================


// Call MENU_Command_Processor every 5ms
MENU_Command_Processor();

//===== USER CODE - End =========================================


}

...

Copyright © 2009-2011 TTE Systems Ltd


121 Licensed to University of Leicester

Working with MISRA C

Copyright © 2009-2011 TTE Systems Ltd


122 Licensed to University of Leicester

Page 123
The vision and objectives of MISRA C
 When faced with the widespread (and increasing) use of C for the production of
embedded code with safety-related constraints, it was felt that there was a need to
produce a set of standards to assist software developers.
 The Motor Industry Software Reliability Association (MISRA) set out to develop
such a set of guidelines in the late 1980’s / early 1990’s; this culminated in 1994
with the publication of MISRA C (revised in 2004).

 The MISRA guidelines define a subset of the C language that can be used in critical
systems, by setting out a number of guidelines (141 in total). It also places a great
emphasis on the use of static checking tools to help enforce these guidelines.

 MISRA C has become widely accepted in the UK and Europe, and is now
considered to be ‘best-practice’ in many industries, even those which produce
non-critical embedded systems.

Copyright © 2009-2011 TTE Systems Ltd


123 Licensed to University of Leicester

Relationship to other guidelines


 There are several sources that have heavily influenced the MISRA rules
(e.g. IEC 61508).
 There are also other sets of coding guidelines (for C as well as other
languages) that have been suggested independently by experts in their
respective fields.

Copyright © 2009-2011 TTE Systems Ltd


124 Licensed to University of Leicester

Page 124
Applying the MISRA C guidelines
(Simple tool support)

Copyright © 2009-2011 TTE Systems Ltd


125 Licensed to University of Leicester

Applying the MISRA C guidelines (simple tool support)


 We will provide you with a
complete copy of the MISRA
C guidelines

 We will also provide you with


simple checker for some of
the MISRA C rules
(Education Licence)

Copyright © 2009-2011 TTE Systems Ltd


126 Licensed to University of Leicester

Page 125
Applying the MISRA C guidelines (simple tool support)
2.2
Source code shall only use /* ... */ style comments

2.3
The character sequence /* shall not be used within a comment

2.4
Sections of code should not be /* commented out */

4.2
Trigraphs shall not be used

5.1
Identifiers (internal and external) shall not rely on the significance of more than 31
characters

Copyright © 2009-2011 TTE Systems Ltd


127 Licensed to University of Leicester

Applying the MISRA C guidelines (simple tool support)


5.2
Identifiers in an inner scope shall not use the same name as an identifier in an
outer scope, and therefore hide that identifier.

5.3
A typedef name shall be a unique identifier

5.4
A tag name shall be a unique identifier.

5.5
No object or function identifier with static storage duration should be reused

5.6
No identifier in one name space should have the same spelling as an identifier in
another name space, with the exception of structure and union member names.

Copyright © 2009-2011 TTE Systems Ltd


128 Licensed to University of Leicester

Page 126
Applying the MISRA C guidelines (simple tool support)
5.7
No identifier name should be reused.

6.3
typedefs that indicate size and signedness should be used in place of the
basic types

7.1
Octal constants (other than zero) and octal escape sequences shall not be
used.

8.1
Functions shall have prototype declarations and the prototype shall be visible
at both the function definition and call.

Copyright © 2009-2011 TTE Systems Ltd


129 Licensed to University of Leicester

Applying the MISRA C guidelines (simple tool support)


8.2
Whenever an object or function is declared or defined, its type shall be
explicitly stated.

8.3
For each function parameter the type given in the declaration and definition
shall be identical, and the return types shall also be identical.

8.6
Functions shall be declared at file scope.

Copyright © 2009-2011 TTE Systems Ltd


130 Licensed to University of Leicester

Page 127
Further reading related to MISRA C
MISRA. (2004). “Guidelines for the use of the C language in critical systems”. Motor
Industry Software Reliability Report, Released October 2004.

SAE. (1993) "Class C Application Requirement Considerations”. SAE Recommended


Practice J2056/1, SAE, June 1993.

Holzmann, G.J. (2006) “The Power of Ten: Rules for Developing Safety Critical Code”.
IEEE Computer, Vol. 39, No. 6, pp. 93-95, June 2006.

IEC 61508. (2000) “Functional safety of electrical/electronic/programmable electronic


safety-related systems, Part 3”. (2000).

Maguire, S. (1993) “Writing solid code”. Microsoft Press, 1993.

Copyright © 2009-2011 TTE Systems Ltd


131 Licensed to University of Leicester

Conclusion
 Today we have considered:
– Creating and using a “simple embedded operating system”;
– Creating multi-state systems;
– Executing sequences of functions;
– Dealing with “long tasks” in reliable embedded systems;
– MISRA C.

Copyright © 2009-2011 TTE Systems Ltd


132 Licensed to University of Leicester

Page 128
All my own work
 The following individuals contributed to the material and slides
presented in this session:
– Musharraf Hanif (University of Leicester)
– Devaraj Ayavoo (TTE Systems Ltd)
– Zemian Hughes (TTE Systems Ltd)
– Peter Vidler (TTE Systems Ltd)
– Muhammad Waqas Raza (TTE Systems Ltd)
– Keith Athaide (TTE Systems Ltd)
– Anjali Das (TTE Systems Ltd)
– Michael Short (Teesside University)

Copyright © 2009-2011 TTE Systems Ltd


133 Licensed to University of Leicester

Page 129
(Blank page)

Page 130
Day 3: Working with modern hardware platforms

Michael J. Pont

MSc in Reliable Embedded Systems


Module EG7510 (“A1a”)

Introduction and review

Copyright © 2009-2011 TTE Systems Ltd


2 Licensed to University of Leicester

Page 131
The story so far …
 Seminar 1:
– Introduction to embedded systems, super loops and the “8051”;
– A first look at software architectures for embedded systems;
– A first look at techniques required to meet RT constraints.

 Seminar 2:
– TTC concepts and sEOS;
– Creating multi-state systems;
– Executing sequences of functions;
– Dealing with “long tasks” (without resorting to pre-emption);
– MISRA C.

Copyright © 2009-2011 TTE Systems Ltd


3 Licensed to University of Leicester

Day 3 Outline
 A closer look at some important timing issues
 Welcome to the 32-bit MCU world!
– Higher CPU performance; More memory
– Enhanced set of hardware “peripherals”; Enhanced debug support

 A multi-task TTC scheduler


 Debugging with JTAG
 The need for timing analysis in RT embedded systems

 We will also consider two further platforms which are widely


used when developing modern embedded systems:
– The “x86” architecture (the “embedded PC”)
– The field-programmable gate array (a “roll your own” solution)

Copyright © 2009-2011 TTE Systems Ltd


4 Licensed to University of Leicester

Page 132
Thinking allowed …
 Suppose that we were to compare 1000 embedded systems:
– 500 systems will be based on 8-bit processors
– 500 systems will be based on 32-bit processors

 On average, would you expect the 8-bit or 32-bit systems to


be more reliable?

Copyright © 2009-2011 TTE Systems Ltd


5 Licensed to University of Leicester

A slightly closer look at timing issues

Copyright © 2009-2011 TTE Systems Ltd


6 Licensed to University of Leicester

Page 133
Real-time systems vs. embedded systems
“A real-time computer system is a computer system in which the
correctness of the system behaviour depends not only on the logical results
of the computations, but also on the physical instant at which these results
are produced.”
Source: Kopetz, H., “Real-Time Systems: Design Principles for Distributed Embedded Applications”,
(Kluwer Academic Publishers, 2002)

Copyright © 2009-2011 TTE Systems Ltd


7 Licensed to University of Leicester

Why timing matters: Jitter

Task Task Task Task Task Task

t=0 t=1 t=2 t=3 t=4 t=5


Time

Jitter can be defined as the variation of the interval between the start times of
periodic tasks in a RT system

Copyright © 2009-2011 TTE Systems Ltd


8 Licensed to University of Leicester

Page 134
Why timing matters: Jitter
Signal amplitude (Volts)

∆t ∆v

Time

For example, suppose we wish to sample a


500 Hz tone, using an 8-bit ADC
(a very modest requirement)

Application: The maximum allowable jitter


Any sampled-data system before we start using losing data)
(e.g. control, condition monitoring, will be ~1 µs
DSP, etc)
Rule of thumb: >10% jitter means that
data are likely to be meaningless

Copyright © 2009-2011 TTE Systems Ltd


9 Licensed to University of Leicester

Why timing matters: Jitter

Task Task Task Task Task Task

t=0 t=1 t=2 t=3 t=4 t=5


Time

Jitter can be defined as the variation of the interval between the start times of
periodic tasks in a RT system

BUT – suppose the activity we are interested in does not occur at the
start of the task? We may want to “balance” the task code
(see Seminar 1)

Copyright © 2009-2011 TTE Systems Ltd


10 Licensed to University of Leicester

Page 135
A very short history of embedded systems …

Copyright © 2009-2011 TTE Systems Ltd


11 Licensed to University of Leicester

History

1 P1.0 VCC 40
2 P1.1 P0.0 39
3 P1.2 P0.1 38
4 P1.3 P0.2 37
5 P1.4 P0.3 36
6 P1.5 P0.4 35
7 P1.6 P0.5 34
8 P1.7 P0.6 33
‘8051’

9 RST P0.7 32
10 P3.0 / EA 31
11 P3.1 ALE 30
12 P3.2 / PSEN 29
13 P3.3 P2.7 28
14 P3.4 P2.6 27
15 P3.5 P2.5 26
16 P3.6 P2.4 25
17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
Photo by Per Anders 20 VSS P2.0 21

Copyright © 2009-2011 TTE Systems Ltd


12 Licensed to University of Leicester

Page 136
History (and future?)

1 P1.0 VCC 40
2 P1.1 P0.0 39
3 P1.2 P0.1 38
4 P1.3 P0.2 37
5 P1.4 P0.3 36
6 P1.5 P0.4 35
7 P1.6 P0.5 34
8 P1.7 P0.6 33
‘8051’

9 RST P0.7 32
10 P3.0 / EA 31
11 P3.1 ALE 30
12 P3.2 / PSEN 29
13 P3.3 P2.7 28
14 P3.4 P2.6 27
15 P3.5 P2.5 26
16 P3.6 P2.4 25
17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
20 VSS P2.0 21

Copyright © 2009-2011 TTE Systems Ltd


13 Licensed to University of Leicester

Creating a complete hardware platform

Copyright © 2009-2011 TTE Systems Ltd


14 Licensed to University of Leicester

Page 137
Minimal circuit for the 8051

Copyright © 2009-2011 TTE Systems Ltd


15 Licensed to University of Leicester

Minimal circuit for the LPC2xxx


3.3V
Gnd
47

43

42

41

40

39

38

37
48

44
46

45

VDD3-1 (I/O)
P0.17

P0.16

VSS4

P0.13

P0.26

P0.25

P0.12
NC
P0.18

P0.15

P0.14

1 P0.19 P0.11 36
3.3V
2 P0.20 P0.10 35
3.3V 3 P0.21 P0.24 34

4 NC P0.23 33
1.3K
10 K
1.8V 5 VDD1.8 (Core) P0.22 32

6 /RST
LPC2104
VSS3 31 Gnd
10 µ F Gnd 7 VSS1 P0.9 30

8 P0.27 P0.8 29 1 mA LED


18 pF Gnd 9 P0.28 P0.7 28
Logic 0 (0v)
10 P0.29 DBGSEL 27
to light LED
11 X1 RTCK 26
VDD3-2 (I/O)

12 X2 NC 25
P0.0.31
P0.30

VSS2
P0.0

P0.1

P0.2

P0.3

P0.4

P0.5

P0.6
NC

10 MHz
18 pF
14

18

19

20

21

22

23

24
13

15

16

17

Gnd
Gnd
3.3V

Copyright © 2009-2011 TTE Systems Ltd


16 Licensed to University of Leicester

Page 138
Example 32-bit processor:
the NXP LPC2378

Copyright © 2009-2011 TTE Systems Ltd


17 Licensed to University of Leicester

Introduction to LPC2378
 ARM7TDMI-S core running at up to 72 MHz
 On chip 512 kB Flash and 32 kB SRAM
 Dual Advanced High-performance Bus (AHB) architecture
 Advanced vectored interrupt controller (VIC) with 32 sources
 104 fast GPIO pins
 4 x general purpose timers
 1 x real time clock (RTC)
 1 x PWM generator.
 Multiple serial interfaces, including CAN

 Support for testing and debugging

Copyright © 2009-2011 TTE Systems Ltd


18 Licensed to University of Leicester

Page 139
LPC2378: Memory Map
 Program, data, external and
all peripherals are mapped in
a 4GB address space.

 A 32-bit pointer variable can


be linked to any location in
the memory map

Copyright © 2009-2011 TTE Systems Ltd


19 Licensed to University of Leicester

LPC2378’s Vectored Interrupt Controller


 32 interrupt request inputs.
 Each input can be configured as either an FIQ or vectored IRQ
 FIQs have highest priority.
 Multiple inputs configured to trigger the FIQ interrupt are
logically ORed (ISR will have to check the actual source)
 Vectored IRQs have programmable priorities and have the
address of the associated ISR programmed into the VIC.
 Each peripheral has one interrupt line connected to the VIC
but can have multiple interrupt flags.

Copyright © 2009-2011 TTE Systems Ltd


20 Licensed to University of Leicester

Page 140
LPC2378’s fast general purpose parallel I/O (GPIO)
 Located on ARM local bus to allow fastest possible I/O
 Entire port value can be written in one instruction
 Bit level set and clear registers
 Direction control of individual bits
 Port 0 and Port 2 pins can be configured to trigger an interrupt
on rising and/or falling edge. This interrupt generation works
even if clock sources are powered down.

Copyright © 2009-2011 TTE Systems Ltd


21 Licensed to University of Leicester

LPC2378’s ADC
 10-bit successive approximation ADC
 Input multiplexing from 8 input pins.
 Measurement range between 0V to Vi(VREF) (2.5-3.3V)
 Conversion time ≥ 2.44µs
 Supports burst conversion for single or multiple inputs
 Conversion on manual prompt, transition of input pin or timer
match signal

 Allows the controller to ‘see’ analogue signals (e.g.


temperature from a thermocouple, absolute position from a
potentiometer, sound signal sampling, etc.)

Copyright © 2009-2011 TTE Systems Ltd


22 Licensed to University of Leicester

Page 141
Analogue inputs
 What central-heating
temperature does the user
require? B

 What is the current angle of


the crane?
C
 What is the humidity level in
Greenhouse 3?
A

Actuator Main
Main control
control
Actuator
ActuatorAA Actuator BB Actuator
ActuatorCC
(Slave) &&user
user interface
interface
(Slave)
(Slave) (Slave) (Slave)
(Slave) (Master)
(Master)

Copyright © 2009-2011 TTE Systems Ltd


23 Licensed to University of Leicester

Analogue inputs

20oC

15oC 25oC

10oC 30oC

7805

≤ +24v (DC) + 5v

0.1 uF 50 k pot 0-5v


To ADC
0
0

Copyright © 2009-2011 TTE Systems Ltd


24 Licensed to University of Leicester

Page 142
Analogue inputs vs. digital inputs

3000

2000 4000

1894
1000 5000

Up Down

Copyright © 2009-2011 TTE Systems Ltd


25 Licensed to University of Leicester

LPC2378’s DAC
 10-bit DAC.
 Resistor string architecture with buffered output.

 Can be used to reproduce analogue signals from samples


(e.g. Speech playback or audio signal processing, etc)

Copyright © 2009-2011 TTE Systems Ltd


26 Licensed to University of Leicester

Page 143
LPC2378’s Pulse width modulator
 1 x PWM block with timer/counter operation.
 7 match registers allow up to 6 single-edge or 3 double-edge
PWM outputs, or a mix of single and double edge signals.
 It is also possible to generate an interrupt, stop and / or reset
the timer on a match event.

 PWM is mainly used in power control but can be used as a


DAC if a low-pass filter is added to the PWM output.

Copyright © 2009-2011 TTE Systems Ltd


27 Licensed to University of Leicester

Analogue (PWM) outputs


“PWM” can be implemented in software
(low frequencies) or in hardware

PWM_PERIOD_G
PWM_G
PWM_position_G

if (PWM_position_G < PWM_G)


{
PWM_pin = PWM_ON;
}
else
{
PWM_pin = PWM_OFF;
}

Copyright © 2009-2011 TTE Systems Ltd


28 Licensed to University of Leicester

Page 144
Serial interfaces
 10/100 Ethernet Media Access Controller (MAC) with 16 kB
SRAM
 USB 2.0 Full speed device with 8 kB SRAM shared between
USB DMA and General-Purpose DMA (GPDMA)
 4 x UARTs
 1 x 2-channel CAN controller
 1 x SPI controller
 2 x SSP controllers
 3 x I2C interfaces
 1 x I2S (Inter IC Sound) interface with GPDMA

Copyright © 2009-2011 TTE Systems Ltd


29 Licensed to University of Leicester

LPC2378’s UARTs
 4 on-chip UARTs (UART0, 1, 2 and 3)
 Conform to 16C550 industry standard.
 16-byte receive and transmit FIFOs.
 Receive interrupt trigger points at 1, 4, 8 or 14 bytes.
 Fractional baud rate generator to gen. standard baud rate
(e.g. 115200) without using crystals of particular values.
 UART 1 equipped with standard modem interface signals with
full support for hardware flow control
 UART 3 includes an IrDA encoding / decoding mode to
support infrared communication.
 Can be used to communicate with serial device through wired
serial links or IrDA compliant links (UART 3)
Copyright © 2009-2011 TTE Systems Ltd
30 Licensed to University of Leicester

Page 145
LPC2378’s CAN controller
 Compatible with CAN specification 2.0B
 Two CAN controllers and buses with up to 1 Mbits/s data
rates.
 11-bit and 29-bit receive identifier supported
 Acceptance filter can provide automatic reception for selected
standard identifiers.

 CAN is used in Shared-Clock scheduling,


distributed real-time control, etc.

Copyright © 2009-2011 TTE Systems Ltd


31 Licensed to University of Leicester

LPC2378’s general purpose 32-bit timers


 4 x 32-bit timers (Timer 0, 1, 2 and 3)
 32-bit counters with programmable 32-bit prescalers.
 Selectable counter or timer operation.
 Up to four 32-bit capture channels per timer with the option of
generating an interrupt on a capture event.
 Four 32-bit match channels allowing generation of interrupt,
stopping the timer and / or resetting the timer, and optionally change
or toggle a corresponding output pin, on a match event.

 These versatile timers can be used to generate scheduler ticks


(interrupt and reset on match), measure the time between multiple
external events (capture with optional interrupt), etc.

Copyright © 2009-2011 TTE Systems Ltd


32 Licensed to University of Leicester

Page 146
Working with FPGAs:
Introduction

Copyright © 2009-2011 TTE Systems Ltd


33 Licensed to University of Leicester

History (and future?)

1 P1.0 VCC 40
2 P1.1 P0.0 39
3 P1.2 P0.1 38
4 P1.3 P0.2 37
5 P1.4 P0.3 36
6 P1.5 P0.4 35
7 P1.6 P0.5 34
8 P1.7 P0.6 33
‘8051’

9 RST P0.7 32
10 P3.0 / EA 31
11 P3.1 ALE 30
12 P3.2 / PSEN 29
13 P3.3 P2.7 28
14 P3.4 P2.6 27
15 P3.5 P2.5 26
16 P3.6 P2.4 25
17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
20 VSS P2.0 21

Copyright © 2009-2011 TTE Systems Ltd


34 Licensed to University of Leicester

Page 147
Why work with FPGAs?
 In order to build a processor which has a peripheral set which
matches your precise requirements (e.g. 5 digital inputs, 4
UARTs, etc)

 To add high-speed custom peripherals (e.g. ADC with large


buffer and FFT hardware – reduce CPU load).

 To “future proof” your design (If your current product uses


Microcontroller X, will you be able to buy this device in 5
years? In 10 years?)

 To ensure that processor (core) behaviour is predictable


(you select appropriate design features and you have access
to the full spec.)
Copyright © 2009-2011 TTE Systems Ltd
35 Licensed to University of Leicester

Example: TTE32-HR2
 Predictable processor core with 5-stage pipeline

Copyright © 2009-2011 TTE Systems Ltd


36 Licensed to University of Leicester

Page 148
An introduction to FPGAs

 Field Programmable Gate Arrays (FPGAs) allow the user


to use memory on a hardware device to store the require
device configuration: if we change the memory contents,
we change the device behaviour

 Using an FPGA, we can change the system “hardware” in a


manner which is very similar to the way in which we would
change the system software.

Copyright © 2009-2011 TTE Systems Ltd


37 Licensed to University of Leicester

How do we configure an FPGA


process (CLK)
begin
VHDL implementation
if CLK = ‘0’ and CLK’event of a flip flop
Q <= D;
endif;
end process;

reg Q;
always @ (negedge CLK)
Verilog implementation begin
of a flip flop
Q <= D;
end

Copyright © 2009-2011 TTE Systems Ltd


38 Licensed to University of Leicester

Page 149
RAM FPGAs
 Configuration data is stored in SRAM
 We need some form of Flash device (internal or external) to
store the configuration information
 We need to load the information from the Flash when the
FPGA is powered up

 The SRAM is vulnerable to radiation effects:


not generally used in passenger aircraft (for example).

Copyright © 2009-2011 TTE Systems Ltd


39 Licensed to University of Leicester

Flash FPGAs
 Configuration data is stored in Flash
 We don’t an external Flash device to store the FPGA
configuration
 We may still need an external Flash device to store program
code (for example, if our FPGA implements a microcontroller)

 The Flash is less vulnerable to radiation effects:


these devices are used in passenger aircraft (for example).

Copyright © 2009-2011 TTE Systems Ltd


40 Licensed to University of Leicester

Page 150
Anti-fuse FPGAs
 Configuration data is stored in “fuses”
 CAN ONLY BE PROGRAMMED ONCE!
 Not cheap!

 Very high immunity to radiation effects:


these devices are used in space (for example).

Copyright © 2009-2011 TTE Systems Ltd


41 Licensed to University of Leicester

Implications of a move from 8- to 32-bit platforms:


A. Additional memory and CPU performance

Copyright © 2009-2011 TTE Systems Ltd


42 Licensed to University of Leicester

Page 151
Implications of improved CPU performance
 Increased CPU performance gives more flexibility when
we wish to create reliable systems using portable code
 Much easier to apply simple TTC designs!

ARM ~50 MIPS

8051 ~0.5 MIPS

Copyright © 2009-2011 TTE Systems Ltd


43 Licensed to University of Leicester

What’s wrong with sEOS?


Water void WASHER_Update(void)
Valve
{
Water
Heater switch (System_state_G)
Start {
Switch
Water case INIT:
Pump
Selector
Dial case START:
Washing Drum
Machine Motor
Water Controller case FILL_DRUM:
Level
Sensor
LED
indicators case HEAT_WATER:
Temperature
Sensor
Door
case WASH_01:
lock

...
Detergent }
Hatch
}

(Interrupt)

1 ms timer

Copyright © 2009-2011 TTE Systems Ltd


44 Licensed to University of Leicester

Page 152
What’s wrong with sEOS?
 All code ends up in one ISR void WASHER_Update(void)
{

 Difficult to maintain / re-use code switch (System_state_G)


{
(e.g. 30-page switch statement) case INIT:

 Minimal separation between case START:

OS and task set case FILL_DRUM:

case HEAT_WATER:
 What happens if the task overruns?
case WASH_01:

...
 There are better solutions … }
}

(Interrupt)

1 ms timer

Copyright © 2009-2011 TTE Systems Ltd


45 Licensed to University of Leicester

Introducing a complete TTC scheduler


 Builds upon the functionality of sEOS
 Still maintains co-operative time-triggered task executions.
 Supports execution of multiple periodic tasks with different
periods and different initial delays (different phases)

 Moves the execution of the user tasks out of the Timer ISR:
– Greater task independence (easier to re-use / recycle)
– Can detect if a task overruns

 Still easy to understand with limited resources

Copyright © 2009-2011 TTE Systems Ltd


46 Licensed to University of Leicester

Page 153
TTC functions and data structures
 Task array
 Initialisation function
 Start function
 Update function
Further information:
 Dispatcher function
 Sleep function
 Add task function
 Delete task function

Copyright © 2009-2011 TTE Systems Ltd


47 Licensed to University of Leicester

Task array: SCH_tasks

...

sTask_t SCH_tasks[SCH_MAX_TASKS];

...

typedef struct
{
// Pointer to the task (must be a 'void (void)' function)
void (*pTask) (void);

// Delay (ticks) until the function will (next) be run


// - see SCH_Add_Task() for further details
uint32_t Delay;

// Interval (ticks) between subsequent runs.


// - see SCH_Add_Task() for further details
uint32_t Period;
} sTask_t;

Copyright © 2009-2011 TTE Systems Ltd


48 Licensed to University of Leicester

Page 154
Initialisation function: SCH_Init()
void SCH_Init(const uint32_t tick_us)
{
uint8_t index;

for (index = 0; index < SCH_MAX_TASKS; index++)


{
SCH_Delete_Task(index);
}

Tick_count = 0;
System_time = 0;

Stack_Ptr = (uint32_t*)&Stack_G;

// Primitive check for user and interrupt stack overflow


TTE_DEBUG_ASSERT(Stack_Ptr[INT_Stk_Off] == INT_Stk_Val);
TTE_DEBUG_ASSERT(Stack_Ptr[USR_Stk_Off] == USR_Stk_Val);

System_Tick_Init(tick_us);

Tick_interval = tick_us;
}

Copyright © 2009-2011 TTE Systems Ltd


49 Licensed to University of Leicester

Add task function: SCH_Add_Task()


uint8_t SCH_Add_Task(void(* pFunction)(), const uint32_t delay, const uint32_t period)
{
uint8_t index = 0;

// First find a gap in the array (if there is one)


while ((SCH_tasks[index].pTask != 0) && (index < SCH_MAX_TASKS))
{
index++;
}

// Have we reached the end of the list?


if (index == SCH_MAX_TASKS)
{
// Also return an error code
return SCH_MAX_TASKS;
}

// If we're here, there is a space in the task array


SCH_tasks[index].pTask = pFunction;

SCH_tasks[index].Delay = delay + 1;
SCH_tasks[index].Period = period;

return index; // return position of task (to allow later deletion)


}

Copyright © 2009-2011 TTE Systems Ltd


50 Licensed to University of Leicester

Page 155
Start function: SCH_Start()
void SCH_Start(void)
{
#ifdef TTE_PROVIDE_TIMING
LOG_Init();
#endif

Sys_Tick_Int_Flag_Reset();
Select_System_Interrupt(SYS_TICK_SOURCE);
Enable_System_Interrupt(SYS_TICK_SOURCE);
Enable_Interrupts();
System_Scheduler_Start();
}

Copyright © 2009-2011 TTE Systems Ltd


51 Licensed to University of Leicester

Update function: SCH_Update()


void SCH_Update(void)
{
// Note that an interrupt has occurred
Tick_count++;

// Increase the global system time


System_time++;

#ifdef TTE_PROVIDE_TIMING
LOG_Check_Finished(System_time);
#endif

// After interrupt, reset interrupt flag


Sys_Tick_Int_Flag_Reset();
}

Copyright © 2009-2011 TTE Systems Ltd


52 Licensed to University of Leicester

Page 156
Dispatcher function: SCH_Dispatch_Tasks()
void SCH_Dispatch_Tasks(void)
{
uint32_t index;
uint32_t update_required = 0;

// Disable system interrupt


Disable_Interrupts();

if (Tick_count > 0)
{
Tick_count--;
update_required = 1;
}

// Re-enable system interrupts


Enable_Interrupts();

...

Copyright © 2009-2011 TTE Systems Ltd


53 Licensed to University of Leicester

Dispatcher function: SCH_Dispatch_Tasks()


while (update_required)
{
// Go through the task array
for (index = 0; index < SCH_MAX_TASKS; index++)
{
// Check if there is a task at this location
if (SCH_tasks[index].pTask)
{
if (--SCH_tasks[index].Delay == 0)
{
// The task is due to run
(*SCH_tasks[index].pTask)(); // Run the task
// Simple check for user and interrupt stack overflow
// The 'index' variable should show you which task did it!
TTE_DEBUG_ASSERT(Stack_Ptr[INT_Stk_Off] == INT_Stk_Val);
TTE_DEBUG_ASSERT(Stack_Ptr[USR_Stk_Off] == USR_Stk_Val);
if (SCH_tasks[index].Period != 0)
{
// Schedule period tasks to run again
SCH_tasks[index].Delay = SCH_tasks[index].Period;
}
else
{
// Delete one-shot tasks
SCH_tasks[index].pTask = 0;
}
}
}
}

Copyright © 2009-2011 TTE Systems Ltd


54 Licensed to University of Leicester

Page 157
Dispatcher function: SCH_Dispatch_Tasks()
// Disable system interrupt
Disable_Interrupts();

if (Tick_count > 0)
{
Tick_count--;
update_required = 1;
}
else
{
update_required = 0;
}

// Re-enable system interrupts


Enable_Interrupts();
}

// The scheduler may enter idle mode at this point (if used)
SCH_Go_To_Sleep();
}

Copyright © 2009-2011 TTE Systems Ltd


55 Licensed to University of Leicester

Sleep function: SCH_Go_To_Sleep()


void SCH_Go_To_Sleep()
{
#ifdef TTE_PROVIDE_TIMING
Disable_Interrupts();
if (!In_idle)
{
In_idle = TRUE;
// The idle task is special and should not be in the task array!
LOG_Time(LOG_TASK_START, SCH_MAX_TASKS);
}
Enable_Interrupts();
#endif

// Lots of further power saving that can be done ...


// - see user manual
System_Scheduler_Sleep();
}

Copyright © 2009-2011 TTE Systems Ltd


56 Licensed to University of Leicester

Page 158
Delete task function: SCH_Delete_Task()
int SCH_Delete_Task(const uint32_t task_index)
{
int return_code;

// Check for valid task pointer...


if (task_index >= SCH_MAX_TASKS)
{
// Invalid - exit and return error
Error_code = ERROR_SCH_CANNOT_DELETE_TASK;

return (RETURN_ERROR);
}

if (SCH_tasks[task_index].pTask == 0)
{
// ...also return an error code
return_code = RETURN_ERROR;
}
else
{
return_code = RETURN_NORMAL;
}

SCH_tasks[task_index].pTask = 0x0000;
SCH_tasks[task_index].Delay = 0;
SCH_tasks[task_index].Period = 0;

return return_code; // return status


}

Copyright © 2009-2011 TTE Systems Ltd


57 Licensed to University of Leicester

Using TT Cooperative Scheduler


 Phase 1 – Initialisation
1. Scheduler is initialised by the SCH_Init function.
2. Tasks are added to the task set using SCH_Add_Task
function.
3. Scheduler is started using the SCH_Start function.

 Phase 2 – Normal operation


1. Dispatcher SCH_Dispatch_Tasks is called in a while(1) loop.
2. After running all tasks scheduled to run in a tick, the
scheduler puts the system into sleep.

Copyright © 2009-2011 TTE Systems Ltd


58 Licensed to University of Leicester

Page 159
TTC considerations: Task execution sequence
 If multiple tasks have to run in the same tick, the sequence is
determined by the order in which the tasks are stored in the
task array
– By varying the task sequence, different algorithms can be implemented

 If the scheduler is not overloaded, the (start) jitter for a given


task depends on:
– The scheduler overheads (small and predictable);
– The execution times of other tasks running before it in the same tick.

Copyright © 2009-2011 TTE Systems Ltd


59 Licensed to University of Leicester

TTC considerations: Task execution time


 Ideally, sum of WCET of all tasks set to run in a tick should be
less than the tick period.
 However, if the sum of execution times of the tasks running in
the same tick is more than the tick period (transient overload):
– Scheduler will finish running the tasks in the current tick in their order
before continuing to the tasks in the next tick.
– Scheduler will be able to catch up if there is sufficient slack in
subsequent ticks.
– System will meet specifications if no deadlines are missed.

Copyright © 2009-2011 TTE Systems Ltd


60 Licensed to University of Leicester

Page 160
Implications of a move from 8- to 32-bit platforms:
B. Debugging capabilities

Copyright © 2009-2011 TTE Systems Ltd


61 Licensed to University of Leicester

Debugging basics
 Debugging is the process of trying to find and remove logical
errors from software.
 The programmer has access to debugging tools that allow the
program execution to be stopped and the system state to be
examined.

 Typical debugger controls:


– Program execution control (stepping and running through code)
– Break points (execution halts when a break point is hit)
– Memory / variable watch (checking and changing the contents of
memory locations)

Copyright © 2009-2011 TTE Systems Ltd


62 Licensed to University of Leicester

Page 161
Introduction to JTAG
 Joint Test-Action Group was formed in the 1980s by the
makers and users of components and boards.
 Their proposal was adopted by IEEE as the IEEE Standard
1149.1 in 1990.
 JTAG was initially developed to help test the connections on
printed circuit boards without using “bed of nails” test setup.
 Current uses also include:
– Storing / updating firmware
– Debugging embedded software
 Most modern microcontrollers (ARM, Cortex, MIPS, etc) have
JTAG ports built in.
* Amontec application note JTAG Interface: Simple Introduction. http://www.amontec.com/pub/amt_ann004.pdf
* JTAG Technoligies, http://www.jtag.com/en/About/History

Copyright © 2009-2011 TTE Systems Ltd


63 Licensed to University of Leicester

JTAG internals
 The JTAG standard specifies the
following components in
supporting devices:
– Test access port controller (TAP)
– Scan instruction register
– Scan data registers

 JTAG interface uses the following


signals:
– TCK – Test clock http://www.jtag.com/en/Learn/Standards/IEEE_1149.1

– TMS – Test mode select


– TDI – Test data in
– TDO – Test data out
– TRST – Test reset (optional)
Copyright © 2009-2011 TTE Systems Ltd
64 Licensed to University of Leicester

Page 162
Example: JTAG and ARM7TDMI-S

Copyright © 2009-2011 TTE Systems Ltd


65 Licensed to University of Leicester

Example: JTAG and ARM7TDMI-S


 In the ARM7, JTAG port interfaces
with the Embedded ICE module
through scan chains.
 The Embedded ICE module
provides:
1. Debug control and status registers.
2. Two watchpoint units that allow the
system to enter debug state when
either a certain address is executed
(breakpoint), or a certain memory
location is accessed / modified
(watchpoint).
* ARM7TDMI-S Technical Reference Manual,
http://infocenter.arm.com/help/topic/com.arm.doc.ddi
0084f/DDI0084.pdf

Copyright © 2009-2011 TTE Systems Ltd


66 Licensed to University of Leicester

Page 163
Example: Why we need timing analysis
“A real-time computer system is a computer system in which the
correctness of the system behaviour depends not only on the logical results
of the computations, but also on the physical instant at which these results
are produced.”
Source: Kopetz, H., “Real-Time Systems: Design Principles for Distributed Embedded Applications”,
(Kluwer Academic Publishers, 2002)

Copyright © 2009-2011 TTE Systems Ltd


67 Licensed to University of Leicester

Example: Timing analysis

Copyright © 2009-2011 TTE Systems Ltd


68 Licensed to University of Leicester

Page 164
Completing your 32-bit design

Copyright © 2009-2011 TTE Systems Ltd


69 Licensed to University of Leicester

Completing your 32-bit design


 So far we’ve:
– Looked at the implications of jitter in RT systems
– Looked at the implications of a move to 32-bit processors, incl.
 Higher CPU performance and more memory
 Enhanced set of hardware “peripherals” (e.g. “intelligent” UARTs)
 Enhanced debug support (including JTAG support)

– Introduced a multi-task TTC scheduler (easy on a 32-bit target)


– Explored the need for timing analysis in RT embedded systems
(and seen how this too is supported on high-end targets)

 We’ll now consider how to complete your design with a


watchdog timer and heartbeat LED …

Copyright © 2009-2011 TTE Systems Ltd


70 Licensed to University of Leicester

Page 165
Working with watchdog timers

Copyright © 2009-2011 TTE Systems Ltd


71 Licensed to University of Leicester

The watchdog analogy


 Suppose there is a hungry dog guarding a house, and
someone wishes to break in .
 If, during the burglary, an accomplice repeatedly throws the
guard dog small pieces of meat, then the animal will be so
busy concentrating on the food that he will ignore his guard
duties, and will not bark.
 However, if the accomplice run out of meat
or forgets to feed the dog for some other
reason, the animal will start barking,
thereby alerting the neighbours, property
occupants or police.

Copyright © 2009-2011 TTE Systems Ltd


72 Licensed to University of Leicester

Page 166
Working with watchdog timers
 “Watchdog timers” typically operate as follows:
– The timer must be refreshed at regular, well-defined, intervals.

If the timer is not refreshed at the required time it will overflow, an


process which will usually cause the associated microcontroller to be
reset.

– When starting up, the microcontroller can determine the cause of


the reset.

That is, it can determine if it has been started ‘normally’, or re-started


as a result of a watchdog overflow. This means that, in the latter case,
the programmer can ensure that the system will try to handle the error
that caused the watchdog overflow.

Copyright © 2009-2011 TTE Systems Ltd


73 Licensed to University of Leicester

Working with watchdog timers


 Watchdogs can provide a ‘last resort’ form of error recovery.
If you think of the use of watchdogs in terms of ‘if all else fails,
then we’ll let the watchdog reset the system’, you are taking a
realistic view of the capabilities of this approach.

 Used without due care at the design phase and / or adequate


testing, watchdogs can reduce the system reliability
dramatically. In particular, in the presence of sustained faults,
badly-designed watchdog “recovery” mechanisms can cause
your system to reset itself repeatedly:
this can be very dangerous.

Copyright © 2009-2011 TTE Systems Ltd


74 Licensed to University of Leicester

Page 167
LPC2378’s Watchdog timer
 Can be enabled by software but disabled only after a reset
or watchdog interrupt.
 Incorrect / incomplete feed can be programmed to generate a
reset or interrupt.
 Selectable time period from (Tcy(WDCLK) x 256 x 4) to (Tcy(WDCLK)
x 232 x 4) in multiples of (Tcy(WDCLK) x 4).
 Watchdog clock source can be selected from RTC clock,
internal RC oscillator or APB peripheral clock for
wide range of timing possibilities as well as keeping the
watchdog operational in power-reduction modes.

Copyright © 2009-2011 TTE Systems Ltd


75 Licensed to University of Leicester

Adding a “Heartbeat LED”

Copyright © 2009-2011 TTE Systems Ltd


76 Licensed to University of Leicester

Page 168
Heartbeat LED
Problem
How can you tell, at a glance, that the system is “alive”?
Solution
Include a task that flashes a ‘heartbeat LED’ every time you implement an
embedded system.

Source: Adapted from Heartbeat LED in Mwelwa, C. and Pont, M.J., “Two simple patterns to support the development of
reliable embedded systems”, Presented at VikingPLoP 2003 (Bergen, Norway), September 2003.

Copyright © 2009-2011 TTE Systems Ltd


77 Licensed to University of Leicester

Working with high-end hardware:


Running a TTC scheduler on an embedded PC

Copyright © 2009-2011 TTE Systems Ltd


78 Licensed to University of Leicester

Page 169
Running TTC software on an Intel® Atom
 The development board we will
be using is the
Gigabyte GA-GC230D
 This board has a 1.6 GHz Atom
230 integrated with an 945GC
chipset, 512MB of L2 Cache and
RAM
 The 954GC chipset includes the
ICH-7 I/O controller and GMA-
950 graphics interface

Copyright © 2009-2011 TTE Systems Ltd


79 Licensed to University of Leicester

Boot sequence for the Atom board


 After power on, the system first boots from BIOS (4MB Flash, etc);
 BIOS then searches for a valid mass-storage device
(signature bytes 0x55 and 0xAA at end of the first boot sector);
 A Syslinux bootloader is placed on the boot sector of the flash drive
(and run by the BIOS);
[Note: we are not running Linux – we simply use the same bootloader]

 By default, the linker script copies the binary into high memory
(0x1000000) before execution.

Copyright © 2009-2011 TTE Systems Ltd


80 Licensed to University of Leicester

Page 170
Input and output (Overview)
 Our development boards have the following I/O capabilities:
– LPT Parallel Port
– RS-232

– VGA / Audio Output


– Keyboard / Mouse

– USB Serial Ports


– 10/100 Mbit/sec Ethernet

Copyright © 2009-2011 TTE Systems Ltd


81 Licensed to University of Leicester

Input and output (LPT1)


 Since 1981, most PCs have had a 25-pin D-type connector on
the rear panel.
 This provides a connection to the “parallel port” (or “printer port”)
and was originally used to connect to a printer
(Centronics protocol).
 This is “Line Print Terminal 1” (LPT1)

 In embedded designs, this can serve as a simple GPIO port.

Copyright © 2009-2011 TTE Systems Ltd


82 Licensed to University of Leicester

Page 171
Input and output (LPT1)

13 1

25 14

Pin Label Input / Output Pin Pin Label Input / Output Pin
1 /Strobe Input / Output 10 /Ack Input
2 Data 0 Input / Output 11 Busy Input
3 Data 1 Input / Output 12 Paper Input
4 Data 2 Input / Output 13 Online Input
5 Data 3 Input / Output 14 /AF Input / Output
6 Data 4 Input / Output 15 /Error Input
7 Data 5 Input / Output 16 Initialise Input / Output
8 Data 6 Input / Output 17 /Select Input / Output
9 Data 7 Input / Output 18-25 Ground -

Pin connections for the PC’s parallel port (diagram shows the 25-pin DB25 socket, viewed from the outside).

Copyright © 2009-2011 TTE Systems Ltd


83 Licensed to University of Leicester

Conclusions

Copyright © 2009-2011 TTE Systems Ltd


84 Licensed to University of Leicester

Page 172
Conclusion
 Today we have:
– Looked at the implications of jitter in RT systems
– Looked at the implications of a move to 32-bit processors, incl.
 Higher CPU performance and more memory
 Enhanced set of hardware “peripherals” (e.g. “intelligent” UARTs)
 Enhanced debug support (including JTAG support)

– Introduced a multi-task TTC scheduler (easy on a 32-bit target)


– Explored the need for timing analysis in RT embedded systems
– Reviewed the basic use of WDTs and “Heartbeat” LEDs

– See that we can run TTC architectures on high-end platforms too


(and considered the fact that timing analysis on such platforms can be
challenging)
– Consider how we can design and implement our own processors, if we
want to take complete control.

Copyright © 2009-2011 TTE Systems Ltd


85 Licensed to University of Leicester

Thinking allowed …
 Suppose that we were to compare 1000 embedded systems:
– 500 systems will be based on 8-bit processors
– 500 systems will be based on 32-bit processors

 On average, would you expect the 8-bit or 32-bit systems to


be more reliable?

Copyright © 2009-2011 TTE Systems Ltd


86 Licensed to University of Leicester

Page 173
Appendix
(Timing and jitter)

Copyright © 2009-2011 TTE Systems Ltd


87 Licensed to University of Leicester

Why timing matters: Background


 Suppose we have an analogue signal in the range 0 – 10V

 If we use an 8-bit ADC to sample this signal,


the resolution will be 10 / (28 – 1) = 39 mV
 If we use a 12-bit ADC to sample this signal,
the resolution will be 10 / (212 – 1) = 2.44 mV

Copyright © 2009-2011 TTE Systems Ltd


88 Licensed to University of Leicester

Page 174
Why timing matters: Jitter
S ig n a l a m p litu d e ( V o lts )

∆ t ∆ v

T im e

It is known that:
v ( t ) = A sin( 2π ft )
∆V dv

∆t dt
Also:
dv
= 2π fA cos( 2π ft )
dt

Copyright © 2009-2011 TTE Systems Ltd


89 Licensed to University of Leicester

Why timing matters: Jitter


At t = 0:
dv
= 2π fA
dt

Assuming a signal is being sampled at the maximum amplitude (AFS), using an N-bit ADC:
AFS = 2 N z
where z is the ADC “step size” (lsb).

Then:
dv
= 2π fAFS
dt

Thus:
∆ V = 2π f ∆ tAFS

If the jitter is to have no measurable impact, we need to ensure that it has an amplitude < z / 2.

This implies that ∆t must satisfy this condition:


1 1
∆t < ⋅
2 N 2π f

Otherwise, jitter will cause sampling data loss.

Copyright © 2009-2011 TTE Systems Ltd


90 Licensed to University of Leicester

Page 175
All my own work
 The following individuals contributed to the material and slides
presented in this session:
– Musharraf Hanif (University of Leicester)
– Devaraj Ayavoo (TTE Systems Ltd)
– Zemian Hughes (TTE Systems Ltd)
– Peter Vidler (TTE Systems Ltd)
– Muhammad Waqas Raza (TTE Systems Ltd)
– Keith Athaide (TTE Systems Ltd)
– Anjali Das (TTE Systems Ltd)
– Michael Short (Teesside University)

Copyright © 2009-2011 TTE Systems Ltd


91 Licensed to University of Leicester

Page 176
Day 4: Multi-tasking systems

Michael J. Pont

MSc in Reliable Embedded Systems


Module EG7510 (“A1a”)

Introduction and review

Copyright © 2009-2011 TTE Systems Ltd


2 Licensed to University of Leicester

Page 177
The story so far …
 Seminar 1:
– Introduction to embedded systems, super loops and the “8051”;
– A first look at software architectures for embedded systems;
– A first look at techniques required to meet RT constraints.

 Seminar 2:
– TTC concepts and sEOS;
– Creating multi-state systems;
– Executing sequences of functions;
– Dealing with “long tasks” (without resorting to pre-emption);
– MISRA C.

Copyright © 2009-2011 TTE Systems Ltd


3 Licensed to University of Leicester

The story so far …


 Seminar 3:
– The implications of jitter in RT systems
– The implications of a move to 32-bit processors, incl.
 Higher CPU performance and more memory
 Enhanced set of hardware “peripherals” (e.g. “intelligent” UARTs)
 Enhanced debug support (including JTAG support)

– A multi-task TTC scheduler (easy on a 32-bit target)


– The need for timing analysis in RT embedded systems
– The basic use of WDTs and “Heartbeat” LEDs

– Running TTC architectures on high-end hardware platforms


 Timing analysis on such platforms can be challenging
– Consider how we can design and implement our own processors
 If we want to take complete control

Copyright © 2009-2011 TTE Systems Ltd


4 Licensed to University of Leicester

Page 178
The story so far …

At last! We’ve moved from 8-


At last! We’ve moved from 8-
bit to 32-bit processors –
bit to 32-bit processors –
now we can get rid of that
now we can use a full TTC
TTC scheduler and run a full
scheduler!
RTOS or Linux!

Copyright © 2009-2011 TTE Systems Ltd


5 Licensed to University of Leicester

Simple TTC designs: The “long task problem” …

It’s easy to think up task sets which can’t be scheduled using a TTC architecture …

A A A A ...
Time

B ...
Time

Copyright © 2009-2011 TTE Systems Ltd


6 Licensed to University of Leicester

Page 179
Example: Using an appropriate task structure (RS-232)

Current core temperature All characters copied to buffer


is 36.678 degrees (fast operation)

Buffer (character array)

Schedule a task to send one character


from the buffer every 10 ms (for example)

Copyright © 2009-2011 TTE Systems Ltd


7 Licensed to University of Leicester

Sometimes we need to support task pre-emption


 If possible, system should use TTC tasks:
– Lower overheads (therefore lower unit costs)
– Greater predictability (therefore shorter testing times & higher reliability)
– Ease of certification (where required)

 With appropriate design approaches, we can often reduce the


number of designs which require task pre-emption
… but few developers manage to spend their working life
without having to employ pre-emption at some point

Copyright © 2009-2011 TTE Systems Ltd


8 Licensed to University of Leicester

Page 180
Day 4 Outline
 We’ll consider:
– The challenges of full “ET multi-tasking” designs
– Time-triggered “hybrid” schedulers (the best of both worlds?)
– Working with multiple processors (distributed systems)

Copyright © 2009-2011 TTE Systems Ltd


9 Licensed to University of Leicester

Use of a standard RTOS in reliable embedded


systems: Issues and challenges

Copyright © 2009-2011 TTE Systems Ltd


10 Licensed to University of Leicester

Page 181
Priority-based pre-emptive scheduling

“Input”
H
M Time
L

“Output”

Copyright © 2009-2011 TTE Systems Ltd


11 Licensed to University of Leicester

Challenges caused by shared resources

A ADC

C UART

E Shared data

Copyright © 2009-2011 TTE Systems Ltd


12 Licensed to University of Leicester

Page 182
Mutual exclusion
 Two semaphore options to consider:
– Basic (binary) semaphores
– Counting semaphores

 The other main option is a “mutex”


– A form of semaphore which is linked to a specific task

Copyright © 2009-2011 TTE Systems Ltd


13 Licensed to University of Leicester

Priority inversion
 We need semaphores (etc) to help us to avoid “train crashes”
(e.g. two tasks fighting over the same ADC)

 In any priority-based system, we then have the risk of


“priority inversion” (and related problems of deadlock and
chained blocking)

 We therefore need to consider algorithms such as priority


inheritance, priority ceiling, priority ceiling emulation, etc

Copyright © 2009-2011 TTE Systems Ltd


14 Licensed to University of Leicester

Page 183
Priority inversion (example)
 This is what we want to happen …

Priority N Normal Code


ADC

C Critical Section

P TaskH N C N

PTaskL N C C N

t1 t2 t3 t4 t5

Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).

Copyright © 2009-2011 TTE Systems Ltd


15 Licensed to University of Leicester

Priority inversion (example)


 This is what happens (bounded priority inversion) …

Priority B Blocked N Normal Code

C Critical Section

PTaskH N B C N

PTaskL N C C N

t1 t2 t3 t4 t5 t6 t7

Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).

Copyright © 2009-2011 TTE Systems Ltd


16 Licensed to University of Leicester

Page 184
Priority inversion (example)
 It gets worse as we add more tasks (unbounded pi) …

Priority B Blocked N Normal Code C Critical Section

P TaskH N B RESET

N
PTaskM

N C C
PTaskL
t1 t2 t3 t4 t5 t6 t7

Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).

Copyright © 2009-2011 TTE Systems Ltd


17 Licensed to University of Leicester

From priority inversion to deadlock (example)


 PI isn’t the only potential problem …
 This is what we want:
Priority N Normal Code

C2 Critical Section2

P TaskH C1 Critical Section1


N C1 C2 C1 N

P TaskL N C2 C2 C1 C2 N

t1 t2 t3 t4 t5 t6 t7

Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).

Copyright © 2009-2011 TTE Systems Ltd


18 Licensed to University of Leicester

Page 185
From priority inversion to deadlock (example)
 This is what happens …

Priority B Blocked C1 Critical Section1 C2 Critical Section2 N Normal Code

Require C2 locked by TaskL

Dead Lock
P TaskH N C1 B

C2 still locked
Require C1 locked by TaskH
PTaskL N C2 C2

t1 t2 t3 t4 t5 t6 t7

Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).

Copyright © 2009-2011 TTE Systems Ltd


19 Licensed to University of Leicester

Dealing with deadlock


 Applying the priority ceiling emulation protocol

Priority Blocked Critical Section1 Critical Section2 Normal Code


B C1 C2 N

Adapted from:
Wang, H., Pont, M.J.
and Kurian, S. (2007)
“Patterns which help to
avoid conflicts over
shared resources in
B N C1 C2 C1 N time-triggered
PTaskH embedded systems
which employ a pre-
emptive scheduler”
Paper presented at the
12th European
DPTaskL= C2 C2 C1 C2 Conference on Pattern
Languages of
PTaskH Programs (EuroPLoP
2007).

P TaskL N N

t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11

Copyright © 2009-2011 TTE Systems Ltd


20 Licensed to University of Leicester

Page 186
Priority inversion presents real challenges
 When we have to deal with resource conflicts at run time, the
system behaviour becomes much more difficult to predict

 Eg: When will our “high priority” task take the sample ..?

Signal amplitude (Volts)

∆t ∆v

Time

Copyright © 2009-2011 TTE Systems Ltd


21 Licensed to University of Leicester

Priority inversion presents real challenges


 Even NASA gets it wrong …

Problems with the Mars Pathfinder mission in 1997


were caused by priority inversion

Copyright © 2009-2011 TTE Systems Ltd


22 Licensed to University of Leicester

Page 187
Challenges with a dynamic RTOS
 Real systems have shared
resources
A ADC
 When we don’t know when
B
tasks will be pre-empted, we
C UART
need semaphores, which
D
means we need to address
priority inversion, etc E Shared data

 If you need predictable


behaviour, be prepared to
spend a lot of time doing
system testing (and then keep
your fingers crossed …)

Copyright © 2009-2011 TTE Systems Ltd


23 Licensed to University of Leicester

TT solutions

Copyright © 2009-2011 TTE Systems Ltd


24 Licensed to University of Leicester

Page 188
Advantages of a time-triggered RTOS

ADC UART

A B C D E ...
Time

Either:
“Global” variables - No conflicts (co-operative design)
- Predict (and avoid) conflicts
where pre-emption is employed
(TRAP protocols)

Copyright © 2009-2011 TTE Systems Ltd


25 Licensed to University of Leicester

Minimising the use of interrupts

TT systems
A “safe subset”

“Event triggered” systems


with multiple interrupt sources

Copyright © 2009-2011 TTE Systems Ltd


26 Licensed to University of Leicester

Page 189
Dynamic (ET) RTOS vs. Static (TT) RTOS

Verification
effort

TT

ET

System size
Copyright © 2009-2011 TTE Systems Ltd
27 Licensed to University of Leicester

Dynamic (ET) RTOS vs. Static (TT) RTOS

 Conventional RTOS
– “My door is always open …”
ET
– Easy to build but …
… difficult to predict behaviour (test, etc)
– Scalability is a concern

 Time-triggered RTOS
– “Please make an appointment with my secretary …”
TT
– Predictable behaviour (easy to test) but …
… can be more challenging to build
– Highly scalable

Copyright © 2009-2011 TTE Systems Ltd


28 Licensed to University of Leicester

Page 190
The TTH scheduler

Copyright © 2009-2011 TTE Systems Ltd


29 Licensed to University of Leicester

An alternative to a to fully pre-emptive scheduler


 Using a limited pre-emption (limited multitasking) architecture:
– One “high priority” pre-empting task
(immediately avoid many of the key challenges with priority inversion)
– Multiple “low priority” co-operative tasks
 It is possible to:
– Achieve low overheads (processing and memory).
– Achieve rapid responses to external events.
– With careful design, similar reliability as a (pure) co-operative
scheduler can be obtained.

 In implementation terms, the main difference between


TTC and TTH schedulers is the timer ISR.

Copyright © 2009-2011 TTE Systems Ltd


30 Licensed to University of Leicester

Page 191
The TTH scheduler
 A TTH scheduler provides limited multi-tasking capabilities
 Operation:
– Supports any number of co-operatively-scheduled tasks
– Supports a single pre-empting task (which can interrupt the co-operative
tasks)
 Implementation:
– The scheduler is simple, and can be implemented in a small amount of
code.
– The scheduler must allocate memory for - at most - two tasks at a time.
– The scheduler will generally be written entirely in a high-level language
(such as ‘C’).
– The scheduler is not a separate application; it becomes part of the
developer’s code
 Performance:
– Rapid responses to external events can be obtained.
 Reliability and safety:
– With careful design, can be as reliable as a (pure) co-operative scheduler.

Copyright © 2009-2011 TTE Systems Ltd


31 Licensed to University of Leicester

The time-triggered hybrid (TTH) scheduler


Interrupt

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9
t (ms)
Interrupt

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9

Co-operative task
t (ms)
Pre-empting task

Copyright © 2009-2011 TTE Systems Ltd


32 Licensed to University of Leicester

Page 192
Difference between fully pre-emptive and hybrid
 A common way to use shared resources is to set a lock on
them before accessing them. The simple check and lock code
works on the hybrid scheduler but can fail in a fully pre-
emptive environment (priority inheritance).
#define UNLOCKED 0
#define LOCKED 1

bit Lock; // Global lock flag

// ...

// Ready to enter critical section


// - Wait for lock to become clear
// (FOR SIMPLICITY, NO TIMEOUT CAPABILITY IS SHOWN)
while(Lock == LOCKED);

// Lock is clear
// Enter critical section
A
// Set the lock
Lock = LOCKED;

// CRITICAL CODE HERE //

// Ready to leave critical section


// Release the lock
Lock = UNLOCKED;

// ...

Copyright © 2009-2011 TTE Systems Ltd


33 Licensed to University of Leicester

Differences between TTC and TTH code


 The main difference is in the scheduler update function
 The pre-empting task’s info is not added into the task array
but is (usually) kept separate.
 Minor changes in the initialisation and add task functions to
initialise and add pre-empting tasks.

Copyright © 2009-2011 TTE Systems Ltd


34 Licensed to University of Leicester

Page 193
Task information storage

...

sTask_t SCH_tasks[SCH_MAX_TASKS];
static sTask_t SCH_pTask;

...

typedef struct
{
// Pointer to the task (must be a 'void (void)' function)
void (*pTask) (void);

// Delay (ticks) until the function will (next) be run


// - see SCH_Add_Task() for further details
uint32_t Delay;

// Interval (ticks) between subsequent runs.


// - see SCH_Add_Task() for further details
uint32_t Period;
} sTask_t;

Copyright © 2009-2011 TTE Systems Ltd


35 Licensed to University of Leicester

Modified scheduler update


void SCH_Update(void)
{
Tick_count++; // Note that an interrupt has occurred
System_time++; // Increase the global system time
Scheduler_Started = TRUE;

// Check the preemptive task exists


if (SCH_pTask.pTask)
{

// Check to see if it is due to run


if (--SCH_pTask.Delay == 0)
{
(*SCH_pTask.pTask)(); // Run the preemptive task

// If the task is periodic, set it to run again


if (SCH_pTask.Period)
{
SCH_pTask.Delay = SCH_pTask.Period; // Schedule regular tasks to run again
}
}
}
Sys_Tick_Int_Flag_Reset(); // After interrupt, reset interrupt flag
}

Copyright © 2009-2011 TTE Systems Ltd


36 Licensed to University of Leicester

Page 194
A closer look at jitter issues for TTH designs

Copyright © 2009-2011 TTE Systems Ltd


37 Licensed to University of Leicester

The time-triggered hybrid (TTH) scheduler


Interrupt

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9
t (ms)
Interrupt

t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9

Co-operative task
t (ms)
Pre-empting task

Copyright © 2009-2011 TTE Systems Ltd


38 Licensed to University of Leicester

Page 195
Jitter due to variable instruction lengths
Interrupt service
(fixed service time)
Interrupt

Processor in sleep mode

Interrupt service
Interrupt

Inst Inst Inst Inst Inst Inst

Interrupt service
Interrupt

Inst Inst Inst Inst Inst Inst

Copyright © 2009-2011 TTE Systems Ltd


39 Licensed to University of Leicester

Jitter assessment in TTH and TTHj schedulers

From:
Maaita, A. and Pont, M.J. (2005) “Using
‘planned pre-emption’ to reduce levels of task
jitter in a time-triggered hybrid scheduler”.
In: Koelmans, A., Bystrov, A., Pont, M.J., Ong,
R. and Brown, A. (Eds.), Proceedings of the
Second UK Embedded Forum (Birmingham,
UK, October 2005), pp.18-35. Published by
University of Newcastle upon Tyne [ISBN: 0-
7017-0191-9].

Copyright © 2009-2011 TTE Systems Ltd


40 Licensed to University of Leicester

Page 196
Working with distributed systems
(multiple CPUs)

Copyright © 2009-2011 TTE Systems Ltd


41 Licensed to University of Leicester

Multi-processor embedded systems


 Multi-processor designs:
– Automotive
– Aerospace
– Medical
– Industrial automation
– Fire alarms
– Intruder alarms
– Computer games
– …

Photo and diagram by Amir Muhammad

Copyright © 2009-2011 TTE Systems Ltd


42 Licensed to University of Leicester

Page 197
Benefit 1: More hardware resources
 Allows parallel processing:
– Spreads the processing load
– Run long tasks and short frequent tasks without pre-emption

 Increases the number of peripherals available:


– More timers, UARTS, GPIO, etc.

Copyright © 2009-2011 TTE Systems Ltd


43 Licensed to University of Leicester

Benefit 2: Modular approach


 Low-cost replication of Sensor
1

common modules in large


numbers Sensor
2
Acquisition
system PC

 Easier to detect faults in Sensor


3

“intelligent” sensors
– Airbus A310 slat and flap Sensor
1
MCU
A

control with a safe sub- 2

system shutdown state in


case of a fault Sensor
2
MCU
B
Acquisition
system PC

3 1

Sensor MCU
3 C

Copyright © 2009-2011 TTE Systems Ltd


44 Licensed to University of Leicester

Page 198
Key challenges for distributed embedded systems
 Synchronising clocks on the different nodes
 Data sharing between the nodes
 Detecting and managing node and cable failures

Copyright © 2009-2011 TTE Systems Ltd


45 Licensed to University of Leicester

Synchronising clocks on the different nodes

Copyright © 2009-2011 TTE Systems Ltd


46 Licensed to University of Leicester

Page 199
Oscillators and processors

Oscillator frequencies will


NOT be identical

Copyright © 2009-2011 TTE Systems Ltd


47 Licensed to University of Leicester

The need for synchronised clocks

Portable traffic-light
controller

Copyright © 2009-2011 TTE Systems Ltd


48 Licensed to University of Leicester

Page 200
The need for synchronised clocks

Portable traffic-light
controller

Copyright © 2009-2011 TTE Systems Ltd


49 Licensed to University of Leicester

Synchronising the clocks

Master Slave 1 Slave 2 Slave N

Tick messages (from Master to Slaves) E.g. CAN bus, RS-485


FlexRay, etc

Copyright © 2009-2011 TTE Systems Ltd


50 Licensed to University of Leicester

Page 201
Sharing data between the different nodes

Copyright © 2009-2011 TTE Systems Ltd


51 Licensed to University of Leicester

Sharing data between nodes


 Using an appropriate network protocol to send “Tick”
messages, the master can address a node and send data to
one or more nodes as part of the tick message.
 The addressed Slave can then reply (Acknowledgement
message) with data that needs to be sent to the Master.
Slave tick (from CAN hardware)

Tick Ack Tick Ack Tick Ack


Message Message Message Message Message Message ...
(Data for S1) (from S1) (Data for S2) (from S2) (Data for S1) (from S1)

Time
Master tick (from timer)

 Note:
– One Slave replies at a time
– Direct Slave to Slave comms is not possible

Copyright © 2009-2011 TTE Systems Ltd


52 Licensed to University of Leicester

Page 202
Sharing data between nodes
 Note:
– One Slave replies at a time
– Direct Slave to Slave comms is not possible

Slave tick (from CAN hardware)

Tick Ack Tick Ack Tick Ack


Message Message Message Message Message Message ...
(Data for S1) (from S1) (Data for S2) (from S2) (Data for S1) (from S1)

Time
Master tick (from timer)

Copyright © 2009-2011 TTE Systems Ltd


53 Licensed to University of Leicester

Sharing data between nodes


 Further information / different design options for S-C systems:

– Ayavoo, D., Pont, M.J., Short, M. and Parker, S. (2007) “Two novel
shared-clock scheduling algorithms for use with CAN-based distributed
systems”, Microprocessors and Microsystems, 31(5): 326-334.

– Short, M.J. and Pont, M.J. (2007) “Fault-tolerant time-triggered


communication using CAN”, IEEE Transactions on Industrial
Informatics, 3(2): 131-142.

Copyright © 2009-2011 TTE Systems Ltd


54 Licensed to University of Leicester

Page 203
Dealing with errors

Copyright © 2009-2011 TTE Systems Ltd


55 Licensed to University of Leicester

Detecting network problems and node failures


Detecting errors from the Master’s perspective:
 If a Slave does not acknowledge a message sent to it, the
Master node can assume there is either a problem with the
network link to that Slave or the Slave node has failed

Detecting errors from the Slave’s perspective:


 If a Tick Message is not received in an interval greater than
the tick period, it can assume there is a fault with the Master
node or the network link

Copyright © 2009-2011 TTE Systems Ltd


56 Licensed to University of Leicester

Page 204
Handling faults on the Master
 Enter safe state and shut down network
– Easy to implement and effective in most systems
– Can be last line of defence if advanced recovery options fail
– Does not try to recover to normal operation

 Restart network
– Easy to implement and allows the use of “backup” Slaves
– Takes time to restart the network and restore normal operation
– Incorrect implementation can be dangerous

 Engage backup Slave


– Allows full use of backup nodes
– Takes little time to engage backup nodes
– Underlying code is complicated

Copyright © 2009-2011 TTE Systems Ltd


57 Licensed to University of Leicester

Handling faults on the Slave


 A watchdog timer can be used to reset the slave if a tick
message is not received every tick period.

 The slave nodes should enter a “safe” state after restart and
stay in that state till they receive Tick messages.

 A breakdown in the communication with the Master will usually


result in the Slave entering a “fail silent” mode

Copyright © 2009-2011 TTE Systems Ltd


58 Licensed to University of Leicester

Page 205
General reliability concerns

Copyright © 2009-2011 TTE Systems Ltd


59 Licensed to University of Leicester

Will adding additional nodes increase reliability?


 For example:
– Suppose a system with 100 nodes
– Suppose each node is 99% reliable
– The system reliability is just 37%
(assuming all nodes need to be running for reliable operation)

 To reverse this, we need redundant components

Copyright © 2009-2011 TTE Systems Ltd


60 Licensed to University of Leicester

Page 206
Increased reliability requires redundancy
B

Actuator Main
Main control
control
Actuator
Actuator AA Actuator BB Actuator
Actuator CC
(Slave) &&user
user interface
interface
(Slave)
(Slave) (Slave) (Slave)
(Slave) (Master)
(Master)

Copyright © 2009-2011 TTE Systems Ltd


61 Licensed to University of Leicester

Increased reliability requires redundancy


B

Actuator Main
Main control
control
Actuator
Actuator AA Actuator BB Actuator
Actuator CC &&user
(Slave) (Slave)
(Slave) (Slave) user interface
interface
(Slave) (Slave) (Master)
(Master)

Actuator Actuator
Actuator B1 Main control
Actuator A1
A B Actuator
Actuator C1
C
(Backup Slave) (Backup Slave)
(Slave) (Backup Slave) &Backup Master
user interface
(Slave) (Slave)
(Master)

Copyright © 2009-2011 TTE Systems Ltd


62 Licensed to University of Leicester

Page 207
Increased reliability requires redundancy
B

Actuator Main
Main control
control
Actuator
Actuator AA Actuator BB Actuator
Actuator CC
(Slave) &&user
user interface
interface
(Slave)
(Slave) (Slave) (Slave)
(Slave) (Master)
(Master)

Copyright © 2009-2011 TTE Systems Ltd


63 Licensed to University of Leicester

Specific reliability issues with shared-clock


(and other TT network protocols)

Copyright © 2009-2011 TTE Systems Ltd


64 Licensed to University of Leicester

Page 208
Assumptions in a S-C network
 Shared-clock designs are based on a “time division multiple
access” (TDMA) protocol

 For correct operation, we assume that the communication


medium (e.g. CAN network) is free when we wish to send
either a Tick or Acknowledgement message

 One implication is that it is not usually possible to share the


network with another system

Copyright © 2009-2011 TTE Systems Ltd


65 Licensed to University of Leicester

“Babbling Idiot” failures


 For a S-C system, the worst-case scenario is a “babbling idiot”
failure on a node
 This results in a constant stream of (high-priority) messages,
making it impossible to run the network as required

 One solution is to add “bus guardians” to each node

Node

BG

Copyright © 2009-2011 TTE Systems Ltd


66 Licensed to University of Leicester

Page 209
CASE STUDY:
S-C scheduling using CAN

Copyright © 2009-2011 TTE Systems Ltd


67 Licensed to University of Leicester

Introducing CAN
 The “Controller Area Network” (CAN) protocol

 Very popular and cost-effective due to:


– Simplicity
– Low cost
– Availability
– Robustness

 CAN supports high-speed (1 Mbit/s) data transmission over short distances


(40m) and low-speed (5 kbit/s) transmissions at lengths of up to 10,000m.

 A large number of microcontrollers have on-chip support for CAN, allowing


the protocol to be used with minimal overheads.
 Off-chip CAN transceivers can be used to allow use of this protocol with a
huge range of devices.

 The maximum number of nodes on a CAN bus is 32.

Copyright © 2009-2011 TTE Systems Ltd


68 68 Licensed to University of Leicester

Page 210
Introducing CAN
 Messages can be up to 8 bytes in length.
 Used in a shared-clock scheduler, the data transfer between Master
and Slaves (and vice versa) is up to 7 bytes per Tick. This is
adequate for most applications.

 CAN is a shared broadcast bus: all messages are sent to all nodes.
However, each message has an identifier: this can be used to ‘filter’
messages. This means that - by using a ‘Full CAN’ controller (see
below) - we can ensure that a particular node will only respond to
‘relevant’ messages: that is, messages with a particular ID.

This is very powerful. What this means in practice is, for


example, that a Slave node can be set to ignore all messages
directed from a different Slave to the Master.
Copyright © 2009-2011 TTE Systems Ltd
69 Licensed to University of Leicester

Determining the required baud rate for “S-C CAN”


Description Size (bits)
Data 64
Start bit 1
Identifier bits 11
SRR bit 1
IDE bit 1
Identifier bits 18
RTR bit 1
Control bits 6
CRC bits 15
Stuff bits (maximum) 23
CRC delimiter 1
ACK slot 1
ACK delimiter 1
EOF bits 7
IFS bits 3
TOTAL 154 bits / message

Copyright © 2009-2011 TTE Systems Ltd


70 Licensed to University of Leicester

Page 211
Determining the required baud rate for “S-C CAN”
 We require two messages per tick

 For 1 ms ticks, we require at least 308,000 baud:


allowing 350,000 baud gives a margin for error.
 This is achievable with CAN, at distances up to around 100m

 Should you require larger distances, the tick interval must


either be lengthened, or repeater nodes should be added in
the network at 100-metre intervals.

Copyright © 2009-2011 TTE Systems Ltd


71 Licensed to University of Leicester

Node wiring for distributed networks

Can High

120 Ω 120 Ω
Can Low

Node 1 Node 2 Node 3

Copyright © 2009-2011 TTE Systems Ltd


72 Licensed to University of Leicester

Page 212
Node wiring for distributed networks
 The most common means of linking together CAN nodes is
through the use of a two-wire, twisted pair (like RS-485).
 In the CAN bus, the two signal lines are termed ‘CAN High’
and ‘CAN Low’. In the quiescent state, both lines sit at 2.5V.
A ‘1’ is transmitted by raising the voltage of the High line
above that of Low line: this is termed a ‘dominant’ bit. A ‘0’ is
represented by raising the voltage of the Low line above that
of the High line: this is termed a ‘recessive’ bit.
 Using twisted-pair wiring, the differential CAN inputs
successfully cancel out noise. In addition, the CAN networks
connected in this way continue to function even when one of
the lines is severed.

Copyright © 2009-2011 TTE Systems Ltd


73 Licensed to University of Leicester

Master / Slave latency in S-C CAN

Copyright © 2009-2011 TTE Systems Ltd


74 Licensed to University of Leicester

Page 213
Master / Slave latency

Tick latency
(varies with baud rate)

Tick Ack
Message Message ...
(Data for S1) (from S1)

Time

Copyright © 2009-2011 TTE Systems Ltd


75 Licensed to University of Leicester

Master / Slave jitter in S-C CAN

Copyright © 2009-2011 TTE Systems Ltd


76 Licensed to University of Leicester

Page 214
Controller Area Network (CAN) – bit coding
 CAN uses NRZ coding
Vcc
– high voltage  Logic ‘1’
0V
– low voltage  Logic ‘0’ 1 0

1 0 0 0 0 0 0 0

1 0 0 0 0 0 1 0 0

 CAN employs bit stuffing


– Original frame: 0001111111001100000100111111 …
– Sent frame: 0001111101100110000011001111101 …

Copyright © 2009-2011 TTE Systems Ltd


77 Licensed to University of Leicester

Jitter in CAN-based S-C networks


 Bit stuffing causes the CAN frames to become of variable lengths.

 Example: if 8 data bytes are used, with standard CAN identifiers:


 Minimum message length = 111 bits.
 Maximum message length = 135 bits.
 A possible variation in message length of 24 µs (at 1 Mbaud).

 This variation causes a system jitter  affects performance

Nahas, M., Pont, M.J. and Short, M.J. (2009) “Reducing message-
length variations in resource-constrained embedded systems
implemented using the Controller Area Network (CAN) protocol”,
Journal of Systems Architecture Vol. 55: pp.344–354.

Copyright © 2009-2011 TTE Systems Ltd


78 Licensed to University of Leicester

Page 215
Reducing jitter in CAN-based S-C networks

Copyright © 2009-2011 TTE Systems Ltd


79 Licensed to University of Leicester

Reducing jitter in CAN-based S-C networks

Copyright © 2009-2011 TTE Systems Ltd


80 Licensed to University of Leicester

Page 216
Conclusion
 We’ve considered:
– The challenges of full “ET multi-tasking” designs
– Time-triggered “hybrid” schedulers (the best of both worlds?)
– Shared-clock schedulers

 Now it’s time to roll up your sleeves …

Copyright © 2009-2011 TTE Systems Ltd


81 Licensed to University of Leicester

All my own work


 The following individuals contributed to the material and slides
presented in this session:
– Musharraf Hanif (University of Leicester)
– Devaraj Ayavoo (TTE Systems Ltd)
– Zemian Hughes (TTE Systems Ltd)
– Peter Vidler (TTE Systems Ltd)
– Muhammad Waqas Raza (TTE Systems Ltd)
– Keith Athaide (TTE Systems Ltd)
– Anjali Das (TTE Systems Ltd)
– Michael Short (Teesside University)

Copyright © 2009-2011 TTE Systems Ltd


82 Licensed to University of Leicester

Page 217
(Blank page)

Page 218
Day 5: Case study

Michael J. Pont

MSc in Reliable Embedded Systems


Module EG7510 (“A1a”)

In this session, we will complete a detailed case study


(building on the material presented
earlier in the week)

Copyright © 2009-2011 TTE Systems Ltd


2 Licensed to University of Leicester

Page 219
Where do we go from here?

Copyright © 2009-2011 TTE Systems Ltd


3 Licensed to University of Leicester

Where do we go from here?


 We’ve introduced a number of key topics in this course

 Many of these topics will be explored in greater detail in later


MSc modules

Copyright © 2009-2011 TTE Systems Ltd


4 Licensed to University of Leicester

Page 220
Working with
FPGAs
 Six modules
 15 credits per
Design patterns for Understanding and module
reliable embedded using an RTOS
systems  Each module is
run every 3 - 4
months
 Join the MSc at
any stage
Multi-processor and
Software and system
multi-core designs
architectures

Programming techniques
for reliable embedded
systems
Copyright © 2009-2011 TTE Systems Ltd
5 Licensed to University of Leicester

The next course is “Module A2a”


“Software considerations in airborne systems and equipment certification”
US guidelines: RTCA DO-178b
European equivalent: EUROCAE ED-12b

 We’ll focus on techniques which are compatible with DO-178b


– The “benchmark” against which software development guidelines
are judged at the present time

 We’ll also consider:


– ESA guidelines
– NASA guidelines

Copyright © 2009-2011 TTE Systems Ltd


6 Licensed to University of Leicester

Page 221
About TTE Systems Ltd
At TTE Systems, we help our customers to create reliable embedded systems.

We develop and sell high-integrity processor cores, both ‘off the shelf’ & custom software
development tools and advanced safety protection mechanisms (‘shutdown systems’). We also
offer a range of training, consultancy and custom design services.

Application sectors for our products and services range from aerospace, medical, industrial,
automotive, defence and satellite systems to high-end consumer goods.

Many of our products can be provided in forms which are suitable for use in DO-178b, DO-254, ED-
80, IEC 61508 (SIL3), ISO 26262 (ASIL D) and similar high-reliability and safety-critical projects.

We are based in Leicester, UK.

www.TTE-Systems.com

Page 222
Page 223
Further reading
Ahmad, N. and Pont, M.J. (2009) “Remote debugging of embedded systems which employ a
time-triggered architecture”, Proceedings of the 5th UK Embedded Forum, Leicester,
UK, 23-24 September, 2009, pp.97-106. Published by Newcastle University. ISBN
978-0-7017-0222-9.
Ahmad, N. and Pont, M.J. (2010) “Debugging remote embedded systems: The impact of
system software architecture”, Proceedings of the 2010 UK Electronics Forum,
Newcastle, UK, 30 June-1 July, 2010, pp.17-23. Published by Newcastle University.
ISBN 978-0-7017-0232-8.
Amir, M. and Pont, M.J. (2008) “Synchronising tasks in wireless multi-processor
environments using a shared-clock architecture: A pilot study”, Proceedings of the 4th
UK Embedded Forum, Southampton, UK, 9-10 September, 2008, pp.30-39. Published
by IET. ISBN 978-0-8634-1949-2.
Amir, M. and Pont, M.J. (2009) “A time-triggered communication protocol for CAN-based
networks with a star topology”, Proceedings of the 5th UK Embedded Forum, Leicester,
UK, 23-24 September, 2009, pp.30-44. Published by Newcastle University. ISBN 978-
0-7017-0222-9.
Amir, M. and Pont, M.J. (2010) “A novel shared-clock scheduling protocol for fault-
confinement in CAN-based distributed systems”, Proceedings of the 5th IEEE
International Conference on System of Systems, IEEE SoSE 2010, Loughborough
University, UK, 22nd-24th, June 2010.
Amir, M. and Pont, M.J. (2010) “A time-triggered communication protocol for CAN-based
networks with a fault-tolerant star topology “, Proceedings of the International
Symposium on Advanced Topics in Embedded Systems and Applications under the 7th
IEEE International Conference on Embedded Software and Systems, Bradford, West
Yorkshire, UK, 29th June-1st July, 2010. ISBN 978-0-7695-4108-2.
Amir, M. and Pont, M.J. (2010) “Integration of TTC-SC5 and TTC-SC6 shared-clock
protocols”, Proceedings of the 1st UK Electronics Forum, Newcastle, UK, 30th June-1st
July, 2010. Published by Newcastle University. ISBN 978-0-7017-0232-8.
Athaide, K., Hughes, Z.M. and Pont, M.J. (2007) “Towards a time-triggered processor”,
Proceedings of the 3rd UK Embedded Forum, Durham, UK, 203 April, 2007, pp.166.
Published by IET. ISBN 9780863418037. ISSN 0537-9989.
Athaide, K.F., Pont, M.J. and Ayavoo, D. (2008) “Deploying a time-triggered shared-clock
architecture in a multiprocessor system-on-chip design”, in Proceedings of the 4th UK
Embedded Forum (September 2008, Southampton, UK).
Athaide, K.F., Pont, M.J. and Ayavoo, D. (2008) “Shared-clock methodology for time-
triggered multi-cores”, in Susan Stepney, Fiona Polack, Alistair McEwan, Peter Welch,
and Wilson Ifill (Eds.), “Communicating Process Architectures 2008”, IOS Press.
Ayavoo, D., Pont, M.J. and Parker, S. (2004) “Using simulation to support the design of
distributed embedded control systems: A case study”. In: Koelmans, A., Bystrov, A. and
Pont, M.J. (Eds.) Proceedings of the UK Embedded Forum 2004 (Birmingham, UK,
October 2004), pp.54-65. Published by University of Newcastle upon Tyne [ISBN: 0-
7017-0180-3].

Page 224
Ayavoo, D., Pont, M.J. and Parker, S. (2005) “Observing the development of a reliable
embedded system”. In Vardanega, T and Wellings, A. (Eds.) “Proceedings of the 10th
Ada-Europe International Conference on Reliable Software Technologies, York, UK,
June 20-24 2005”, pp. 167-179. Lecture Notes in Computer Science, Vol. 3555.
Published by Springer-Verlag [ISBN: 3-540-26286-5]
Ayavoo, D., Pont, M.J. and Parker, S. (2006) “Does a „simulation first‟ approach reduce the
effort involved in the development of distributed embedded control systems?”.
Proceedings of the 6th UKACC International Control Conference, Glasgow, Scotland,
2006.
Ayavoo, D., Pont, M.J., Fang, J., Short, M. and Parker, S. (2005) “A „Hardware-in-the Loop‟
testbed representing the operation of a cruise-control system in a passenger car”. In:
Koelmans, A., Bystrov, A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the
Second UK Embedded Forum (Birmingham, UK, October 2005), pp.60-90. Published by
University of Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Ayavoo, D., Pont, M.J., Short, M. and Parker, S. (2005) “Two novel shared-clock scheduling
algorithms for use with CAN-based distributed systems”. In: Koelmans, A., Bystrov, A.,
Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded
Forum (Birmingham, UK, October 2005), pp.246-261. Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Ayavoo, D., Pont, M.J., Short, M. and Parker, S. (2007) “Two novel shared-clock scheduling
algorithms for use with CAN-based distributed systems”, Microprocessors and
Microsystems, 31(5): 326-334.
Bautista, R., Pont, M.J. and Edwards, T. (2005) “Comparing the performance and resource
requirements of „PID‟ and „LQR‟ algorithms when used in a practical embedded control
system: A pilot study”. In: Koelmans, A., Bystrov, A., Pont, M.J., Ong, R. and Brown,
A. (Eds.), Proceedings of the Second UK Embedded Forum (Birmingham, UK, October
2005), pp.262-289. Published by University of Newcastle upon Tyne [ISBN: 0-7017-
0191-9].
Bautista-Quintero, R. and Pont, M.J. (2006) “Is fuzzy logic a practical choice in resource-
constrained embedded control systems implemented using general-purpose
microcontrollers?”, Proceedings of the 9th IEEE International Workshop on Advanced
Motion Control (Istanbul, March 27-29, 2006), Volume 2, pp.692-697. IEEE catalog
number 06TH8850. ISBN 0-7803-9511-5.
Bautista-Quintero, R. and Pont, M.J. (2008) “Implementation of H-infinity control algorithms
for sensor-constrained mechatronic systems using low-cost microcontrollers”, IEEE
Transactions on Industrial Informatics, 16(4): 175-184.
Chan, K.L. and Pont, M.J. (2010) “Real-time non-invasive detection of timing-constraint
violations in time-triggered embedded systems”, Proceedings of the 7th IEEE
International Conference on Embedded Software and Systems, Bradford, UK, 2010,
pp.1978-1986. Published by IEEE Computer Society. ISBN 978-0-7695-4108-2.
Edwards, T., Pont, M.J., Scotson, P. and Crumpler, S. (2004) “A test-bed for evaluating and
comparing designs for embedded control systems”. In: Koelmans, A., Bystrov, A. and
Pont, M.J. (Eds.) Proceedings of the UK Embedded Forum 2004 (Birmingham, UK,
October 2004), pp.106-126. Published by University of Newcastle upon Tyne [ISBN: 0-
7017-0180-3].

Page 225
Edwards, T., Pont, M.J., Short, M.J., Scotson, P. and Crumpler, S. (2005) “An initial
comparison of synchronous and asynchronous network architectures for use in
embedded control systems with duplicate processor nodes”. In: Koelmans, A., Bystrov,
A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded
Forum (Birmingham, UK, October 2005), pp.290-303. Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Gendy, A. and Pont, M.J. (2007) “Towards a generic „single-path programming‟ solution
with reduced power consumption”, Proceedings of the ASME 2007 International Design
Engineering Technical Conferences & Computers and Information in Engineering
Conference (IDETC/CIE 2007), September 4-7, 2007, Las Vegas, Nevada, USA.
Gendy, A. and Pont, M.J. (2008) “Automating the processes of selecting an appropriate
scheduling algorithm and configuring the scheduler implementation for time-triggered
embedded systems”, Proceedings of The 27th International Conference on Computer
Safety, Reliability and Security (SAFECOMP08), 22-25 September 2008, Newcastle
upon Tyne, UK
Gendy, A. and Pont, M.J. (2008) “Automating the processes of selecting an appropriate
scheduling algorithm and configuring the scheduler implementation for time-triggered
embedded systems”, Proceedings of The 27th International Conference on Computer
Safety, Reliability and Security (SAFECOMP08), 22-25 September 2008, Newcastle
upon Tyne, UK
Gendy, A., Dong, L. and Pont, M.J. (2007) “Improving the performance of time-triggered
embedded systems by means of a scheduler agent”, Proceedings of the ASME 2007
International Design Engineering Technical Conferences & Computers and Information
in Engineering Conference (IDETC/CIE 2007), September 4-7, 2007, Las Vegas,
Nevada, USA.
Gendy, A.K. and Pont, M.J. (2008) “Automatically configuring time-triggered schedulers for
use with resource-constrained, single-processor embedded systems”, IEEE Transactions
on Industrial Informatics, 4(1): 37-46.
Hanif, M., Pont, M.J. and Ayavoo, D. (2008) “Implementing a simple but flexible time-
triggered architecture for practical deeply-embedded applications”, in Proceedings of the
4th UK Embedded Forum (September 2008, Southampton, UK).
Hughes, Z.H. and Pont, M.J. (2004) “Design and test of a task guardian for use in TTCS
embedded systems”. In: Koelmans, A., Bystrov, A. and Pont, M.J. (Eds.) Proceedings of
the UK Embedded Forum 2004 (Birmingham, UK, October 2004), pp.16-25. Published
by University of Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Hughes, Z.M. and Pont, M.J. (2008) “Reducing the impact of task overruns in resource-
constrained embedded systems in which a time-triggered software architecture is
employed”, Transactions of the Institute of Measurement and Control, Vol. 30: pp.427-
450.
Hughes, Z.M., Pont, M.J. and Ong, H.L.R. (2005) “Design and evaluation of a “time-
triggered” microcontroller”. Poster presentation at DATE 2005 (PhD Forum), Munich,
Germany, March 2005.

Page 226
Hughes, Z.M., Pont, M.J. and Ong, H.L.R. (2005) “The PH Processor: A soft embedded core
for use in university research and teaching”. In: Koelmans, A., Bystrov, A., Pont, M.J.,
Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded Forum
(Birmingham, UK, October 2005), pp.224-245. Published by University of Newcastle
upon Tyne [ISBN: 0-7017-0191-9].
IEC 61508 (2000) “Functional safety of electrical/electronic/programmable electronic safety-
related systems, Part 3”. (2000).
Imran, S., Short, M. and Pont, M.J. (2008) “Hardware implementation of a shared-clock
scheduling protocol for CAN: A pilot study”, in Proceedings of the 4th UK Embedded
Forum (September 2008, Southampton, UK).
Imran, S., Short, M. and Pont, M.J. (2008) “Hardware implementation of a shared-clock
scheduling protocol for CAN: A pilot study”, in Proceedings of the 4th UK Embedded
Forum (September 2008, Southampton, UK).
Key, S. and Pont, M.J. (2004) “Implementing PID control systems using resource-limited
embedded processors”. In: Koelmans, A., Bystrov, A. and Pont, M.J. (Eds.) Proceedings
of the UK Embedded Forum 2004 (Birmingham, UK, October 2004), pp.76-92.
Published by University of Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Key, S.A., Pont, M.J. and Edwards, S. (2004) “Implementing low-cost TTCS systems using
assembly language”. In: Henney, K. and Schutz, D. (Eds) Proceedings of the Eighth
European conference on Pattern Languages of Programs (EuroPLoP 8), Germany, June
2003: pp.667-690. Published by Universitätsverlag Konstanz. ISBN 3-87940-788-6.
Koelmans, A., Bystrov, A. and Pont, M.J. (2004)(Eds.) “Proceedings of the First UK
Embedded Forum” (Birmingham, UK, October 2004). Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Koelmans, A., Bystrov, A., Pont, M.J., Ong, R. and Brown, A. (2005)(Eds.) “Proceedings of
the Second UK Embedded Forum” (Birmingham, UK, October 2005). Published by
University of Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Kurian, S. and Pont, M.J. (2005) “Building reliable embedded systems using Abstract
Patterns, Patterns, and Pattern Implementation Examples”. In: Koelmans, A., Bystrov,
A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded
Forum (Birmingham, UK, October 2005), pp.36-59. Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Kurian, S. and Pont, M.J. (2005) “Mining for pattern implementation examples”. In:
Koelmans, A., Bystrov, A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the
Second UK Embedded Forum (Birmingham, UK, October 2005), pp.194-201. Published
by University of Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Kurian, S. and Pont, M.J. (2006) “Evaluating and improving pattern-based software designs
for resource-constrained embedded systems”. In: C. Guedes Soares & E. Zio (Eds),
“Safety and Reliability for Managing Risk: Proceedings of the 15th European Safety and
Reliabilty Conference (ESREL 2006), Estoril, Portugal, 18-22 September 2006”, Vol. 2,
pp.1417-1423. Published by Taylor and Francis, London. ISBN: 0-415-41620-5 (for
complete 3-volume set of proceedings). ISBN: 978-0-415-42314-4 (for Volume 2).
Kurian, S. and Pont, M.J. (2007) “Maintenance and evolution of resource-constrained
embedded systems created using design patterns”, Journal of Systems and Software,
80(1): 32-41.

Page 227
Lakhani, F. and Pont, M.J. (2010) “Using design patterns to support migration between
different system architectures”, Proceedings of 5th IEEE International Conference on
Systems of Systems Engineering, June 2010, Loughborough , UK.
Lakhani, F., and Pont, M.J. (2010) “Code balancing as a philosophy for change: Helping
developers to migrate from event-triggered to time-triggered architectures” Proceedings
of First UK Electronics Forum, 30June- 1 July 2010, Newcastle, UK , Published by
Newcastle University. ISBN: 978-0-7017-0232-8
Lakhani, F., Pont, M.J. and Das, A. (2009) “Can we support the migration from event
triggered to time triggered architectures using design patterns?” Proceedings of 5th UK
Embedded Forum, Leicester, UK , pp. 62-67. Published by Newcastle University.
ISBN: 978-0-7017-0222-9
Lakhani, F., Pont, M.J. and Das, A. (2009) “Towards a pattern language which supports the
migration of systems from an event-triggered pre-emptive to a time-triggered co-
operative software architecture” Proceedings of 14th Annual European Conference on
Pattern Languages of Programming”, Irsee, Germany, 8-12 July 2009. published by
CEUR vol. 566 . ISSN : 1613-0073
Lakhani, F., Pont, M.J. and Das, A. (2010) “Creating embedded systems with predictable
patterns of behaviour, supporting the migration between event-triggered and time-
triggered software architectures” Proceedings of 15th Annual European Conference on
Pattern Languages of Programming” , Irsee, Germany, 7 -11 July 2010.
Li, Y. and Pont, M.J. (2002) “On selecting pre-processing techniques for fault classification
using neural networks: A pilot study”, International Journal of Knowledge-Based
Intelligent Engineering Systems, 6(2): 80-87.
Li, Y., Pont, M.J. and Jones, N.B. (2002) “Improving the performance of radial basis function
classifiers in condition monitoring and fault diagnosis applications where „unknown‟
faults may occur”, Pattern Recognition Letters, 23: 569-577.
Li, Y., Pont, M.J., and Jones, N.B. (1999) “A comparison of the performance of radial basis
function and multi-layer Perceptron networks in a practical condition monitoring
application”, Proceedings of Condition Monitoring 1999 [Swansea, UK, April 12-15,
1999] pp.577-592.
Li, Y., Pont, M.J., Jones, N.B. and Twiddle, J.A. (2001) “Using MLP and RBF classifiers in
embedded condition monitoring and fault diagnosis applications”, Transactions of the
Institute of Measurement & Control, 23(3): 313-339.
Li, Y., Pont, M.J., Parikh, C.R. and Jones, N.B. (2000) “Comparing the performance of three
neural classifiers for use in embedded applications”, in: John, R. and Birkenhead, R.
(Eds.) Advances in Soft Computing: Soft Computing Techniques and Applications,
Springer-Verlag, Heidelberg, pp.34-39, [ISBN 3-7908-1257-9]
Li, Y.H., Jones, N.B. and Pont, M.J. (1998) “Applying neural networks and fuzzy logic to
fault diagnosis: a review”. in John, R.I. (1998), Editor, “Proceedings of: „Recent
Advances in Soft Computing „98” [Leicester, July 1998] pp.104-119. Published by
DeMontfort Expertise, Leicester, UK [ISBN 185 721 2592].
Maaita, A. and Pont, M.J. (2005) “Using „planned pre-emption‟ to reduce levels of task jitter
in a time-triggered hybrid scheduler”. In: Koelmans, A., Bystrov, A., Pont, M.J., Ong,
R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded Forum
(Birmingham, UK, October 2005), pp.18-35. Published by University of Newcastle upon
Tyne [ISBN: 0-7017-0191-9].

Page 228
Maguire, S. (1993) “Writing solid code”. Microsoft Press, 1993.
Mearns, D.D.U., Pont, M.J. and Ayavoo, D. (2008) “Towards Ctt (a programming language
for time-triggered embedded systems)”, in Proceedings of the 4th UK Embedded Forum
(September 2008, Southampton, UK).
MISRA (2004) “Guidelines for the use of the C language in critical systems”. Motor Industry
Software Reliability Report, Released October 2004.
Muhammad, A. and Pont, M.J. (2008) “Synchronising tasks in wireless multi-processor
environments using a shared-clock architecture: A pilot study”, in Proceedings of the 4th
UK Embedded Forum (September 2008, Southampton, UK).
Muhammad, A. and Pont, M.J. (2011) “Comments on: Two novel shared-clock scheduling
algorithms for use with CAN-based distributed systems”, Microprocessors and
Microsystems, Vol. 35, pp.81-82.
Mwelwa, C. and Pont, M.J. (2003) “Two new patterns to support the development of reliable
embedded systems” Paper presented at the Second Nordic Conference on Pattern
Languages of Programs, (“VikingPLoP 2003”), Bergen, Norway, September 2003.
Mwelwa, C., Athaide, K., Mearns, D., Pont, M.J. and Ward, D. (2007) “Rapid software
development for reliable embedded systems using a pattern-based code generation tool”.
SAE Transactions: Journal of Passenger Cars (Electronic and Electrical Systems),
115(7): 795-803.
Mwelwa, C., Pont, M.J. and Ward, D. (2004) “Code generation supported by a pattern-based
design methodology”. In: Koelmans, A., Bystrov, A. and Pont, M.J. (Eds.) Proceedings
of the UK Embedded Forum 2004 (Birmingham, UK, October 2004), pp.36-55.
Published by University of Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Mwelwa, C., Pont, M.J. and Ward, D. (2004) “Using patterns to support the development and
maintenance of software for reliable embedded systems: A case study”, Proceedings of
the IEE / ACM Postgraduate Seminar on “System-On-Chip Design, Test and
Technology”, Loughborough, UK, 15 September 2004. Published by IEE. ISBN: 0
86341 460 5 (ISSN: 0537-9989), pp. 15-20.
Mwelwa, C., Pont, M.J. and Ward, D. (2005) “Developing reliable embedded systems using a
pattern-based code generation tool: A case study”. In: Koelmans, A., Bystrov, A., Pont,
M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded Forum
(Birmingham, UK, October 2005), pp.177-193. Published by University of Newcastle
upon Tyne [ISBN: 0-7017-0191-9].
Nahas, M. and Pont, M.J. (2005) “Using XOR operations to reduce variations in the
transmission time of CAN messages: A pilot study”. In: Koelmans, A., Bystrov, A.,
Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded
Forum (Birmingham, UK, October 2005), pp.4-17. Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Nahas, M., Pont, M.J. and Jain, A. (2004) “Reducing task jitter in shared-clock embedded
systems using CAN”. In: Koelmans, A., Bystrov, A. and Pont, M.J. (Eds.) Proceedings
of the UK Embedded Forum 2004 (Birmingham, UK, October 2004), pp.184-194.
Published by University of Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Nahas, M., Pont, M.J. and Short, M.J. (2009) “Reducing message-length variations in
resource-constrained embedded systems implemented using the Controller Area
Network (CAN) protocol”, Journal of Systems Architecture Vol. 55: pp.344–354.

Page 229
Nahas, M., Short, M.J. and Pont, M.J. (2005) “Exploring the impact of software bit stuffing
on the behaviour of a distributed embedded control system implemented using CAN”, in
Proceedings of the 10th international CAN Conference, held in Rome, 8-10 March 2005,
pp. 10-1 to 10-7.
Ong, H.L.R and Pont, M.J. (2001) “Empirical comparison of software-based error detection
and correction techniques for embedded systems”, Proceedings of the 9th International
Symposium on Hardware / Software Codesign, April 25-27 2001, Copenhagen,
Denmark. Pp.230-235. Published by ACM Press, New York. ISBN: 1-58113-364-2.
Ong, H.L.R and Pont, M.J. (2002) “The impact of instruction pointer corruption on program
flow: a computational modelling study”, Microprocessors and Microsystems, 25: 409-
419
Ong, H.L.R, Pont, M.J. and Peasgood, W. (2001) “A comparison of software-based
techniques intended to increase the reliability of embedded applications in the presence
of EMI” Microprocessors and Microsystems, 24(10): 481-491.
Ong, H.L.R., Pont, M.J., and Peasgood, W. (2000) “Hardware-software tradeoffs when
designing microcontroller-based applications for high-EMI environments”, IEE
Colloquium on Hardware-Software Co-Design, Savoy Place, London, 8 December,
2000. IEE Colloquium Digests #111.
Parikh C.R., M.J. Pont and N.B. Jones (2001) “Application of Dempster-Shafer theory in
condition monitoring systems”, Pattern Recognition Letters, 22(6-7): 777-785.
Parikh C.R., Pont, M.J., Jones, N.B. and Schlindwein, F.S. (2003) “Improving the
performance of CMFD applications using multiple classifiers and a fusion framework”,
Transactions of the Institute of Measurement and Control, 25(2): 123-144.
Parikh, C., Pont, M.J., Jones, N.B., Bhatti, A.I., Li, Y.H., Spurgeon, S.K., Scotson, P. and
Scaife, M. (1998) “Towards an application framework for condition monitoring and fault
diagnosis”. In John, R.I. (1998), Editor, “Proceedings of: „Recent Advances in Soft
Computing „98” [Leicester, July 1998] pp.128-141. Published by DeMontfort Expertise,
Leicester, UK [ISBN 185 721 2592].
Parikh, C.R., Pont, M.J., Li, Y. and Jones, N.B. (1999) “Improving the performance of multi-
layer Perceptrons where limited training data are available for some classes”,
Proceedings IEE International Conference on Neural Networks, Edinburgh, September
1999, pp.227-232.
Parikh, C.R., Pont, M.J., Li, Y. and Jones, N.B. (1999) “Neural networks for condition
monitoring and fault diagnosis: The effect of training data on classifier performance”,
Proceedings of Condition Monitoring 1999 [Swansea, UK, April 1999] pp.237-244.
Parikh, C.R., Pont, M.J., Li, Y. and Jones, N.B. (2000) “Investigating the performance of
MLP classifiers where limited training data are available for some classes”, in: John, R.
and Birkenhead, R. (Eds.) Advances in Soft Computing: Soft Computing Techniques and
Applications, Springer-Verlag, Heidelberg, pp.22-27, [ISBN 3-7908-1257-9]
Parikh, C.R., Pont, M.J., Li, Y.H., Jones, N.B. and Twiddle, J.A. (1998) “Towards a flexible
application framework for data fusion using real-time design patterns,” Proceedings of
6th European Congress on Intelligent Techniques & Soft Computing (EUFIT), Aachen,
Germany, September 7-10, 1998. pp.1131-1135.

Page 230
Phatrapornnant, T. and Pont, M.J. (2004) “The application of dynamic voltage scaling in
embedded systems employing a TTCS software architecture: A case study”, Proceedings
of the IEE / ACM Postgraduate Seminar on “System-On-Chip Design, Test and
Technology”, Loughborough, UK, 15 September 2004. Published by IEE. ISBN: 0
86341 460 5 (ISSN: 0537-9989), pp. 3-8.
Phatrapornnant, T. and Pont, M.J. (2004) “The application of dynamic voltage scaling in
embedded systems employing a TTCS software architecture”. In: Koelmans, A.,
Bystrov, A. and Pont, M.J. (Eds.) Proceedings of the UK Embedded Forum 2004
(Birmingham, UK, October 2004), pp.127-143. Published by University of Newcastle
upon Tyne [ISBN: 0-7017-0180-3].
Phatrapornnant, T. and Pont, M.J. (2006) “Reducing jitter in embedded systems employing a
time-triggered software architecture and dynamic voltage scaling”, IEEE Transactions
on Computers, 55(2): 113-124.
Pont, M.J. (1996) “Software Engineering with C++ and CASE Tools”, Addison-Wesley [964
pages]. ISBN: 0-201-87718-X.
Pont, M.J. (1998) “Control system design using real-time design patterns”, Proceedings of
Control „98 (Swansea, UK), September 1998, pp.1078-1083.
Pont, M.J. (2000) “Can patterns increase the reliability of embedded hardware-software co-
designs?”, IEE Colloquium on Hardware-Software Co-Design, Savoy Place, London, 8
December, 2000. IEE Colloquium Digests #111.
Pont, M.J. (2000) “Designing and implementing reliable embedded systems using patterns”,
in, Dyson, P. and Devos, Martine (Eds.) “EuroPLoP „99: Proceedings of the 4th
European Conference on Pattern Languages of Programming and Computing, 1999”.
ISBN 3-87940-774-6, Universitätsverlag Konstanz.
Pont, M.J. (2001) “Patterns for Time-Triggered Embedded Systems: Building Reliable
Applications with the 8051 Family of Microcontrollers”, Addison-Wesley / ACM Press.
[1012 pages] ISBN: 0-201-331381.
Pont, M.J. (2002) “Embedded C”, Addison-Wesley. [302 pages] ISBN: 0-201-79523-X.
Pont, M.J. (2003) “An object-oriented approach to software development for embedded
systems implemented using C”, Transactions of the Institute of Measurement and
Control 25(3): 217-238.
Pont, M.J. (2003) “Supporting the development of time-triggered co-operatively scheduled
(TTCS) embedded software using design patterns”, Informatica, 27: 81-88.
Pont, M.J. (2008) “Applying time-triggered architectures in reliable embedded systems:
Challenges and solutions”, Elektrotechnik & Informationstechnik, Vol. 125(11): 401-
405.
Pont, M.J. and Banner, M.P. (2004) “Designing embedded systems using patterns: A case
study”, Journal of Systems and Software, 71(3): 201-213.
Pont, M.J. and Mwelwa, C. (2003) “Developing reliable embedded systems using 8051 and
ARM processors: Towards a new pattern language” Paper presented at the Second
Nordic Conference on Pattern Languages of Programs, (“VikingPLoP 2003”), Bergen,
Norway, September 2003.

Page 231
Pont, M.J. and Ong, H.L.R. (2003) “Using watchdog timers to improve the reliability of
TTCS embedded systems”, in Hruby, P. and Soressen, K. E. [Eds.] Proceedings of the
First Nordic Conference on Pattern Languages of Programs, September, 2002
(“VikingPloP 2002”), pp.159-200. Published by Micrsoft Business Solutions. ISBN:
87-7849-769-8.
Pont, M.J., Kureemun, R., Ong, H.L.R. and Peasgood, W. (1999) “Increasing the reliability
of embedded automotive applications in the presence of EMI: A pilot study”, IEE
Colloquium on Automotive EMC, Birmingham, September 28, 1999.
Pont, M.J., Kurian, S. and Bautista-Quintero, R. (2007) “Meeting real-time constraints using
„Sandwich Delays‟”. In: Zdun, U. and Hvatum, L. (Eds) Proceedings of the Eleventh
European conference on Pattern Languages of Programs (EuroPLoP '06), Germany, July
2006: pp.67-77. Published by Universitätsverlag Konstanz. ISBN 978-3-87940-813-9.
Pont, M.J., Kurian, S., Wang, H. and Phatrapornnant, T. (2007) “Selecting an appropriate
scheduler for use with time-triggered embedded systems” Paper presented at the 12th
European Conference on Pattern Languages of Programs (EuroPLoP 2007).
Pont, M.J., Li, Y., Parikh, C.R. and Wong, C.P. (1999) “The design of embedded systems
using software patterns”, Proceedings of Condition Monitoring 1999 [Swansea, UK,
April 12-15, 1999] pp.221-236.
Pont, M.J., Norman, A.J., Mwelwa, C. and Edwards, T. (2004) “Prototyping time-triggered
embedded systems using PC hardware”. In: Henney, K. and Schutz, D. (Eds)
Proceedings of the Eighth European conference on Pattern Languages of Programs
(EuroPLoP 8), Germany, June 2003: pp.691-716. Published by Universitätsverlag
Konstanz. ISBN 3-87940-788-6.
Rizvi, S.A.I. and Pont, M.J. (2009) “Hardware support for deadlock-free resource sharing in
an embedded system with a TT architecture”, Proceedings of 5th UK Embedded Forum
2009, University of Leicester, UK, 23-24 September, pp. 1-9. Published by Newcastle
University. ISBN: 978-0-7017-0222-9
SAE (1993) “Class C Application Requirement Considerations”. SAE Recommended
Practice J2056/1, SAE, June 1993.
Short, M. (2008) “Development guidelines for dependable real-time embedded systems”.
Proceedings of the 6th IEEE/ACS International Conference on Computer Systems and
Applications (AICCSA 2008), pp. 1032 - 1039, April 2008.
Short, M. and Pont, M.J. (2005) “Hardware in the loop simulation of embedded automotive
control systems”, in Proceedings of the 8th IEEE International Conference on Intelligent
Transportation Systems (IEEE ITSC 2005) held in Vienna, Austria, 13-16 September
2005, pp. 226-231.
Short, M. and Pont, M.J. (2006) “Predicting the impact of hardware redundancy on the
performance of embedded control systems”. Proceedings of the 6th UKACC
International Control Conference, Glasgow, Scotland, 30 August to 1 September, 2006.
Short, M. and Pont, M.J. (2007) “Fault-tolerant time-triggered communication using CAN”,
IEEE Transactions on Industrial Informatics, 3(2): 131-142.
Short, M. and Pont, M.J. (2008) “Assessment of high-integrity embedded automotive control
systems using Hardware-in-the-Loop simulation”, Journal of Systems and Software,
81(7): 1163-1183.

Page 232
Short, M., Fang, J., Pont, M.J. and Rajabzadeh, A. (2007) “Assessing the impact of
redundancy on the performance of a brake-by-wire system”. SAE Transactions: Journal
of Passenger Cars (Electronic and Electrical Systems), 115(7): 331-338.
Short, M., Pont, M.J. and Fang, J. (2008) “Assessment of performance and dependability in
embedded control systems: Methodology and case study”, Control Engineering Practice.
Vol. 16, pp.1293– 1307
Short, M., Pont, M.J. and Fang, J. (2008) “Exploring the impact of task pre-emption on
dependability in time-triggered embedded systems: A pilot study”, Proceedings of the
20th EUROMICRO Conference on Real-Time Systems (ECRTS 08), Prague, Czech
Republic, July 2nd - 4th, 2008
Short, M., Pont, M.J. and Fang, J. (2008) “Exploring the impact of task pre-emption on
dependability in time-triggered embedded systems: A pilot study”, Proceedings of the
20th EUROMICRO Conference on Real-Time Systems (ECRTS 08), Prague, Czech
Republic, July 2nd - 4th, 2008
Vidler, P.J. and Pont, M.J. (2005) “Automatic conversion from „single processor‟ to „multi-
processor‟ software architectures for embedded control systems”. In: Koelmans, A.,
Bystrov, A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK
Embedded Forum (Birmingham, UK, October 2005), pp.209-223. Published by
University of Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Vidler, P.J. and Pont, M.J. (2006) “Computer assisted source-code parallelisation”. In:
Gavrilova, M., Gervasi, O., Kumar, V., Tan, C.J.K., Taniar, D., Laganà, A., Mun, Y. and
Choo, H. (eds.) Proceedings of the IEE International Conference on Computational
Science and its Applications (Glasgow, May 8-11, 2006), Part V. Lecture Notes in
Computer Science (LNCS), Vol. 3984, pp.22-31.
Wang, H. and Pont, M.J. (2008) “Design and implementation of a static pre-emptive
scheduler with highly predictable behaviour”, in Proceedings of the 4th UK Embedded
Forum (September 2008, Southampton, UK).
Wang, H. and Pont, M.J. (2008) “Design and implementation of a static pre-emptive
scheduler with highly predictable behaviour”, in Proceedings of the 4th UK Embedded
Forum (September 2008, Southampton, UK).
Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over
shared resources in time-triggered embedded systems which employ a pre-emptive
scheduler” Paper presented at the 12th European Conference on Pattern Languages of
Programs (EuroPLoP 2007).

Page 233