Certified Embedded C Notes V01a

Certified ‘Embedded C’ Programmer:
Training materials
Course notes to accompany

training seminars
Michael J. Pont
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

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)

Embedded systems

Page 4
Embedded systems

“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

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

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.

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

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.

Page 7
The world before embedded processors …

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

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 …]

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

Page 9
Our first target:
the “8051” microcontroller

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

Page 10
Is the 8051 still useful?
From Infineon
design brochure
(March 2009)

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

Page 11
Minimal circuit for the 8051

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.

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

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

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

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

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”)

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

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

Why use the C language?

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).

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;

}

Page 17
int Sum_of_Squares1(const int A, const int B)

{
int Square1 = A*A;
int Square2 = B*B;
return Square1 + Square2;

}

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

{
int Square1 = A*A;
int Square2 = B*B;
*sum_PTR = Square1 + Square2;

}

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

{
int Square1 = A*A;
int Square2 = B*B;
*sum_PTR = Square1 + Square2;

}

uint8_t Test(void(* pFunction)())

{
uint8_t index = 0;
...
SCH_tasks[index].pTask = pFunction;
...
(*SCH_tasks[index].pTask)();
...

Page 19
Software architecture for a
simple embedded system

Typical software architecture for a “desktop” processor
Word Processor
OS provides ‘common code’ for:
• Graphics
Operating System
• Printing
• File storage
• Sound
BIOS
• ...
Hardware

Page 20
Typical code structure for desktop processor
Desktop code
Function
Function 4
2 Function
Function 5
1
Function Function
3 6

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;
}

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

Task-oriented software engineering?
Embedded code
Task 1 Task 2 Task 3 Task 4
Function Function
1 2

Page 22
Example:
Working with switches

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:

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

Writing to the port pins
/* Port SFRs */
sfr P1 = 0x90;
/* Write 11111111 */
P1 = 0xFF;
/* Write 00001111 */
P1 = 0x0F;

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

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;
}
}

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
}
}

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

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;
}

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);
}

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.
ASIDE: Which type of switch should you use?
On Off

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

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
{
Return_value = SWITCH_PRESSED;
}
}
// Now return switch value
return Return_value;
}

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.

Using switches in real systems:

Counting goats …

Page 30
Counting goats
Mechanical sensor
at goat body
height
Sensor
Goat detected

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);

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
}

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
-*------------------------------------------------------------------*/
{
{
{
// Wait until the switch is released.
while (Switch_pin == 0);
}
}
// Now (finally) return switch value
}

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++);
}
}

Counting goats (simulation)
The number of goats (in binary)
The switch input (Pin 1.0)

Page 33
Switch hardware

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’

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’

Adding structure to your code

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

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.

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();

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).

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.

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.

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 -------------------------------------------------
-*------------------------------------------------------------------*/

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

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(...)
{
...
}

PC_IO.C
/*------------------------------------------------------------------*/
char PC_LINK_IO_Get_Char_From_Buffer(...)
{
...
}
/*------------------------------------------------------------------*/
void PC_LINK_IO_Send_Char(...)
{
...
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

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.

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)

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
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

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”
...

Page 42
Case study

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

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)

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)

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

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 -------------------------------------------------
-*------------------------------------------------------------------*/

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 -------------------------------------------------
-*------------------------------------------------------------------*/

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

// 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 -------------------------------------------------
-*------------------------------------------------------------------*/

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()
-*------------------------------------------------------------------*/
{
Switch_pin = 1; // Use this pin for input
}

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)
{
{
{
while (Switch_pin == 0);
}
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

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

void DISPLAY_COUNT_Init(void);
void DISPLAY_COUNT_Update(const tByte);
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

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 -------------------------------------------------
-*------------------------------------------------------------------*/

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 -------------------------------------------------
-*------------------------------------------------------------------*/

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 -------------------------------------------------
-*------------------------------------------------------------------*/

What does “real time” really mean?

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)


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

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)

Requirements
Software running “as fast as possible” not good enough!
Need guarantees in operation (timing).
Failure to meet timing requirements makes the

system useless

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?

Meeting real-time constraints

Page 52
Problems with the code we have written till now

{
{
DELAY_LOOP_Wait(DEBOUNCE_PERIOD); Software delay is not precise.
{
while (Switch_pin == 0); Blocks the system until the switch is released
}
}
}

Creating “hardware delays”

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

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)

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.

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

}

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();
}
}

Creating “timeout” mechanisms

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

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.

Page 57
Switch timeout code (example)
{

DELAY_T0_Wait(DEBOUNCE_PERIOD);
{
// (WITH TIMEOUT LOOP - 10 seconds)
while ((Switch_pin == 0) && (++Timeout_loop != 0));

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);

Page 58
“Balanced code” and “sandwich delays”

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.

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;
}

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;
}

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

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 …

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)

Page 62
Day 2: Key software architectures
Michael J. Pont

Introduction and review

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

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

Page 64
Time, time, time …

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

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.

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 …

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

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)

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)

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

Page 68
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

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...

}

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;
}

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.

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 =========================================

}

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);

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 -------------------------------------------------
-*------------------------------------------------------------------*/

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.
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.

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.

Page 73
Simple sEOS example

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

Page 74
Simple sEOS example
/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Demonstration of sEOS running a dummy task.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.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 -------------------------------------------------
-*------------------------------------------------------------------*/

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 -------------------------------------------------
-*------------------------------------------------------------------*/

Page 75
Simple sEOS example
/*------------------------------------------------------------------*-
------------------------------------------------------------------
Demonstration version with dummy task X().
-*------------------------------------------------------------------*/
...
/*------------------------------------------------------------------*-
sEOS_ISR()
-*------------------------------------------------------------------*/
{
TF2 = 0;
//===== USER CODE - Begin =======================================
// Call user task here

X();
//===== USER CODE - End =========================================

}
...

Creating useful TTC tasks

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

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"
bit Sw_pressed_G = 0; // The current switch status
// 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)

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


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...
}

Page 78
Case study

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.

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 -------------------------------------------------
-*------------------------------------------------------------------*/


/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Milk pasteurization example.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Bargraph.H"
#include "Pulse_Count.H"
/* --------------------------------------------------------------- */
void main(void)
{
PULSE_COUNT_Init();
BARGRAPH_Init();
// Set up simple EOS (30ms tick interval)
{
sEOS_Go_To_Sleep();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Page 80
/*------------------------------------------------------------------*-
------------------------------------------------------------------
-- This version for milk-flow-rate monitoring.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Pulse_count.H"
/*------------------------------------------------------------------*-
sEOS_ISR()
-*------------------------------------------------------------------*/
{
TF2 = 0;
//===== USER CODE - Begin =======================================

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


/*------------------------------------------------------------------*-
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"
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;

Page 81
// Allows changed of logic without hardware changes
#define HI_LEVEL (0)
#define LO_LEVEL (1)
/*------------------------------------------------------------------*-
PULSE_COUNT_Init()
-*------------------------------------------------------------------*/
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;
}


/*------------------------------------------------------------------*-
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>

Page 82
<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;
}


<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 -------------------------------------------------
-*------------------------------------------------------------------*/

Page 83
/*------------------------------------------------------------------*-
Bargraph.h (v1.00)
------------------------------------------------------------------
- See Bargraph.c for details.
-*------------------------------------------------------------------*/
#include "Main.h"
// ------ Public data type declarations ----------------------------

typedef tByte tBargraph;

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

#define BARGRAPH_MAX (9)
#define BARGRAPH_MIN (0)
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/


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

// The data to be displayed
tBargraph Data_G;

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

// These variables store the thresholds
// used to update the display
static tBargraph M9_1_G;

Page 84
/*------------------------------------------------------------------*-
BARGRAPH_Init()
Prepare for the bargraph display.
-*------------------------------------------------------------------*/
void BARGRAPH_Init(void)
{
Pin0 = 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;
}


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

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

Page 85
Pros and cons of “TTC” architectures

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.

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’

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’

Page 87
Multi-state systems and function sequences

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

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?)

Case study

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

Case Study: Basic traffic light – Code listing

/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Traffic light example.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.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_Go_To_Sleep();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

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;

void TRAFFIC_LIGHTS_Init(const eLight_State);
void TRAFFIC_LIGHTS_Update(void);
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/


/*------------------------------------------------------------------*-
T_lights.C (v1.00)
------------------------------------------------------------------
Traffic light control program (Test Version 1.0)
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "T_lights.H"
// 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

// 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;

Page 91
/*------------------------------------------------------------------*-
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>


<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;
}

Page 92
<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 -------------------------------------------------
-*------------------------------------------------------------------*/

Case study

Page 93
Case study: Washing machine controller
Valve
{
Water
Start
Switch
{
Water case INIT:
Pump
Selector
Dial case START:
Washing Drum
Machine
Controller Motor
Water case FILL_DRUM:
Level
Sensor
LED
Temperature
Sensor
Door
case WASH_01:
lock
...
Detergent }
Hatch
}
(Interrupt)
1 ms timer

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

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;

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);


#define OFF 0
#define ON 1
#define MAX_FILL_DURATION (tLong) 1000

#define MAX_WATER_HEAT_DURATION (tLong) 1000
#define WASH_01_DURATION 30000

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;
}

Page 95
/* --------------------------------------------------------------- */
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;
}


case START:
{
// 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;
}

Page 96
case FILL_DRUM:
{
// 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
}
else
{
System_state_G = WASH_01; // Ready to go to next state
}
}
break;
}


case HEAT_WATER:
{
// 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;
}
break;
}

Page 97
case WASH_01:
{
// 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;
}
break;
}
// REMAINING WASH PHASES OMITTED HERE ...
case WASH_02:
{
break;
}


case ERROR:
{
break;
}
}
}
/* --------------------------------------------------------------- */
tByte WASHER_Read_Selector_Dial(void)
{
// User code here...
return 0;
}

Page 98
/* --------------------------------------------------------------- */
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)
{
return 1;
}


/* --------------------------------------------------------------- */
bit WASHER_Read_Water_Temperature(void)
{
return 1;
}
/* --------------------------------------------------------------- */
void WASHER_Control_Detergent_Hatch(bit State)
{
bit Tmp = State;
}
/* --------------------------------------------------------------- */
void WASHER_Control_Door_Lock(bit State)
{
bit Tmp = State;
}
/* --------------------------------------------------------------- */
void WASHER_Control_Motor(bit State)
{
bit Tmp = State;
}

Page 99
/* --------------------------------------------------------------- */
void WASHER_Control_Pump(bit State)
{
bit Tmp = State;
}
/* --------------------------------------------------------------- */
void WASHER_Control_Water_Heater(bit State)
{
bit Tmp = State;
}
/* --------------------------------------------------------------- */
void WASHER_Control_Water_Valve(bit State)
{
bit Tmp = State;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Dealing with long tasks in TTC designs

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

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

Page 101
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)

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.

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.)

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)

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

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

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

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)

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%.

Case study

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)

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 -------------------------------------------------
-*------------------------------------------------------------------*/

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_Go_To_Sleep(); // Enter idle mode to save power
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/


/*------------------------------------------------------------------*-
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"

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

// 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);
}

Page 108
/*------------------------------------------------------------------*-
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];


<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 -------------------------------------------------
-*------------------------------------------------------------------*/

Page 109
/*------------------------------------------------------------------*-
PC_O_T1.C (v1.00)
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_O_T1.h"
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;
}


/*------------------------------------------------------------------*-
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"



static tByte Time_count_G = 0;

Page 110
/*------------------------------------------------------------------*-
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
}
}


/*------------------------------------------------------------------*-
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++;
}
}

Page 111
/*------------------------------------------------------------------*-
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;
if (Timeout1 == 0)
{
// UART did not respond - error
return;
}
TI = 0;
SBUF = CHARACTER;
}


/*------------------------------------------------------------------*-
-*------------------------------------------------------------------*/
#include ...
// ------ Private variable definitions -----------------------------

static tByte Call_count_G = 0;
/*------------------------------------------------------------------*-
sEOS_ISR()
-*------------------------------------------------------------------*/
{
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 =========================================
}

Page 112
Case study

Serial menus – Alternative to switch based UI

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

Page 113
Menu-based data acquisition – Code Listing
/*------------------------------------------------------------------*-
Main.c (v1.01)
------------------------------------------------------------------
Data acquisition example.
-*------------------------------------------------------------------*/
#include "Main.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_Go_To_Sleep(); // Enter idle mode to save power
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

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"

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

static bit First_time_only_G;

Page 114
/*------------------------------------------------------------------*-
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();
}
}


/*------------------------------------------------------------------*-
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("? : ");
}

Page 115
/*------------------------------------------------------------------*-
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;
}
}
}


/*------------------------------------------------------------------*-
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 -------------------------------------------------
-*------------------------------------------------------------------*/

Page 116
/*------------------------------------------------------------------*-
PC_IO_T1.C (v1.00)
------------------------------------------------------------------
PC link library. Bidirectional. T1 used for baud rate generation.
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_IO_T1.h"
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>


<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;
// Interrupt *NOT* enabled
ES = 0;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Menu based data acquision
Page 117
/*------------------------------------------------------------------*-
PC_IO.C (v1.00)
------------------------------------------------------------------
Core files for simple PC link library for 8051 family
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_IO.h"

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

static void PC_LINK_IO_Send_Char(const char);

// The receive buffer length
#define RECV_BUFFER_LENGTH 8
#define XON 0x11

#define XOFF 0x13


static tByte Recv_buffer[RECV_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
}
<Continued>

Page 118
<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
}
}


/*------------------------------------------------------------------*-
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++;
}
}

Page 119
/*------------------------------------------------------------------*-
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++;
}
}


/*------------------------------------------------------------------*-
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;
}

Page 120
/*------------------------------------------------------------------*-
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>


< PC_LINK_IO_Send_Char() – Continued>
if (Timeout2 == 0)
{
// No error reporting in this simple library...
return;
}
RI = 0;
}
}
Timeout1 = 0;
if (Timeout1 == 0)
{
return;
}
TI = 0;
SBUF = 0x0d; // Output CR
}
<Continued>

Page 121
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)
{
return;
}
} while ((++Timeout2) && (SBUF != XON));
RI = 0;
}
}
<Continued>


Timeout1 = 0;
if (Timeout1 == 0)
{
return;
}
TI = 0;
SBUF = CHARACTER;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/

Page 122
/*------------------------------------------------------------------*-
------------------------------------------------------------------
- This version for project DATA_ACQ (Chapter 9).
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Menu_Data.H"
/*------------------------------------------------------------------*-
sEOS_ISR()
-*------------------------------------------------------------------*/
{
TF2 = 0; // Must manually reset the T2 flag
//===== USER CODE - Begin =======================================

// Call MENU_Command_Processor every 5ms
MENU_Command_Processor();
//===== USER CODE - End =========================================

}
...

Working with MISRA C

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.

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.

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

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)

Page 125
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


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.

Page 126
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.


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.

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.

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

Page 128
All my own work

Page 129
(Blank page)
Page 130
Day 3: Working with modern hardware platforms
Michael J. Pont


Page 131
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;
– Dealing with “long tasks” (without resorting to pre-emption);
– MISRA C.

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)

Page 132
Suppose that we were to compare 1000 embedded systems:
– 500 systems will be based on 8-bit processors
On average, would you expect the 8-bit or 32-bit systems to

be more reliable?

A slightly closer look at timing issues

Page 133
are produced.”
Source: Kopetz, H., “Real-Time Systems: Design Principles for Distributed Embedded Applications”,
(Kluwer Academic Publishers, 2002)

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

Page 134
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

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)

Page 135
A very short history of embedded systems …

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

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

Creating a complete hardware platform

Page 137
Minimal circuit for the 8051

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

Page 138
Example 32-bit processor:
the NXP LPC2378

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

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

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.

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.

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.)

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)

Analogue inputs
20oC
15oC 25oC
10oC 30oC
7805
≤ +24v (DC) + 5v
0.1 uF 50 k pot 0-5v

To ADC
0
0

Page 142
Analogue inputs vs. digital inputs
3000
2000 4000
1894
1000 5000
Up Down

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)

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.

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;
}

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

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)
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.

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.

Page 146
Working with FPGAs:
Introduction

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

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.)
Example: TTE32-HR2
Predictable processor core with 5-stage pipeline

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.

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

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).

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).

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).

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

A. Additional memory and CPU performance

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

What’s wrong with sEOS?

Valve
{
Water
Start {
Switch
Water case INIT:
Pump
Selector
Dial case START:
Washing Drum
Machine Motor
Water Controller case FILL_DRUM:
Level
Sensor
LED
Temperature
Sensor
Door
case WASH_01:
lock
...
Detergent }
Hatch
}
(Interrupt)
1 ms timer

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

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

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

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.

uint32_t Period;
} sTask_t;

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;
}

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)

}

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();
}

Update function: SCH_Update()

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

System_time++;
LOG_Check_Finished(System_time);
#endif
// After interrupt, reset interrupt flag

Sys_Tick_Int_Flag_Reset();
}

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

...


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;
}
}
}
}

Page 157
// Disable system interrupt
if (Tick_count > 0)
{
Tick_count--;
}
else
{
}
// Re-enable system interrupts

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

Sleep function: SCH_Go_To_Sleep()

void SCH_Go_To_Sleep()
{
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);
}
#endif
// Lots of further power saving that can be done ...

// - see user manual
System_Scheduler_Sleep();
}

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

}

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.

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.

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.

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

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)

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

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)
Page 162
Example: JTAG and ARM7TDMI-S

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

Page 163
Example: Why we need timing analysis
are produced.”
Source: Kopetz, H., “Real-Time Systems: Design Principles for Distributed Embedded Applications”,
(Kluwer Academic Publishers, 2002)

Example: Timing analysis

Page 164
Completing your 32-bit design

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 …

Page 165
Working with watchdog timers

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.

Page 166
“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.


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.

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.

Adding a “Heartbeat LED”

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.

Working with high-end hardware:

Running a TTC scheduler on an embedded PC

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

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.

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

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.

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).

Conclusions

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.
– 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.

Suppose that we were to compare 1000 embedded systems:
On average, would you expect the 8-bit or 32-bit systems to

be more reliable?

Page 173
Appendix
(Timing and jitter)

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

Page 174
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


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.

Page 175
All my own work

Page 176
Day 4: Multi-tasking systems
Michael J. Pont


Page 177
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;
– Dealing with “long tasks” (without resorting to pre-emption);
– MISRA C.


Seminar 3:
– The implications of jitter in RT systems
– The implications of a move to 32-bit processors, incl.
– 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

Page 178
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!

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

Page 179
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)

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

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)

Use of a standard RTOS in reliable embedded

systems: Issues and challenges

Page 181
Priority-based pre-emptive scheduling
“Input”
H
M Time
L
“Output”

Challenges caused by shared resources
A ADC
C UART
E Shared data

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

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

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).


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

Page 184
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

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

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

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

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

Priority inversion presents real challenges

Even NASA gets it wrong …
Problems with the Mars Pathfinder mission in 1997

were caused by priority inversion

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 …)

TT solutions

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)

Minimising the use of interrupts
TT systems
A “safe subset”
“Event triggered” systems

with multiple interrupt sources

Page 189
Dynamic (ET) RTOS vs. Static (TT) RTOS
Verification
effort
TT
ET
System size
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

Page 190
The TTH scheduler

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.

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.

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

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;
// ...

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.

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

uint32_t Delay;
// Interval (ticks) between subsequent runs.

uint32_t Period;
} sTask_t;

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
}

Page 194
A closer look at jitter issues for TTH designs

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

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

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].

Page 196
Working with distributed systems
(multiple CPUs)

Multi-processor embedded systems

Multi-processor designs:
– Automotive
– Aerospace
– Medical
– Industrial automation
– Fire alarms
– Intruder alarms
– Computer games
– …
Photo and diagram by Amir Muhammad

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.

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

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

Synchronising clocks on the different nodes

Page 199
Oscillators and processors
Oscillator frequencies will

NOT be identical

The need for synchronised clocks
Portable traffic-light
controller

Page 200
The need for synchronised clocks
Portable traffic-light
controller

Synchronising the clocks
Master Slave 1 Slave 2 Slave N
Tick messages (from Master to Slaves) E.g. CAN bus, RS-485

FlexRay, etc

Page 201
Sharing data between the different nodes

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

Page 202
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)


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.

Page 203
Dealing with errors

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

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

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

Page 205
General reliability concerns

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

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) (Master)
(Master)


B
Actuator Main
Main control
control
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)

Page 207
B
Actuator Main
Main control
control
Actuator
Actuator CC
(Slave) &&user
user interface
interface
(Slave)
(Slave) (Master)
(Master)

Specific reliability issues with shared-clock

(and other TT network protocols)

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

“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

Page 209
CASE STUDY:
S-C scheduling using CAN

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.

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.
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

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.

Node wiring for distributed networks
Can High
120 Ω 120 Ω
Can Low
Node 1 Node 2 Node 3

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.

Master / Slave latency in S-C CAN

Page 213
Master / Slave latency
Tick latency
(varies with baud rate)
Tick Ack
Message Message ...
(Data for S1) (from S1)
Time

Master / Slave jitter in S-C CAN

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 …

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.

Page 215
Reducing jitter in CAN-based S-C networks

Reducing jitter in CAN-based S-C networks

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 …

All my own work


Page 217
(Blank page)
Page 218
Day 5: Case study
Michael J. Pont

In this session, we will complete a detailed case study

(building on the material presented
earlier in the week)

Page 219
Where do we go from here?

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

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
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

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
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
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
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
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
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
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
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
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
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
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
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
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
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

Certified Embedded C Notes V01a

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Certified Embedded C Notes V01a

Загружено:

Авторское право:

Доступные форматы

Certified ‘Embedded C’ Programmer:

Course notes to accompany

Copyright © 2009-2011 TTE Systems Ltd

Release date: 2011-11-09

This document may be distributed freely for non-commercial purposes

MSc in Reliable Embedded Systems

Introduction and overview

Copyright © 2009-2011 TTE Systems Ltd

An embedded system is an application that contains at least one

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

“Deeply embedded” systems

Techniques may be less appropriate for …

Copyright © 2009-2011 TTE Systems Ltd

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

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

Copyright © 2009-2011 TTE Systems Ltd

Structure of this course

If you are studying for an MSc:

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Software and hardware

Our main hardware targets will be:

The techniques discussed can be adapted easily for use with

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Taking control (without an embedded processor)

Control systems (etc)

New hardware design for

Copyright © 2009-2011 TTE Systems Ltd

[Sometimes the hardware

Copyright © 2009-2011 TTE Systems Ltd

Taking control (with an embedded processor)

This is a pretty impressive spec. –

Software changes are thought to be easy …

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Meet the 8051

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

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Meet the 8051

Up to 64 kbytes on-chip ROM 4

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

1 x UART 8 P1.7 P0.6 33

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Clock frequency and performance

Why limit performance?

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Up to 7 interrupt sources: Time

– 2 to 3 timer interrupts Function 1

Copyright © 2009-2011 TTE Systems Ltd

Copyright © 2009-2011 TTE Systems Ltd

Power down modes

Device Normal Idle Power Down

Copyright © 2009-2011 TTE Systems Ltd

Some SFRs are bit addressable

Copyright © 2009-2011 TTE Systems Ltd