Certified Embedded C Notes V01a
Uploaded by
HashCertified Embedded C Notes V01a
Uploaded by
HashCertified ‘Embedded C’ Programmer:
Training materials
Course notes to accompany
training seminars
Michael J. Pont
Copyright © 2009-2011 TTE Systems Ltd
Copyright © 2009-2011 TTE Systems Ltd
Version 3.2
Release date: 2011-11-09
This document may be distributed freely for non-commercial purposes
provided that it is not altered in any way.
Page 2
Day 1: Introduction
Michael J. Pont,
MSc in Reliable Embedded Systems
Module EG7510 (“A1a”)
Introduction and overview
Copyright © 2009-2011 TTE Systems Ltd
2 Licensed to University of Leicester
Page 3
Embedded systems
An embedded system is an application that contains at least one
programmable computer (typically in the form of a microcontroller, a
microprocessor or digital signal processor chip) and which is used
by individuals who are, in the main, unaware that the system is
computer-based.
Source: Pont, M.J., “Patterns for Time-Triggered Embedded Systems”, (Addison-Wesley, 2001)
Copyright © 2009-2011 TTE Systems Ltd
3 Licensed to University of Leicester
Embedded systems
Copyright © 2009-2011 TTE Systems Ltd
4 Licensed to University of Leicester
Page 4
Embedded systems
Copyright © 2009-2011 TTE Systems Ltd
5 Licensed to University of Leicester
“Deeply embedded” systems
Our focus: “deeply embedded” systems
Techniques discussed are appropriate for …
– Aerospace
– Automotive
– Medical
– Railways
– Telecomms
– Industrial / factory control, CMFD …
– Defence …
– Agriculture …
– White goods;
– Brown goods …
– Sports …
– …
Techniques may be less appropriate for …
– Applications in which users add / remove programs
Copyright © 2009-2011 TTE Systems Ltd
6 Licensed to University of Leicester
Page 5
Developing software for reliable embedded systems
This 5-day course is intended to introduce you to a range of
programming techniques which will help you to create
embedded systems which are reliable.
For safety-related or safety-critical systems (e.g. medical
devices) the need for such reliability is obvious:
if the system fails, people may be injured or killed.
For more general “deeply embedded” systems, we believe
that the introduction of the techniques discussed in this course
in your organisation is likely to lead to:
– Reduced testing times
– Reduced warranty costs
Copyright © 2009-2011 TTE Systems Ltd
7 Licensed to University of Leicester
Structure of this course
This course is divided into five individual seminars (this is the
first), plus associated practical sessions.
On most days, we will begin with a seminar (with breaks as
required), then run lab exercises for the rest of the day.
If you are studying for an MSc:
– The exercises that you will be given will contribute up to 40 credits
towards your mark for Module EG7510.
– There will be an exam at the start of the next module.
Copyright © 2009-2011 TTE Systems Ltd
8 Licensed to University of Leicester
Page 6
Structure of this course
Day 1: Introduction and motivation
Day 2: Key software architectures
Day 3: Exploring modern hardware platforms
Day 4: Working with multiple tasks and distributed systems
Day 5: Case study
Copyright © 2009-2011 TTE Systems Ltd
9 Licensed to University of Leicester
Software and hardware
The programming exercises in this module will use ‘C’
Our main hardware targets will be:
A COTS 8051 microcontroller (hardware simulation)
A 32-bit “soft” microcontroller running on an FPGA
The techniques discussed can be adapted easily for use with
any embedded system platform.
Copyright © 2009-2011 TTE Systems Ltd
10 Licensed to University of Leicester
Page 7
The world before embedded processors …
Copyright © 2009-2011 TTE Systems Ltd
11 Licensed to University of Leicester
Taking control (without an embedded processor)
Use discrete components
(transistors, etc) to create
your design
Control systems (etc)
created by “hardware”
designers
New hardware design for
each project Photo by Per Anders
Copyright © 2009-2011 TTE Systems Ltd
12 Licensed to University of Leicester
Page 8
Taking control (with an embedded processor)
Hardware design is still
required – but we may not
require a new hardware
design for each project
Software used to
distinguish behaviour
(feature set) of different
products
[Sometimes the hardware
engineers still create the
software …]
Copyright © 2009-2011 TTE Systems Ltd
13 Licensed to University of Leicester
Taking control (with an embedded processor)
This is a pretty impressive spec. –
but feedback from our customers
suggests that this product would
be even more popular if we could
just make a couple of small
changes to the …
Software changes are thought to be easy …
… we need to create robust designs
which can withstand subsequent changes
Copyright © 2009-2011 TTE Systems Ltd
14 Licensed to University of Leicester
Page 9
Our first target:
the “8051” microcontroller
Copyright © 2009-2011 TTE Systems Ltd
15 Licensed to University of Leicester
Meet the 8051
Developed by Intel in 1980 for embedded applications
Available in various sizes and forms 1 P1.0 VCC 40
2 P1.1 P0.0 39
3 P1.2 P0.1 38
4 P1.3 37
Why start with the 8051? 5 P1.4
P0.2
P0.3 36
6 P1.5 P0.4 35
– A simple “starter processor” 7 P1.6 P0.5 34
– Significant resource constraints 8 P1.7 P0.6 33
‘8051’
9 RST P0.7 32
– Significant performance constraints 10 P3.0 / EA 31
11 P3.1 ALE 30
12 P3.2 / PSEN 29
13 P3.3 P2.7 28
14 P3.4 P2.6 27
15 P3.5 P2.5 26
16 P3.6 P2.4 25
17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
20 VSS P2.0 21
Copyright © 2009-2011 TTE Systems Ltd
16 Licensed to University of Leicester
Page 10
Is the 8051 still useful?
From Infineon
design brochure
(March 2009)
Copyright © 2009-2011 TTE Systems Ltd
17 Licensed to University of Leicester
Meet the 8051
8-bit microcontroller
1 P1.0 VCC 40
128 / 256* bytes on-chip RAM 2 P1.1 P0.0 39
3 P1.2 P0.1 38
Up to 64 kbytes on-chip ROM 4
5
P1.3
P1.4
P0.2
P0.3
37
36
4 x 8-bit bi-directional I/O ports 6
7
P1.5
P1.6
P0.4
P0.5
35
34
1 x UART 8 P1.7 P0.6 33
‘8051’
9 RST P0.7 32
10 31
2 / 3* x 16-bit Counter/timers 11
P3.0
P3.1
/ EA
ALE 30
12 P3.2 29
9 interrupt sources 13 P3.3
/ PSEN
P2.7 28
14 P3.4 P2.6 27
Two-level interrupt priority 15 P3.5 P2.5 26
16 P3.6 P2.4 25
Low-power Idle and power-down modes 17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
20 21
* 8052 specification. VSS P2.0
Copyright © 2009-2011 TTE Systems Ltd
18 Licensed to University of Leicester
Page 11
Minimal circuit for the 8051
Copyright © 2009-2011 TTE Systems Ltd
19 Licensed to University of Leicester
Clock frequency and performance
Standard 8051: 12 oscillator cycles = 1 machine cycle
Higher clock frequency → Higher performance
Higher clock frequency → Higher power usage
Why limit performance?
Not all applications require maximum clock rates
Using the lowest frequency reduces the power requirement.
When accessing low-speed peripherals, programming and
hardware design can be simplified.
The electromagnetic interference (EMI) generated by a circuit
increases with clock frequency.
Copyright © 2009-2011 TTE Systems Ltd
20 Licensed to University of Leicester
Page 12
Adding external memory
16 bit address bus: up to 64kB of external RAM and ROM
28
P 2.7 (A15)
27
P 2.6 (A14)
26
P 2.5 (A13)
25
P 2.4 (A12) 8-bit (upper) address byte
24
P 2.3 (A11)
23
P 2.2 (A10)
22
P 2.1 (A9)
P 2.0 (A8) 21 16-bit
address
‘Standard 8051’
30
ALE
bus
8-bit
Latch (lower)
address
byte
32
P 0.7 (AD7)
33
P 0.6 (AD6)
P 0.5 (AD5) 34
P 0.4 (AD4) 35
36
P 0.3 (AD3)
37
8-bit data bus
P 0.2 (AD2)
P 0.1 (AD1) 38
P 0.0 (AD0) 39
17
P 3.7 (/ RD)
16
P 3.6 (/ WR)
Timing and control lines
/ PSEN 29
Copyright © 2009-2011 TTE Systems Ltd
21 Licensed to University of Leicester
I/O Pins
Standard 8051 has 4 ports (Port 0, Port 1, Port2 and Port3)
Port 0 and Port 2 are used for data / address bus if external
memory is connected
Port 3 pins are shared by the on-board peripherals
– External interrupts
– Serial Transmit and Receive
– Timer gate / counter count control
– External memory read/write control
Port 1 pins do not have any alternate functions
Port 0 pins are open collector
All ports are quasi bi directional*
* If a pin is set high by software, external circuits can pull it low
Copyright © 2009-2011 TTE Systems Ltd
22 Licensed to University of Leicester
Page 13
Timers
Typically two or three 16-bit timers / counters
In timer mode:
Incremented every machine cycle (12 oscillator cycles)
Use to measure time intervals between two events
Use to generate precise hardware delays
Use to generate ‘time out’ facilities
Use to generate regular ‘ticks’
In counter mode:
Incremented on the detection of external events
Use to count number of pulses coming from outside circuitry /
sensor
Copyright © 2009-2011 TTE Systems Ltd
23 Licensed to University of Leicester
Interrupts
Hardware mechanism to notify a
processor of an ‘event’
Background Foreground
Up to 7 interrupt sources: Time
– 2 to 3 timer interrupts Function 1
– 2 external interrupts
t1
– 2 serial interrupts (shared vector) ISR 1
t2
Provide a mechanism for creating Function 1
multitasking applications t3
Function 2
t4
ISR 2
t5
Function 2
Copyright © 2009-2011 TTE Systems Ltd
24 Licensed to University of Leicester
Page 14
Serial Interface
Serial port compatible with RS-232 communication protocol
Possible uses:
Debugging embedded applications using a PC
Communicating with another embedded processor or PC
using RS-232
Load code into the FLASH memory using a serial port
(“In System Programming”)
Copyright © 2009-2011 TTE Systems Ltd
25 Licensed to University of Leicester
Power down modes
Device Normal Idle Power Down
Intel 8051 160 mA - -
Atmel 89S53 11 mA 2 mA 60 uA
Dallas 87C520 15 mA 8 mA 50 µA
Intel 80C51 16 mA 4 mA 50 µA
*12 MHz clock source
Idle Mode
Only the peripherals are kept running (active clock)
CPU state and contents of RAM are preserved
Exit by an enabled interrupt or a hardware reset
Power Down Mode
Oscillator is stopped
Contents of RAM are preserved
Exit by hardware reset only
Copyright © 2009-2011 TTE Systems Ltd
26 Licensed to University of Leicester
Page 15
Special Function Registers
SFRs are used to interface with the peripherals in the 8051
SFRs are mapped in a special area of the memory
(address 0x80-0xFF)
– Example: Port 2 SFR is at 0xA0
To use the peripherals, the software needs to read from /
write to the corresponding SFRs
– Examples
To read the Timer 1 value, we read the TH1 and TL1 SFRs
To write to Port 1, we write to the P1 SFR
Some SFRs are bit addressable
Copyright © 2009-2011 TTE Systems Ltd
27 Licensed to University of Leicester
Why use the C language?
Copyright © 2009-2011 TTE Systems Ltd
28 Licensed to University of Leicester
Page 16
Why use the ‘C’ language?
It is a ‘mid-level’ language, with ‘high-level’ features (such as support for
functions and modules), and ‘low-level’ features (such as good access to
hardware via pointers);
It is very efficient, popular and well understood;
Even desktop developers who have used only Java or C++ can soon
understand C syntax;
Good, well-proven compilers are available for every embedded processor
(8-bit to 32-bit or more);
Experienced staff are available;
Books, training courses, code samples and WWW sites discussing the use
of the language are all widely available.
Overall, C may not be a perfect language for developing embedded
systems - but it is a good choice (and it is unlikely that a ‘perfect’ language
will ever be created).
Copyright © 2009-2011 TTE Systems Ltd
29 Licensed to University of Leicester
Using the C language (Simple example)
int Sum_of_Squares1(int a, int b)
{
/* No checking … */
int Square1 = a*a;
int Square2 = b*b;
return Square1 + Square2;
}
Copyright © 2009-2011 TTE Systems Ltd
30 Licensed to University of Leicester
Page 17
Using the C language (Simple example)
int Sum_of_Squares1(const int A, const int B)
{
/* No checking … */
int Square1 = A*A;
int Square2 = B*B;
return Square1 + Square2;
}
Copyright © 2009-2011 TTE Systems Ltd
31 Licensed to University of Leicester
Using the C language (Simple example)
void Sum_of_Squares1(const int A, const int B, int* sum_PTR)
{
/* No checking … */
int Square1 = A*A;
int Square2 = B*B;
*sum_PTR = Square1 + Square2;
}
Copyright © 2009-2011 TTE Systems Ltd
32 Licensed to University of Leicester
Page 18
Using the C language (Simple example)
void Sum_of_Squares1(const int A, const int B, int* const sum_PTR)
{
/* No checking … */
int Square1 = A*A;
int Square2 = B*B;
*sum_PTR = Square1 + Square2;
}
Copyright © 2009-2011 TTE Systems Ltd
33 Licensed to University of Leicester
Using the C language (Simple example)
uint8_t Test(void(* pFunction)())
{
uint8_t index = 0;
...
SCH_tasks[index].pTask = pFunction;
...
(*SCH_tasks[index].pTask)();
...
Copyright © 2009-2011 TTE Systems Ltd
34 Licensed to University of Leicester
Page 19
Software architecture for a
simple embedded system
Copyright © 2009-2011 TTE Systems Ltd
35 Licensed to University of Leicester
Typical software architecture for a “desktop” processor
Word Processor
OS provides ‘common code’ for:
• Graphics
Operating System
• Printing
• File storage
• Sound
BIOS
• ...
Hardware
Copyright © 2009-2011 TTE Systems Ltd
36 Licensed to University of Leicester
Page 20
Typical code structure for desktop processor
Desktop code
Function
Function 4
2 Function
Function 5
1
Function Function
3 6
Copyright © 2009-2011 TTE Systems Ltd
37 Licensed to University of Leicester
Basic software architecture for deeply-embedded processor
Temperature
sensor
Central
heating Boiler
controller
Temperature
dial
int main(void)
{
C_HEAT_Init();// Init the system
while(1) // 'for ever' (Super Loop)
{
C_HEAT_Get_Required_Temperature(); // Get input from the user
C_HEAT_Get_Actual_Temperature(); // Find out current room temperature
C_HEAT_Control_Boiler(); // Adjust the gas burner
}
return 1;
}
Copyright © 2009-2011 TTE Systems Ltd
38 Licensed to University of Leicester
Page 21
Task-oriented software engineering?
void C_HEAT_Get_Required_Temperature(void);
This can be viewed as a task, implemented as a C function
We will use a range of different operating systems and
schedulers to call these functions (or “release” these tasks)
More specifically:
– Most of our systems will be built from “void void” functions;
– Data transfer between tasks will be carried out using global variables
Copyright © 2009-2011 TTE Systems Ltd
39 Licensed to University of Leicester
Task-oriented software engineering?
Embedded code
Task 1 Task 2 Task 3 Task 4
Function Function
1 2
Copyright © 2009-2011 TTE Systems Ltd
40 Licensed to University of Leicester
Page 22
Example:
Working with switches
Copyright © 2009-2011 TTE Systems Ltd
41 Licensed to University of Leicester
Switches and embedded systems
Input from a user:
On Off 1 2 3 Start Engage AP
4 5 6 Temporary Manual
1 2 3 4 5 Disengage AP
7 8 9
STOP
0 Enter < > Up and Around
Other information from the operating environment:
Copyright © 2009-2011 TTE Systems Ltd
42 Licensed to University of Leicester
Page 23
Working with 8051 port pins
The I/O ports are controlled using the specific Special
Function Registers (SFR) for the individual ports
// Ports
sfr P0 = 0x80;
sfr P1 = 0x90;
sfr P2 = 0xA0;
sfr P3 = 0xB0;
Write 1s to the pins of a port that you want to use as input
External logic should be designed to pull a pin low
Note: if a pin is set to “low” by software and pulled “high” by
external hardware, you can damage the microcontroller
P1 = 0xFF; // Prepare port for input
Port_data = P1; // Store the state of the pins in the variable
Copyright © 2009-2011 TTE Systems Ltd
43 Licensed to University of Leicester
Writing to the port pins
/* Port SFRs */
sfr P1 = 0x90;
/* Write 11111111 */
P1 = 0xFF;
/* Write 00001111 */
P1 = 0x0F;
Copyright © 2009-2011 TTE Systems Ltd
44 Licensed to University of Leicester
Page 24
Review: “Hex”
Hexadecimal (base 16) Binary (base 2) Decimal (base 10)
0x00 00000000 0
0xFF 11111111 255
0x0F 00001111 15
0xF0 11110000 240
0xAA 10101010 170
0xFFFF 1111111111111111 65535
0xFFAA 1111111110101010 65450
See “Embedded C”, Chapter 2
Copyright © 2009-2011 TTE Systems Ltd
45 Licensed to University of Leicester
Reading bytes
/*---------------------------------------------------------*-
Bytes.C (v1.00)
----------------------------------------------------------
Reads from P1 and copies the value to P2.
-*---------------------------------------------------------*/
#include <reg52.H>
void main (void)
The input port
{
unsigned char Port1_value; The output port
// Must set up P1 for reading
P1 = 0xFF;
while(1)
{
// Read the value of P1
Port1_value = P1;
// Copy the value to P2
P2 = Port1_value;
}
}
Copyright © 2009-2011 TTE Systems Ltd
46 Licensed to University of Leicester
Page 25
Reading bits (8051)
/*------------------------------------------------------------------*-
Bits1.C (v1.00)
------------------------------------------------------------------
Reading and writing individual port pins.
NOTE: Both pins on the same port
-*------------------------------------------------------------------*/
#include <Reg52.H>
sbit Switch_pin = P1^0; “sbit” variable declaration. The symbol ‘^’ is used,
sbit LED_pin = P1^1; but the XOR bitwise operator is NOT involved
void main (void)
{
bit x;
// Set switch pin for reading
Switch_pin = 1;
while(1)
{
x = Switch_pin; // Read Pin 1.0
LED_pin = x; // Write to Pin 1.1
}
}
Copyright © 2009-2011 TTE Systems Ltd
47 Licensed to University of Leicester
Reading bits - Generic
Operator Description Example: (x = 11111110)
& Bitwise AND x & 0x0f = 00001110
| Bitwise OR (inclusive OR) x | 0x0f = 11111111
^ Bitwise XOR (exclusive OR) x ^ 0x0f = 11110001
<< Left shift x <<= 1 = 11111100
>> Right shift x >>= 4 = 00001111
~ One’s complement ~x = 00000001
Copyright © 2009-2011 TTE Systems Ltd
48 Licensed to University of Leicester
Page 26
Reading bits - Generic
#include <reg52.H>
// Function prototypes
void Write_Bit_P1(const unsigned char, const bit);
bit Read_Bit_P1(const unsigned char);
int main (void)
{
bit x;
while(1)
{
x = Read_Bit_P1(0); // Read Port 1, Pin 0
Write_Bit_P1(1,x); // Write to Port 1, Pin 1
}
return 0;
}
Copyright © 2009-2011 TTE Systems Ltd
49 Licensed to University of Leicester
Reading bits – Generic
void Write_Bit_P1(const unsigned char PIN, const bit VALUE)
{
unsigned char p = 0x01; // 00000001
// Left shift appropriate number of places
p <<= PIN;
// If we want 1 output at this pin
if (VALUE == 1)
{
P1 |= p; // Bitwise OR
return;
}
// If we want 0 output at this pin
p = ~p; // Complement
P1 &= p; // Bitwise AND
}
/* --------------------------------------------------------------- */
bit Read_Bit_P1(const unsigned char PIN)
{
unsigned char p = 0x01; // 00000001
// Left shift appropriate number of places
p <<= PIN;
// Write a 1 to the pin (to set up for reading)
Write_Bit_P1(PIN, 1);
// Read the pin (bitwise AND) and return
return (P1 & p);
}
Copyright © 2009-2011 TTE Systems Ltd
50 Licensed to University of Leicester
Page 27
Need for switch de-bouncing
Upon press or release, all mechanical switch contacts bounce
+5v
Voltage
+5v
t1 t2 Time
This creates challenges for the software design
– Counting the number of times that a switch is pressed gets tricky (e.g.
Rather than reading ‘A’ from a keypad, we may read ‘AAAAA’)
– If a switch is depressed once, and then released some time later, the
‘bounce’ could make the release seem like a second press.
Copyright © 2009-2011 TTE Systems Ltd
51 Licensed to University of Leicester
ASIDE: Which type of switch should you use?
On Off
Copyright © 2009-2011 TTE Systems Ltd
52 Licensed to University of Leicester
Page 28
Basic software for switch debouncing
Creating some simple software to check for a valid switch
input is straightforward:
1. We read the relevant port pin.
2. If we think we have detected a switch depression, we wait for
debounce period* (usually 20ms to 50ms) and then read the
pin again.
3. If the second reading confirms the first reading, we assume
the switch really has been depressed.
* Debounce period ≥ mechanical bounce period of the switch
Copyright © 2009-2011 TTE Systems Ltd
53 Licensed to University of Leicester
Code for switch state check with debouncing
/*------------------------------------------------------------------*-
SWITCH_Get_Input()
Reads and debounces a mechanical switch as follows:
1. If switch is not pressed, return SWITCH_NOT_PRESSED.
2. If switch is pressed, wait for DEBOUNCE_PERIOD (in ms).
a. If switch is not pressed, return SWITCH_NOT_PRESSED.
b. If switch is pressed, return SWITCH_PRESSED
See Switch_Wait.H for details of return values.
-*------------------------------------------------------------------*/
bit SWITCH_Get_Input(const unsigned char DEBOUNCE_PERIOD)
{
bit Return_value = SWITCH_NOT_PRESSED;
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_LOOP_Wait(DEBOUNCE_PERIOD);
// Check switch again
if (Switch_pin == 0)
{
Return_value = SWITCH_PRESSED;
}
}
// Now return switch value
return Return_value;
}
Copyright © 2009-2011 TTE Systems Ltd
54 Licensed to University of Leicester
Page 29
Implications of this code
Can be used to check the state of a switch
(is the switch pressed?)
Problems can arise whenever a switch is pressed for a period
longer than the debounce interval (typical switch presses are
at least 500ms or until user gets feedback from the system)
A user typing “Hello” on a keypad may see:
– “HHHHHHHHHeeeeeeeeellllllllllllllllooooooooooo” appear on the
screen.
Copyright © 2009-2011 TTE Systems Ltd
55 Licensed to University of Leicester
Using switches in real systems:
Counting goats …
Copyright © 2009-2011 TTE Systems Ltd
56 Licensed to University of Leicester
Page 30
Counting goats
Mechanical sensor
at goat body
height
Sensor
Goat detected
Copyright © 2009-2011 TTE Systems Ltd
57 Licensed to University of Leicester
Counting goats
/*------------------------------------------------------------------*-
Switch_count.C (v1.00)
------------------------------------------------------------------
A 'goat counting' program for the 8051...
-*------------------------------------------------------------------*/
#include <Reg52.h>
// Connect switch to this pin
sbit Switch_pin = P1^0;
// Display count (binary) on this port
#define Count_port P3
// Return values from Switch_Get_Input()
#define SWITCH_NOT_PRESSED (bit) 0
#define SWITCH_PRESSED (bit) 1
// Function prototypes
void SWITCH_Init(void);
bit SWITCH_Get_Input(const unsigned char DEBOUNCE_PERIOD);
void DISPLAY_COUNT_Init(void);
void DISPLAY_COUNT_Update(const unsigned char);
void DELAY_LOOP_Wait(const unsigned int DELAY_MS);
Copyright © 2009-2011 TTE Systems Ltd
58 Licensed to University of Leicester
Page 31
Counting goats
/* ---------------------------------------------------------------- */
void main(void)
{
unsigned char Switch_presses = 0;
// Init functions
SWITCH_Init();
DISPLAY_COUNT_Init();
while(1)
{
if (SWITCH_Get_Input(30) == SWITCH_PRESSED)
{
Switch_presses++;
}
DISPLAY_COUNT_Update(Switch_presses);
}
}
/*------------------------------------------------------------------*-
SWITCH_Init()
Initialisation function for the switch library.
-*------------------------------------------------------------------*/
void SWITCH_Init(void)
{
Switch_pin = 1; // Use this pin for input
}
Copyright © 2009-2011 TTE Systems Ltd
59 Licensed to University of Leicester
Counting goats
/*------------------------------------------------------------------*-
SWITCH_Get_Input()
Reads and debounces a mechanical switch as follows:
1. If switch is not pressed, return SWITCH_NOT_PRESSED.
2. If switch is pressed, wait for DEBOUNCE_PERIOD (in ms).
a. If switch is not pressed, return SWITCH_NOT_PRESSED.
b. If switch is pressed, wait (indefinitely) for
switch to be released, then return SWITCH_PRESSED
-*------------------------------------------------------------------*/
bit SWITCH_Get_Input(const unsigned char DEBOUNCE_PERIOD)
{
bit Return_value = SWITCH_NOT_PRESSED;
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_LOOP_Wait(DEBOUNCE_PERIOD);
// Check switch again
if (Switch_pin == 0)
{
// Wait until the switch is released.
while (Switch_pin == 0);
Return_value = SWITCH_PRESSED;
}
}
// Now (finally) return switch value
return Return_value;
}
Copyright © 2009-2011 TTE Systems Ltd
60 Licensed to University of Leicester
Page 32
Counting goats
/*------------------------------------------------------------------*-
Initialisation function for the DISAPLY COUNT library.
-*------------------------------------------------------------------*/
void DISPLAY_COUNT_Init(void)
{
Count_port = 0x00;
}
/*------------------------------------------------------------------*-
Simple function to display data (COUNT) on LEDs connected to Count_Port
-*------------------------------------------------------------------*/
void DISPLAY_COUNT_Update(const unsigned char COUNT)
{
Count_port = COUNT;
}
/*------------------------------------------------------------------*-
DELAY_LOOP_Wait()
Delay duration varies with parameter.
Parameter is, *ROUGHLY*, the delay, in milliseconds, on 12MHz 8051
-*------------------------------------------------------------------*/
void DELAY_LOOP_Wait(const unsigned int DELAY_MS)
{
unsigned int x, y;
for (x = 0; x <= DELAY_MS; x++)
{
for (y = 0; y <= 120; y++);
}
}
Copyright © 2009-2011 TTE Systems Ltd
61 Licensed to University of Leicester
Counting goats (simulation)
The number of goats (in binary)
The switch input (Pin 1.0)
Copyright © 2009-2011 TTE Systems Ltd
62 Licensed to University of Leicester
Page 33
Switch hardware
Copyright © 2009-2011 TTE Systems Ltd
63 Licensed to University of Leicester
Switches and pull-up resistors
Vcc
When the switch is open, pin is at logic level high.
An external (Port 0) or internal resistor (other ports)
10KΩ
‘pulls up’ the pin to the supply voltage of the
To pin on:
microcontroller (typically 5V). Port 0.
On reading the pin, we will see the value ‘1’.
When the switch is closed (pressed), the pin voltage
To pin on:
will be 0V. Port 1,
Port 2,
or
Port 3.
On reading the pin, we will see the value ‘0’
Copyright © 2009-2011 TTE Systems Ltd
64 Licensed to University of Leicester
Page 34
Switches and pull-up resistors
With pull up resistors:
Vcc Vcc
Switch released: Switch pressed:
Reads ‘1’ Reads ‘0’
Without pull up resistors:
Vcc Vcc
Switch released: Switch pressed:
Reads ‘0’ Reads ‘0’
Copyright © 2009-2011 TTE Systems Ltd
65 Licensed to University of Leicester
Adding structure to your code
Copyright © 2009-2011 TTE Systems Ltd
66 Licensed to University of Leicester
Page 35
Adding structure to your code
To stay competitive in today’s environment:
1. Reuse code as much as possible
2. Write code easy to understand now and in the future
Outline
Benefits of Object Oriented (O-O) programming
O-O and C?
Project header file
Port header file
Look at case studies
Copyright © 2009-2011 TTE Systems Ltd
67 Licensed to University of Leicester
Views on object-oriented code
“[The phrase] ‘object-oriented’ has become almost synonymous
with modernity, goodness and worth in information technology
circles.” – Graham
“One main claimed advantage of using object orientation is that
an OO model closely represents the problem domain, which
makes it easier to produce and understand designs.” – Jalote
Graham, I. (1994) “Object-Oriented Methods,” (2nd Ed.) Addison-Wesley. Page 1.
Jalote, P. (1997) “An Integrated Approach to Software Engineering”, (2nd Ed.) Springer-
Verlag. Page 273.
Copyright © 2009-2011 TTE Systems Ltd
68 Licensed to University of Leicester
Page 36
Comparison of regular C and O-O C++
int Xyz; class cClass
{
// Assigning a value public:
Xyz = 3; int Get_Xyz(void) const;
void Set_Xyz(int);
// Displaying the value of the variable private:
printf(“%d”, Xyz); int _Xyz; // Encapsulated data
};
// Creating an instance of the class
cClass abc;
// Assigning a value
abc.Set_Xyz(3);
// Displaying the value of the object
cout << abc.Get_Xyz();
Copyright © 2009-2011 TTE Systems Ltd
69 Licensed to University of Leicester
Comparison of regular C and O-O C++
_Xyz is accessible only through the class (member) functions
Xyz in C is not protected
Protection provided O-O languages may result in higher
overheads (either in CPU time for “normal” functions
or in code size for “inline” functions).
Copyright © 2009-2011 TTE Systems Ltd
70 Licensed to University of Leicester
Page 37
Object Oriented C?
Modular file based classes
// BEGIN: File XYZ.C
Header file
// Define “file global” variable
static int Xyz; Serial.C
Serial.C
Xyz = 3; All
All
program
program
...
code Header file
code
printf(“%d”, Xyz); in
in aa
single Switch.C
Switch.C
// END: File XYZ.C single
source
source
file
file Header file
“File global” variables and
functions, like the variable Xyz, sEOS.C
sEOS.C
are visible only inside the XYZ.C
file.
Copyright © 2009-2011 TTE Systems Ltd
71 Licensed to University of Leicester
Example: PC_IO library
Please concentrate on the library structure only!
Public ‘member’ functions, (e.g. PC_LINK_IO_Write_String_To_Buffer())
have their prototypes in the H file.
Private ‘member’ functions, (e.g. PC_LINK_IO_Send_Char()) have their
prototypes in the C file.
A public constant (e.g. PC_LINK_IO_NO_CHAR), with a value which must
be accessed by the rest of the program is in the H file.
A limited number of public variables (e.g. In_read_index_G), are defined in
the C file (without the static keyword) – to access these variables in
another file, the keyword extern is added before their declaration in the
other C file (e.g. extern tByte In_read_index_G;).
Numerous private constants and private variables (e.g.
RECV_BUFFER_LENGTH) are defined / declared in the C file and are
‘invisible’ outside this file.
Copyright © 2009-2011 TTE Systems Ltd
72 Licensed to University of Leicester
Page 38
PC_IO.H
/*------------------------------------------------------------------*-
PC_IO.H (v1.00)
------------------------------------------------------------------
- see PC_IO.C for details.
-*------------------------------------------------------------------*/
#ifndef _PC_IO_H
#define _PC_IO_H
// ------ Public constants -----------------------------------------
// Value returned by PC_LINK_Get_Char_From_Buffer if no character is
// available in buffer
#define PC_LINK_IO_NO_CHAR 127
// ------ Public function prototypes -------------------------------
void PC_LINK_IO_Write_String_To_Buffer(const char* const);
void PC_LINK_IO_Write_Char_To_Buffer(const char);
char PC_LINK_IO_Get_Char_From_Buffer(void);
// Must call this function frequently ...
void PC_LINK_IO_Update(void);
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
73 Licensed to University of Leicester
PC_IO.C
/*------------------------------------------------------------------*-
PC_IO.C (v1.00)
------------------------------------------------------------------
Core files for simple PC link library for 8051 family
Uses the USART, and Pins 3.1 (Tx) and 3.0 (Rx)
[INCOMPLETE - STRUCTURE ONLY - see Chap 9 for complete library]
-*------------------------------------------------------------------*/
#include "Main.H"
#include "PC_IO.H"
// ------ Public variable definitions ------------------------------
tByte In_read_index_G; // Data in buffer that has been read
tByte In_waiting_index_G; // Data in buffer not yet read
tByte Out_written_index_G; // Data in buffer that has been written
tByte Out_waiting_index_G; // Data in buffer not yet written
// ------ Private function prototypes ------------------------------
static void PC_LINK_IO_Send_Char(const char);
// ------ Private constants ----------------------------------------
// The receive buffer length
#define RECV_BUFFER_LENGTH 8
// The transmit buffer length
#define TRAN_BUFFER_LENGTH 50
#define XON 0x11
#define XOFF 0x13
Copyright © 2009-2011 TTE Systems Ltd
74 Licensed to University of Leicester
Page 39
PC_IO.C
// ------ Private variables ----------------------------------------
static tByte Recv_buffer[RECV_BUFFER_LENGTH];
static tByte Tran_buffer[TRAN_BUFFER_LENGTH];
/*------------------------------------------------------------------*/
void PC_LINK_IO_Update(...)
{
...
}
/*------------------------------------------------------------------*/
void PC_LINK_IO_Write_Char_To_Buffer(...)
{
...
}
/*------------------------------------------------------------------*/
void PC_LINK_IO_Write_String_To_Buffer(...)
{
...
}
Copyright © 2009-2011 TTE Systems Ltd
75 Licensed to University of Leicester
PC_IO.C
/*------------------------------------------------------------------*/
char PC_LINK_IO_Get_Char_From_Buffer(...)
{
...
}
/*------------------------------------------------------------------*/
void PC_LINK_IO_Send_Char(...)
{
...
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
76 Licensed to University of Leicester
Page 40
Project Header - MAIN.H
Groups the key information about the device you have used,
along with other key parameters (e.g. Oscillator frequency)
‘Do not duplicate information in numerous files; place the
information in one place, and refer to it where necessary’ (Date)
Advantages
Easier to read code
Easier to port to other devices
Date, C.J. (1999) “An Introduction to Database Systems,” (7th Ed.). Addison-Wesley.
Copyright © 2009-2011 TTE Systems Ltd
77 Licensed to University of Leicester
Example MAIN.H
/*------------------------------------------------------------------*-
Main.H (v1.00)
------------------------------------------------------------------
'Project Header' for project HELLO2 (see Chap 5)
-*------------------------------------------------------------------*/
#ifndef _MAIN_H
#define _MAIN_H
//------------------------------------------------------------------
// WILL NEED TO EDIT THIS SECTION FOR EVERY PROJECT
//------------------------------------------------------------------
// Must include the appropriate microcontroller header file here
#include <reg52.h> Device specific header file with all SFR declarations
// Oscillator / resonator frequency (in Hz) e.g. (11059200UL)
#define OSC_FREQ (12000000UL)
Clock frequency used for the project
// Number of oscillations per instruction (12, etc)
// 12 - Original 8051 / 8052 and numerous modern versions
// 6 - Various Infineon and Philips devices, etc.
// 4 - Dallas 320, 520 etc.
// 1 - Dallas 420, etc.
#define OSC_PER_INST (12) Core’s machine cycle length (Device dependent)
Copyright © 2009-2011 TTE Systems Ltd
78 Licensed to University of Leicester
Page 41
Example MAIN.H
//------------------------------------------------------------------
// SHOULD NOT NEED TO EDIT THE SECTIONS BELOW
//------------------------------------------------------------------
// Typedefs (see Chap 5)
typedef unsigned char tByte;
typedef unsigned int tWord; Type definitions
typedef unsigned long tLong;
// Interrupts (see Chap 7)
#define INTERRUPT_Timer_0_Overflow 1
#define INTERRUPT_Timer_1_Overflow 3
#define INTERRUPT_Timer_2_Overflow 5
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
79 Licensed to University of Leicester
Port header file (PORT.H)
Groups all the pin allocations to a single file for the project.
Avoids potential conflicts
// ----- Port.H -----
// File A // Port access for File B
... #define Port_B = P0;
sbit Pin_A = P3^2; // Port access for File A
sbit Pin_A = P3^2;
...
// Port access for File C
sbit Pin_C = P2^7;
// File B
...
...
#define Port_B = P0; // File A
#include “port.h”
... ...
// File C // File B
... #include “port.h”
...
sbit Pin_C = P2^7;
// File C
... #include “port.h”
...
Copyright © 2009-2011 TTE Systems Ltd
80 Licensed to University of Leicester
Page 42
Case study
Copyright © 2009-2011 TTE Systems Ltd
81 Licensed to University of Leicester
O-O version of goat counting
List of files
main.h
port.h
main.c
switch_wait.h
switch_wait.c
display_count.h
display_count.c
delay_loop.h
delay_loop.c
Copyright © 2009-2011 TTE Systems Ltd
82 Licensed to University of Leicester
Page 43
O-O goat counting (MAIN.H)
/*------------------------------------------------------------------*-
Main.H (v1.00)
------------------------------------------------------------------
'Project Header' for project HELLO2 (see Chap 5)
-*------------------------------------------------------------------*/
#ifndef _MAIN_H
#define _MAIN_H
//------------------------------------------------------------------
// WILL NEED TO EDIT THIS SECTION FOR EVERY PROJECT
//------------------------------------------------------------------
// Must include the appropriate microcontroller header file here
#include <reg52.h>
// Oscillator / resonator frequency (in Hz) e.g. (11059200UL)
#define OSC_FREQ (12000000UL)
// Number of oscillations per instruction (12, etc)
// 12 - Original 8051 / 8052 and numerous modern versions
// 6 - Various Infineon and Philips devices, etc.
// 4 - Dallas 320, 520 etc.
// 1 - Dallas 420, etc.
#define OSC_PER_INST (12)
Copyright © 2009-2011 TTE Systems Ltd
83 Licensed to University of Leicester
O-O goat counting (MAIN.H – Cont.)
//------------------------------------------------------------------
// SHOULD NOT NEED TO EDIT THE SECTIONS BELOW
//------------------------------------------------------------------
// Typedefs (see Chap 5)
typedef unsigned char tByte;
typedef unsigned int tWord;
typedef unsigned long tLong;
// Interrupts (see Chap 7)
#define INTERRUPT_Timer_0_Overflow 1
#define INTERRUPT_Timer_1_Overflow 3
#define INTERRUPT_Timer_2_Overflow 5
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
84 Licensed to University of Leicester
Page 44
O-O goat counting (PORT.H)
/*------------------------------------------------------------------*-
Port.H (v1.00)
------------------------------------------------------------------
'Port Header' for project GOATS2 (see Chap 5)
-*------------------------------------------------------------------*/
#ifndef _PORT_H
#define _PORT_H
// ------ Switch_Wait.C -----------------------------------------------
// Connect switch to this pin
sbit Switch_pin = P1^0;
// ------ Display_count.C -----------------------------------------------
// Display count (binary) on this port
#define Count_port P3
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
85 Licensed to University of Leicester
O-O goat counting (MAIN.C)
/*------------------------------------------------------------------*-
Main.C (v1.00)
------------------------------------------------------------------
A 'switch count' program for the 8051.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Switch_wait.H"
#include "Display_count.H"
/* ---------------------------------------------------------------- */
void main(void)
{
tByte Switch_presses = 0;
// Init functions
SWITCH_Init();
DISPLAY_COUNT_Init();
while(1)
{
if (SWITCH_Get_Input(30) == SWITCH_PRESSED)
{
Switch_presses++;
}
DISPLAY_COUNT_Update(Switch_presses);
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
86 Licensed to University of Leicester
Page 45
O-O goat counting (SWITCH_WAIT.H)
/*------------------------------------------------------------------*-
Switch_wait.H (v1.00)
------------------------------------------------------------------
- See Switch_wait.C for details.
-*------------------------------------------------------------------*/
#ifndef _SWITCH_WAIT_H
#define _SWITCH_WAIT_H
// ------ Public constants -----------------------------------------
// Return values from Switch_Get_Input()
#define SWITCH_NOT_PRESSED (bit) 0
#define SWITCH_PRESSED (bit) 1
// ------ Public function prototype --------------------------------
void SWITCH_Init(void);
bit SWITCH_Get_Input(const tByte DEBOUNCE_PERIOD);
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
87 Licensed to University of Leicester
O-O goat counting (SWITCH_WAIT.C)
/*------------------------------------------------------------------*-
Switch_Wait.C (v1.00)
------------------------------------------------------------------
Simple library for debouncing a switch input.
NOTE: Duration of function is highly variable!
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Switch_wait.h"
#include "Delay_loop.h"
/*------------------------------------------------------------------*-
SWITCH_Init()
Initialisation function for the switch library.
-*------------------------------------------------------------------*/
void SWITCH_Init(void)
{
Switch_pin = 1; // Use this pin for input
}
Copyright © 2009-2011 TTE Systems Ltd
88 Licensed to University of Leicester
Page 46
O-O goat counting (SWITCH_WAIT.C – Cont.)
/*------------------------------------------------------------------*-
SWITCH_Get_Input()
Reads and debounces a mechanical switch
See Switch_Wait.H for details of return values.
-*------------------------------------------------------------------*/
bit SWITCH_Get_Input(const tByte DEBOUNCE_PERIOD)
{
bit Return_value = SWITCH_NOT_PRESSED;
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_LOOP_Wait(DEBOUNCE_PERIOD);
// Check switch again
if (Switch_pin == 0)
{
// Wait until the switch is released.
while (Switch_pin == 0);
Return_value = SWITCH_PRESSED;
}
}
// Now (finally) return switch value
return Return_value;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
89 Licensed to University of Leicester
O-O goat counting (DISPLAY_COUNT.H)
/*------------------------------------------------------------------*-
Display_count.H (v1.00)
------------------------------------------------------------------
- See Display_count.C for details.
-*------------------------------------------------------------------*/
#ifndef _DISPLAY_COUNT_H
#define _DISPLAY_COUNT_H
// ------ Public function prototypes -------------------------------
void DISPLAY_COUNT_Init(void);
void DISPLAY_COUNT_Update(const tByte);
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
90 Licensed to University of Leicester
Page 47
O-O goat counting (DISPLAY_COUNT.C)
/*------------------------------------------------------------------*-
Display_count.C (v1.00)
------------------------------------------------------------------
Display an unsigned char on a port.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Display_Count.H"
/*------------------------------------------------------------------*-
DISPLAY_COUNT_Init()
Initialisation function for the DISPLAY COUNT library.
-*------------------------------------------------------------------*/
void DISPLAY_COUNT_Init(void)
{
Count_port = 0x00;
}
/*------------------------------------------------------------------*-
DISPLAY_COUNT_Update()
Simple function to display tByte data (COUNT)
on LEDs connected to port (Count_Port)
-*------------------------------------------------------------------*/
void DISPLAY_COUNT_Update(const tByte COUNT)
{
Count_port = COUNT;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
91 Licensed to University of Leicester
O-O goat counting (DELAY_LOOP.H)
/*------------------------------------------------------------------*-
Delay_Loop.H (v1.00)
------------------------------------------------------------------
- See Delay_Loop.C for details.
-*------------------------------------------------------------------*/
#ifndef _DELAY_LOOP_H
#define _DELAY_LOOP_H
// ------ Public function prototype --------------------------------
void DELAY_LOOP_Wait(const tWord DELAY_MS);
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
92 Licensed to University of Leicester
Page 48
O-O goat counting (DELAY_LOOP.C)
/*------------------------------------------------------------------*-
Delay_Loop.C (v1.00)
------------------------------------------------------------------
Create a simple software delay using a loop.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Delay_loop.h"
/*------------------------------------------------------------------*-
DELAY_LOOP_Wait()
Delay duration varies with parameter.
Parameter is, *ROUGHLY*, the delay, in milliseconds,
on 12MHz 8051 (12 osc cycles).
You need to adjust the timing for your application!
-*------------------------------------------------------------------*/
void DELAY_LOOP_Wait(const tWord DELAY_MS)
{
tWord x, y;
for (x = 0; x <= DELAY_MS; x++)
{
for (y = 0; y <= 120; y++);
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
93 Licensed to University of Leicester
What does “real time” really mean?
Copyright © 2009-2011 TTE Systems Ltd
94 Licensed to University of Leicester
Page 49
Real-time systems vs. embedded systems
“A real-time computer system is a computer system in which the
correctness of the system behaviour depends not only on the logical results
of the computations, but also on the physical instant at which these results
are produced.
A real-time computer system is always part of a larger system – this larger
system is called a real-time system.”
Source: Kopetz, H., “Real-Time Systems: Design Principles for Distributed Embedded Applications”, (Kluwer
Academic Publishers, 2002)
Copyright © 2009-2011 TTE Systems Ltd
95 Licensed to University of Leicester
Real-time systems vs. embedded systems
One way of classifying real-time systems:
– Hard real-time: we guarantee that the processing will meet all deadlines
If this specification is not met, then the system is considered useless.
Example: autopilot system in an aircraft
– Soft real-time systems: we can tolerate some missed deadlines
Example: live audio-video systems where a delay in processing may result in
degraded quality but not a catastrophe
Copyright © 2009-2011 TTE Systems Ltd
96 Licensed to University of Leicester
Page 50
The importance of real-time systems
x, y, z = position coordinates
q υ, β, ϖ = velocity cordinates
p = roll rate
q = pitch rate
y,β Rudder
r = yaw rate
δr
Elevator
δe
Aileron
x,υ δa
Yaw (rate)
sensor
p
Pitch z,ϖ
(rate) Rudder
sensor
Roll r
(rate) Elevator
sensor Aircraft
Autopilot
System
Main
pilot Aileron
controls
Position Main engine
sensors (fuel)
(GPS) controllers
Velocity
sensors
(3 axes)
Copyright © 2009-2011 TTE Systems Ltd
97 Licensed to University of Leicester
Requirements
Software running “as fast as possible” not good enough!
Need guarantees in operation (timing).
Failure to meet timing requirements makes the
system useless
Copyright © 2009-2011 TTE Systems Ltd
98 Licensed to University of Leicester
Page 51
Thinking allowed …
Suppose you are creating a real-time embedded system.
In the following list, which is the most important design goal?
– Minimal BCET (best-case execution time)?
– Minimal WCET (worst-case execution time)?
– BCET = WCET?
Copyright © 2009-2011 TTE Systems Ltd
99 Licensed to University of Leicester
Meeting real-time constraints
Copyright © 2009-2011 TTE Systems Ltd
100 Licensed to University of Leicester
Page 52
Problems with the code we have written till now
bit SWITCH_Get_Input(const unsigned char DEBOUNCE_PERIOD)
{
bit Return_value = SWITCH_NOT_PRESSED;
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_LOOP_Wait(DEBOUNCE_PERIOD); Software delay is not precise.
// Check switch again
if (Switch_pin == 0)
{
// Wait until the switch is released.
while (Switch_pin == 0); Blocks the system until the switch is released
Return_value = SWITCH_PRESSED;
}
}
// Now (finally) return switch value
return Return_value;
}
Copyright © 2009-2011 TTE Systems Ltd
101 Licensed to University of Leicester
Creating “hardware delays”
Copyright © 2009-2011 TTE Systems Ltd
102 Licensed to University of Leicester
Page 53
Generating precise delays
8051 timer operation recap:
16-bit timers.
Incremented periodically based on the oscillator frequency
On a standard 8051/8052 (12 MHz clock), timers are
incremented every 1 µs and have a maximum period of
65.536ms (1 µs x 216).
Sets a flag when timer rolls over
Can be used to trigger an interrupt (more on Day 2)
Shorter periods can be obtained starting the timer from a
value greater than 0
Copyright © 2009-2011 TTE Systems Ltd
103 Licensed to University of Leicester
Timer 0 and 1 SFRs
Bit 7 (MSB) 6 5 4 3 2 1 0 (LSB)
TCON
NAME TF1 TR1 TF0 TR0
Timer 0 run control
Timer 0 overflow flag
Timer 1 run control
Timer 1 overflow flag
Bit 7 (MSB) 6 5 4 3 2 1 0 (LSB)
TMOD Timer 1 Timer 1 Timer 1 Timer 1 Timer 0 Timer 0 Timer 0 Timer 0
NAME Gate Mode 0 Gate C/T Mode 0
C/T Mode 1 Mode 1
Gate If 0, timer runs when TRx bit is set. If 1, timer runs when external gate pin
is active and TRx bit is set.
Counter / Timer If 0, timer increments every machine cycle. If 1, timer counts pulses on
external pin
Mode 1 & 0 Sets one of the four timer modes (including 16 bit timer / counter and 8 bit
auto reload)
Copyright © 2009-2011 TTE Systems Ltd
104 Licensed to University of Leicester
Page 54
Timer 0 and 1 SFRs
TH0, TL0, TH1 and TL1
Timer high (TH0, TH1) and low byte (TL0, TL1) SFRs are
used to access the high and low bytes of the timer counter.
Timer 0 can be set to overflow after 15ms by writing the
following value to the timer counter registers:
Timer interrupt enable bits
The timer interrupts are enables and disabled by setting or
clearing the ET0 and ET1 bits in the IE SFR.
Copyright © 2009-2011 TTE Systems Ltd
105 Licensed to University of Leicester
Hardware Delay – 50 ms
/*------------------------------------------------------------------*-
DELAY_HARDWARE_50ms()
Hardware delay of 50ms.
*** Assumes 12MHz 8051 (12 osc cycles) ***
-*------------------------------------------------------------------*/
void DELAY_HARDWARE_50ms(void)
{
// Configure Timer 0 as a 16-bit timer
TMOD &= 0xF0; // Clear all T0 bits (T1 left unchanged)
TMOD |= 0x01; // Set required T0 bits (T1 left unchanged)
ET0 = 0; // No interrupts
// Values for 50 ms delay
TH0 = 0x3C; // Timer 0 initial value (High Byte)
TL0 = 0xB0; // Timer 0 initial value (Low Byte)
TF0 = 0; // Clear overflow flag
TR0 = 1; // Start timer 0
while (TF0 == 0); // Loop until Timer 0 overflows (TF0 == 1)
TR0 = 0; // Stop Timer 0
}
Copyright © 2009-2011 TTE Systems Ltd
106 Licensed to University of Leicester
Page 55
Hardware Delay – 1 s
Delays longer that the maximum period of the timers can be
achieved by multiple calls to a delay less than this period.
/*------------------------------------------------------------------*-
DELAY_HARDWARE_One_Second()
Hardware delay of 1000 ms.
*** Assumes 12MHz 8051 (12 osc cycles) ***
-*------------------------------------------------------------------*/
void DELAY_HARDWARE_One_Second(void)
{
unsigned char d;
// Call DELAY_HARDWARE_50ms() twenty times
for (d = 0; d < 20; d++)
{
DELAY_HARDWARE_50ms();
}
}
Copyright © 2009-2011 TTE Systems Ltd
107 Licensed to University of Leicester
Creating “timeout” mechanisms
Copyright © 2009-2011 TTE Systems Ltd
108 Licensed to University of Leicester
Page 56
The need for timeout mechanisms
Looping wait structures From goat
while (Switch_pin == 0); // Loop until switch is released counting
example
From app
// Wait until AD conversion finishes (checking ADCI)
note for
while ((ADCON & ADCI) == 0);
8Xc552
Dangers of these structures:
Unpredictable behaviour if peripheral is configured incorrectly
Unpredictable behaviour if peripheral is damaged
Copyright © 2009-2011 TTE Systems Ltd
109 Licensed to University of Leicester
Loop timeout mechanism
tWord Timeout_loop = 0;((ADCON & ADCI) == 0);
...
// Wait for test condition with built in timeout
while (((Test condition) == 0) && (++ Timeout_loop != 0));
Assuming 16-bit variables, the loop will run a maximum of
65535 times before the timeout logic causes the loop to exit.
The exact maximum time of the loop has to be tested, but
ensures that loop eventually exits.
The timeout duration can be changed by using different
starting values for the timeout variable.
Copyright © 2009-2011 TTE Systems Ltd
110 Licensed to University of Leicester
Page 57
Switch timeout code (example)
if (Switch_pin == 0)
{
// Switch is pressed
// Debounce - just wait...
DELAY_T0_Wait(DEBOUNCE_PERIOD);
// Check switch again
if (Switch_pin == 0)
{
// Wait until the switch is released.
// (WITH TIMEOUT LOOP - 10 seconds)
while ((Switch_pin == 0) && (++Timeout_loop != 0));
Copyright © 2009-2011 TTE Systems Ltd
111 Licensed to University of Leicester
Hardware loop timeout
// Define Timer 0 / Timer 1 preload values for ~10 msec delay
#define PRELOAD_10ms (65536 - (tWord)(OSC_FREQ / (OSC_PER_INST * 100)))
#define PRELOAD_10ms_H (PRELOAD_10ms / 256)
#define PRELOAD_10ms_L (PRELOAD_10ms % 256)
...
// Configure Timer 0 as a 16-bit timer
TMOD &= 0xF0; // Clear all T0 bits (T1 left unchanged)
TMOD |= 0x01; // Set required T0 bits (T1 left unchanged)
ET0 = 0; // No interrupts
// Simple timeout feature - approx 10 ms
TH0 = PRELOAD_10ms_H; // See Timeout.H for PRELOAD details
TL0 = PRELOAD_10ms_L;
TF0 = 0; // Clear flag
TR0 = 1; // Start timer
while (((ADCON & ADCI) == 0) && !TF0);
Copyright © 2009-2011 TTE Systems Ltd
112 Licensed to University of Leicester
Page 58
“Balanced code” and “sandwich delays”
Copyright © 2009-2011 TTE Systems Ltd
113 Licensed to University of Leicester
Example: Sandwich Delay
Problem
You are running two activities, one after the other. How can we ensure that
the interval between release times of the two activities is known and fixed?
Solution
// Execute Do_X() in a ‘Sandwich Delay’ – BEGIN
Set_Sandwich_Timer_Overflow(5); // Set timer to overflow after 5 ms
Do_X(); // Execute Do_X - WCET approx. 4 ms
Wait_For_Sandwich_Timer_Overflow(); // Wait for timer to overflow
// Execute Do_X() in a ‘Sandwich Delay’ - END
Do_Y();
Source: Adapted from Sandwich Delay in Pont, M.J. et al., “Meeting real-time constraints using “Sandwich Delays””,
Presented at EuroPLoP 2006 (Irsee, Germany), July 2006.
Please note that this pattern is described in much more detail in the original text.
Copyright © 2009-2011 TTE Systems Ltd
114 Licensed to University of Leicester
Page 59
Example
int main(void)
{ A simple “cyclic executive”
…
// Super Loop
while(1)
{
X();
Delay(); // Software delay?
Y();
Delay();
}
// No OS to return to …
return 1;
}
Copyright © 2009-2011 TTE Systems Ltd
115 Licensed to University of Leicester
Example
int main(void)
{ Better control over timing …
…
while(1)
{
Start_Timer();
X(); // Task runs in “sandwich delay”
Wait_For_Timer(10);
Start_Timer()
Y();
Wait_For_Timer(10);
}
return 1;
}
Copyright © 2009-2011 TTE Systems Ltd
116 Licensed to University of Leicester
Page 60
Example
int main(void)
{ Fixed delay
X();
X() Y()
Delay(); Time
System
Y(); reset
Power_Down();
while(1); // Safety net
return 1;
}
E.g. Garage doors
Copyright © 2009-2011 TTE Systems Ltd
117 Licensed to University of Leicester
Conclusion
We’ve covered a lot of ground in this first seminar:
– Introduction to embedded systems
– Introduction to super loops
– Introduction to the 8051
– A first look at software architectures for embedded systems
– A first look at some coding guidelines
– A first look at techniques required to meet RT constraints
Now it’s time to try out some of these ideas in the first lab
session …
Copyright © 2009-2011 TTE Systems Ltd
118 Licensed to University of Leicester
Page 61
All my own work
The following individuals contributed to the material and slides
presented in this session:
– Musharraf Hanif (University of Leicester)
– Devaraj Ayavoo (TTE Systems Ltd)
– Zemian Hughes (TTE Systems Ltd)
– Peter Vidler (TTE Systems Ltd)
– Muhammad Waqas Raza (TTE Systems Ltd)
– Keith Athaide (TTE Systems Ltd)
– Anjali Das (TTE Systems Ltd)
– Michael Short (Teesside University)
Copyright © 2009-2011 TTE Systems Ltd
119 Licensed to University of Leicester
Page 62
Day 2: Key software architectures
Michael J. Pont
MSc in Reliable Embedded Systems
Module EG7510 (“A1a”)
Introduction and review
Copyright © 2009-2011 TTE Systems Ltd
2 Licensed to University of Leicester
Page 63
The story so far …
We covered a lot of ground in Seminar 1:
– Introduction to embedded systems
– Introduction to super loops
– Introduction to the 8051
– A first look at software architectures for embedded systems
– A first look at some coding guidelines
– A first look at techniques required to meet RT constraints
Copyright © 2009-2011 TTE Systems Ltd
3 Licensed to University of Leicester
Day 2 Outline
On the agenda today:
– Creating and using a “simple embedded operating system”;
– Creating multi-state systems;
– Executing sequences of functions;
– Dealing with “long tasks” in reliable embedded systems
– A first look at MISRA C
Copyright © 2009-2011 TTE Systems Ltd
4 Licensed to University of Leicester
Page 64
Time, time, time …
Copyright © 2009-2011 TTE Systems Ltd
5 Licensed to University of Leicester
Super loops revisited void main(void)
{
Pros Init_System();
while(1) // (Super Loop)
Very easy to understand {
X();
Minimal resource requirements }
}
Suitable for some “soft RT” systems
Cons
Difficult to execute functions with a known period
Not suitable for “hard RT” systems
Copyright © 2009-2011 TTE Systems Ltd
6 Licensed to University of Leicester
Page 65
The need for accurate timing
Most embedded applications require tasks to be performed
periodically:
Generating sound from stored samples.
Measuring the speed of a vehicle every 0.5 seconds.
Refreshing a display 40 times per second.
Logging vibration data from sensor at a rate of 1000 Hz.
Scanning a keypad every 200 ms.
Copyright © 2009-2011 TTE Systems Ltd
7 Licensed to University of Leicester
Inserting a delay into the super loop
If task timings do not vary at run time, it is possible to use a
super loop to call a task periodically
E.g. Call function X every 60ms:
void main(void)
{
Init_System();
while(1) // 'for ever' (Super Loop)
{
X(); // Call the function (10 ms duration)
Delay_50ms(); // Delay for 50 ms
}
}
Unfortunately, task timings often vary considerably
- interrupts provide an effective solution …
Copyright © 2009-2011 TTE Systems Ltd
8 Licensed to University of Leicester
Page 66
Creating and using a “simple embedded
operating system” (sEOS)
Copyright © 2009-2011 TTE Systems Ltd
9 Licensed to University of Leicester
What is an interrupt?
“A signal informing a program that an event has occurred.
When a program receives an interrupt signal, it takes a
specified action (which can be to ignore the signal). Interrupt
signals can cause a program to suspend itself temporarily to
service the interrupt” (Webopedia computer dictionary)
From a programmer’s perspective, interrupts can be seen as a
way of linking hardware events to function calls
– In an “event triggered” design, we often have multiple “interrupt service
routines” (ISRs), all associated with different hardware events. In
most cases, we don’t know when these events will occur
– In a “time triggered” design, we usually have one ISR, linked to a
timer (e.g., the ISR may be triggered by a periodic timer overflow)
Copyright © 2009-2011 TTE Systems Ltd
10 Licensed to University of Leicester
Page 67
Basis of a “simple embedded operating system” (sEOS)
Update() Update() Update() ...
Time
System ‘ticks’
BACKGROUND FOREGROUND
Tasks (functions)
PROCESSING PROCESSING Called from here:
E.g. a long “switch”
statement
while(1) Update();
{
Go_To_Sleep(); (Interrupt)
}
1 ms timer
A simple
time-triggered system with
co-operative tasks
(TTC)
Copyright © 2009-2011 TTE Systems Ltd
11 Licensed to University of Leicester
Basis of a “simple embedded operating system” (sEOS)
Water void WASHER_Update(void)
Valve
{
Water
Heater switch (System_state_G)
Start {
Switch
Water case INIT:
Pump
Selector
Dial case START:
Washing Drum
Machine Motor
Water Controller case FILL_DRUM:
Level
Sensor
LED
indicators case HEAT_WATER:
Temperature
Sensor
Door
case WASH_01:
lock
...
Detergent }
Hatch
}
(Interrupt)
1 ms timer
Copyright © 2009-2011 TTE Systems Ltd
12 Licensed to University of Leicester
Page 68
Basis of a “simple embedded operating system” (sEOS)
Needs to be able to run “tasks” (functions) at specified rates
Timer interrupt service routine (ISR) provides a good starting
point:
– Set up a timer to generate an interrupt periodically
– Use code placed in the ISR to run the tasks at the desired rates
Interrupts are easy to manage in a high-level language
Copyright © 2009-2011 TTE Systems Ltd
13 Licensed to University of Leicester
Timer ISR framework
/*------------------------------------------------------------------*-
Main.c
------------------------------------------------------------------
Simple timer ISR demonstration program.
-*------------------------------------------------------------------*/
#include <reg52.H>
#define INTERRUPT_Timer_2_Overflow 5 IE index for Timer 2 overflow interrupt
// Function prototype
// NOTE: ISR is not explictly called and does not require a prototype
void Timer_2_Init(void);
/* --------------------------------------------------------------- */
void main(void)
{
Timer_2_Init(); // Set up Timer 2
EA = 1; // Globally enable interrupts
while(1); // An empty Super Loop
}
/* --------------------------------------------------------------- */
void X(void) interrupt INTERRUPT_Timer_2_Overflow
Compiler keyword to link the function to
{
// This ISR is called every 1 ms the interrupt vector
// Place required code here...
}
Copyright © 2009-2011 TTE Systems Ltd
14 Licensed to University of Leicester
Page 69
Timer ISR framework
void Timer_2_Init(void)
{
// Timer 2 is configured as a 16-bit timer,
// which is automatically reloaded when it overflows
//
// This code (generic 8051/52) assumes a 12 MHz system osc.
// The Timer 2 resolution is then 1.000 µs
//
// Reload value is FC18 (hex) = 64536 (decimal)
// Timer (16-bit) overflows when it reaches 65536 (decimal)
// Thus, with these setting, timer will overflow every 1 ms
T2CON = 0x04; // Load Timer 2 control register
TH2 = 0xFC; // Load Timer 2 high byte
RCAP2H = 0xFC; // Load Timer 2 reload capt. reg. high byte
TL2 = 0x18; // Load Timer 2 low byte
RCAP2L = 0x18; // Load Timer 2 reload capt. reg. low byte
// Timer 2 interrupt is enabled, and ISR will be called
// whenever the timer overflows - see below.
ET2 = 1;
// Start Timer 2 running
TR2 = 1;
}
Copyright © 2009-2011 TTE Systems Ltd
15 Licensed to University of Leicester
The Simple Embedded Operating System (sEOS)
Formalisation of the “timer ISR” based system.
Provides a framework to ease the development process of
embedded systems.
Puts the processor “to sleep” between tasks:
– To conserve power;
– To reduce task jitter.
Copyright © 2009-2011 TTE Systems Ltd
16 Licensed to University of Leicester
Page 70
sEOS Listing
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
------------------------------------------------------------------
Main file for Simple Embedded Operating System (sEOS) for 8051.
Demonstration version with dummy task X().
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Simple_EOS.H"
// Header for dummy task
#include "X.H"
/*------------------------------------------------------------------*-
sEOS_ISR()
Invoked periodically by Timer 2 overflow:
see sEOS_Init_Timer2() for timing details.
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
// Must manually reset the T2 flag
TF2 = 0;
//===== USER CODE - Begin =======================================
// Call user task here
//===== USER CODE - End =========================================
}
Copyright © 2009-2011 TTE Systems Ltd
17 Licensed to University of Leicester
sEOS Listing
/*------------------------------------------------------------------*-
sEOS_Init_Timer2()
Sets up Timer 2 to drive the simple EOS.
Parameter gives tick interval in MILLISECONDS.
Max tick interval is ~60ms (12 MHz oscillator).
Note: Precise tick intervals are only possible with certain
oscillator / tick interval combinations. If timing is important,
you should check the timing calculations manually.
-*------------------------------------------------------------------*/
void sEOS_Init_Timer2(const tByte TICK_MS)
{
tLong Inc;
tWord Reload_16;
tByte Reload_08H, Reload_08L;
// Timer 2 is configured as a 16-bit timer,
// which is automatically reloaded when it overflows
T2CON = 0x04; // Load Timer 2 control register
// Number of timer increments required (max 65536)
Inc = ((tLong)TICK_MS * (OSC_FREQ/1000)) / (tLong)OSC_PER_INST;
// 16-bit reload value
Reload_16 = (tWord) (65536UL - Inc);
// 8-bit reload values (High & Low)
Reload_08H = (tByte)(Reload_16 / 256);
Reload_08L = (tByte)(Reload_16 % 256);
Copyright © 2009-2011 TTE Systems Ltd
18 Licensed to University of Leicester
Page 71
sEOS Listing
TH2 = Reload_08H; // Load Timer 2 high byte
RCAP2H = Reload_08H; // Load Timer 2 reload capt. reg. high byte
TL2 = Reload_08L; // Load Timer 2 low byte
RCAP2L = Reload_08L; // Load Timer 2 reload capt. reg. low byte
// Timer 2 interrupt is enabled, and ISR will be called
// whenever the timer overflows.
ET2 = 1;
// Start Timer 2 running
TR2 = 1;
EA = 1; // Globally enable interrupts
}
/*------------------------------------------------------------------*-
sEOS_Go_To_Sleep()
This operating system enters 'idle mode' between clock ticks
to save power. The next clock tick will return the processor
to the normal operating state.
-*------------------------------------------------------------------*/
void sEOS_Go_To_Sleep(void)
{
PCON |= 0x01; // Enter idle mode (generic 8051 version)
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
19 Licensed to University of Leicester
sEOS design features
Tasks and scheduling
sEOS can schedule a single task (function in C) to be run
periodically
Tick interval
The control of the tick interval has been largely automated
(sEOS_Init_Timer2())
Using the 12 MHz oscillator, precise timing can be achieved in
the range from 1 ms to 65 ms ticks
Using “odd” frequency oscillators (like 11.0592 MHz for
precise serial communication) limits the precision of the tick
period being generated.
Copyright © 2009-2011 TTE Systems Ltd
20 Licensed to University of Leicester
Page 72
sEOS design features
Power saving
sEOS reduces the power consumption by putting the
processor into idle mode between task executions.
Idle Idle Idle
Task Task Task ...
Time
System ‘ticks’
Portability to other devices
Most of the processors used in embedded applications have
at least one timer for generating operating system ticks.
Copyright © 2009-2011 TTE Systems Ltd
21 Licensed to University of Leicester
What about Timer 0 or Timer 1?
It is possible to use a timer without automatic reload to run the
scheduler by manually reloading the timer in every tick to
ensure proper tick periods.
These tick periods will not be very accurate as the time
between the timer overflow and the moment when the timer is
reloaded is not taken into consideration during reloads.
Copyright © 2009-2011 TTE Systems Ltd
22 Licensed to University of Leicester
Page 73
Simple sEOS example
Copyright © 2009-2011 TTE Systems Ltd
23 Licensed to University of Leicester
Simple sEOS example
We’ll use sEOS to call “Task X” (a function) every 60 ms.
Unlike the super loop with delay, the Task X will be run every
60 ms by sEOS even if the execution time varies.
If we assume that X takes 10 ms to run the average
consumption is 3.5 mA (cf. 11 mA at “full power”).
10ms × 11mA + 50ms × 2mA
Average Current Consumption = = 3.5mA
60ms
Copyright © 2009-2011 TTE Systems Ltd
24 Licensed to University of Leicester
Page 74
Simple sEOS example
/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Demonstration of sEOS running a dummy task.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Simple_EOS.H"
#include "X.H"
/* --------------------------------------------------------------- */
void main(void)
{
// Prepare for dummy task
X_Init();
// Set up simple EOS (60 ms tick interval)
sEOS_Init_Timer2(60);
while(1) // Super Loop
{
// Enter idle mode to save power
sEOS_Go_To_Sleep();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
25 Licensed to University of Leicester
Simple sEOS example
/*------------------------------------------------------------------*-
X.C (v1.00)
------------------------------------------------------------------
Dummy task to introduce sEOS.
-*------------------------------------------------------------------*/
#include "X.H"
/*------------------------------------------------------------------*-
X_Init()
Dummy task init function.
-*------------------------------------------------------------------*/
void X_Init(void)
{
// Dummy task init...
}
/*------------------------------------------------------------------*-
X()
Dummy task called from sEOS ISR.
-*------------------------------------------------------------------*/
void X(void)
{
// Dummy task...
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
26 Licensed to University of Leicester
Page 75
Simple sEOS example
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
------------------------------------------------------------------
Main file for Simple Embedded Operating System (sEOS) for 8051.
Demonstration version with dummy task X().
-*------------------------------------------------------------------*/
...
/*------------------------------------------------------------------*-
sEOS_ISR()
Invoked periodically by Timer 2 overflow:
see sEOS_Init_Timer2() for timing details.
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
// Must manually reset the T2 flag
TF2 = 0;
//===== USER CODE - Begin =======================================
// Call user task here
X();
//===== USER CODE - End =========================================
}
...
Copyright © 2009-2011 TTE Systems Ltd
27 Licensed to University of Leicester
Creating useful TTC tasks
Copyright © 2009-2011 TTE Systems Ltd
28 Licensed to University of Leicester
Page 76
Creating useful tasks for sEOS
“Embedded C” gives a number of examples of tasks for use
with TTC architectures
“Patterns for Time-Triggered Embedded Systems” also has
many relevant examples
Copyright © 2009-2011 TTE Systems Ltd
29 Licensed to University of Leicester
Example: Reading switch state (PTTES, Ch. 19)
/*------------------------------------------------------------------*-
SWIT_A.C (v1.00)
------------------------------------------------------------------
Simple switch interface code, with software debounce.
-*------------------------------------------------------------------*/
#include "Main.h"
#include "Port.h"
#include "Swit_A.h"
// ------ Public variable definitions ------------------------------
bit Sw_pressed_G = 0; // The current switch status
// ------ Private constants ----------------------------------------
// Allows NO or NC switch to be used (or other wiring variations)
#define SW_PRESSED (0)
// SW_THRES must be > 1 for correct debounce behaviour
#define SW_THRES (3)
Copyright © 2009-2011 TTE Systems Ltd
30 Licensed to University of Leicester
Page 77
Example: Reading switch state (PTTES, Ch. 19)
/*------------------------------------------------------------------*-
SWITCH_Init()
Initialisation function for the switch library.
-*------------------------------------------------------------------*/
void SWITCH_Init(void)
{
Sw_pin = 1; // Use this pin for input
}
Copyright © 2009-2011 TTE Systems Ltd
31 Licensed to University of Leicester
Example: Reading switch state (PTTES, Ch. 19)
void SWITCH_Update(void)
{
static tByte Duration;
The key task
if (Sw_pin == SW_PRESSED) Usually schedule this to run every 10 ms
{ (slower rates are possible)
Duration += 1;
if (Duration > SW_THRES)
{
Duration = SW_THRES;
Sw_pressed_G = 1; // Switch is pressed...
return;
}
// Switch pressed, but not yet for long enough
Sw_pressed_G = 0;
return;
}
// Switch not pressed - reset the count
Duration = 0;
Sw_pressed_G = 0; // Switch not pressed...
}
Copyright © 2009-2011 TTE Systems Ltd
32 Licensed to University of Leicester
Page 78
Case study
Copyright © 2009-2011 TTE Systems Ltd
33 Licensed to University of Leicester
Case study: Milk pasteurisation
Determine flow rate from pulse stream
Design a system to monitor
the rate of liquid (milk) flow
through a pasteurisation
system. Milk
Milkpasteurisation
pasteurisationsystem
system
The rate of flow is measured
using a flow rate sensor.
Optical
Desired outputs: sensor
– Bar graph giving a representation
of rate of flow To ‘counter’ input
– Audible alarm when rate falls Rotating
shaft
below a threshold.
Copyright © 2009-2011 TTE Systems Ltd
34 Licensed to University of Leicester
Page 79
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Port.H (v1.00)
------------------------------------------------------------------
Port Header file for the milk pasteurization example (Chapter 7)
-*------------------------------------------------------------------*/
// ------ Pulse_Count.C -------------------------------------------------
// Connect pulse input to this pin - debounced in software
sbit Sw_pin = P3^0;
// Connect alarm to this pin (set if pulse is below threshold)
sbit Alarm_pin = P3^7;
// ------ Bargraph.C -----------------------------------------------
// Bargraph display on these pins
// The 8 port pins may be distributed over several ports if required
sbit Pin0 = P1^0;
sbit Pin1 = P1^1;
sbit Pin2 = P1^2;
sbit Pin3 = P1^3;
sbit Pin4 = P1^4;
sbit Pin5 = P1^5;
sbit Pin6 = P1^6;
sbit Pin7 = P1^7;
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
35 Licensed to University of Leicester
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Milk pasteurization example.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Simple_EOS.H"
#include "Bargraph.H"
#include "Pulse_Count.H"
/* --------------------------------------------------------------- */
void main(void)
{
PULSE_COUNT_Init();
BARGRAPH_Init();
// Set up simple EOS (30ms tick interval)
sEOS_Init_Timer2(30);
while(1) // Super Loop
{
// Enter idle mode to save power
sEOS_Go_To_Sleep();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
36 Licensed to University of Leicester
Page 80
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
------------------------------------------------------------------
Main file for Simple Embedded Operating System (sEOS) for 8051.
-- This version for milk-flow-rate monitoring.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Simple_EOS.H"
#include "Pulse_count.H"
/*------------------------------------------------------------------*-
sEOS_ISR()
Invoked periodically by Timer 2 overflow:
see sEOS_Init_Timer2() for timing details.
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
// Must manually reset the T2 flag
TF2 = 0;
//===== USER CODE - Begin =======================================
// Call 'Update' function here
PULSE_COUNT_Update();
//===== USER CODE - End =========================================
}
...
...
Copyright © 2009-2011 TTE Systems Ltd
37 Licensed to University of Leicester
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Pulse_Count.C (v1.00)
------------------------------------------------------------------
Count pulses from a mechanical switch or similar device.
Responds to falling edge of pulse: |___
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Bargraph.H"
#include "Pulse_Count.H"
// ------ Private function prototypes ------------------------------
void PULSE_COUNT_Check_Below_Threshold(const tByte);
// ------ Public variable declarations -----------------------------
// The data to be displayed
extern tBargraph Data_G;
// ------ Public variable definitions -------------------------------
// Set only after falling edge is detected
bit Falling_edge_G;
// ------ Private variable definitions ------------------------------
// The results of successive tests of the pulse signal
// (NOTE: Can't have arrays of bits...)
static bit Test4, Test3, Test2, Test1, Test0;
static tByte Total_G = 0;
static tWord Calls_G = 0;
Copyright © 2009-2011 TTE Systems Ltd
38 Licensed to University of Leicester
Page 81
Milk pasteurisation: Code listing
// ------ Private constants ----------------------------------------
// Allows changed of logic without hardware changes
#define HI_LEVEL (0)
#define LO_LEVEL (1)
/*------------------------------------------------------------------*-
PULSE_COUNT_Init()
Initialisation function for the switch library.
-*------------------------------------------------------------------*/
void PULSE_COUNT_Init(void)
{
Sw_pin = 1; // Use this pin for input
// The tests (see text)
Test4 = LO_LEVEL;
Test3 = LO_LEVEL;
Test2 = LO_LEVEL;
Test1 = LO_LEVEL;
Test0 = LO_LEVEL;
}
Copyright © 2009-2011 TTE Systems Ltd
39 Licensed to University of Leicester
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
PULSE_COUNT_Check_Below_Threshold()
Checks to see if pulse count is below a specified
threshold value. If it is, sounds an alarm.
-*------------------------------------------------------------------*/
void PULSE_COUNT_Check_Below_Threshold(const tByte THRESHOLD)
{
if (Data_G < THRESHOLD)
{
Alarm_pin = 0;
}
else
{
Alarm_pin = 1;
}
}
/*------------------------------------------------------------------*-
PULSE_COUNT_Update()
This is the main switch function.
It should be called every 30 ms
(to allow for typical 20ms debounce time).
-*------------------------------------------------------------------*/
void PULSE_COUNT_Update(void)
{
// Clear timer flag
TF2 = 0;
<Continued>
Copyright © 2009-2011 TTE Systems Ltd
40 Licensed to University of Leicester
Page 82
Milk pasteurisation: Code listing
<PULSE_COUNT_Update() – Continued>
// Shuffle the test results
Test4 = Test3;
Test3 = Test2;
Test2 = Test1;
Test1 = Test0;
// Get latest test result
Test0 = Sw_pin;
// Required result:
// Test4 == HI_LEVEL
// Test3 == HI_LEVEL
// Test1 == LO_LEVEL
// Test0 == LO_LEVEL
if ((Test4 == HI_LEVEL) && (Test3 == HI_LEVEL) &&
(Test1 == LO_LEVEL) && (Test0 == LO_LEVEL))
{
// Falling edge detected
Falling_edge_G = 1;
}
else
{
// Default
Falling_edge_G = 0;
}
Copyright © 2009-2011 TTE Systems Ltd
41 Licensed to University of Leicester
Milk pasteurisation: Code listing
<PULSE_COUNT_Update() – Continued>
// Calculate average every 45 calls to this task
// - maximum count over this period is 9 pulses
// if (++Calls_G < 45)
// 450 used here for test purposes (in simulator)
// [Because there is a limit to how fast you can simulate pulses
// by hand...]
if (++Calls_G < 450)
{
Total_G += (int) Falling_edge_G;
}
else
{
// Update the display
Data_G = Total_G; // Max is 9
Total_G = 0;
Calls_G = 0;
PULSE_COUNT_Check_Below_Threshold(3);
BARGRAPH_Update();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
42 Licensed to University of Leicester
Page 83
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Bargraph.h (v1.00)
------------------------------------------------------------------
- See Bargraph.c for details.
-*------------------------------------------------------------------*/
#include "Main.h"
// ------ Public data type declarations ----------------------------
typedef tByte tBargraph;
// ------ Public function prototypes -------------------------------
void BARGRAPH_Init(void);
void BARGRAPH_Update(void);
// ------ Public constants -----------------------------------------
#define BARGRAPH_MAX (9)
#define BARGRAPH_MIN (0)
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
43 Licensed to University of Leicester
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
Bargraph.c (v1.00)
------------------------------------------------------------------
Simple bargraph library.
-*------------------------------------------------------------------*/
#include "Main.h"
#include "Port.h"
#include "Bargraph.h"
// ------ Public variable declarations -----------------------------
// The data to be displayed
tBargraph Data_G;
// ------ Private constants ----------------------------------------
#define BARGRAPH_ON (1)
#define BARGRAPH_OFF (0)
// ------ Private variables ----------------------------------------
// These variables store the thresholds
// used to update the display
static tBargraph M9_1_G;
static tBargraph M9_2_G;
static tBargraph M9_3_G;
static tBargraph M9_4_G;
static tBargraph M9_5_G;
static tBargraph M9_6_G;
static tBargraph M9_7_G;
static tBargraph M9_8_G;
Copyright © 2009-2011 TTE Systems Ltd
44 Licensed to University of Leicester
Page 84
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
BARGRAPH_Init()
Prepare for the bargraph display.
-*------------------------------------------------------------------*/
void BARGRAPH_Init(void)
{
Pin0 = BARGRAPH_OFF;
Pin1 = BARGRAPH_OFF;
Pin2 = BARGRAPH_OFF;
Pin3 = BARGRAPH_OFF;
Pin4 = BARGRAPH_OFF;
Pin5 = BARGRAPH_OFF;
Pin6 = BARGRAPH_OFF;
Pin7 = BARGRAPH_OFF;
// Use a linear scale to display data
// Remember: *9* possible output states
// - do all calculations ONCE
M9_1_G = (BARGRAPH_MAX - BARGRAPH_MIN) / 9;
M9_2_G = M9_1_G * 2;
M9_3_G = M9_1_G * 3;
M9_4_G = M9_1_G * 4;
M9_5_G = M9_1_G * 5;
M9_6_G = M9_1_G * 6;
M9_7_G = M9_1_G * 7;
M9_8_G = M9_1_G * 8;
}
Copyright © 2009-2011 TTE Systems Ltd
45 Licensed to University of Leicester
Milk pasteurisation: Code listing
/*------------------------------------------------------------------*-
BARGRAPH_Update()
Update the bargraph display.
-*------------------------------------------------------------------*/
void BARGRAPH_Update(void)
{
tBargraph Data = Data_G - BARGRAPH_MIN;
Pin0 = ((Data >= M9_1_G) == BARGRAPH_ON);
Pin1 = ((Data >= M9_2_G) == BARGRAPH_ON);
Pin2 = ((Data >= M9_3_G) == BARGRAPH_ON);
Pin3 = ((Data >= M9_4_G) == BARGRAPH_ON);
Pin4 = ((Data >= M9_5_G) == BARGRAPH_ON);
Pin5 = ((Data >= M9_6_G) == BARGRAPH_ON);
Pin6 = ((Data >= M9_7_G) == BARGRAPH_ON);
Pin7 = ((Data >= M9_8_G) == BARGRAPH_ON);
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
46 Licensed to University of Leicester
Page 85
Pros and cons of “TTC” architectures
Copyright © 2009-2011 TTE Systems Ltd
47 Licensed to University of Leicester
sEOS characterisation
The sEOS is a time-triggered co-operative (TTC) scheduling
architecture:
The co-operative environment avoids the overheads and
potential problems (e.g. systems with shared resources) of
multitasking environments.
The workload of a time-triggered system can be ensured to be
evenly distributed at design time: in most cases, the same
cannot be said about a system in which multiple interrupts are
enabled.
We’ll consider these matters in greater detail in later seminars.
Copyright © 2009-2011 TTE Systems Ltd
48 Licensed to University of Leicester
Page 86
The “one interrupt per microcontroller” rule
In theory:
When saying that an embedded system has a
time-triggered (TT) architecture we mean that we can
determine in advance – before the system begins
executing – exactly what it will do at every moment of
time during which it is running.
In practice, TT usually means:
– One interrupt source per CPU
– The interrupt is often (not always) a “timer tick”
– Peripherals are ‘polled’
Copyright © 2009-2011 TTE Systems Ltd
49 Licensed to University of Leicester
Limitations of co-operative multitasking systems
As the active task has control of the system and cannot be
stopped or interrupted by the scheduler, a task overrunning its
allotted time can cause problems.
Tick Interval
Execution time
Task ...
System ‘ticks’ Time
It is up to the designer to ensure that the worst case execution
time (WCET) of any task is less that the tick interval.
Task ...
Time
System ‘ticks’
Copyright © 2009-2011 TTE Systems Ltd
50 Licensed to University of Leicester
Page 87
Multi-state systems and function sequences
Copyright © 2009-2011 TTE Systems Ltd
51 Licensed to University of Leicester
Multiple state in systems
Most embedded systems can be modelled in terms of their
various operating states.
Transition between states may result in the execution of a
particular sequence of functions.
Transitions may depend on passage of time and / or inputs.
Some examples
Auto pilot system
Industrial robots
Traffic lights
Automatic washing machine
Copyright © 2009-2011 TTE Systems Ltd
52 Licensed to University of Leicester
Page 88
Classification based on transition rules
Time-dependent, multi-state systems
– Basic traffic light control system
Time- and input-dependent, multi-state systems
– Washing machine
Input-dependent, multi-state systems (less common?)
Copyright © 2009-2011 TTE Systems Ltd
53 Licensed to University of Leicester
Case study
Copyright © 2009-2011 TTE Systems Ltd
54 Licensed to University of Leicester
Page 89
Case Study: Basic traffic light
Timed four-state system
1. Red (for 20 seconds)
2. Red and amber (for 5 seconds)
3. Green (for 30 seconds)
4. Amber (for 5 seconds)
No inputs to the system
Copyright © 2009-2011 TTE Systems Ltd
55 Licensed to University of Leicester
Case Study: Basic traffic light – Code listing
/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
Traffic light example.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Simple_EOS.H"
#include "T_Lights.H"
/* --------------------------------------------------------------- */
void main(void)
{
// Prepare to run traffic sequence
TRAFFIC_LIGHTS_Init(RED);
// Set up simple EOS (50 ms ticks)
sEOS_Init_Timer2(50);
while(1) // Super Loop
{
// Enter idle mode to save power
sEOS_Go_To_Sleep();
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
56 Licensed to University of Leicester
Page 90
Case Study: Basic traffic light: Code listing
/*------------------------------------------------------------------*-
T_Lights.H (v1.00)
------------------------------------------------------------------
- See T_Lights.C for details.
-*------------------------------------------------------------------*/
#ifndef _T_LIGHTS_H
#define _T_LIGHTS_H
// ------ Public data type declarations ----------------------------
// Possible system states
typedef enum {RED, RED_AND_AMBER, GREEN, AMBER} eLight_State;
// ------ Public function prototypes -------------------------------
void TRAFFIC_LIGHTS_Init(const eLight_State);
void TRAFFIC_LIGHTS_Update(void);
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
57 Licensed to University of Leicester
Case Study: Basic traffic light – Code listing
/*------------------------------------------------------------------*-
T_lights.C (v1.00)
------------------------------------------------------------------
Traffic light control program (Test Version 1.0)
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "T_lights.H"
// ------ Private constants ----------------------------------------
// Easy to change logic here
#define ON 0
#define OFF 1
// Times in each of the (four) possible light states
// (Times are in seconds)
#define RED_DURATION 20
#define RED_AND_AMBER_DURATION 5
#define GREEN_DURATION 30
#define AMBER_DURATION 5
// ------ Private variables ----------------------------------------
// The state of the system
static eLight_State Light_state_G;
// The time in that state
static tLong Time_in_state;
// Used by sEOS
static tByte Call_count_G = 0;
Copyright © 2009-2011 TTE Systems Ltd
58 Licensed to University of Leicester
Page 91
Case Study: Basic traffic light – Code listing
/*------------------------------------------------------------------*-
TRAFFIC_LIGHTS_Init()
-*------------------------------------------------------------------*/
void TRAFFIC_LIGHTS_Init(const eLight_State START_STATE)
{
Light_state_G = START_STATE; // Decide on initial state
}
/*------------------------------------------------------------------*-
TRAFFIC_LIGHTS_Update()
Must be called once per second.
-*------------------------------------------------------------------*/
void TRAFFIC_LIGHTS_Update(void)
{
switch (Light_state_G)
{
case RED:
{
Red_light = ON;
Amber_light = OFF;
Green_light = OFF;
if (++Time_in_state == RED_DURATION)
{
Light_state_G = RED_AND_AMBER;
Time_in_state = 0;
}
break;
}
<Continued>
Copyright © 2009-2011 TTE Systems Ltd
59 Licensed to University of Leicester
Case Study: Basic traffic light – Code listing
<TRAFFIC_LIGHTS_Update() - Continued>
case RED_AND_AMBER:
{
Red_light = ON;
Amber_light = ON;
Green_light = OFF;
if (++Time_in_state == RED_AND_AMBER_DURATION)
{
Light_state_G = GREEN;
Time_in_state = 0;
}
break;
}
case GREEN:
{
Red_light = OFF;
Amber_light = OFF;
Green_light = ON;
if (++Time_in_state == GREEN_DURATION)
{
Light_state_G = AMBER;
Time_in_state = 0;
}
break;
}
Copyright © 2009-2011 TTE Systems Ltd
60 Licensed to University of Leicester
Page 92
Case Study: Basic traffic light – Code listing
<TRAFFIC_LIGHTS_Update() - Continued>
case AMBER:
{
Red_light = OFF;
Amber_light = ON;
Green_light = OFF;
if (++Time_in_state == AMBER_DURATION)
{
Light_state_G = RED;
Time_in_state = 0;
}
break;
}
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
61 Licensed to University of Leicester
Case study
Copyright © 2009-2011 TTE Systems Ltd
62 Licensed to University of Leicester
Page 93
Case study: Washing machine controller
Water void WASHER_Update(void)
Valve
{
Water
Heater switch (System_state_G)
Start
Switch
{
Water case INIT:
Pump
Selector
Dial case START:
Washing Drum
Machine
Controller Motor
Water case FILL_DRUM:
Level
Sensor
LED
indicators case HEAT_WATER:
Temperature
Sensor
Door
case WASH_01:
lock
...
Detergent }
Hatch
}
(Interrupt)
1 ms timer
Copyright © 2009-2011 TTE Systems Ltd
63 Licensed to University of Leicester
Case study: Washing machine controller
Example of time- and Water
Valve
input-dependent, multi-
state system. Water
Heater
Machine has multiple Start
Switch
preset programs. Water
Pump
Selector
Dial
Washing Drum
Machine Motor
Water Controller
Level
Sensor
LED
indicators
Temperature
Sensor
Door
lock
Detergent
Hatch
Copyright © 2009-2011 TTE Systems Ltd
64 Licensed to University of Leicester
Page 94
Washing machine controller: Code listing
/*------------------------------------------------------------------*-
Washer.C (v1.01)
------------------------------------------------------------------
Multi-state framework for washing-machine controller.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Washer.H"
// ------ Private data type declarations ---------------------------
// Possible system states
typedef enum {INIT, START, FILL_DRUM, HEAT_WATER,
WASH_01, WASH_02, ERROR} eSystem_state;
// ------ Private function prototypes ------------------------------
tByte WASHER_Read_Selector_Dial(void);
bit WASHER_Read_Start_Switch(void);
bit WASHER_Read_Water_Level(void);
bit WASHER_Read_Water_Temperature(void);
void WASHER_Control_Detergent_Hatch(bit);
void WASHER_Control_Door_Lock(bit);
void WASHER_Control_Motor(bit);
void WASHER_Control_Pump(bit);
void WASHER_Control_Water_Heater(bit);
void WASHER_Control_Water_Valve(bit);
Copyright © 2009-2011 TTE Systems Ltd
65 Licensed to University of Leicester
Washing machine controller: Code listing
// ------ Private constants ----------------------------------------
#define OFF 0
#define ON 1
#define MAX_FILL_DURATION (tLong) 1000
#define MAX_WATER_HEAT_DURATION (tLong) 1000
#define WASH_01_DURATION 30000
// ------ Private variables ----------------------------------------
static eSystem_state System_state_G;
static tWord Time_in_state_G;
static tByte Program_G;
// Ten different programs are supported
// Each one may or may not use detergent
static tByte Detergent_G[10] = {1,1,1,0,0,1,0,1,1,0};
// Each one may or may not use hot water
static tByte Hot_Water_G[10] = {1,1,1,0,0,1,0,1,1,0};
/* --------------------------------------------------------------- */
void WASHER_Init(void)
{
System_state_G = INIT;
}
Copyright © 2009-2011 TTE Systems Ltd
66 Licensed to University of Leicester
Page 95
Washing machine controller: Code listing
/* --------------------------------------------------------------- */
void WASHER_Update(void) // Call once per second
{
switch (System_state_G)
{
case INIT:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;
// Set up initial state
WASHER_Control_Motor(OFF); // Motor is off
WASHER_Control_Pump(OFF); // Pump is off
WASHER_Control_Water_Heater(OFF); // Heater is off
WASHER_Control_Water_Valve(OFF);
// Wait (indefinitely) until START is pressed
if (WASHER_Read_Start_Switch() != 1)
{
return;
}
// Start switch pressed...
Program_G = WASHER_Read_Selector_Dial(); // Read the selector dial
System_state_G = START; // Change state
break;
}
Copyright © 2009-2011 TTE Systems Ltd
67 Licensed to University of Leicester
Washing machine controller: Code listing
case START:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;
// Lock the door
WASHER_Control_Door_Lock(ON);
// Start filling the drum
WASHER_Control_Water_Valve(ON);
// Release the detergent (if any)
if (Detergent_G[Program_G] == 1)
{
WASHER_Control_Detergent_Hatch(ON);
}
// Ready to go to next state
System_state_G = FILL_DRUM;
Time_in_state_G = 0;
break;
}
Copyright © 2009-2011 TTE Systems Ltd
68 Licensed to University of Leicester
Page 96
Washing machine controller: Code listing
case FILL_DRUM:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;
// Remain in this state until drum is full
// NOTE: Timeout facility included here
if (++Time_in_state_G >= MAX_FILL_DURATION)
{
System_state_G = ERROR; // Should have filled the drum by now...
}
// Check the water level
if (WASHER_Read_Water_Level() == 1)
{
// Drum is full
if (Hot_Water_G[Program_G] == 1) // Does the program require hot water?
{
WASHER_Control_Water_Heater(ON);
System_state_G = HEAT_WATER; // Ready to go to next state
Time_in_state_G = 0;
}
else
{
System_state_G = WASH_01; // Ready to go to next state
Time_in_state_G = 0;
}
}
break;
}
Copyright © 2009-2011 TTE Systems Ltd
69 Licensed to University of Leicester
Washing machine controller: Code listing
case HEAT_WATER:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;
// Remain in this state until water is hot
// NOTE: Timeout facility included here
if (++Time_in_state_G >= MAX_WATER_HEAT_DURATION)
{
// Should have warmed the water by now...
System_state_G = ERROR;
}
// Check the water temperature
if (WASHER_Read_Water_Temperature() == 1)
{
// Water is at required temperature
// Ready to go to next state
System_state_G = WASH_01;
Time_in_state_G = 0;
}
break;
}
Copyright © 2009-2011 TTE Systems Ltd
70 Licensed to University of Leicester
Page 97
Washing machine controller: Code listing
case WASH_01:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;
// All wash program involve WASH_01
// Drum is slowly rotated to ensure clothes are fully wet
WASHER_Control_Motor(ON);
if (++Time_in_state_G >= WASH_01_DURATION)
{
System_state_G = WASH_02;
Time_in_state_G = 0;
}
break;
}
// REMAINING WASH PHASES OMITTED HERE ...
case WASH_02:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;
break;
}
Copyright © 2009-2011 TTE Systems Ltd
71 Licensed to University of Leicester
Washing machine controller: Code listing
case ERROR:
{
// For demo purposes only
Debug_port = (tByte) System_state_G;
break;
}
}
}
/* --------------------------------------------------------------- */
tByte WASHER_Read_Selector_Dial(void)
{
// User code here...
return 0;
}
Copyright © 2009-2011 TTE Systems Ltd
72 Licensed to University of Leicester
Page 98
Washing machine controller: Code listing
/* --------------------------------------------------------------- */
bit WASHER_Read_Start_Switch(void)
{
// Simplified for demo ...
if (Start_pin == 0)
{
// Start switch pressed
return 1;
}
else
{
return 0;
}
}
/* --------------------------------------------------------------- */
bit WASHER_Read_Water_Level(void)
{
// User code here...
return 1;
}
Copyright © 2009-2011 TTE Systems Ltd
73 Licensed to University of Leicester
Washing machine controller: Code listing
/* --------------------------------------------------------------- */
bit WASHER_Read_Water_Temperature(void)
{
// User code here...
return 1;
}
/* --------------------------------------------------------------- */
void WASHER_Control_Detergent_Hatch(bit State)
{
bit Tmp = State;
// User code here...
}
/* --------------------------------------------------------------- */
void WASHER_Control_Door_Lock(bit State)
{
bit Tmp = State;
// User code here...
}
/* --------------------------------------------------------------- */
void WASHER_Control_Motor(bit State)
{
bit Tmp = State;
// User code here...
}
Copyright © 2009-2011 TTE Systems Ltd
74 Licensed to University of Leicester
Page 99
Washing machine controller: Code listing
/* --------------------------------------------------------------- */
void WASHER_Control_Pump(bit State)
{
bit Tmp = State;
// User code here...
}
/* --------------------------------------------------------------- */
void WASHER_Control_Water_Heater(bit State)
{
bit Tmp = State;
// User code here...
}
/* --------------------------------------------------------------- */
void WASHER_Control_Water_Valve(bit State)
{
bit Tmp = State;
// User code here...
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
75 Licensed to University of Leicester
Dealing with long tasks in TTC designs
Copyright © 2009-2011 TTE Systems Ltd
76 Licensed to University of Leicester
Page 100
Simple TTC designs: The “long task problem” …
It’s easy to think up task sets which can’t be scheduled using a TTC architecture …
A A A A ...
Time
B ...
Time
Copyright © 2009-2011 TTE Systems Ltd
77 Licensed to University of Leicester
Example: Using an appropriate task structure (RS-232)
printf(“Current core temperature is 36.678 degrees”);
Assume:
- Using RS-232 to send data to a PC (or similar)
- 9600 baud
Takes ~ 42 ms to send these data
Copyright © 2009-2011 TTE Systems Ltd
78 Licensed to University of Leicester
Page 101
Example: Using an appropriate task structure (RS-232)
Current core temperature All characters copied to buffer
is 36.678 degrees (fast operation)
Buffer (character array)
Schedule a task to send one character
from the buffer every 10 ms (for example)
Copyright © 2009-2011 TTE Systems Ltd
79 Licensed to University of Leicester
What is RS-232?
Recommended Standard 232 first appeared in 1960s and
defines:
– The protocol to be used for data transmission
– The voltages to be used on the signal lines
– The connectors to be used to link equipment together
Widely used at data rates up to around 115 or 330 kbits /
second (k baud).
Used to communicate with devices at 15 meters or more.
Copyright © 2009-2011 TTE Systems Ltd
80 Licensed to University of Leicester
Page 102
Is it still significant?
Used by some derivatives of the 8051 and most of the newer
microcontrollers (e.g. C166, ARM7, Cortex, etc) for in system
programming (ISP) or in circuit programming (ICP).
Provides a link between a PC and the microcontroller that can
be used for:
– Testing and debugging
– Data acquisition
Does not have the complexities of USB or Bluetooth and is still
used in some of the recent devices (e.g. GPS sensors, TV
boxes for updating the device configuration, etc.)
Copyright © 2009-2011 TTE Systems Ltd
81 Licensed to University of Leicester
The basics of RS-232
Asynchronous data transmission
+3V to +15V for bit value of 0
-3V to -15V for bit value of 1
Quiescent (idle) state: (1, indefinite duration)
Start bit: (0, 1 x bit duration)
Data: (typically 7-8 data bits, with optional parity bit)
Stop bit(s): (0, duration of 1, 1.5 or 2 bits)
Source: Wikipedia (http://en.wikipedia.org/wiki/File:Rs232_oscilloscope_trace.svg)
Copyright © 2009-2011 TTE Systems Ltd
82 Licensed to University of Leicester
Page 103
Transmission rates and flow control
Operates in a restricted band of speeds, for example:
– 75, 110, 300, 1200, 2400, 4800, 9600, 14400, 19200, 28800, 33600,
56000, 115000, 330000, 460800 (some new machines) baud
9600 is a very safe choice
Hardware handshaking possible but requires extra connections
Software based “Xon / Xoff” control is possible on half or full
duplex links:
– The receiver uses the “Xon” (Control q) and “Xoff” (Control s) commands
to pace the data flow to it
– Transmitter sends data bytes until it receives “Xoff” command. It resumes
transmission when it receives the “Xon” command
Copyright © 2009-2011 TTE Systems Ltd
83 Licensed to University of Leicester
On-chip UART SFRs
SCON
Bit # 7 6 5 4 3 2 1 0
Name SM0 SM1 SM2 REN TB8 RB8 TI RI
Function Mode bit 0 Mode bit 1 Multi Receiver 8th bit for 9 8th bit for 9 Transmit Receive
processor enable bit data TX bit data interrupt interrupt
comm. mode RX mode flag flag
SM0 SM1 Mode # Description Baud rate
0 0 0 8-bit shift register Oscillator derived
0 1 1 8-bit UART Timer 1 overflow derived
1 0 2 9-bit UART Oscillator derived
1 1 3 9-bit UART Timer 1 overflow derived
Copyright © 2009-2011 TTE Systems Ltd
84 Licensed to University of Leicester
Page 104
On-chip UART SFRs
SBUF
The SBUF SFR links to separate internal registers based on
the operation being performed
Reading SBUF accesses the receiver’s buffer and returns the
received byte. The receive buffer retains the last value
received while another byte is being received
Writing to SBUF accesses the transmitter’s buffer and starts
transmission of the byte just written. Writing to the SBUF
while transmission is in progress corrupts the process
Copyright © 2009-2011 TTE Systems Ltd
85 Licensed to University of Leicester
On-chip UART Mode 1 baud rates
Baud rate in mode 1 is controlled by the rate of Timer 1
overflow and given by the following formula:
2 SMOD × Frequencyoscillator
Baud rate ( Mode 1) =
32 × Instructionscycle × (256 − TH 1)
SMOD - the ‘double baud rate’ bit in the PCON register.
Frequency oscillator - the oscillator / resonator frequency.
Instructions cycle - the number of oscillator cycles per machine cycle
(12 for standard 8051)
TH1 - the reload value for Timer 1
To generate precise baud rates, clock sources are required to
have non-integer frequencies (e.g. 11.0592 MHz)
Copyright © 2009-2011 TTE Systems Ltd
86 Licensed to University of Leicester
Page 105
On-chip UART Mode 1 baud rates
Calculating the reload values for Timer 1 for 9600 baud
(xtal = 11.0592 MHz / 12 MHz, SMOD = 0 in both cases):
11059200 12000000
9600 = 9600 =
32 × 12 × (256 − TH 1) 32 ×12 × (256 − TH 1)
11059200 12000000
TH 1 = 256 − TH 1 = 256 −
9600 × 384 9600 × 384
TH 1 = 253 TH 1 = 252.7447916667
Using 253 reload value with a 12 MHz oscillator, the resulting
baud rate achieved would be 10417 (off by more than 8%)
In practice the error in the baud rate should be ±2.5%.
Copyright © 2009-2011 TTE Systems Ltd
87 Licensed to University of Leicester
Case study
Copyright © 2009-2011 TTE Systems Ltd
88 Licensed to University of Leicester
Page 106
Case study: Displaying elapsed time
Send time elapsed since system power on over a serial link at
9600 baud (using 11.0592 MHz clock)
Copyright © 2009-2011 TTE Systems Ltd
89 Licensed to University of Leicester
Displaying elapsed time – Code listing
/*------------------------------------------------------------------*-
Port.H (v1.01)
------------------------------------------------------------------
'Port Header' (see Chap 5) for the project TIME (see Chap 9)
-*------------------------------------------------------------------*/
#ifndef _PORT_H
#define _PORT_H
// ------ PC_O.C -----------------------------------------------
// Pins 3.0 and 3.1 used for RS-232 interface
#endif
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
90 Licensed to University of Leicester
Page 107
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
Main.c (v1.00)
------------------------------------------------------------------
RS-232 (Elapsed Time) example - sEOS.
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Simple_EOS.H“
#include "PC_O_T1.h"
#include "Elap_232.h“
/* --------------------------------------------------------------- */
void main(void)
{
// Set baud rate to 9600
PC_LINK_O_Init_T1(9600);
// Prepare for elapsed time measurement
Elapsed_Time_RS232_Init();
// Set up simple EOS (5ms tick)
sEOS_Init_Timer2(5);
while(1) // Super Loop
{
sEOS_Go_To_Sleep(); // Enter idle mode to save power
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
91 Licensed to University of Leicester
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
Elap_232.C (v1.00)
------------------------------------------------------------------
Simple library function for keeping track of elapsed time
Demo version to display time on PC screen via RS232 link.
-*------------------------------------------------------------------*/
#include "Main.h"
#include "Elap_232.h"
#include "PC_O.h"
// ------ Public variable definitions ------------------------------
tByte Hou_G = 0;
tByte Min_G = 0;
tByte Sec_G = 0;
// ------ Public variable declarations -----------------------------
// See Char_Map.c
extern const char code CHAR_MAP_G[10];
/*------------------------------------------------------------------*-
Elapsed_Time_RS232_Init()
-*------------------------------------------------------------------*/
void Elapsed_Time_RS232_Init(void)
{
char Time_Str[] = "Elapsed time";
//PC_LINK_O_Write_String_To_Buffer(Time_Str);
}
Copyright © 2009-2011 TTE Systems Ltd
92 Licensed to University of Leicester
Page 108
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
Elapsed_Time_RS232_Update()
*** Must be called once per second ***
-*------------------------------------------------------------------*/
void Elapsed_Time_RS232_Update(void)
{
char Time_Str[30] = "\rElapsed time: ";
if (++Sec_G == 60)
{
Sec_G = 0;
if (++Min_G == 60)
{
Min_G = 0;
if (++Hou_G == 24)
{
Hou_G = 0;
}
}
}
Time_Str[15] = CHAR_MAP_G[Hou_G / 10];
Time_Str[16] = CHAR_MAP_G[Hou_G % 10];
Time_Str[18] = CHAR_MAP_G[Min_G / 10];
Time_Str[19] = CHAR_MAP_G[Min_G % 10];
Copyright © 2009-2011 TTE Systems Ltd
93 Licensed to University of Leicester
Displaying elapsed time: Code listing
<Elapsed_Time_RS232_Update() – Continued>
Time_Str[21] = CHAR_MAP_G[Sec_G / 10];
Time_Str[22] = CHAR_MAP_G[Sec_G % 10];
// We don't display seconds in this version.
// We simply use the seconds data to turn on and off the colon
// (between hours and minutes)
if ((Sec_G % 2) == 0)
{
Time_Str[17] = ':';
Time_Str[20] = ':';
}
else
{
Time_Str[17] = ' ';
Time_Str[20] = ' ';
}
PC_LINK_O_Write_String_To_Buffer(Time_Str);
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
94 Licensed to University of Leicester
Page 109
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
PC_O_T1.C (v1.00)
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_O_T1.h"
// ------ Public variable declarations -----------------------------
extern tByte Out_written_index_G;
extern tByte Out_waiting_index_G;
/*------------------------------------------------------------------*-
PC_LINK_O_Init_T1()
-*------------------------------------------------------------------*/
void PC_LINK_O_Init_T1(const tWord BAUD_RATE)
{
PCON &= 0x7F; // Set SMOD bit to 0 (don't double baud rates)
// 8-bit data, 1 start bit, 1 stop bit, variable baud rate, receiver disabled
SCON = 0x42;
TMOD |= 0x20; // T1 in mode 2, 8-bit auto reload
TH1 = (256 - (tByte)((((tLong)OSC_FREQ / 100) * 3125)
/ ((tLong) BAUD_RATE * OSC_PER_INST * 1000)));
TL1 = TH1;
TR1 = 1; // Run the timer
TI = 1; // Send first character (dummy)
// Set up the buffers for reading and writing
Out_written_index_G = 0;
Out_waiting_index_G = 0;
// Interrupt *NOT* enabled
ES = 0;
}
Copyright © 2009-2011 TTE Systems Ltd
95 Licensed to University of Leicester
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
PC_O.C (v1.00)
------------------------------------------------------------------
Core files for simple write-only PC link library for 8051 family
[Sends data to PC - cannot receive data from PC]
Uses the UART, and Pin 3.1 (Tx)
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_O.h"
#include "Elap_232.h"
// ------ Public variable definitions ------------------------------
tByte Out_written_index_G; // Data in buffer that has been written
tByte Out_waiting_index_G; // Data in buffer not yet written
// ------ Private constants ----------------------------------------
// The transmit buffer length
#define TRAN_BUFFER_LENGTH 20
// ------ Private variables ----------------------------------------
static tByte Tran_buffer[TRAN_BUFFER_LENGTH];
static tByte Time_count_G = 0;
Copyright © 2009-2011 TTE Systems Ltd
96 Licensed to University of Leicester
Page 110
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
PC_LINK_O_Update()
Sends next character from the software transmit buffer
NOTE: Output-only library (Cannot receive chars)
Uses on-chip UART hardware.
-*------------------------------------------------------------------*/
void PC_LINK_O_Update(void)
{
// Deal with transmit bytes here
// Are there any data ready to send?
if (Out_written_index_G < Out_waiting_index_G)
{
PC_LINK_O_Send_Char(Tran_buffer[Out_written_index_G]);
Out_written_index_G++;
}
else
{
// No data to send - just reset the buffer index
Out_waiting_index_G = 0;
Out_written_index_G = 0;
}
}
Copyright © 2009-2011 TTE Systems Ltd
97 Licensed to University of Leicester
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
PC_LINK_O_Write_String_To_Buffer()
Copies a (null terminated) string to the character buffer.
-*------------------------------------------------------------------*/
void PC_LINK_O_Write_String_To_Buffer(const char* const STR_PTR)
{
tByte i = 0;
while (STR_PTR[i] != '\0')
{
PC_LINK_O_Write_Char_To_Buffer(STR_PTR[i]);
i++;
}
}
/*------------------------------------------------------------------*-
PC_LINK_O_Write_Char_To_Buffer()
Stores a character in the 'write' buffer, ready for later transmission
-*------------------------------------------------------------------*/
void PC_LINK_O_Write_Char_To_Buffer(const char CHARACTER)
{
// Write to the buffer *only* if there is space
// (No error reporting in this simple library...)
if (Out_waiting_index_G < TRAN_BUFFER_LENGTH)
{
Tran_buffer[Out_waiting_index_G] = CHARACTER;
Out_waiting_index_G++;
}
}
Copyright © 2009-2011 TTE Systems Ltd
98 Licensed to University of Leicester
Page 111
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
PC_LINK_O_Send_Char()
-*------------------------------------------------------------------*/
void PC_LINK_O_Send_Char(const char CHARACTER)
{
tLong Timeout1 = 0;
if (CHARACTER == '\n')
{
Timeout1 = 0;
while ((++Timeout1) && (TI == 0));
if (Timeout1 == 0)
{
// usart did not respond - error
return;
}
TI = 0;
SBUF = 0x0d; // Output CR
}
Timeout1 = 0;
while ((++Timeout1) && (TI == 0));
if (Timeout1 == 0)
{
// UART did not respond - error
return;
}
TI = 0;
SBUF = CHARACTER;
}
Copyright © 2009-2011 TTE Systems Ltd
99 Licensed to University of Leicester
Displaying elapsed time: Code listing
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
-*------------------------------------------------------------------*/
#include ...
// ------ Private variable definitions -----------------------------
static tByte Call_count_G = 0;
/*------------------------------------------------------------------*-
sEOS_ISR()
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
TF2 = 0; // Must manually reset the T2 flag
//===== USER CODE - Begin =======================================
// Call RS-232 update function every 5ms
PC_LINK_O_Update();
// This ISR is called every 5 ms
// - only want to update time every second
if (++Call_count_G == 200)
{
// Time to update time
Call_count_G = 0;
// Call time update function
Elapsed_Time_RS232_Update();
}
//===== USER CODE - End =========================================
}
Copyright © 2009-2011 TTE Systems Ltd
100 Licensed to University of Leicester
Page 112
Case study
Copyright © 2009-2011 TTE Systems Ltd
101 Licensed to University of Leicester
Serial menus – Alternative to switch based UI
Display a menu over a serial link
Change system operation based on input from user
Copyright © 2009-2011 TTE Systems Ltd
102 Licensed to University of Leicester
Page 113
Menu-based data acquisition – Code Listing
/*------------------------------------------------------------------*-
Main.c (v1.01)
------------------------------------------------------------------
Data acquisition example.
-*------------------------------------------------------------------*/
#include "Main.h"
#include "Simple_EOS.H"
#include "PC_IO_T1.h"
/* ............................................................... */
void main(void)
{
// Set baud rate to 9600: generic 8051 version
PC_LINK_IO_Init_T1(9600);
// Set up sEOS (5ms tick)
sEOS_Init_Timer2(5);
while(1) // Super Loop
{
sEOS_Go_To_Sleep(); // Enter idle mode to save power
}
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
103 Licensed to University of Leicester
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
Menu_Data.C (v1.00)
------------------------------------------------------------------
Simple framework for menu-driven data acquisition.
Use 'Hyperterminal' (under Windows 95, 98, 2000) or similar
terminal emulator program on other operating systems.
Terminal options:
- Data bits = 8
- Parity = None
- Stop bits = 1
- Flow control = Xon / Xoff
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Port.H"
#include "Menu_Data.h"
#include "PC_IO.h"
// ------ Public variable declarations -----------------------------
// See Char_Map.c
extern const char code CHAR_MAP_G[10];
// ------ Private variables ----------------------------------------
static bit First_time_only_G;
Copyright © 2009-2011 TTE Systems Ltd
104 Licensed to University of Leicester
Page 114
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
MENU_Command_Processor()
This function is the main menu 'command processor' function.
Schedule this (say) once every 10 ms (approx.).
-*------------------------------------------------------------------*/
void MENU_Command_Processor(void)
{
char Ch;
if (First_time_only_G == 0)
{
First_time_only_G = 1;
MENU_Show_Menu();
}
// Check for user inputs
PC_LINK_IO_Update();
Ch = PC_LINK_IO_Get_Char_From_Buffer();
if (Ch != PC_LINK_IO_NO_CHAR)
{
MENU_Perform_Task(Ch);
MENU_Show_Menu();
}
}
Copyright © 2009-2011 TTE Systems Ltd
105 Licensed to University of Leicester
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
MENU_Show_Menu()
Display menu options on PC screen (via serial link)
-*------------------------------------------------------------------*/
void MENU_Show_Menu(void)
{
PC_LINK_IO_Write_String_To_Buffer("Menu:\n");
PC_LINK_IO_Write_String_To_Buffer("a - Read P1\n");
PC_LINK_IO_Write_String_To_Buffer("b - Read P2\n\n");
PC_LINK_IO_Write_String_To_Buffer("? : ");
}
Copyright © 2009-2011 TTE Systems Ltd
106 Licensed to University of Leicester
Page 115
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
MENU_Perform_Task()
Perform the required user task
-*------------------------------------------------------------------*/
void MENU_Perform_Task(char c)
{
// Echo the menu option
PC_LINK_IO_Write_Char_To_Buffer(c);
PC_LINK_IO_Write_Char_To_Buffer('\n'); // Perform the task
switch (c)
{
case 'a':
case 'A':
{
Get_Data_From_Port1();
break;
}
case 'b':
case 'B':
{
Get_Data_From_Port2();
break;
}
}
}
Copyright © 2009-2011 TTE Systems Ltd
107 Licensed to University of Leicester
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
Get_Data_From_Port1()
-*------------------------------------------------------------------*/
void Get_Data_From_Port1(void)
{
tByte Port1 = Data_Port1;
char String[11] = "\nP1 = XXX\n\n";
String[6] = CHAR_MAP_G[Port1 / 100];
String[7] = CHAR_MAP_G[(Port1 / 10) % 10];
String[8] = CHAR_MAP_G[Port1 % 10];
PC_LINK_IO_Write_String_To_Buffer(String);
}
/*------------------------------------------------------------------*-
Get_Data_From_Port2()
-*------------------------------------------------------------------*/
void Get_Data_From_Port2(void)
{
tByte Port2 = Data_Port2;
char String[11] = "\nP2 = XXX\n\n";
String[6] = CHAR_MAP_G[Port2 / 100];
String[7] = CHAR_MAP_G[(Port2 / 10) % 10];
String[8] = CHAR_MAP_G[Port2 % 10];
PC_LINK_IO_Write_String_To_Buffer(String);
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
108 Licensed to University of Leicester
Page 116
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_IO_T1.C (v1.00)
------------------------------------------------------------------
PC link library. Bidirectional. T1 used for baud rate generation.
Uses the USART, and Pins 3.1 (Tx) and 3.0 (Rx)
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_IO_T1.h"
// ------ Public variable declarations -----------------------------
extern tByte In_read_index_G;
extern tByte In_waiting_index_G;
extern tByte Out_written_index_G;
extern tByte Out_waiting_index_G;
/*------------------------------------------------------------------*-
PC_LINK_IO_Init_T1()
This (generic) version uses T1 for baud rate generation.
-*------------------------------------------------------------------*/
void PC_LINK_IO_Init_T1(const tWord BAUD_RATE)
{
PCON &= 0x7F; // Set SMOD bit to 0 (don't double baud rates)
<Continued>
Copyright © 2009-2011 TTE Systems Ltd
109 Licensed to University of Leicester
Menu-based data acquisition: Code listing
<PC_LINK_IO_Init_T1() - Continued>
// Receiver enabled.
// 8-bit data, 1 start bit, 1 stop bit,
// Variable baud rate (asynchronous)
// Receive flag will only be set if a valid stop bit is received
// Set TI (transmit buffer is empty)
SCON = 0x72;
TMOD |= 0x20; // T1 in mode 2, 8-bit auto reload
TH1 = (256 - (tByte)((((tLong)OSC_FREQ / 100) * 3125)
/ ((tLong) BAUD_RATE * OSC_PER_INST * 1000)));
TL1 = TH1;
TR1 = 1; // Run the timer
TI = 1; // Send first character (dummy)
// Set up the buffers for reading and writing
In_read_index_G = 0;
In_waiting_index_G = 0;
Out_written_index_G = 0;
Out_waiting_index_G = 0;
// Interrupt *NOT* enabled
ES = 0;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Menu based data acquision
Copyright © 2009-2011 TTE Systems Ltd
110 Licensed to University of Leicester
Page 117
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_IO.C (v1.00)
------------------------------------------------------------------
Core files for simple PC link library for 8051 family
Uses the USART, and Pins 3.1 (Tx) and 3.0 (Rx)
-*------------------------------------------------------------------*/
#include "Main.h"
#include "PC_IO.h"
// ------ Public variable definitions ------------------------------
tByte In_read_index_G; // Data in buffer that has been read
tByte In_waiting_index_G; // Data in buffer not yet read
tByte Out_written_index_G; // Data in buffer that has been written
tByte Out_waiting_index_G; // Data in buffer not yet written
// ------ Private function prototypes ------------------------------
static void PC_LINK_IO_Send_Char(const char);
// ------ Private constants ----------------------------------------
// The receive buffer length
#define RECV_BUFFER_LENGTH 8
// The transmit buffer length
#define TRAN_BUFFER_LENGTH 50
#define XON 0x11
#define XOFF 0x13
Copyright © 2009-2011 TTE Systems Ltd
111 Licensed to University of Leicester
Menu-based data acquisition: Code listing
// ------ Private variables ----------------------------------------
static tByte Recv_buffer[RECV_BUFFER_LENGTH];
static tByte Tran_buffer[TRAN_BUFFER_LENGTH];
/*------------------------------------------------------------------*-
PC_LINK_IO_Update()
Checks for character in the UART (hardware) receive buffer
Sends next character from the software transmit buffer
-*------------------------------------------------------------------*/
void PC_LINK_IO_Update(void)
{
// Deal with transmit bytes here
// Is there any data ready to send?
if (Out_written_index_G < Out_waiting_index_G)
{
PC_LINK_IO_Send_Char(Tran_buffer[Out_written_index_G]);
Out_written_index_G++;
}
else
{
// No data to send - just reset the buffer index
Out_waiting_index_G = 0;
Out_written_index_G = 0;
}
<Continued>
Copyright © 2009-2011 TTE Systems Ltd
112 Licensed to University of Leicester
Page 118
Menu-based data acquisition: Code listing
<PC_LINK_IO_Update() – Continued>
// Only dealing with received bytes here
if (RI == 1)
{
// Flag only set when a valid stop bit is received,
// -> data ready to be read into the received buffer
// Want to read into index 0, if old data has been read
// (simple ~circular buffer)
if (In_waiting_index_G == In_read_index_G)
{
In_waiting_index_G = 0;
In_read_index_G = 0;
}
// Read the data from USART buffer
Recv_buffer[In_waiting_index_G] = SBUF;
if (In_waiting_index_G < RECV_BUFFER_LENGTH)
{
// Increment without overflowing buffer
In_waiting_index_G++;
}
RI = 0; // Clear RT flag
}
}
Copyright © 2009-2011 TTE Systems Ltd
113 Licensed to University of Leicester
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_LINK_IO_Write_Char_To_Buffer()
Stores a character in the 'write' buffer, ready for
later transmission
-*------------------------------------------------------------------*/
void PC_LINK_IO_Write_Char_To_Buffer(const char CHARACTER)
{
// Write to the buffer *only* if there is space
// - No error reporting in this simple library...
if (Out_waiting_index_G < TRAN_BUFFER_LENGTH)
{
Tran_buffer[Out_waiting_index_G] = CHARACTER;
Out_waiting_index_G++;
}
}
Copyright © 2009-2011 TTE Systems Ltd
114 Licensed to University of Leicester
Page 119
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_LINK_IO_Write_String_To_Buffer()
Copies a (null terminated) string to the character buffer.
(The contents of the buffer are then passed over the serial link)
STR_PTR - Pointer to the NULL-TERMINATED string.
-*------------------------------------------------------------------*/
void PC_LINK_IO_Write_String_To_Buffer(const char* const STR_PTR)
{
tByte i = 0;
while (STR_PTR[i] != '\0')
{
PC_LINK_IO_Write_Char_To_Buffer(STR_PTR[i]);
i++;
}
}
Copyright © 2009-2011 TTE Systems Ltd
115 Licensed to University of Leicester
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_LINK_IO_Get_Char_From_Buffer()
Retrieves a character from the (software) buffer, if available
The character from the buffer is returned, or - if no
data are available - PC_LINK_IO_NO_CHAR is returned.
-*------------------------------------------------------------------*/
char PC_LINK_IO_Get_Char_From_Buffer(void)
{
char Ch = PC_LINK_IO_NO_CHAR;
// If there is new data in the buffer
if (In_read_index_G < In_waiting_index_G)
{
Ch = Recv_buffer[In_read_index_G];
if (In_read_index_G < RECV_BUFFER_LENGTH)
{
In_read_index_G++;
}
}
return Ch;
}
Copyright © 2009-2011 TTE Systems Ltd
116 Licensed to University of Leicester
Page 120
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
PC_LINK_IO_Send_Char()
Based on Keil sample code, with added (loop) timeouts.
Implements Xon / Off control.
-*------------------------------------------------------------------*/
void PC_LINK_IO_Send_Char(const char CHARACTER)
{
tLong Timeout1 = 0;
tLong Timeout2 = 0;
if (CHARACTER == '\n')
{
if (RI)
{
if (SBUF == XOFF)
{
Timeout2 = 0;
do {
RI = 0;
// Wait for uart (with simple timeout)
Timeout1 = 0;
while ((++Timeout1) && (RI == 0));
if (Timeout1 == 0)
{
// USART did not respond - error
return;
}
} while ((++Timeout2) && (SBUF != XON));
< Continued>
Copyright © 2009-2011 TTE Systems Ltd
117 Licensed to University of Leicester
Menu-based data acquisition: Code listing
< PC_LINK_IO_Send_Char() – Continued>
if (Timeout2 == 0)
{
// UART did not respond - error
// No error reporting in this simple library...
return;
}
RI = 0;
}
}
Timeout1 = 0;
while ((++Timeout1) && (TI == 0));
if (Timeout1 == 0)
{
// UART did not respond - error
// No error reporting in this simple library...
return;
}
TI = 0;
SBUF = 0x0d; // Output CR
}
<Continued>
Copyright © 2009-2011 TTE Systems Ltd
118 Licensed to University of Leicester
Page 121
Menu-based data acquisition: Code listing
< PC_LINK_IO_Send_Char() – Continued>
if (RI)
{
if (SBUF == XOFF)
{
Timeout2 = 0;
do {
RI = 0;
// Wait for USART (with simple timeout)
Timeout1 = 0;
while ((++Timeout1) && (RI == 0));
if (Timeout1 == 0)
{
// UART did not respond - error
// No error reporting in this simple library...
return;
}
} while ((++Timeout2) && (SBUF != XON));
RI = 0;
}
}
<Continued>
Copyright © 2009-2011 TTE Systems Ltd
119 Licensed to University of Leicester
Menu-based data acquisition: Code listing
< PC_LINK_IO_Send_Char() – Continued>
Timeout1 = 0;
while ((++Timeout1) && (TI == 0));
if (Timeout1 == 0)
{
// UART did not respond - error
// No error reporting in this simple library...
return;
}
TI = 0;
SBUF = CHARACTER;
}
/*------------------------------------------------------------------*-
---- END OF FILE -------------------------------------------------
-*------------------------------------------------------------------*/
Copyright © 2009-2011 TTE Systems Ltd
120 Licensed to University of Leicester
Page 122
Menu-based data acquisition: Code listing
/*------------------------------------------------------------------*-
Simple_EOS.C (v1.00)
------------------------------------------------------------------
Main file for Simple Embedded Operating System (sEOS) for 8051.
- This version for project DATA_ACQ (Chapter 9).
-*------------------------------------------------------------------*/
#include "Main.H"
#include "Simple_EOS.H"
#include "Menu_Data.H"
/*------------------------------------------------------------------*-
sEOS_ISR()
Invoked periodically by Timer 2 overflow:
see sEOS_Init_Timer2() for timing details.
-*------------------------------------------------------------------*/
sEOS_ISR() interrupt INTERRUPT_Timer_2_Overflow
{
TF2 = 0; // Must manually reset the T2 flag
//===== USER CODE - Begin =======================================
// Call MENU_Command_Processor every 5ms
MENU_Command_Processor();
//===== USER CODE - End =========================================
}
...
Copyright © 2009-2011 TTE Systems Ltd
121 Licensed to University of Leicester
Working with MISRA C
Copyright © 2009-2011 TTE Systems Ltd
122 Licensed to University of Leicester
Page 123
The vision and objectives of MISRA C
When faced with the widespread (and increasing) use of C for the production of
embedded code with safety-related constraints, it was felt that there was a need to
produce a set of standards to assist software developers.
The Motor Industry Software Reliability Association (MISRA) set out to develop
such a set of guidelines in the late 1980’s / early 1990’s; this culminated in 1994
with the publication of MISRA C (revised in 2004).
The MISRA guidelines define a subset of the C language that can be used in critical
systems, by setting out a number of guidelines (141 in total). It also places a great
emphasis on the use of static checking tools to help enforce these guidelines.
MISRA C has become widely accepted in the UK and Europe, and is now
considered to be ‘best-practice’ in many industries, even those which produce
non-critical embedded systems.
Copyright © 2009-2011 TTE Systems Ltd
123 Licensed to University of Leicester
Relationship to other guidelines
There are several sources that have heavily influenced the MISRA rules
(e.g. IEC 61508).
There are also other sets of coding guidelines (for C as well as other
languages) that have been suggested independently by experts in their
respective fields.
Copyright © 2009-2011 TTE Systems Ltd
124 Licensed to University of Leicester
Page 124
Applying the MISRA C guidelines
(Simple tool support)
Copyright © 2009-2011 TTE Systems Ltd
125 Licensed to University of Leicester
Applying the MISRA C guidelines (simple tool support)
We will provide you with a
complete copy of the MISRA
C guidelines
We will also provide you with
simple checker for some of
the MISRA C rules
(Education Licence)
Copyright © 2009-2011 TTE Systems Ltd
126 Licensed to University of Leicester
Page 125
Applying the MISRA C guidelines (simple tool support)
2.2
Source code shall only use /* ... */ style comments
2.3
The character sequence /* shall not be used within a comment
2.4
Sections of code should not be /* commented out */
4.2
Trigraphs shall not be used
5.1
Identifiers (internal and external) shall not rely on the significance of more than 31
characters
Copyright © 2009-2011 TTE Systems Ltd
127 Licensed to University of Leicester
Applying the MISRA C guidelines (simple tool support)
5.2
Identifiers in an inner scope shall not use the same name as an identifier in an
outer scope, and therefore hide that identifier.
5.3
A typedef name shall be a unique identifier
5.4
A tag name shall be a unique identifier.
5.5
No object or function identifier with static storage duration should be reused
5.6
No identifier in one name space should have the same spelling as an identifier in
another name space, with the exception of structure and union member names.
Copyright © 2009-2011 TTE Systems Ltd
128 Licensed to University of Leicester
Page 126
Applying the MISRA C guidelines (simple tool support)
5.7
No identifier name should be reused.
6.3
typedefs that indicate size and signedness should be used in place of the
basic types
7.1
Octal constants (other than zero) and octal escape sequences shall not be
used.
8.1
Functions shall have prototype declarations and the prototype shall be visible
at both the function definition and call.
Copyright © 2009-2011 TTE Systems Ltd
129 Licensed to University of Leicester
Applying the MISRA C guidelines (simple tool support)
8.2
Whenever an object or function is declared or defined, its type shall be
explicitly stated.
8.3
For each function parameter the type given in the declaration and definition
shall be identical, and the return types shall also be identical.
8.6
Functions shall be declared at file scope.
Copyright © 2009-2011 TTE Systems Ltd
130 Licensed to University of Leicester
Page 127
Further reading related to MISRA C
MISRA. (2004). “Guidelines for the use of the C language in critical systems”. Motor
Industry Software Reliability Report, Released October 2004.
SAE. (1993) "Class C Application Requirement Considerations”. SAE Recommended
Practice J2056/1, SAE, June 1993.
Holzmann, G.J. (2006) “The Power of Ten: Rules for Developing Safety Critical Code”.
IEEE Computer, Vol. 39, No. 6, pp. 93-95, June 2006.
IEC 61508. (2000) “Functional safety of electrical/electronic/programmable electronic
safety-related systems, Part 3”. (2000).
Maguire, S. (1993) “Writing solid code”. Microsoft Press, 1993.
Copyright © 2009-2011 TTE Systems Ltd
131 Licensed to University of Leicester
Conclusion
Today we have considered:
– Creating and using a “simple embedded operating system”;
– Creating multi-state systems;
– Executing sequences of functions;
– Dealing with “long tasks” in reliable embedded systems;
– MISRA C.
Copyright © 2009-2011 TTE Systems Ltd
132 Licensed to University of Leicester
Page 128
All my own work
The following individuals contributed to the material and slides
presented in this session:
– Musharraf Hanif (University of Leicester)
– Devaraj Ayavoo (TTE Systems Ltd)
– Zemian Hughes (TTE Systems Ltd)
– Peter Vidler (TTE Systems Ltd)
– Muhammad Waqas Raza (TTE Systems Ltd)
– Keith Athaide (TTE Systems Ltd)
– Anjali Das (TTE Systems Ltd)
– Michael Short (Teesside University)
Copyright © 2009-2011 TTE Systems Ltd
133 Licensed to University of Leicester
Page 129
(Blank page)
Page 130
Day 3: Working with modern hardware platforms
Michael J. Pont
MSc in Reliable Embedded Systems
Module EG7510 (“A1a”)
Introduction and review
Copyright © 2009-2011 TTE Systems Ltd
2 Licensed to University of Leicester
Page 131
The story so far …
Seminar 1:
– Introduction to embedded systems, super loops and the “8051”;
– A first look at software architectures for embedded systems;
– A first look at techniques required to meet RT constraints.
Seminar 2:
– TTC concepts and sEOS;
– Creating multi-state systems;
– Executing sequences of functions;
– Dealing with “long tasks” (without resorting to pre-emption);
– MISRA C.
Copyright © 2009-2011 TTE Systems Ltd
3 Licensed to University of Leicester
Day 3 Outline
A closer look at some important timing issues
Welcome to the 32-bit MCU world!
– Higher CPU performance; More memory
– Enhanced set of hardware “peripherals”; Enhanced debug support
A multi-task TTC scheduler
Debugging with JTAG
The need for timing analysis in RT embedded systems
We will also consider two further platforms which are widely
used when developing modern embedded systems:
– The “x86” architecture (the “embedded PC”)
– The field-programmable gate array (a “roll your own” solution)
Copyright © 2009-2011 TTE Systems Ltd
4 Licensed to University of Leicester
Page 132
Thinking allowed …
Suppose that we were to compare 1000 embedded systems:
– 500 systems will be based on 8-bit processors
– 500 systems will be based on 32-bit processors
On average, would you expect the 8-bit or 32-bit systems to
be more reliable?
Copyright © 2009-2011 TTE Systems Ltd
5 Licensed to University of Leicester
A slightly closer look at timing issues
Copyright © 2009-2011 TTE Systems Ltd
6 Licensed to University of Leicester
Page 133
Real-time systems vs. embedded systems
“A real-time computer system is a computer system in which the
correctness of the system behaviour depends not only on the logical results
of the computations, but also on the physical instant at which these results
are produced.”
Source: Kopetz, H., “Real-Time Systems: Design Principles for Distributed Embedded Applications”,
(Kluwer Academic Publishers, 2002)
Copyright © 2009-2011 TTE Systems Ltd
7 Licensed to University of Leicester
Why timing matters: Jitter
Task Task Task Task Task Task
t=0 t=1 t=2 t=3 t=4 t=5
Time
Jitter can be defined as the variation of the interval between the start times of
periodic tasks in a RT system
Copyright © 2009-2011 TTE Systems Ltd
8 Licensed to University of Leicester
Page 134
Why timing matters: Jitter
Signal amplitude (Volts)
∆t ∆v
Time
For example, suppose we wish to sample a
500 Hz tone, using an 8-bit ADC
(a very modest requirement)
Application: The maximum allowable jitter
Any sampled-data system before we start using losing data)
(e.g. control, condition monitoring, will be ~1 µs
DSP, etc)
Rule of thumb: >10% jitter means that
data are likely to be meaningless
Copyright © 2009-2011 TTE Systems Ltd
9 Licensed to University of Leicester
Why timing matters: Jitter
Task Task Task Task Task Task
t=0 t=1 t=2 t=3 t=4 t=5
Time
Jitter can be defined as the variation of the interval between the start times of
periodic tasks in a RT system
BUT – suppose the activity we are interested in does not occur at the
start of the task? We may want to “balance” the task code
(see Seminar 1)
Copyright © 2009-2011 TTE Systems Ltd
10 Licensed to University of Leicester
Page 135
A very short history of embedded systems …
Copyright © 2009-2011 TTE Systems Ltd
11 Licensed to University of Leicester
History
1 P1.0 VCC 40
2 P1.1 P0.0 39
3 P1.2 P0.1 38
4 P1.3 P0.2 37
5 P1.4 P0.3 36
6 P1.5 P0.4 35
7 P1.6 P0.5 34
8 P1.7 P0.6 33
‘8051’
9 RST P0.7 32
10 P3.0 / EA 31
11 P3.1 ALE 30
12 P3.2 / PSEN 29
13 P3.3 P2.7 28
14 P3.4 P2.6 27
15 P3.5 P2.5 26
16 P3.6 P2.4 25
17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
Photo by Per Anders 20 VSS P2.0 21
Copyright © 2009-2011 TTE Systems Ltd
12 Licensed to University of Leicester
Page 136
History (and future?)
1 P1.0 VCC 40
2 P1.1 P0.0 39
3 P1.2 P0.1 38
4 P1.3 P0.2 37
5 P1.4 P0.3 36
6 P1.5 P0.4 35
7 P1.6 P0.5 34
8 P1.7 P0.6 33
‘8051’
9 RST P0.7 32
10 P3.0 / EA 31
11 P3.1 ALE 30
12 P3.2 / PSEN 29
13 P3.3 P2.7 28
14 P3.4 P2.6 27
15 P3.5 P2.5 26
16 P3.6 P2.4 25
17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
20 VSS P2.0 21
Copyright © 2009-2011 TTE Systems Ltd
13 Licensed to University of Leicester
Creating a complete hardware platform
Copyright © 2009-2011 TTE Systems Ltd
14 Licensed to University of Leicester
Page 137
Minimal circuit for the 8051
Copyright © 2009-2011 TTE Systems Ltd
15 Licensed to University of Leicester
Minimal circuit for the LPC2xxx
3.3V
Gnd
47
43
42
41
40
39
38
37
48
44
46
45
VDD3-1 (I/O)
P0.17
P0.16
VSS4
P0.13
P0.26
P0.25
P0.12
NC
P0.18
P0.15
P0.14
1 P0.19 P0.11 36
3.3V
2 P0.20 P0.10 35
3.3V 3 P0.21 P0.24 34
4 NC P0.23 33
1.3K
10 K
1.8V 5 VDD1.8 (Core) P0.22 32
6 /RST
LPC2104
VSS3 31 Gnd
10 µ F Gnd 7 VSS1 P0.9 30
8 P0.27 P0.8 29 1 mA LED
18 pF Gnd 9 P0.28 P0.7 28
Logic 0 (0v)
10 P0.29 DBGSEL 27
to light LED
11 X1 RTCK 26
VDD3-2 (I/O)
12 X2 NC 25
P0.0.31
P0.30
VSS2
P0.0
P0.1
P0.2
P0.3
P0.4
P0.5
P0.6
NC
10 MHz
18 pF
14
18
19
20
21
22
23
24
13
15
16
17
Gnd
Gnd
3.3V
Copyright © 2009-2011 TTE Systems Ltd
16 Licensed to University of Leicester
Page 138
Example 32-bit processor:
the NXP LPC2378
Copyright © 2009-2011 TTE Systems Ltd
17 Licensed to University of Leicester
Introduction to LPC2378
ARM7TDMI-S core running at up to 72 MHz
On chip 512 kB Flash and 32 kB SRAM
Dual Advanced High-performance Bus (AHB) architecture
Advanced vectored interrupt controller (VIC) with 32 sources
104 fast GPIO pins
4 x general purpose timers
1 x real time clock (RTC)
1 x PWM generator.
Multiple serial interfaces, including CAN
Support for testing and debugging
Copyright © 2009-2011 TTE Systems Ltd
18 Licensed to University of Leicester
Page 139
LPC2378: Memory Map
Program, data, external and
all peripherals are mapped in
a 4GB address space.
A 32-bit pointer variable can
be linked to any location in
the memory map
Copyright © 2009-2011 TTE Systems Ltd
19 Licensed to University of Leicester
LPC2378’s Vectored Interrupt Controller
32 interrupt request inputs.
Each input can be configured as either an FIQ or vectored IRQ
FIQs have highest priority.
Multiple inputs configured to trigger the FIQ interrupt are
logically ORed (ISR will have to check the actual source)
Vectored IRQs have programmable priorities and have the
address of the associated ISR programmed into the VIC.
Each peripheral has one interrupt line connected to the VIC
but can have multiple interrupt flags.
Copyright © 2009-2011 TTE Systems Ltd
20 Licensed to University of Leicester
Page 140
LPC2378’s fast general purpose parallel I/O (GPIO)
Located on ARM local bus to allow fastest possible I/O
Entire port value can be written in one instruction
Bit level set and clear registers
Direction control of individual bits
Port 0 and Port 2 pins can be configured to trigger an interrupt
on rising and/or falling edge. This interrupt generation works
even if clock sources are powered down.
Copyright © 2009-2011 TTE Systems Ltd
21 Licensed to University of Leicester
LPC2378’s ADC
10-bit successive approximation ADC
Input multiplexing from 8 input pins.
Measurement range between 0V to Vi(VREF) (2.5-3.3V)
Conversion time ≥ 2.44µs
Supports burst conversion for single or multiple inputs
Conversion on manual prompt, transition of input pin or timer
match signal
Allows the controller to ‘see’ analogue signals (e.g.
temperature from a thermocouple, absolute position from a
potentiometer, sound signal sampling, etc.)
Copyright © 2009-2011 TTE Systems Ltd
22 Licensed to University of Leicester
Page 141
Analogue inputs
What central-heating
temperature does the user
require? B
What is the current angle of
the crane?
C
What is the humidity level in
Greenhouse 3?
A
Actuator Main
Main control
control
Actuator
ActuatorAA Actuator BB Actuator
ActuatorCC
(Slave) &&user
user interface
interface
(Slave)
(Slave) (Slave) (Slave)
(Slave) (Master)
(Master)
Copyright © 2009-2011 TTE Systems Ltd
23 Licensed to University of Leicester
Analogue inputs
20oC
15oC 25oC
10oC 30oC
7805
≤ +24v (DC) + 5v
0.1 uF 50 k pot 0-5v
To ADC
0
0
Copyright © 2009-2011 TTE Systems Ltd
24 Licensed to University of Leicester
Page 142
Analogue inputs vs. digital inputs
3000
2000 4000
1894
1000 5000
Up Down
Copyright © 2009-2011 TTE Systems Ltd
25 Licensed to University of Leicester
LPC2378’s DAC
10-bit DAC.
Resistor string architecture with buffered output.
Can be used to reproduce analogue signals from samples
(e.g. Speech playback or audio signal processing, etc)
Copyright © 2009-2011 TTE Systems Ltd
26 Licensed to University of Leicester
Page 143
LPC2378’s Pulse width modulator
1 x PWM block with timer/counter operation.
7 match registers allow up to 6 single-edge or 3 double-edge
PWM outputs, or a mix of single and double edge signals.
It is also possible to generate an interrupt, stop and / or reset
the timer on a match event.
PWM is mainly used in power control but can be used as a
DAC if a low-pass filter is added to the PWM output.
Copyright © 2009-2011 TTE Systems Ltd
27 Licensed to University of Leicester
Analogue (PWM) outputs
“PWM” can be implemented in software
(low frequencies) or in hardware
PWM_PERIOD_G
PWM_G
PWM_position_G
if (PWM_position_G < PWM_G)
{
PWM_pin = PWM_ON;
}
else
{
PWM_pin = PWM_OFF;
}
Copyright © 2009-2011 TTE Systems Ltd
28 Licensed to University of Leicester
Page 144
Serial interfaces
10/100 Ethernet Media Access Controller (MAC) with 16 kB
SRAM
USB 2.0 Full speed device with 8 kB SRAM shared between
USB DMA and General-Purpose DMA (GPDMA)
4 x UARTs
1 x 2-channel CAN controller
1 x SPI controller
2 x SSP controllers
3 x I2C interfaces
1 x I2S (Inter IC Sound) interface with GPDMA
Copyright © 2009-2011 TTE Systems Ltd
29 Licensed to University of Leicester
LPC2378’s UARTs
4 on-chip UARTs (UART0, 1, 2 and 3)
Conform to 16C550 industry standard.
16-byte receive and transmit FIFOs.
Receive interrupt trigger points at 1, 4, 8 or 14 bytes.
Fractional baud rate generator to gen. standard baud rate
(e.g. 115200) without using crystals of particular values.
UART 1 equipped with standard modem interface signals with
full support for hardware flow control
UART 3 includes an IrDA encoding / decoding mode to
support infrared communication.
Can be used to communicate with serial device through wired
serial links or IrDA compliant links (UART 3)
Copyright © 2009-2011 TTE Systems Ltd
30 Licensed to University of Leicester
Page 145
LPC2378’s CAN controller
Compatible with CAN specification 2.0B
Two CAN controllers and buses with up to 1 Mbits/s data
rates.
11-bit and 29-bit receive identifier supported
Acceptance filter can provide automatic reception for selected
standard identifiers.
CAN is used in Shared-Clock scheduling,
distributed real-time control, etc.
Copyright © 2009-2011 TTE Systems Ltd
31 Licensed to University of Leicester
LPC2378’s general purpose 32-bit timers
4 x 32-bit timers (Timer 0, 1, 2 and 3)
32-bit counters with programmable 32-bit prescalers.
Selectable counter or timer operation.
Up to four 32-bit capture channels per timer with the option of
generating an interrupt on a capture event.
Four 32-bit match channels allowing generation of interrupt,
stopping the timer and / or resetting the timer, and optionally change
or toggle a corresponding output pin, on a match event.
These versatile timers can be used to generate scheduler ticks
(interrupt and reset on match), measure the time between multiple
external events (capture with optional interrupt), etc.
Copyright © 2009-2011 TTE Systems Ltd
32 Licensed to University of Leicester
Page 146
Working with FPGAs:
Introduction
Copyright © 2009-2011 TTE Systems Ltd
33 Licensed to University of Leicester
History (and future?)
1 P1.0 VCC 40
2 P1.1 P0.0 39
3 P1.2 P0.1 38
4 P1.3 P0.2 37
5 P1.4 P0.3 36
6 P1.5 P0.4 35
7 P1.6 P0.5 34
8 P1.7 P0.6 33
‘8051’
9 RST P0.7 32
10 P3.0 / EA 31
11 P3.1 ALE 30
12 P3.2 / PSEN 29
13 P3.3 P2.7 28
14 P3.4 P2.6 27
15 P3.5 P2.5 26
16 P3.6 P2.4 25
17 P3.7 P2.3 24
18 XTL2 P2.2 23
19 XTL1 P2.1 22
20 VSS P2.0 21
Copyright © 2009-2011 TTE Systems Ltd
34 Licensed to University of Leicester
Page 147
Why work with FPGAs?
In order to build a processor which has a peripheral set which
matches your precise requirements (e.g. 5 digital inputs, 4
UARTs, etc)
To add high-speed custom peripherals (e.g. ADC with large
buffer and FFT hardware – reduce CPU load).
To “future proof” your design (If your current product uses
Microcontroller X, will you be able to buy this device in 5
years? In 10 years?)
To ensure that processor (core) behaviour is predictable
(you select appropriate design features and you have access
to the full spec.)
Copyright © 2009-2011 TTE Systems Ltd
35 Licensed to University of Leicester
Example: TTE32-HR2
Predictable processor core with 5-stage pipeline
Copyright © 2009-2011 TTE Systems Ltd
36 Licensed to University of Leicester
Page 148
An introduction to FPGAs
Field Programmable Gate Arrays (FPGAs) allow the user
to use memory on a hardware device to store the require
device configuration: if we change the memory contents,
we change the device behaviour
Using an FPGA, we can change the system “hardware” in a
manner which is very similar to the way in which we would
change the system software.
Copyright © 2009-2011 TTE Systems Ltd
37 Licensed to University of Leicester
How do we configure an FPGA
process (CLK)
begin
VHDL implementation
if CLK = ‘0’ and CLK’event of a flip flop
Q <= D;
endif;
end process;
reg Q;
always @ (negedge CLK)
Verilog implementation begin
of a flip flop
Q <= D;
end
Copyright © 2009-2011 TTE Systems Ltd
38 Licensed to University of Leicester
Page 149
RAM FPGAs
Configuration data is stored in SRAM
We need some form of Flash device (internal or external) to
store the configuration information
We need to load the information from the Flash when the
FPGA is powered up
The SRAM is vulnerable to radiation effects:
not generally used in passenger aircraft (for example).
Copyright © 2009-2011 TTE Systems Ltd
39 Licensed to University of Leicester
Flash FPGAs
Configuration data is stored in Flash
We don’t an external Flash device to store the FPGA
configuration
We may still need an external Flash device to store program
code (for example, if our FPGA implements a microcontroller)
The Flash is less vulnerable to radiation effects:
these devices are used in passenger aircraft (for example).
Copyright © 2009-2011 TTE Systems Ltd
40 Licensed to University of Leicester
Page 150
Anti-fuse FPGAs
Configuration data is stored in “fuses”
CAN ONLY BE PROGRAMMED ONCE!
Not cheap!
Very high immunity to radiation effects:
these devices are used in space (for example).
Copyright © 2009-2011 TTE Systems Ltd
41 Licensed to University of Leicester
Implications of a move from 8- to 32-bit platforms:
A. Additional memory and CPU performance
Copyright © 2009-2011 TTE Systems Ltd
42 Licensed to University of Leicester
Page 151
Implications of improved CPU performance
Increased CPU performance gives more flexibility when
we wish to create reliable systems using portable code
Much easier to apply simple TTC designs!
ARM ~50 MIPS
8051 ~0.5 MIPS
Copyright © 2009-2011 TTE Systems Ltd
43 Licensed to University of Leicester
What’s wrong with sEOS?
Water void WASHER_Update(void)
Valve
{
Water
Heater switch (System_state_G)
Start {
Switch
Water case INIT:
Pump
Selector
Dial case START:
Washing Drum
Machine Motor
Water Controller case FILL_DRUM:
Level
Sensor
LED
indicators case HEAT_WATER:
Temperature
Sensor
Door
case WASH_01:
lock
...
Detergent }
Hatch
}
(Interrupt)
1 ms timer
Copyright © 2009-2011 TTE Systems Ltd
44 Licensed to University of Leicester
Page 152
What’s wrong with sEOS?
All code ends up in one ISR void WASHER_Update(void)
{
Difficult to maintain / re-use code switch (System_state_G)
{
(e.g. 30-page switch statement) case INIT:
Minimal separation between case START:
OS and task set case FILL_DRUM:
case HEAT_WATER:
What happens if the task overruns?
case WASH_01:
...
There are better solutions … }
}
(Interrupt)
1 ms timer
Copyright © 2009-2011 TTE Systems Ltd
45 Licensed to University of Leicester
Introducing a complete TTC scheduler
Builds upon the functionality of sEOS
Still maintains co-operative time-triggered task executions.
Supports execution of multiple periodic tasks with different
periods and different initial delays (different phases)
Moves the execution of the user tasks out of the Timer ISR:
– Greater task independence (easier to re-use / recycle)
– Can detect if a task overruns
Still easy to understand with limited resources
Copyright © 2009-2011 TTE Systems Ltd
46 Licensed to University of Leicester
Page 153
TTC functions and data structures
Task array
Initialisation function
Start function
Update function
Further information:
Dispatcher function
Sleep function
Add task function
Delete task function
Copyright © 2009-2011 TTE Systems Ltd
47 Licensed to University of Leicester
Task array: SCH_tasks
...
sTask_t SCH_tasks[SCH_MAX_TASKS];
...
typedef struct
{
// Pointer to the task (must be a 'void (void)' function)
void (*pTask) (void);
// Delay (ticks) until the function will (next) be run
// - see SCH_Add_Task() for further details
uint32_t Delay;
// Interval (ticks) between subsequent runs.
// - see SCH_Add_Task() for further details
uint32_t Period;
} sTask_t;
Copyright © 2009-2011 TTE Systems Ltd
48 Licensed to University of Leicester
Page 154
Initialisation function: SCH_Init()
void SCH_Init(const uint32_t tick_us)
{
uint8_t index;
for (index = 0; index < SCH_MAX_TASKS; index++)
{
SCH_Delete_Task(index);
}
Tick_count = 0;
System_time = 0;
Stack_Ptr = (uint32_t*)&Stack_G;
// Primitive check for user and interrupt stack overflow
TTE_DEBUG_ASSERT(Stack_Ptr[INT_Stk_Off] == INT_Stk_Val);
TTE_DEBUG_ASSERT(Stack_Ptr[USR_Stk_Off] == USR_Stk_Val);
System_Tick_Init(tick_us);
Tick_interval = tick_us;
}
Copyright © 2009-2011 TTE Systems Ltd
49 Licensed to University of Leicester
Add task function: SCH_Add_Task()
uint8_t SCH_Add_Task(void(* pFunction)(), const uint32_t delay, const uint32_t period)
{
uint8_t index = 0;
// First find a gap in the array (if there is one)
while ((SCH_tasks[index].pTask != 0) && (index < SCH_MAX_TASKS))
{
index++;
}
// Have we reached the end of the list?
if (index == SCH_MAX_TASKS)
{
// Also return an error code
return SCH_MAX_TASKS;
}
// If we're here, there is a space in the task array
SCH_tasks[index].pTask = pFunction;
SCH_tasks[index].Delay = delay + 1;
SCH_tasks[index].Period = period;
return index; // return position of task (to allow later deletion)
}
Copyright © 2009-2011 TTE Systems Ltd
50 Licensed to University of Leicester
Page 155
Start function: SCH_Start()
void SCH_Start(void)
{
#ifdef TTE_PROVIDE_TIMING
LOG_Init();
#endif
Sys_Tick_Int_Flag_Reset();
Select_System_Interrupt(SYS_TICK_SOURCE);
Enable_System_Interrupt(SYS_TICK_SOURCE);
Enable_Interrupts();
System_Scheduler_Start();
}
Copyright © 2009-2011 TTE Systems Ltd
51 Licensed to University of Leicester
Update function: SCH_Update()
void SCH_Update(void)
{
// Note that an interrupt has occurred
Tick_count++;
// Increase the global system time
System_time++;
#ifdef TTE_PROVIDE_TIMING
LOG_Check_Finished(System_time);
#endif
// After interrupt, reset interrupt flag
Sys_Tick_Int_Flag_Reset();
}
Copyright © 2009-2011 TTE Systems Ltd
52 Licensed to University of Leicester
Page 156
Dispatcher function: SCH_Dispatch_Tasks()
void SCH_Dispatch_Tasks(void)
{
uint32_t index;
uint32_t update_required = 0;
// Disable system interrupt
Disable_Interrupts();
if (Tick_count > 0)
{
Tick_count--;
update_required = 1;
}
// Re-enable system interrupts
Enable_Interrupts();
...
Copyright © 2009-2011 TTE Systems Ltd
53 Licensed to University of Leicester
Dispatcher function: SCH_Dispatch_Tasks()
while (update_required)
{
// Go through the task array
for (index = 0; index < SCH_MAX_TASKS; index++)
{
// Check if there is a task at this location
if (SCH_tasks[index].pTask)
{
if (--SCH_tasks[index].Delay == 0)
{
// The task is due to run
(*SCH_tasks[index].pTask)(); // Run the task
// Simple check for user and interrupt stack overflow
// The 'index' variable should show you which task did it!
TTE_DEBUG_ASSERT(Stack_Ptr[INT_Stk_Off] == INT_Stk_Val);
TTE_DEBUG_ASSERT(Stack_Ptr[USR_Stk_Off] == USR_Stk_Val);
if (SCH_tasks[index].Period != 0)
{
// Schedule period tasks to run again
SCH_tasks[index].Delay = SCH_tasks[index].Period;
}
else
{
// Delete one-shot tasks
SCH_tasks[index].pTask = 0;
}
}
}
}
Copyright © 2009-2011 TTE Systems Ltd
54 Licensed to University of Leicester
Page 157
Dispatcher function: SCH_Dispatch_Tasks()
// Disable system interrupt
Disable_Interrupts();
if (Tick_count > 0)
{
Tick_count--;
update_required = 1;
}
else
{
update_required = 0;
}
// Re-enable system interrupts
Enable_Interrupts();
}
// The scheduler may enter idle mode at this point (if used)
SCH_Go_To_Sleep();
}
Copyright © 2009-2011 TTE Systems Ltd
55 Licensed to University of Leicester
Sleep function: SCH_Go_To_Sleep()
void SCH_Go_To_Sleep()
{
#ifdef TTE_PROVIDE_TIMING
Disable_Interrupts();
if (!In_idle)
{
In_idle = TRUE;
// The idle task is special and should not be in the task array!
LOG_Time(LOG_TASK_START, SCH_MAX_TASKS);
}
Enable_Interrupts();
#endif
// Lots of further power saving that can be done ...
// - see user manual
System_Scheduler_Sleep();
}
Copyright © 2009-2011 TTE Systems Ltd
56 Licensed to University of Leicester
Page 158
Delete task function: SCH_Delete_Task()
int SCH_Delete_Task(const uint32_t task_index)
{
int return_code;
// Check for valid task pointer...
if (task_index >= SCH_MAX_TASKS)
{
// Invalid - exit and return error
Error_code = ERROR_SCH_CANNOT_DELETE_TASK;
return (RETURN_ERROR);
}
if (SCH_tasks[task_index].pTask == 0)
{
// ...also return an error code
return_code = RETURN_ERROR;
}
else
{
return_code = RETURN_NORMAL;
}
SCH_tasks[task_index].pTask = 0x0000;
SCH_tasks[task_index].Delay = 0;
SCH_tasks[task_index].Period = 0;
return return_code; // return status
}
Copyright © 2009-2011 TTE Systems Ltd
57 Licensed to University of Leicester
Using TT Cooperative Scheduler
Phase 1 – Initialisation
1. Scheduler is initialised by the SCH_Init function.
2. Tasks are added to the task set using SCH_Add_Task
function.
3. Scheduler is started using the SCH_Start function.
Phase 2 – Normal operation
1. Dispatcher SCH_Dispatch_Tasks is called in a while(1) loop.
2. After running all tasks scheduled to run in a tick, the
scheduler puts the system into sleep.
Copyright © 2009-2011 TTE Systems Ltd
58 Licensed to University of Leicester
Page 159
TTC considerations: Task execution sequence
If multiple tasks have to run in the same tick, the sequence is
determined by the order in which the tasks are stored in the
task array
– By varying the task sequence, different algorithms can be implemented
If the scheduler is not overloaded, the (start) jitter for a given
task depends on:
– The scheduler overheads (small and predictable);
– The execution times of other tasks running before it in the same tick.
Copyright © 2009-2011 TTE Systems Ltd
59 Licensed to University of Leicester
TTC considerations: Task execution time
Ideally, sum of WCET of all tasks set to run in a tick should be
less than the tick period.
However, if the sum of execution times of the tasks running in
the same tick is more than the tick period (transient overload):
– Scheduler will finish running the tasks in the current tick in their order
before continuing to the tasks in the next tick.
– Scheduler will be able to catch up if there is sufficient slack in
subsequent ticks.
– System will meet specifications if no deadlines are missed.
Copyright © 2009-2011 TTE Systems Ltd
60 Licensed to University of Leicester
Page 160
Implications of a move from 8- to 32-bit platforms:
B. Debugging capabilities
Copyright © 2009-2011 TTE Systems Ltd
61 Licensed to University of Leicester
Debugging basics
Debugging is the process of trying to find and remove logical
errors from software.
The programmer has access to debugging tools that allow the
program execution to be stopped and the system state to be
examined.
Typical debugger controls:
– Program execution control (stepping and running through code)
– Break points (execution halts when a break point is hit)
– Memory / variable watch (checking and changing the contents of
memory locations)
Copyright © 2009-2011 TTE Systems Ltd
62 Licensed to University of Leicester
Page 161
Introduction to JTAG
Joint Test-Action Group was formed in the 1980s by the
makers and users of components and boards.
Their proposal was adopted by IEEE as the IEEE Standard
1149.1 in 1990.
JTAG was initially developed to help test the connections on
printed circuit boards without using “bed of nails” test setup.
Current uses also include:
– Storing / updating firmware
– Debugging embedded software
Most modern microcontrollers (ARM, Cortex, MIPS, etc) have
JTAG ports built in.
* Amontec application note JTAG Interface: Simple Introduction. http://www.amontec.com/pub/amt_ann004.pdf
* JTAG Technoligies, http://www.jtag.com/en/About/History
Copyright © 2009-2011 TTE Systems Ltd
63 Licensed to University of Leicester
JTAG internals
The JTAG standard specifies the
following components in
supporting devices:
– Test access port controller (TAP)
– Scan instruction register
– Scan data registers
JTAG interface uses the following
signals:
– TCK – Test clock http://www.jtag.com/en/Learn/Standards/IEEE_1149.1
– TMS – Test mode select
– TDI – Test data in
– TDO – Test data out
– TRST – Test reset (optional)
Copyright © 2009-2011 TTE Systems Ltd
64 Licensed to University of Leicester
Page 162
Example: JTAG and ARM7TDMI-S
Copyright © 2009-2011 TTE Systems Ltd
65 Licensed to University of Leicester
Example: JTAG and ARM7TDMI-S
In the ARM7, JTAG port interfaces
with the Embedded ICE module
through scan chains.
The Embedded ICE module
provides:
1. Debug control and status registers.
2. Two watchpoint units that allow the
system to enter debug state when
either a certain address is executed
(breakpoint), or a certain memory
location is accessed / modified
(watchpoint).
* ARM7TDMI-S Technical Reference Manual,
http://infocenter.arm.com/help/topic/com.arm.doc.ddi
0084f/DDI0084.pdf
Copyright © 2009-2011 TTE Systems Ltd
66 Licensed to University of Leicester
Page 163
Example: Why we need timing analysis
“A real-time computer system is a computer system in which the
correctness of the system behaviour depends not only on the logical results
of the computations, but also on the physical instant at which these results
are produced.”
Source: Kopetz, H., “Real-Time Systems: Design Principles for Distributed Embedded Applications”,
(Kluwer Academic Publishers, 2002)
Copyright © 2009-2011 TTE Systems Ltd
67 Licensed to University of Leicester
Example: Timing analysis
Copyright © 2009-2011 TTE Systems Ltd
68 Licensed to University of Leicester
Page 164
Completing your 32-bit design
Copyright © 2009-2011 TTE Systems Ltd
69 Licensed to University of Leicester
Completing your 32-bit design
So far we’ve:
– Looked at the implications of jitter in RT systems
– Looked at the implications of a move to 32-bit processors, incl.
Higher CPU performance and more memory
Enhanced set of hardware “peripherals” (e.g. “intelligent” UARTs)
Enhanced debug support (including JTAG support)
– Introduced a multi-task TTC scheduler (easy on a 32-bit target)
– Explored the need for timing analysis in RT embedded systems
(and seen how this too is supported on high-end targets)
We’ll now consider how to complete your design with a
watchdog timer and heartbeat LED …
Copyright © 2009-2011 TTE Systems Ltd
70 Licensed to University of Leicester
Page 165
Working with watchdog timers
Copyright © 2009-2011 TTE Systems Ltd
71 Licensed to University of Leicester
The watchdog analogy
Suppose there is a hungry dog guarding a house, and
someone wishes to break in .
If, during the burglary, an accomplice repeatedly throws the
guard dog small pieces of meat, then the animal will be so
busy concentrating on the food that he will ignore his guard
duties, and will not bark.
However, if the accomplice run out of meat
or forgets to feed the dog for some other
reason, the animal will start barking,
thereby alerting the neighbours, property
occupants or police.
Copyright © 2009-2011 TTE Systems Ltd
72 Licensed to University of Leicester
Page 166
Working with watchdog timers
“Watchdog timers” typically operate as follows:
– The timer must be refreshed at regular, well-defined, intervals.
If the timer is not refreshed at the required time it will overflow, an
process which will usually cause the associated microcontroller to be
reset.
– When starting up, the microcontroller can determine the cause of
the reset.
That is, it can determine if it has been started ‘normally’, or re-started
as a result of a watchdog overflow. This means that, in the latter case,
the programmer can ensure that the system will try to handle the error
that caused the watchdog overflow.
Copyright © 2009-2011 TTE Systems Ltd
73 Licensed to University of Leicester
Working with watchdog timers
Watchdogs can provide a ‘last resort’ form of error recovery.
If you think of the use of watchdogs in terms of ‘if all else fails,
then we’ll let the watchdog reset the system’, you are taking a
realistic view of the capabilities of this approach.
Used without due care at the design phase and / or adequate
testing, watchdogs can reduce the system reliability
dramatically. In particular, in the presence of sustained faults,
badly-designed watchdog “recovery” mechanisms can cause
your system to reset itself repeatedly:
this can be very dangerous.
Copyright © 2009-2011 TTE Systems Ltd
74 Licensed to University of Leicester
Page 167
LPC2378’s Watchdog timer
Can be enabled by software but disabled only after a reset
or watchdog interrupt.
Incorrect / incomplete feed can be programmed to generate a
reset or interrupt.
Selectable time period from (Tcy(WDCLK) x 256 x 4) to (Tcy(WDCLK)
x 232 x 4) in multiples of (Tcy(WDCLK) x 4).
Watchdog clock source can be selected from RTC clock,
internal RC oscillator or APB peripheral clock for
wide range of timing possibilities as well as keeping the
watchdog operational in power-reduction modes.
Copyright © 2009-2011 TTE Systems Ltd
75 Licensed to University of Leicester
Adding a “Heartbeat LED”
Copyright © 2009-2011 TTE Systems Ltd
76 Licensed to University of Leicester
Page 168
Heartbeat LED
Problem
How can you tell, at a glance, that the system is “alive”?
Solution
Include a task that flashes a ‘heartbeat LED’ every time you implement an
embedded system.
Source: Adapted from Heartbeat LED in Mwelwa, C. and Pont, M.J., “Two simple patterns to support the development of
reliable embedded systems”, Presented at VikingPLoP 2003 (Bergen, Norway), September 2003.
Copyright © 2009-2011 TTE Systems Ltd
77 Licensed to University of Leicester
Working with high-end hardware:
Running a TTC scheduler on an embedded PC
Copyright © 2009-2011 TTE Systems Ltd
78 Licensed to University of Leicester
Page 169
Running TTC software on an Intel® Atom
The development board we will
be using is the
Gigabyte GA-GC230D
This board has a 1.6 GHz Atom
230 integrated with an 945GC
chipset, 512MB of L2 Cache and
RAM
The 954GC chipset includes the
ICH-7 I/O controller and GMA-
950 graphics interface
Copyright © 2009-2011 TTE Systems Ltd
79 Licensed to University of Leicester
Boot sequence for the Atom board
After power on, the system first boots from BIOS (4MB Flash, etc);
BIOS then searches for a valid mass-storage device
(signature bytes 0x55 and 0xAA at end of the first boot sector);
A Syslinux bootloader is placed on the boot sector of the flash drive
(and run by the BIOS);
[Note: we are not running Linux – we simply use the same bootloader]
By default, the linker script copies the binary into high memory
(0x1000000) before execution.
Copyright © 2009-2011 TTE Systems Ltd
80 Licensed to University of Leicester
Page 170
Input and output (Overview)
Our development boards have the following I/O capabilities:
– LPT Parallel Port
– RS-232
– VGA / Audio Output
– Keyboard / Mouse
– USB Serial Ports
– 10/100 Mbit/sec Ethernet
Copyright © 2009-2011 TTE Systems Ltd
81 Licensed to University of Leicester
Input and output (LPT1)
Since 1981, most PCs have had a 25-pin D-type connector on
the rear panel.
This provides a connection to the “parallel port” (or “printer port”)
and was originally used to connect to a printer
(Centronics protocol).
This is “Line Print Terminal 1” (LPT1)
In embedded designs, this can serve as a simple GPIO port.
Copyright © 2009-2011 TTE Systems Ltd
82 Licensed to University of Leicester
Page 171
Input and output (LPT1)
13 1
25 14
Pin Label Input / Output Pin Pin Label Input / Output Pin
1 /Strobe Input / Output 10 /Ack Input
2 Data 0 Input / Output 11 Busy Input
3 Data 1 Input / Output 12 Paper Input
4 Data 2 Input / Output 13 Online Input
5 Data 3 Input / Output 14 /AF Input / Output
6 Data 4 Input / Output 15 /Error Input
7 Data 5 Input / Output 16 Initialise Input / Output
8 Data 6 Input / Output 17 /Select Input / Output
9 Data 7 Input / Output 18-25 Ground -
Pin connections for the PC’s parallel port (diagram shows the 25-pin DB25 socket, viewed from the outside).
Copyright © 2009-2011 TTE Systems Ltd
83 Licensed to University of Leicester
Conclusions
Copyright © 2009-2011 TTE Systems Ltd
84 Licensed to University of Leicester
Page 172
Conclusion
Today we have:
– Looked at the implications of jitter in RT systems
– Looked at the implications of a move to 32-bit processors, incl.
Higher CPU performance and more memory
Enhanced set of hardware “peripherals” (e.g. “intelligent” UARTs)
Enhanced debug support (including JTAG support)
– Introduced a multi-task TTC scheduler (easy on a 32-bit target)
– Explored the need for timing analysis in RT embedded systems
– Reviewed the basic use of WDTs and “Heartbeat” LEDs
– See that we can run TTC architectures on high-end platforms too
(and considered the fact that timing analysis on such platforms can be
challenging)
– Consider how we can design and implement our own processors, if we
want to take complete control.
Copyright © 2009-2011 TTE Systems Ltd
85 Licensed to University of Leicester
Thinking allowed …
Suppose that we were to compare 1000 embedded systems:
– 500 systems will be based on 8-bit processors
– 500 systems will be based on 32-bit processors
On average, would you expect the 8-bit or 32-bit systems to
be more reliable?
Copyright © 2009-2011 TTE Systems Ltd
86 Licensed to University of Leicester
Page 173
Appendix
(Timing and jitter)
Copyright © 2009-2011 TTE Systems Ltd
87 Licensed to University of Leicester
Why timing matters: Background
Suppose we have an analogue signal in the range 0 – 10V
If we use an 8-bit ADC to sample this signal,
the resolution will be 10 / (28 – 1) = 39 mV
If we use a 12-bit ADC to sample this signal,
the resolution will be 10 / (212 – 1) = 2.44 mV
Copyright © 2009-2011 TTE Systems Ltd
88 Licensed to University of Leicester
Page 174
Why timing matters: Jitter
S ig n a l a m p litu d e ( V o lts )
∆ t ∆ v
T im e
It is known that:
v ( t ) = A sin( 2π ft )
∆V dv
≈
∆t dt
Also:
dv
= 2π fA cos( 2π ft )
dt
Copyright © 2009-2011 TTE Systems Ltd
89 Licensed to University of Leicester
Why timing matters: Jitter
At t = 0:
dv
= 2π fA
dt
Assuming a signal is being sampled at the maximum amplitude (AFS), using an N-bit ADC:
AFS = 2 N z
where z is the ADC “step size” (lsb).
Then:
dv
= 2π fAFS
dt
Thus:
∆ V = 2π f ∆ tAFS
If the jitter is to have no measurable impact, we need to ensure that it has an amplitude < z / 2.
This implies that ∆t must satisfy this condition:
1 1
∆t < ⋅
2 N 2π f
Otherwise, jitter will cause sampling data loss.
Copyright © 2009-2011 TTE Systems Ltd
90 Licensed to University of Leicester
Page 175
All my own work
The following individuals contributed to the material and slides
presented in this session:
– Musharraf Hanif (University of Leicester)
– Devaraj Ayavoo (TTE Systems Ltd)
– Zemian Hughes (TTE Systems Ltd)
– Peter Vidler (TTE Systems Ltd)
– Muhammad Waqas Raza (TTE Systems Ltd)
– Keith Athaide (TTE Systems Ltd)
– Anjali Das (TTE Systems Ltd)
– Michael Short (Teesside University)
Copyright © 2009-2011 TTE Systems Ltd
91 Licensed to University of Leicester
Page 176
Day 4: Multi-tasking systems
Michael J. Pont
MSc in Reliable Embedded Systems
Module EG7510 (“A1a”)
Introduction and review
Copyright © 2009-2011 TTE Systems Ltd
2 Licensed to University of Leicester
Page 177
The story so far …
Seminar 1:
– Introduction to embedded systems, super loops and the “8051”;
– A first look at software architectures for embedded systems;
– A first look at techniques required to meet RT constraints.
Seminar 2:
– TTC concepts and sEOS;
– Creating multi-state systems;
– Executing sequences of functions;
– Dealing with “long tasks” (without resorting to pre-emption);
– MISRA C.
Copyright © 2009-2011 TTE Systems Ltd
3 Licensed to University of Leicester
The story so far …
Seminar 3:
– The implications of jitter in RT systems
– The implications of a move to 32-bit processors, incl.
Higher CPU performance and more memory
Enhanced set of hardware “peripherals” (e.g. “intelligent” UARTs)
Enhanced debug support (including JTAG support)
– A multi-task TTC scheduler (easy on a 32-bit target)
– The need for timing analysis in RT embedded systems
– The basic use of WDTs and “Heartbeat” LEDs
– Running TTC architectures on high-end hardware platforms
Timing analysis on such platforms can be challenging
– Consider how we can design and implement our own processors
If we want to take complete control
Copyright © 2009-2011 TTE Systems Ltd
4 Licensed to University of Leicester
Page 178
The story so far …
At last! We’ve moved from 8-
At last! We’ve moved from 8-
bit to 32-bit processors –
bit to 32-bit processors –
now we can get rid of that
now we can use a full TTC
TTC scheduler and run a full
scheduler!
RTOS or Linux!
Copyright © 2009-2011 TTE Systems Ltd
5 Licensed to University of Leicester
Simple TTC designs: The “long task problem” …
It’s easy to think up task sets which can’t be scheduled using a TTC architecture …
A A A A ...
Time
B ...
Time
Copyright © 2009-2011 TTE Systems Ltd
6 Licensed to University of Leicester
Page 179
Example: Using an appropriate task structure (RS-232)
Current core temperature All characters copied to buffer
is 36.678 degrees (fast operation)
Buffer (character array)
Schedule a task to send one character
from the buffer every 10 ms (for example)
Copyright © 2009-2011 TTE Systems Ltd
7 Licensed to University of Leicester
Sometimes we need to support task pre-emption
If possible, system should use TTC tasks:
– Lower overheads (therefore lower unit costs)
– Greater predictability (therefore shorter testing times & higher reliability)
– Ease of certification (where required)
With appropriate design approaches, we can often reduce the
number of designs which require task pre-emption
… but few developers manage to spend their working life
without having to employ pre-emption at some point
Copyright © 2009-2011 TTE Systems Ltd
8 Licensed to University of Leicester
Page 180
Day 4 Outline
We’ll consider:
– The challenges of full “ET multi-tasking” designs
– Time-triggered “hybrid” schedulers (the best of both worlds?)
– Working with multiple processors (distributed systems)
Copyright © 2009-2011 TTE Systems Ltd
9 Licensed to University of Leicester
Use of a standard RTOS in reliable embedded
systems: Issues and challenges
Copyright © 2009-2011 TTE Systems Ltd
10 Licensed to University of Leicester
Page 181
Priority-based pre-emptive scheduling
“Input”
H
M Time
L
“Output”
Copyright © 2009-2011 TTE Systems Ltd
11 Licensed to University of Leicester
Challenges caused by shared resources
A ADC
C UART
E Shared data
Copyright © 2009-2011 TTE Systems Ltd
12 Licensed to University of Leicester
Page 182
Mutual exclusion
Two semaphore options to consider:
– Basic (binary) semaphores
– Counting semaphores
The other main option is a “mutex”
– A form of semaphore which is linked to a specific task
Copyright © 2009-2011 TTE Systems Ltd
13 Licensed to University of Leicester
Priority inversion
We need semaphores (etc) to help us to avoid “train crashes”
(e.g. two tasks fighting over the same ADC)
In any priority-based system, we then have the risk of
“priority inversion” (and related problems of deadlock and
chained blocking)
We therefore need to consider algorithms such as priority
inheritance, priority ceiling, priority ceiling emulation, etc
Copyright © 2009-2011 TTE Systems Ltd
14 Licensed to University of Leicester
Page 183
Priority inversion (example)
This is what we want to happen …
Priority N Normal Code
ADC
C Critical Section
P TaskH N C N
PTaskL N C C N
t1 t2 t3 t4 t5
Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).
Copyright © 2009-2011 TTE Systems Ltd
15 Licensed to University of Leicester
Priority inversion (example)
This is what happens (bounded priority inversion) …
Priority B Blocked N Normal Code
C Critical Section
PTaskH N B C N
PTaskL N C C N
t1 t2 t3 t4 t5 t6 t7
Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).
Copyright © 2009-2011 TTE Systems Ltd
16 Licensed to University of Leicester
Page 184
Priority inversion (example)
It gets worse as we add more tasks (unbounded pi) …
Priority B Blocked N Normal Code C Critical Section
P TaskH N B RESET
N
PTaskM
N C C
PTaskL
t1 t2 t3 t4 t5 t6 t7
Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).
Copyright © 2009-2011 TTE Systems Ltd
17 Licensed to University of Leicester
From priority inversion to deadlock (example)
PI isn’t the only potential problem …
This is what we want:
Priority N Normal Code
C2 Critical Section2
P TaskH C1 Critical Section1
N C1 C2 C1 N
P TaskL N C2 C2 C1 C2 N
t1 t2 t3 t4 t5 t6 t7
Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).
Copyright © 2009-2011 TTE Systems Ltd
18 Licensed to University of Leicester
Page 185
From priority inversion to deadlock (example)
This is what happens …
Priority B Blocked C1 Critical Section1 C2 Critical Section2 N Normal Code
Require C2 locked by TaskL
Dead Lock
P TaskH N C1 B
C2 still locked
Require C1 locked by TaskH
PTaskL N C2 C2
t1 t2 t3 t4 t5 t6 t7
Adapted from: Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over shared resources in time-triggered embedded
systems which employ a pre-emptive scheduler” Paper presented at the 12th European Conference on Pattern Languages of Programs (EuroPLoP 2007).
Copyright © 2009-2011 TTE Systems Ltd
19 Licensed to University of Leicester
Dealing with deadlock
Applying the priority ceiling emulation protocol
Priority Blocked Critical Section1 Critical Section2 Normal Code
B C1 C2 N
Adapted from:
Wang, H., Pont, M.J.
and Kurian, S. (2007)
“Patterns which help to
avoid conflicts over
shared resources in
B N C1 C2 C1 N time-triggered
PTaskH embedded systems
which employ a pre-
emptive scheduler”
Paper presented at the
12th European
DPTaskL= C2 C2 C1 C2 Conference on Pattern
Languages of
PTaskH Programs (EuroPLoP
2007).
P TaskL N N
t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11
Copyright © 2009-2011 TTE Systems Ltd
20 Licensed to University of Leicester
Page 186
Priority inversion presents real challenges
When we have to deal with resource conflicts at run time, the
system behaviour becomes much more difficult to predict
Eg: When will our “high priority” task take the sample ..?
Signal amplitude (Volts)
∆t ∆v
Time
Copyright © 2009-2011 TTE Systems Ltd
21 Licensed to University of Leicester
Priority inversion presents real challenges
Even NASA gets it wrong …
Problems with the Mars Pathfinder mission in 1997
were caused by priority inversion
Copyright © 2009-2011 TTE Systems Ltd
22 Licensed to University of Leicester
Page 187
Challenges with a dynamic RTOS
Real systems have shared
resources
A ADC
When we don’t know when
B
tasks will be pre-empted, we
C UART
need semaphores, which
D
means we need to address
priority inversion, etc E Shared data
If you need predictable
behaviour, be prepared to
spend a lot of time doing
system testing (and then keep
your fingers crossed …)
Copyright © 2009-2011 TTE Systems Ltd
23 Licensed to University of Leicester
TT solutions
Copyright © 2009-2011 TTE Systems Ltd
24 Licensed to University of Leicester
Page 188
Advantages of a time-triggered RTOS
ADC UART
A B C D E ...
Time
Either:
“Global” variables - No conflicts (co-operative design)
- Predict (and avoid) conflicts
where pre-emption is employed
(TRAP protocols)
Copyright © 2009-2011 TTE Systems Ltd
25 Licensed to University of Leicester
Minimising the use of interrupts
TT systems
A “safe subset”
“Event triggered” systems
with multiple interrupt sources
Copyright © 2009-2011 TTE Systems Ltd
26 Licensed to University of Leicester
Page 189
Dynamic (ET) RTOS vs. Static (TT) RTOS
Verification
effort
TT
ET
System size
Copyright © 2009-2011 TTE Systems Ltd
27 Licensed to University of Leicester
Dynamic (ET) RTOS vs. Static (TT) RTOS
Conventional RTOS
– “My door is always open …”
ET
– Easy to build but …
… difficult to predict behaviour (test, etc)
– Scalability is a concern
Time-triggered RTOS
– “Please make an appointment with my secretary …”
TT
– Predictable behaviour (easy to test) but …
… can be more challenging to build
– Highly scalable
Copyright © 2009-2011 TTE Systems Ltd
28 Licensed to University of Leicester
Page 190
The TTH scheduler
Copyright © 2009-2011 TTE Systems Ltd
29 Licensed to University of Leicester
An alternative to a to fully pre-emptive scheduler
Using a limited pre-emption (limited multitasking) architecture:
– One “high priority” pre-empting task
(immediately avoid many of the key challenges with priority inversion)
– Multiple “low priority” co-operative tasks
It is possible to:
– Achieve low overheads (processing and memory).
– Achieve rapid responses to external events.
– With careful design, similar reliability as a (pure) co-operative
scheduler can be obtained.
In implementation terms, the main difference between
TTC and TTH schedulers is the timer ISR.
Copyright © 2009-2011 TTE Systems Ltd
30 Licensed to University of Leicester
Page 191
The TTH scheduler
A TTH scheduler provides limited multi-tasking capabilities
Operation:
– Supports any number of co-operatively-scheduled tasks
– Supports a single pre-empting task (which can interrupt the co-operative
tasks)
Implementation:
– The scheduler is simple, and can be implemented in a small amount of
code.
– The scheduler must allocate memory for - at most - two tasks at a time.
– The scheduler will generally be written entirely in a high-level language
(such as ‘C’).
– The scheduler is not a separate application; it becomes part of the
developer’s code
Performance:
– Rapid responses to external events can be obtained.
Reliability and safety:
– With careful design, can be as reliable as a (pure) co-operative scheduler.
Copyright © 2009-2011 TTE Systems Ltd
31 Licensed to University of Leicester
The time-triggered hybrid (TTH) scheduler
Interrupt
t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9
t (ms)
Interrupt
t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9
Co-operative task
t (ms)
Pre-empting task
Copyright © 2009-2011 TTE Systems Ltd
32 Licensed to University of Leicester
Page 192
Difference between fully pre-emptive and hybrid
A common way to use shared resources is to set a lock on
them before accessing them. The simple check and lock code
works on the hybrid scheduler but can fail in a fully pre-
emptive environment (priority inheritance).
#define UNLOCKED 0
#define LOCKED 1
bit Lock; // Global lock flag
// ...
// Ready to enter critical section
// - Wait for lock to become clear
// (FOR SIMPLICITY, NO TIMEOUT CAPABILITY IS SHOWN)
while(Lock == LOCKED);
// Lock is clear
// Enter critical section
A
// Set the lock
Lock = LOCKED;
// CRITICAL CODE HERE //
// Ready to leave critical section
// Release the lock
Lock = UNLOCKED;
// ...
Copyright © 2009-2011 TTE Systems Ltd
33 Licensed to University of Leicester
Differences between TTC and TTH code
The main difference is in the scheduler update function
The pre-empting task’s info is not added into the task array
but is (usually) kept separate.
Minor changes in the initialisation and add task functions to
initialise and add pre-empting tasks.
Copyright © 2009-2011 TTE Systems Ltd
34 Licensed to University of Leicester
Page 193
Task information storage
...
sTask_t SCH_tasks[SCH_MAX_TASKS];
static sTask_t SCH_pTask;
...
typedef struct
{
// Pointer to the task (must be a 'void (void)' function)
void (*pTask) (void);
// Delay (ticks) until the function will (next) be run
// - see SCH_Add_Task() for further details
uint32_t Delay;
// Interval (ticks) between subsequent runs.
// - see SCH_Add_Task() for further details
uint32_t Period;
} sTask_t;
Copyright © 2009-2011 TTE Systems Ltd
35 Licensed to University of Leicester
Modified scheduler update
void SCH_Update(void)
{
Tick_count++; // Note that an interrupt has occurred
System_time++; // Increase the global system time
Scheduler_Started = TRUE;
// Check the preemptive task exists
if (SCH_pTask.pTask)
{
// Check to see if it is due to run
if (--SCH_pTask.Delay == 0)
{
(*SCH_pTask.pTask)(); // Run the preemptive task
// If the task is periodic, set it to run again
if (SCH_pTask.Period)
{
SCH_pTask.Delay = SCH_pTask.Period; // Schedule regular tasks to run again
}
}
}
Sys_Tick_Int_Flag_Reset(); // After interrupt, reset interrupt flag
}
Copyright © 2009-2011 TTE Systems Ltd
36 Licensed to University of Leicester
Page 194
A closer look at jitter issues for TTH designs
Copyright © 2009-2011 TTE Systems Ltd
37 Licensed to University of Leicester
The time-triggered hybrid (TTH) scheduler
Interrupt
t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9
t (ms)
Interrupt
t=0 t=1 t=2 t=3 t=4 t=5 t=6 t=7 t=8 t=9
Co-operative task
t (ms)
Pre-empting task
Copyright © 2009-2011 TTE Systems Ltd
38 Licensed to University of Leicester
Page 195
Jitter due to variable instruction lengths
Interrupt service
(fixed service time)
Interrupt
Processor in sleep mode
Interrupt service
Interrupt
Inst Inst Inst Inst Inst Inst
Interrupt service
Interrupt
Inst Inst Inst Inst Inst Inst
Copyright © 2009-2011 TTE Systems Ltd
39 Licensed to University of Leicester
Jitter assessment in TTH and TTHj schedulers
From:
Maaita, A. and Pont, M.J. (2005) “Using
‘planned pre-emption’ to reduce levels of task
jitter in a time-triggered hybrid scheduler”.
In: Koelmans, A., Bystrov, A., Pont, M.J., Ong,
R. and Brown, A. (Eds.), Proceedings of the
Second UK Embedded Forum (Birmingham,
UK, October 2005), pp.18-35. Published by
University of Newcastle upon Tyne [ISBN: 0-
7017-0191-9].
Copyright © 2009-2011 TTE Systems Ltd
40 Licensed to University of Leicester
Page 196
Working with distributed systems
(multiple CPUs)
Copyright © 2009-2011 TTE Systems Ltd
41 Licensed to University of Leicester
Multi-processor embedded systems
Multi-processor designs:
– Automotive
– Aerospace
– Medical
– Industrial automation
– Fire alarms
– Intruder alarms
– Computer games
– …
Photo and diagram by Amir Muhammad
Copyright © 2009-2011 TTE Systems Ltd
42 Licensed to University of Leicester
Page 197
Benefit 1: More hardware resources
Allows parallel processing:
– Spreads the processing load
– Run long tasks and short frequent tasks without pre-emption
Increases the number of peripherals available:
– More timers, UARTS, GPIO, etc.
Copyright © 2009-2011 TTE Systems Ltd
43 Licensed to University of Leicester
Benefit 2: Modular approach
Low-cost replication of Sensor
1
common modules in large
numbers Sensor
2
Acquisition
system PC
Easier to detect faults in Sensor
3
“intelligent” sensors
– Airbus A310 slat and flap Sensor
1
MCU
A
control with a safe sub- 2
system shutdown state in
case of a fault Sensor
2
MCU
B
Acquisition
system PC
3 1
Sensor MCU
3 C
Copyright © 2009-2011 TTE Systems Ltd
44 Licensed to University of Leicester
Page 198
Key challenges for distributed embedded systems
Synchronising clocks on the different nodes
Data sharing between the nodes
Detecting and managing node and cable failures
Copyright © 2009-2011 TTE Systems Ltd
45 Licensed to University of Leicester
Synchronising clocks on the different nodes
Copyright © 2009-2011 TTE Systems Ltd
46 Licensed to University of Leicester
Page 199
Oscillators and processors
Oscillator frequencies will
NOT be identical
Copyright © 2009-2011 TTE Systems Ltd
47 Licensed to University of Leicester
The need for synchronised clocks
Portable traffic-light
controller
Copyright © 2009-2011 TTE Systems Ltd
48 Licensed to University of Leicester
Page 200
The need for synchronised clocks
Portable traffic-light
controller
Copyright © 2009-2011 TTE Systems Ltd
49 Licensed to University of Leicester
Synchronising the clocks
Master Slave 1 Slave 2 Slave N
Tick messages (from Master to Slaves) E.g. CAN bus, RS-485
FlexRay, etc
Copyright © 2009-2011 TTE Systems Ltd
50 Licensed to University of Leicester
Page 201
Sharing data between the different nodes
Copyright © 2009-2011 TTE Systems Ltd
51 Licensed to University of Leicester
Sharing data between nodes
Using an appropriate network protocol to send “Tick”
messages, the master can address a node and send data to
one or more nodes as part of the tick message.
The addressed Slave can then reply (Acknowledgement
message) with data that needs to be sent to the Master.
Slave tick (from CAN hardware)
Tick Ack Tick Ack Tick Ack
Message Message Message Message Message Message ...
(Data for S1) (from S1) (Data for S2) (from S2) (Data for S1) (from S1)
Time
Master tick (from timer)
Note:
– One Slave replies at a time
– Direct Slave to Slave comms is not possible
Copyright © 2009-2011 TTE Systems Ltd
52 Licensed to University of Leicester
Page 202
Sharing data between nodes
Note:
– One Slave replies at a time
– Direct Slave to Slave comms is not possible
Slave tick (from CAN hardware)
Tick Ack Tick Ack Tick Ack
Message Message Message Message Message Message ...
(Data for S1) (from S1) (Data for S2) (from S2) (Data for S1) (from S1)
Time
Master tick (from timer)
Copyright © 2009-2011 TTE Systems Ltd
53 Licensed to University of Leicester
Sharing data between nodes
Further information / different design options for S-C systems:
– Ayavoo, D., Pont, M.J., Short, M. and Parker, S. (2007) “Two novel
shared-clock scheduling algorithms for use with CAN-based distributed
systems”, Microprocessors and Microsystems, 31(5): 326-334.
– Short, M.J. and Pont, M.J. (2007) “Fault-tolerant time-triggered
communication using CAN”, IEEE Transactions on Industrial
Informatics, 3(2): 131-142.
Copyright © 2009-2011 TTE Systems Ltd
54 Licensed to University of Leicester
Page 203
Dealing with errors
Copyright © 2009-2011 TTE Systems Ltd
55 Licensed to University of Leicester
Detecting network problems and node failures
Detecting errors from the Master’s perspective:
If a Slave does not acknowledge a message sent to it, the
Master node can assume there is either a problem with the
network link to that Slave or the Slave node has failed
Detecting errors from the Slave’s perspective:
If a Tick Message is not received in an interval greater than
the tick period, it can assume there is a fault with the Master
node or the network link
Copyright © 2009-2011 TTE Systems Ltd
56 Licensed to University of Leicester
Page 204
Handling faults on the Master
Enter safe state and shut down network
– Easy to implement and effective in most systems
– Can be last line of defence if advanced recovery options fail
– Does not try to recover to normal operation
Restart network
– Easy to implement and allows the use of “backup” Slaves
– Takes time to restart the network and restore normal operation
– Incorrect implementation can be dangerous
Engage backup Slave
– Allows full use of backup nodes
– Takes little time to engage backup nodes
– Underlying code is complicated
Copyright © 2009-2011 TTE Systems Ltd
57 Licensed to University of Leicester
Handling faults on the Slave
A watchdog timer can be used to reset the slave if a tick
message is not received every tick period.
The slave nodes should enter a “safe” state after restart and
stay in that state till they receive Tick messages.
A breakdown in the communication with the Master will usually
result in the Slave entering a “fail silent” mode
Copyright © 2009-2011 TTE Systems Ltd
58 Licensed to University of Leicester
Page 205
General reliability concerns
Copyright © 2009-2011 TTE Systems Ltd
59 Licensed to University of Leicester
Will adding additional nodes increase reliability?
For example:
– Suppose a system with 100 nodes
– Suppose each node is 99% reliable
– The system reliability is just 37%
(assuming all nodes need to be running for reliable operation)
To reverse this, we need redundant components
Copyright © 2009-2011 TTE Systems Ltd
60 Licensed to University of Leicester
Page 206
Increased reliability requires redundancy
B
Actuator Main
Main control
control
Actuator
Actuator AA Actuator BB Actuator
Actuator CC
(Slave) &&user
user interface
interface
(Slave)
(Slave) (Slave) (Slave)
(Slave) (Master)
(Master)
Copyright © 2009-2011 TTE Systems Ltd
61 Licensed to University of Leicester
Increased reliability requires redundancy
B
Actuator Main
Main control
control
Actuator
Actuator AA Actuator BB Actuator
Actuator CC &&user
(Slave) (Slave)
(Slave) (Slave) user interface
interface
(Slave) (Slave) (Master)
(Master)
Actuator Actuator
Actuator B1 Main control
Actuator A1
A B Actuator
Actuator C1
C
(Backup Slave) (Backup Slave)
(Slave) (Backup Slave) &Backup Master
user interface
(Slave) (Slave)
(Master)
Copyright © 2009-2011 TTE Systems Ltd
62 Licensed to University of Leicester
Page 207
Increased reliability requires redundancy
B
Actuator Main
Main control
control
Actuator
Actuator AA Actuator BB Actuator
Actuator CC
(Slave) &&user
user interface
interface
(Slave)
(Slave) (Slave) (Slave)
(Slave) (Master)
(Master)
Copyright © 2009-2011 TTE Systems Ltd
63 Licensed to University of Leicester
Specific reliability issues with shared-clock
(and other TT network protocols)
Copyright © 2009-2011 TTE Systems Ltd
64 Licensed to University of Leicester
Page 208
Assumptions in a S-C network
Shared-clock designs are based on a “time division multiple
access” (TDMA) protocol
For correct operation, we assume that the communication
medium (e.g. CAN network) is free when we wish to send
either a Tick or Acknowledgement message
One implication is that it is not usually possible to share the
network with another system
Copyright © 2009-2011 TTE Systems Ltd
65 Licensed to University of Leicester
“Babbling Idiot” failures
For a S-C system, the worst-case scenario is a “babbling idiot”
failure on a node
This results in a constant stream of (high-priority) messages,
making it impossible to run the network as required
One solution is to add “bus guardians” to each node
Node
BG
Copyright © 2009-2011 TTE Systems Ltd
66 Licensed to University of Leicester
Page 209
CASE STUDY:
S-C scheduling using CAN
Copyright © 2009-2011 TTE Systems Ltd
67 Licensed to University of Leicester
Introducing CAN
The “Controller Area Network” (CAN) protocol
Very popular and cost-effective due to:
– Simplicity
– Low cost
– Availability
– Robustness
CAN supports high-speed (1 Mbit/s) data transmission over short distances
(40m) and low-speed (5 kbit/s) transmissions at lengths of up to 10,000m.
A large number of microcontrollers have on-chip support for CAN, allowing
the protocol to be used with minimal overheads.
Off-chip CAN transceivers can be used to allow use of this protocol with a
huge range of devices.
The maximum number of nodes on a CAN bus is 32.
Copyright © 2009-2011 TTE Systems Ltd
68 68 Licensed to University of Leicester
Page 210
Introducing CAN
Messages can be up to 8 bytes in length.
Used in a shared-clock scheduler, the data transfer between Master
and Slaves (and vice versa) is up to 7 bytes per Tick. This is
adequate for most applications.
CAN is a shared broadcast bus: all messages are sent to all nodes.
However, each message has an identifier: this can be used to ‘filter’
messages. This means that - by using a ‘Full CAN’ controller (see
below) - we can ensure that a particular node will only respond to
‘relevant’ messages: that is, messages with a particular ID.
This is very powerful. What this means in practice is, for
example, that a Slave node can be set to ignore all messages
directed from a different Slave to the Master.
Copyright © 2009-2011 TTE Systems Ltd
69 Licensed to University of Leicester
Determining the required baud rate for “S-C CAN”
Description Size (bits)
Data 64
Start bit 1
Identifier bits 11
SRR bit 1
IDE bit 1
Identifier bits 18
RTR bit 1
Control bits 6
CRC bits 15
Stuff bits (maximum) 23
CRC delimiter 1
ACK slot 1
ACK delimiter 1
EOF bits 7
IFS bits 3
TOTAL 154 bits / message
Copyright © 2009-2011 TTE Systems Ltd
70 Licensed to University of Leicester
Page 211
Determining the required baud rate for “S-C CAN”
We require two messages per tick
For 1 ms ticks, we require at least 308,000 baud:
allowing 350,000 baud gives a margin for error.
This is achievable with CAN, at distances up to around 100m
Should you require larger distances, the tick interval must
either be lengthened, or repeater nodes should be added in
the network at 100-metre intervals.
Copyright © 2009-2011 TTE Systems Ltd
71 Licensed to University of Leicester
Node wiring for distributed networks
Can High
120 Ω 120 Ω
Can Low
Node 1 Node 2 Node 3
Copyright © 2009-2011 TTE Systems Ltd
72 Licensed to University of Leicester
Page 212
Node wiring for distributed networks
The most common means of linking together CAN nodes is
through the use of a two-wire, twisted pair (like RS-485).
In the CAN bus, the two signal lines are termed ‘CAN High’
and ‘CAN Low’. In the quiescent state, both lines sit at 2.5V.
A ‘1’ is transmitted by raising the voltage of the High line
above that of Low line: this is termed a ‘dominant’ bit. A ‘0’ is
represented by raising the voltage of the Low line above that
of the High line: this is termed a ‘recessive’ bit.
Using twisted-pair wiring, the differential CAN inputs
successfully cancel out noise. In addition, the CAN networks
connected in this way continue to function even when one of
the lines is severed.
Copyright © 2009-2011 TTE Systems Ltd
73 Licensed to University of Leicester
Master / Slave latency in S-C CAN
Copyright © 2009-2011 TTE Systems Ltd
74 Licensed to University of Leicester
Page 213
Master / Slave latency
Tick latency
(varies with baud rate)
Tick Ack
Message Message ...
(Data for S1) (from S1)
Time
Copyright © 2009-2011 TTE Systems Ltd
75 Licensed to University of Leicester
Master / Slave jitter in S-C CAN
Copyright © 2009-2011 TTE Systems Ltd
76 Licensed to University of Leicester
Page 214
Controller Area Network (CAN) – bit coding
CAN uses NRZ coding
Vcc
– high voltage Logic ‘1’
0V
– low voltage Logic ‘0’ 1 0
1 0 0 0 0 0 0 0
1 0 0 0 0 0 1 0 0
CAN employs bit stuffing
– Original frame: 0001111111001100000100111111 …
– Sent frame: 0001111101100110000011001111101 …
Copyright © 2009-2011 TTE Systems Ltd
77 Licensed to University of Leicester
Jitter in CAN-based S-C networks
Bit stuffing causes the CAN frames to become of variable lengths.
Example: if 8 data bytes are used, with standard CAN identifiers:
Minimum message length = 111 bits.
Maximum message length = 135 bits.
A possible variation in message length of 24 µs (at 1 Mbaud).
This variation causes a system jitter affects performance
Nahas, M., Pont, M.J. and Short, M.J. (2009) “Reducing message-
length variations in resource-constrained embedded systems
implemented using the Controller Area Network (CAN) protocol”,
Journal of Systems Architecture Vol. 55: pp.344–354.
Copyright © 2009-2011 TTE Systems Ltd
78 Licensed to University of Leicester
Page 215
Reducing jitter in CAN-based S-C networks
Copyright © 2009-2011 TTE Systems Ltd
79 Licensed to University of Leicester
Reducing jitter in CAN-based S-C networks
Copyright © 2009-2011 TTE Systems Ltd
80 Licensed to University of Leicester
Page 216
Conclusion
We’ve considered:
– The challenges of full “ET multi-tasking” designs
– Time-triggered “hybrid” schedulers (the best of both worlds?)
– Shared-clock schedulers
Now it’s time to roll up your sleeves …
Copyright © 2009-2011 TTE Systems Ltd
81 Licensed to University of Leicester
All my own work
The following individuals contributed to the material and slides
presented in this session:
– Musharraf Hanif (University of Leicester)
– Devaraj Ayavoo (TTE Systems Ltd)
– Zemian Hughes (TTE Systems Ltd)
– Peter Vidler (TTE Systems Ltd)
– Muhammad Waqas Raza (TTE Systems Ltd)
– Keith Athaide (TTE Systems Ltd)
– Anjali Das (TTE Systems Ltd)
– Michael Short (Teesside University)
Copyright © 2009-2011 TTE Systems Ltd
82 Licensed to University of Leicester
Page 217
(Blank page)
Page 218
Day 5: Case study
Michael J. Pont
MSc in Reliable Embedded Systems
Module EG7510 (“A1a”)
In this session, we will complete a detailed case study
(building on the material presented
earlier in the week)
Copyright © 2009-2011 TTE Systems Ltd
2 Licensed to University of Leicester
Page 219
Where do we go from here?
Copyright © 2009-2011 TTE Systems Ltd
3 Licensed to University of Leicester
Where do we go from here?
We’ve introduced a number of key topics in this course
Many of these topics will be explored in greater detail in later
MSc modules
Copyright © 2009-2011 TTE Systems Ltd
4 Licensed to University of Leicester
Page 220
Working with
FPGAs
Six modules
15 credits per
Design patterns for Understanding and module
reliable embedded using an RTOS
systems Each module is
run every 3 - 4
months
Join the MSc at
any stage
Multi-processor and
Software and system
multi-core designs
architectures
Programming techniques
for reliable embedded
systems
Copyright © 2009-2011 TTE Systems Ltd
5 Licensed to University of Leicester
The next course is “Module A2a”
“Software considerations in airborne systems and equipment certification”
US guidelines: RTCA DO-178b
European equivalent: EUROCAE ED-12b
We’ll focus on techniques which are compatible with DO-178b
– The “benchmark” against which software development guidelines
are judged at the present time
We’ll also consider:
– ESA guidelines
– NASA guidelines
Copyright © 2009-2011 TTE Systems Ltd
6 Licensed to University of Leicester
Page 221
About TTE Systems Ltd
At TTE Systems, we help our customers to create reliable embedded systems.
We develop and sell high-integrity processor cores, both ‘off the shelf’ & custom software
development tools and advanced safety protection mechanisms (‘shutdown systems’). We also
offer a range of training, consultancy and custom design services.
Application sectors for our products and services range from aerospace, medical, industrial,
automotive, defence and satellite systems to high-end consumer goods.
Many of our products can be provided in forms which are suitable for use in DO-178b, DO-254, ED-
80, IEC 61508 (SIL3), ISO 26262 (ASIL D) and similar high-reliability and safety-critical projects.
We are based in Leicester, UK.
www.TTE-Systems.com
Page 222
Page 223
Further reading
Ahmad, N. and Pont, M.J. (2009) “Remote debugging of embedded systems which employ a
time-triggered architecture”, Proceedings of the 5th UK Embedded Forum, Leicester,
UK, 23-24 September, 2009, pp.97-106. Published by Newcastle University. ISBN
978-0-7017-0222-9.
Ahmad, N. and Pont, M.J. (2010) “Debugging remote embedded systems: The impact of
system software architecture”, Proceedings of the 2010 UK Electronics Forum,
Newcastle, UK, 30 June-1 July, 2010, pp.17-23. Published by Newcastle University.
ISBN 978-0-7017-0232-8.
Amir, M. and Pont, M.J. (2008) “Synchronising tasks in wireless multi-processor
environments using a shared-clock architecture: A pilot study”, Proceedings of the 4th
UK Embedded Forum, Southampton, UK, 9-10 September, 2008, pp.30-39. Published
by IET. ISBN 978-0-8634-1949-2.
Amir, M. and Pont, M.J. (2009) “A time-triggered communication protocol for CAN-based
networks with a star topology”, Proceedings of the 5th UK Embedded Forum, Leicester,
UK, 23-24 September, 2009, pp.30-44. Published by Newcastle University. ISBN 978-
0-7017-0222-9.
Amir, M. and Pont, M.J. (2010) “A novel shared-clock scheduling protocol for fault-
confinement in CAN-based distributed systems”, Proceedings of the 5th IEEE
International Conference on System of Systems, IEEE SoSE 2010, Loughborough
University, UK, 22nd-24th, June 2010.
Amir, M. and Pont, M.J. (2010) “A time-triggered communication protocol for CAN-based
networks with a fault-tolerant star topology “, Proceedings of the International
Symposium on Advanced Topics in Embedded Systems and Applications under the 7th
IEEE International Conference on Embedded Software and Systems, Bradford, West
Yorkshire, UK, 29th June-1st July, 2010. ISBN 978-0-7695-4108-2.
Amir, M. and Pont, M.J. (2010) “Integration of TTC-SC5 and TTC-SC6 shared-clock
protocols”, Proceedings of the 1st UK Electronics Forum, Newcastle, UK, 30th June-1st
July, 2010. Published by Newcastle University. ISBN 978-0-7017-0232-8.
Athaide, K., Hughes, Z.M. and Pont, M.J. (2007) “Towards a time-triggered processor”,
Proceedings of the 3rd UK Embedded Forum, Durham, UK, 203 April, 2007, pp.166.
Published by IET. ISBN 9780863418037. ISSN 0537-9989.
Athaide, K.F., Pont, M.J. and Ayavoo, D. (2008) “Deploying a time-triggered shared-clock
architecture in a multiprocessor system-on-chip design”, in Proceedings of the 4th UK
Embedded Forum (September 2008, Southampton, UK).
Athaide, K.F., Pont, M.J. and Ayavoo, D. (2008) “Shared-clock methodology for time-
triggered multi-cores”, in Susan Stepney, Fiona Polack, Alistair McEwan, Peter Welch,
and Wilson Ifill (Eds.), “Communicating Process Architectures 2008”, IOS Press.
Ayavoo, D., Pont, M.J. and Parker, S. (2004) “Using simulation to support the design of
distributed embedded control systems: A case study”. In: Koelmans, A., Bystrov, A. and
Pont, M.J. (Eds.) Proceedings of the UK Embedded Forum 2004 (Birmingham, UK,
October 2004), pp.54-65. Published by University of Newcastle upon Tyne [ISBN: 0-
7017-0180-3].
Page 224
Ayavoo, D., Pont, M.J. and Parker, S. (2005) “Observing the development of a reliable
embedded system”. In Vardanega, T and Wellings, A. (Eds.) “Proceedings of the 10th
Ada-Europe International Conference on Reliable Software Technologies, York, UK,
June 20-24 2005”, pp. 167-179. Lecture Notes in Computer Science, Vol. 3555.
Published by Springer-Verlag [ISBN: 3-540-26286-5]
Ayavoo, D., Pont, M.J. and Parker, S. (2006) “Does a „simulation first‟ approach reduce the
effort involved in the development of distributed embedded control systems?”.
Proceedings of the 6th UKACC International Control Conference, Glasgow, Scotland,
2006.
Ayavoo, D., Pont, M.J., Fang, J., Short, M. and Parker, S. (2005) “A „Hardware-in-the Loop‟
testbed representing the operation of a cruise-control system in a passenger car”. In:
Koelmans, A., Bystrov, A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the
Second UK Embedded Forum (Birmingham, UK, October 2005), pp.60-90. Published by
University of Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Ayavoo, D., Pont, M.J., Short, M. and Parker, S. (2005) “Two novel shared-clock scheduling
algorithms for use with CAN-based distributed systems”. In: Koelmans, A., Bystrov, A.,
Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded
Forum (Birmingham, UK, October 2005), pp.246-261. Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Ayavoo, D., Pont, M.J., Short, M. and Parker, S. (2007) “Two novel shared-clock scheduling
algorithms for use with CAN-based distributed systems”, Microprocessors and
Microsystems, 31(5): 326-334.
Bautista, R., Pont, M.J. and Edwards, T. (2005) “Comparing the performance and resource
requirements of „PID‟ and „LQR‟ algorithms when used in a practical embedded control
system: A pilot study”. In: Koelmans, A., Bystrov, A., Pont, M.J., Ong, R. and Brown,
A. (Eds.), Proceedings of the Second UK Embedded Forum (Birmingham, UK, October
2005), pp.262-289. Published by University of Newcastle upon Tyne [ISBN: 0-7017-
0191-9].
Bautista-Quintero, R. and Pont, M.J. (2006) “Is fuzzy logic a practical choice in resource-
constrained embedded control systems implemented using general-purpose
microcontrollers?”, Proceedings of the 9th IEEE International Workshop on Advanced
Motion Control (Istanbul, March 27-29, 2006), Volume 2, pp.692-697. IEEE catalog
number 06TH8850. ISBN 0-7803-9511-5.
Bautista-Quintero, R. and Pont, M.J. (2008) “Implementation of H-infinity control algorithms
for sensor-constrained mechatronic systems using low-cost microcontrollers”, IEEE
Transactions on Industrial Informatics, 16(4): 175-184.
Chan, K.L. and Pont, M.J. (2010) “Real-time non-invasive detection of timing-constraint
violations in time-triggered embedded systems”, Proceedings of the 7th IEEE
International Conference on Embedded Software and Systems, Bradford, UK, 2010,
pp.1978-1986. Published by IEEE Computer Society. ISBN 978-0-7695-4108-2.
Edwards, T., Pont, M.J., Scotson, P. and Crumpler, S. (2004) “A test-bed for evaluating and
comparing designs for embedded control systems”. In: Koelmans, A., Bystrov, A. and
Pont, M.J. (Eds.) Proceedings of the UK Embedded Forum 2004 (Birmingham, UK,
October 2004), pp.106-126. Published by University of Newcastle upon Tyne [ISBN: 0-
7017-0180-3].
Page 225
Edwards, T., Pont, M.J., Short, M.J., Scotson, P. and Crumpler, S. (2005) “An initial
comparison of synchronous and asynchronous network architectures for use in
embedded control systems with duplicate processor nodes”. In: Koelmans, A., Bystrov,
A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded
Forum (Birmingham, UK, October 2005), pp.290-303. Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Gendy, A. and Pont, M.J. (2007) “Towards a generic „single-path programming‟ solution
with reduced power consumption”, Proceedings of the ASME 2007 International Design
Engineering Technical Conferences & Computers and Information in Engineering
Conference (IDETC/CIE 2007), September 4-7, 2007, Las Vegas, Nevada, USA.
Gendy, A. and Pont, M.J. (2008) “Automating the processes of selecting an appropriate
scheduling algorithm and configuring the scheduler implementation for time-triggered
embedded systems”, Proceedings of The 27th International Conference on Computer
Safety, Reliability and Security (SAFECOMP08), 22-25 September 2008, Newcastle
upon Tyne, UK
Gendy, A. and Pont, M.J. (2008) “Automating the processes of selecting an appropriate
scheduling algorithm and configuring the scheduler implementation for time-triggered
embedded systems”, Proceedings of The 27th International Conference on Computer
Safety, Reliability and Security (SAFECOMP08), 22-25 September 2008, Newcastle
upon Tyne, UK
Gendy, A., Dong, L. and Pont, M.J. (2007) “Improving the performance of time-triggered
embedded systems by means of a scheduler agent”, Proceedings of the ASME 2007
International Design Engineering Technical Conferences & Computers and Information
in Engineering Conference (IDETC/CIE 2007), September 4-7, 2007, Las Vegas,
Nevada, USA.
Gendy, A.K. and Pont, M.J. (2008) “Automatically configuring time-triggered schedulers for
use with resource-constrained, single-processor embedded systems”, IEEE Transactions
on Industrial Informatics, 4(1): 37-46.
Hanif, M., Pont, M.J. and Ayavoo, D. (2008) “Implementing a simple but flexible time-
triggered architecture for practical deeply-embedded applications”, in Proceedings of the
4th UK Embedded Forum (September 2008, Southampton, UK).
Hughes, Z.H. and Pont, M.J. (2004) “Design and test of a task guardian for use in TTCS
embedded systems”. In: Koelmans, A., Bystrov, A. and Pont, M.J. (Eds.) Proceedings of
the UK Embedded Forum 2004 (Birmingham, UK, October 2004), pp.16-25. Published
by University of Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Hughes, Z.M. and Pont, M.J. (2008) “Reducing the impact of task overruns in resource-
constrained embedded systems in which a time-triggered software architecture is
employed”, Transactions of the Institute of Measurement and Control, Vol. 30: pp.427-
450.
Hughes, Z.M., Pont, M.J. and Ong, H.L.R. (2005) “Design and evaluation of a “time-
triggered” microcontroller”. Poster presentation at DATE 2005 (PhD Forum), Munich,
Germany, March 2005.
Page 226
Hughes, Z.M., Pont, M.J. and Ong, H.L.R. (2005) “The PH Processor: A soft embedded core
for use in university research and teaching”. In: Koelmans, A., Bystrov, A., Pont, M.J.,
Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded Forum
(Birmingham, UK, October 2005), pp.224-245. Published by University of Newcastle
upon Tyne [ISBN: 0-7017-0191-9].
IEC 61508 (2000) “Functional safety of electrical/electronic/programmable electronic safety-
related systems, Part 3”. (2000).
Imran, S., Short, M. and Pont, M.J. (2008) “Hardware implementation of a shared-clock
scheduling protocol for CAN: A pilot study”, in Proceedings of the 4th UK Embedded
Forum (September 2008, Southampton, UK).
Imran, S., Short, M. and Pont, M.J. (2008) “Hardware implementation of a shared-clock
scheduling protocol for CAN: A pilot study”, in Proceedings of the 4th UK Embedded
Forum (September 2008, Southampton, UK).
Key, S. and Pont, M.J. (2004) “Implementing PID control systems using resource-limited
embedded processors”. In: Koelmans, A., Bystrov, A. and Pont, M.J. (Eds.) Proceedings
of the UK Embedded Forum 2004 (Birmingham, UK, October 2004), pp.76-92.
Published by University of Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Key, S.A., Pont, M.J. and Edwards, S. (2004) “Implementing low-cost TTCS systems using
assembly language”. In: Henney, K. and Schutz, D. (Eds) Proceedings of the Eighth
European conference on Pattern Languages of Programs (EuroPLoP 8), Germany, June
2003: pp.667-690. Published by Universitätsverlag Konstanz. ISBN 3-87940-788-6.
Koelmans, A., Bystrov, A. and Pont, M.J. (2004)(Eds.) “Proceedings of the First UK
Embedded Forum” (Birmingham, UK, October 2004). Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Koelmans, A., Bystrov, A., Pont, M.J., Ong, R. and Brown, A. (2005)(Eds.) “Proceedings of
the Second UK Embedded Forum” (Birmingham, UK, October 2005). Published by
University of Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Kurian, S. and Pont, M.J. (2005) “Building reliable embedded systems using Abstract
Patterns, Patterns, and Pattern Implementation Examples”. In: Koelmans, A., Bystrov,
A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded
Forum (Birmingham, UK, October 2005), pp.36-59. Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Kurian, S. and Pont, M.J. (2005) “Mining for pattern implementation examples”. In:
Koelmans, A., Bystrov, A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the
Second UK Embedded Forum (Birmingham, UK, October 2005), pp.194-201. Published
by University of Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Kurian, S. and Pont, M.J. (2006) “Evaluating and improving pattern-based software designs
for resource-constrained embedded systems”. In: C. Guedes Soares & E. Zio (Eds),
“Safety and Reliability for Managing Risk: Proceedings of the 15th European Safety and
Reliabilty Conference (ESREL 2006), Estoril, Portugal, 18-22 September 2006”, Vol. 2,
pp.1417-1423. Published by Taylor and Francis, London. ISBN: 0-415-41620-5 (for
complete 3-volume set of proceedings). ISBN: 978-0-415-42314-4 (for Volume 2).
Kurian, S. and Pont, M.J. (2007) “Maintenance and evolution of resource-constrained
embedded systems created using design patterns”, Journal of Systems and Software,
80(1): 32-41.
Page 227
Lakhani, F. and Pont, M.J. (2010) “Using design patterns to support migration between
different system architectures”, Proceedings of 5th IEEE International Conference on
Systems of Systems Engineering, June 2010, Loughborough , UK.
Lakhani, F., and Pont, M.J. (2010) “Code balancing as a philosophy for change: Helping
developers to migrate from event-triggered to time-triggered architectures” Proceedings
of First UK Electronics Forum, 30June- 1 July 2010, Newcastle, UK , Published by
Newcastle University. ISBN: 978-0-7017-0232-8
Lakhani, F., Pont, M.J. and Das, A. (2009) “Can we support the migration from event
triggered to time triggered architectures using design patterns?” Proceedings of 5th UK
Embedded Forum, Leicester, UK , pp. 62-67. Published by Newcastle University.
ISBN: 978-0-7017-0222-9
Lakhani, F., Pont, M.J. and Das, A. (2009) “Towards a pattern language which supports the
migration of systems from an event-triggered pre-emptive to a time-triggered co-
operative software architecture” Proceedings of 14th Annual European Conference on
Pattern Languages of Programming”, Irsee, Germany, 8-12 July 2009. published by
CEUR vol. 566 . ISSN : 1613-0073
Lakhani, F., Pont, M.J. and Das, A. (2010) “Creating embedded systems with predictable
patterns of behaviour, supporting the migration between event-triggered and time-
triggered software architectures” Proceedings of 15th Annual European Conference on
Pattern Languages of Programming” , Irsee, Germany, 7 -11 July 2010.
Li, Y. and Pont, M.J. (2002) “On selecting pre-processing techniques for fault classification
using neural networks: A pilot study”, International Journal of Knowledge-Based
Intelligent Engineering Systems, 6(2): 80-87.
Li, Y., Pont, M.J. and Jones, N.B. (2002) “Improving the performance of radial basis function
classifiers in condition monitoring and fault diagnosis applications where „unknown‟
faults may occur”, Pattern Recognition Letters, 23: 569-577.
Li, Y., Pont, M.J., and Jones, N.B. (1999) “A comparison of the performance of radial basis
function and multi-layer Perceptron networks in a practical condition monitoring
application”, Proceedings of Condition Monitoring 1999 [Swansea, UK, April 12-15,
1999] pp.577-592.
Li, Y., Pont, M.J., Jones, N.B. and Twiddle, J.A. (2001) “Using MLP and RBF classifiers in
embedded condition monitoring and fault diagnosis applications”, Transactions of the
Institute of Measurement & Control, 23(3): 313-339.
Li, Y., Pont, M.J., Parikh, C.R. and Jones, N.B. (2000) “Comparing the performance of three
neural classifiers for use in embedded applications”, in: John, R. and Birkenhead, R.
(Eds.) Advances in Soft Computing: Soft Computing Techniques and Applications,
Springer-Verlag, Heidelberg, pp.34-39, [ISBN 3-7908-1257-9]
Li, Y.H., Jones, N.B. and Pont, M.J. (1998) “Applying neural networks and fuzzy logic to
fault diagnosis: a review”. in John, R.I. (1998), Editor, “Proceedings of: „Recent
Advances in Soft Computing „98” [Leicester, July 1998] pp.104-119. Published by
DeMontfort Expertise, Leicester, UK [ISBN 185 721 2592].
Maaita, A. and Pont, M.J. (2005) “Using „planned pre-emption‟ to reduce levels of task jitter
in a time-triggered hybrid scheduler”. In: Koelmans, A., Bystrov, A., Pont, M.J., Ong,
R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded Forum
(Birmingham, UK, October 2005), pp.18-35. Published by University of Newcastle upon
Tyne [ISBN: 0-7017-0191-9].
Page 228
Maguire, S. (1993) “Writing solid code”. Microsoft Press, 1993.
Mearns, D.D.U., Pont, M.J. and Ayavoo, D. (2008) “Towards Ctt (a programming language
for time-triggered embedded systems)”, in Proceedings of the 4th UK Embedded Forum
(September 2008, Southampton, UK).
MISRA (2004) “Guidelines for the use of the C language in critical systems”. Motor Industry
Software Reliability Report, Released October 2004.
Muhammad, A. and Pont, M.J. (2008) “Synchronising tasks in wireless multi-processor
environments using a shared-clock architecture: A pilot study”, in Proceedings of the 4th
UK Embedded Forum (September 2008, Southampton, UK).
Muhammad, A. and Pont, M.J. (2011) “Comments on: Two novel shared-clock scheduling
algorithms for use with CAN-based distributed systems”, Microprocessors and
Microsystems, Vol. 35, pp.81-82.
Mwelwa, C. and Pont, M.J. (2003) “Two new patterns to support the development of reliable
embedded systems” Paper presented at the Second Nordic Conference on Pattern
Languages of Programs, (“VikingPLoP 2003”), Bergen, Norway, September 2003.
Mwelwa, C., Athaide, K., Mearns, D., Pont, M.J. and Ward, D. (2007) “Rapid software
development for reliable embedded systems using a pattern-based code generation tool”.
SAE Transactions: Journal of Passenger Cars (Electronic and Electrical Systems),
115(7): 795-803.
Mwelwa, C., Pont, M.J. and Ward, D. (2004) “Code generation supported by a pattern-based
design methodology”. In: Koelmans, A., Bystrov, A. and Pont, M.J. (Eds.) Proceedings
of the UK Embedded Forum 2004 (Birmingham, UK, October 2004), pp.36-55.
Published by University of Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Mwelwa, C., Pont, M.J. and Ward, D. (2004) “Using patterns to support the development and
maintenance of software for reliable embedded systems: A case study”, Proceedings of
the IEE / ACM Postgraduate Seminar on “System-On-Chip Design, Test and
Technology”, Loughborough, UK, 15 September 2004. Published by IEE. ISBN: 0
86341 460 5 (ISSN: 0537-9989), pp. 15-20.
Mwelwa, C., Pont, M.J. and Ward, D. (2005) “Developing reliable embedded systems using a
pattern-based code generation tool: A case study”. In: Koelmans, A., Bystrov, A., Pont,
M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded Forum
(Birmingham, UK, October 2005), pp.177-193. Published by University of Newcastle
upon Tyne [ISBN: 0-7017-0191-9].
Nahas, M. and Pont, M.J. (2005) “Using XOR operations to reduce variations in the
transmission time of CAN messages: A pilot study”. In: Koelmans, A., Bystrov, A.,
Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK Embedded
Forum (Birmingham, UK, October 2005), pp.4-17. Published by University of
Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Nahas, M., Pont, M.J. and Jain, A. (2004) “Reducing task jitter in shared-clock embedded
systems using CAN”. In: Koelmans, A., Bystrov, A. and Pont, M.J. (Eds.) Proceedings
of the UK Embedded Forum 2004 (Birmingham, UK, October 2004), pp.184-194.
Published by University of Newcastle upon Tyne [ISBN: 0-7017-0180-3].
Nahas, M., Pont, M.J. and Short, M.J. (2009) “Reducing message-length variations in
resource-constrained embedded systems implemented using the Controller Area
Network (CAN) protocol”, Journal of Systems Architecture Vol. 55: pp.344–354.
Page 229
Nahas, M., Short, M.J. and Pont, M.J. (2005) “Exploring the impact of software bit stuffing
on the behaviour of a distributed embedded control system implemented using CAN”, in
Proceedings of the 10th international CAN Conference, held in Rome, 8-10 March 2005,
pp. 10-1 to 10-7.
Ong, H.L.R and Pont, M.J. (2001) “Empirical comparison of software-based error detection
and correction techniques for embedded systems”, Proceedings of the 9th International
Symposium on Hardware / Software Codesign, April 25-27 2001, Copenhagen,
Denmark. Pp.230-235. Published by ACM Press, New York. ISBN: 1-58113-364-2.
Ong, H.L.R and Pont, M.J. (2002) “The impact of instruction pointer corruption on program
flow: a computational modelling study”, Microprocessors and Microsystems, 25: 409-
419
Ong, H.L.R, Pont, M.J. and Peasgood, W. (2001) “A comparison of software-based
techniques intended to increase the reliability of embedded applications in the presence
of EMI” Microprocessors and Microsystems, 24(10): 481-491.
Ong, H.L.R., Pont, M.J., and Peasgood, W. (2000) “Hardware-software tradeoffs when
designing microcontroller-based applications for high-EMI environments”, IEE
Colloquium on Hardware-Software Co-Design, Savoy Place, London, 8 December,
2000. IEE Colloquium Digests #111.
Parikh C.R., M.J. Pont and N.B. Jones (2001) “Application of Dempster-Shafer theory in
condition monitoring systems”, Pattern Recognition Letters, 22(6-7): 777-785.
Parikh C.R., Pont, M.J., Jones, N.B. and Schlindwein, F.S. (2003) “Improving the
performance of CMFD applications using multiple classifiers and a fusion framework”,
Transactions of the Institute of Measurement and Control, 25(2): 123-144.
Parikh, C., Pont, M.J., Jones, N.B., Bhatti, A.I., Li, Y.H., Spurgeon, S.K., Scotson, P. and
Scaife, M. (1998) “Towards an application framework for condition monitoring and fault
diagnosis”. In John, R.I. (1998), Editor, “Proceedings of: „Recent Advances in Soft
Computing „98” [Leicester, July 1998] pp.128-141. Published by DeMontfort Expertise,
Leicester, UK [ISBN 185 721 2592].
Parikh, C.R., Pont, M.J., Li, Y. and Jones, N.B. (1999) “Improving the performance of multi-
layer Perceptrons where limited training data are available for some classes”,
Proceedings IEE International Conference on Neural Networks, Edinburgh, September
1999, pp.227-232.
Parikh, C.R., Pont, M.J., Li, Y. and Jones, N.B. (1999) “Neural networks for condition
monitoring and fault diagnosis: The effect of training data on classifier performance”,
Proceedings of Condition Monitoring 1999 [Swansea, UK, April 1999] pp.237-244.
Parikh, C.R., Pont, M.J., Li, Y. and Jones, N.B. (2000) “Investigating the performance of
MLP classifiers where limited training data are available for some classes”, in: John, R.
and Birkenhead, R. (Eds.) Advances in Soft Computing: Soft Computing Techniques and
Applications, Springer-Verlag, Heidelberg, pp.22-27, [ISBN 3-7908-1257-9]
Parikh, C.R., Pont, M.J., Li, Y.H., Jones, N.B. and Twiddle, J.A. (1998) “Towards a flexible
application framework for data fusion using real-time design patterns,” Proceedings of
6th European Congress on Intelligent Techniques & Soft Computing (EUFIT), Aachen,
Germany, September 7-10, 1998. pp.1131-1135.
Page 230
Phatrapornnant, T. and Pont, M.J. (2004) “The application of dynamic voltage scaling in
embedded systems employing a TTCS software architecture: A case study”, Proceedings
of the IEE / ACM Postgraduate Seminar on “System-On-Chip Design, Test and
Technology”, Loughborough, UK, 15 September 2004. Published by IEE. ISBN: 0
86341 460 5 (ISSN: 0537-9989), pp. 3-8.
Phatrapornnant, T. and Pont, M.J. (2004) “The application of dynamic voltage scaling in
embedded systems employing a TTCS software architecture”. In: Koelmans, A.,
Bystrov, A. and Pont, M.J. (Eds.) Proceedings of the UK Embedded Forum 2004
(Birmingham, UK, October 2004), pp.127-143. Published by University of Newcastle
upon Tyne [ISBN: 0-7017-0180-3].
Phatrapornnant, T. and Pont, M.J. (2006) “Reducing jitter in embedded systems employing a
time-triggered software architecture and dynamic voltage scaling”, IEEE Transactions
on Computers, 55(2): 113-124.
Pont, M.J. (1996) “Software Engineering with C++ and CASE Tools”, Addison-Wesley [964
pages]. ISBN: 0-201-87718-X.
Pont, M.J. (1998) “Control system design using real-time design patterns”, Proceedings of
Control „98 (Swansea, UK), September 1998, pp.1078-1083.
Pont, M.J. (2000) “Can patterns increase the reliability of embedded hardware-software co-
designs?”, IEE Colloquium on Hardware-Software Co-Design, Savoy Place, London, 8
December, 2000. IEE Colloquium Digests #111.
Pont, M.J. (2000) “Designing and implementing reliable embedded systems using patterns”,
in, Dyson, P. and Devos, Martine (Eds.) “EuroPLoP „99: Proceedings of the 4th
European Conference on Pattern Languages of Programming and Computing, 1999”.
ISBN 3-87940-774-6, Universitätsverlag Konstanz.
Pont, M.J. (2001) “Patterns for Time-Triggered Embedded Systems: Building Reliable
Applications with the 8051 Family of Microcontrollers”, Addison-Wesley / ACM Press.
[1012 pages] ISBN: 0-201-331381.
Pont, M.J. (2002) “Embedded C”, Addison-Wesley. [302 pages] ISBN: 0-201-79523-X.
Pont, M.J. (2003) “An object-oriented approach to software development for embedded
systems implemented using C”, Transactions of the Institute of Measurement and
Control 25(3): 217-238.
Pont, M.J. (2003) “Supporting the development of time-triggered co-operatively scheduled
(TTCS) embedded software using design patterns”, Informatica, 27: 81-88.
Pont, M.J. (2008) “Applying time-triggered architectures in reliable embedded systems:
Challenges and solutions”, Elektrotechnik & Informationstechnik, Vol. 125(11): 401-
405.
Pont, M.J. and Banner, M.P. (2004) “Designing embedded systems using patterns: A case
study”, Journal of Systems and Software, 71(3): 201-213.
Pont, M.J. and Mwelwa, C. (2003) “Developing reliable embedded systems using 8051 and
ARM processors: Towards a new pattern language” Paper presented at the Second
Nordic Conference on Pattern Languages of Programs, (“VikingPLoP 2003”), Bergen,
Norway, September 2003.
Page 231
Pont, M.J. and Ong, H.L.R. (2003) “Using watchdog timers to improve the reliability of
TTCS embedded systems”, in Hruby, P. and Soressen, K. E. [Eds.] Proceedings of the
First Nordic Conference on Pattern Languages of Programs, September, 2002
(“VikingPloP 2002”), pp.159-200. Published by Micrsoft Business Solutions. ISBN:
87-7849-769-8.
Pont, M.J., Kureemun, R., Ong, H.L.R. and Peasgood, W. (1999) “Increasing the reliability
of embedded automotive applications in the presence of EMI: A pilot study”, IEE
Colloquium on Automotive EMC, Birmingham, September 28, 1999.
Pont, M.J., Kurian, S. and Bautista-Quintero, R. (2007) “Meeting real-time constraints using
„Sandwich Delays‟”. In: Zdun, U. and Hvatum, L. (Eds) Proceedings of the Eleventh
European conference on Pattern Languages of Programs (EuroPLoP '06), Germany, July
2006: pp.67-77. Published by Universitätsverlag Konstanz. ISBN 978-3-87940-813-9.
Pont, M.J., Kurian, S., Wang, H. and Phatrapornnant, T. (2007) “Selecting an appropriate
scheduler for use with time-triggered embedded systems” Paper presented at the 12th
European Conference on Pattern Languages of Programs (EuroPLoP 2007).
Pont, M.J., Li, Y., Parikh, C.R. and Wong, C.P. (1999) “The design of embedded systems
using software patterns”, Proceedings of Condition Monitoring 1999 [Swansea, UK,
April 12-15, 1999] pp.221-236.
Pont, M.J., Norman, A.J., Mwelwa, C. and Edwards, T. (2004) “Prototyping time-triggered
embedded systems using PC hardware”. In: Henney, K. and Schutz, D. (Eds)
Proceedings of the Eighth European conference on Pattern Languages of Programs
(EuroPLoP 8), Germany, June 2003: pp.691-716. Published by Universitätsverlag
Konstanz. ISBN 3-87940-788-6.
Rizvi, S.A.I. and Pont, M.J. (2009) “Hardware support for deadlock-free resource sharing in
an embedded system with a TT architecture”, Proceedings of 5th UK Embedded Forum
2009, University of Leicester, UK, 23-24 September, pp. 1-9. Published by Newcastle
University. ISBN: 978-0-7017-0222-9
SAE (1993) “Class C Application Requirement Considerations”. SAE Recommended
Practice J2056/1, SAE, June 1993.
Short, M. (2008) “Development guidelines for dependable real-time embedded systems”.
Proceedings of the 6th IEEE/ACS International Conference on Computer Systems and
Applications (AICCSA 2008), pp. 1032 - 1039, April 2008.
Short, M. and Pont, M.J. (2005) “Hardware in the loop simulation of embedded automotive
control systems”, in Proceedings of the 8th IEEE International Conference on Intelligent
Transportation Systems (IEEE ITSC 2005) held in Vienna, Austria, 13-16 September
2005, pp. 226-231.
Short, M. and Pont, M.J. (2006) “Predicting the impact of hardware redundancy on the
performance of embedded control systems”. Proceedings of the 6th UKACC
International Control Conference, Glasgow, Scotland, 30 August to 1 September, 2006.
Short, M. and Pont, M.J. (2007) “Fault-tolerant time-triggered communication using CAN”,
IEEE Transactions on Industrial Informatics, 3(2): 131-142.
Short, M. and Pont, M.J. (2008) “Assessment of high-integrity embedded automotive control
systems using Hardware-in-the-Loop simulation”, Journal of Systems and Software,
81(7): 1163-1183.
Page 232
Short, M., Fang, J., Pont, M.J. and Rajabzadeh, A. (2007) “Assessing the impact of
redundancy on the performance of a brake-by-wire system”. SAE Transactions: Journal
of Passenger Cars (Electronic and Electrical Systems), 115(7): 331-338.
Short, M., Pont, M.J. and Fang, J. (2008) “Assessment of performance and dependability in
embedded control systems: Methodology and case study”, Control Engineering Practice.
Vol. 16, pp.1293– 1307
Short, M., Pont, M.J. and Fang, J. (2008) “Exploring the impact of task pre-emption on
dependability in time-triggered embedded systems: A pilot study”, Proceedings of the
20th EUROMICRO Conference on Real-Time Systems (ECRTS 08), Prague, Czech
Republic, July 2nd - 4th, 2008
Short, M., Pont, M.J. and Fang, J. (2008) “Exploring the impact of task pre-emption on
dependability in time-triggered embedded systems: A pilot study”, Proceedings of the
20th EUROMICRO Conference on Real-Time Systems (ECRTS 08), Prague, Czech
Republic, July 2nd - 4th, 2008
Vidler, P.J. and Pont, M.J. (2005) “Automatic conversion from „single processor‟ to „multi-
processor‟ software architectures for embedded control systems”. In: Koelmans, A.,
Bystrov, A., Pont, M.J., Ong, R. and Brown, A. (Eds.), Proceedings of the Second UK
Embedded Forum (Birmingham, UK, October 2005), pp.209-223. Published by
University of Newcastle upon Tyne [ISBN: 0-7017-0191-9].
Vidler, P.J. and Pont, M.J. (2006) “Computer assisted source-code parallelisation”. In:
Gavrilova, M., Gervasi, O., Kumar, V., Tan, C.J.K., Taniar, D., Laganà, A., Mun, Y. and
Choo, H. (eds.) Proceedings of the IEE International Conference on Computational
Science and its Applications (Glasgow, May 8-11, 2006), Part V. Lecture Notes in
Computer Science (LNCS), Vol. 3984, pp.22-31.
Wang, H. and Pont, M.J. (2008) “Design and implementation of a static pre-emptive
scheduler with highly predictable behaviour”, in Proceedings of the 4th UK Embedded
Forum (September 2008, Southampton, UK).
Wang, H. and Pont, M.J. (2008) “Design and implementation of a static pre-emptive
scheduler with highly predictable behaviour”, in Proceedings of the 4th UK Embedded
Forum (September 2008, Southampton, UK).
Wang, H., Pont, M.J. and Kurian, S. (2007) “Patterns which help to avoid conflicts over
shared resources in time-triggered embedded systems which employ a pre-emptive
scheduler” Paper presented at the 12th European Conference on Pattern Languages of
Programs (EuroPLoP 2007).
Page 233
You might also like
- C Programming For Embedded Microcontrollers, 2008, Warwick A. Smith, 0905705807, 9780905705804, Elektor International Media, 2008100% (1)C Programming For Embedded Microcontrollers, 2008, Warwick A. Smith, 0905705807, 9780905705804, Elektor International Media, 200821 pages
- SE T04 - Variables - Storing Data in ProgramsNo ratings yetSE T04 - Variables - Storing Data in Programs13 pages
- Embedded Systems and Linux Interview Questions - ARM Interview Questions100% (2)Embedded Systems and Linux Interview Questions - ARM Interview Questions5 pages
- 100 Embedded C Interview Questions Your Interviewer Might Ask AticleWorld PDF100% (1)100 Embedded C Interview Questions Your Interviewer Might Ask AticleWorld PDF44 pages
- Embedded Systems Programming with C++: Real-World TechniquesFrom EverandEmbedded Systems Programming with C++: Real-World TechniquesNo ratings yet
- Basic Introduction On Matlab: A Textbook ofNo ratings yetBasic Introduction On Matlab: A Textbook of17 pages
- Interview Questions On Embedded ProcessorsNo ratings yetInterview Questions On Embedded Processors5 pages
- Arm Microcontroller & Embedded Systems PDF100% (1)Arm Microcontroller & Embedded Systems PDF141 pages
- Adaptive AUTOSAR Based High Performance Controller DevelopmentNo ratings yetAdaptive AUTOSAR Based High Performance Controller Development17 pages
- What Is Embedded C Programming? How Is Embedded C Different From C Language?100% (1)What Is Embedded C Programming? How Is Embedded C Different From C Language?8 pages
- ARM Introduction & Instruction Set Architecture100% (1)ARM Introduction & Instruction Set Architecture71 pages
- Simulink-Targetlink Datatypes Defnt ProblemNo ratings yetSimulink-Targetlink Datatypes Defnt Problem16 pages
- Top 18 Embedded Systems Interview Questions PDFNo ratings yetTop 18 Embedded Systems Interview Questions PDF9 pages
- Vehicle Networks: CAN-based Higher Layer Protocols100% (4)Vehicle Networks: CAN-based Higher Layer Protocols46 pages
- Comprehensive Workflow For Autosar Classic and Adaptive Using Model Based DesignNo ratings yetComprehensive Workflow For Autosar Classic and Adaptive Using Model Based Design45 pages
- Embedded Systems (18EC62) - Embedded System Components (Module 3)100% (4)Embedded Systems (18EC62) - Embedded System Components (Module 3)108 pages
- Today's Topic:: To Run A Single Program Is Easy What To Do When Several Programs Run in Parallel?100% (2)Today's Topic:: To Run A Single Program Is Easy What To Do When Several Programs Run in Parallel?33 pages
- Echo on a Chip - Secure Embedded Systems in Cryptography: A New Perception for the Next Generation of Micro-Controllers handling Encryption for Mobile MessagingFrom EverandEcho on a Chip - Secure Embedded Systems in Cryptography: A New Perception for the Next Generation of Micro-Controllers handling Encryption for Mobile MessagingNo ratings yet
- Mastering Embedded C: The Ultimate Guide to Building Efficient SystemsFrom EverandMastering Embedded C: The Ultimate Guide to Building Efficient SystemsNo ratings yet
- Cmos Vlsi Design Lab 2: Datapath Design and Verification: I. Verilog Model RTL SimulationNo ratings yetCmos Vlsi Design Lab 2: Datapath Design and Verification: I. Verilog Model RTL Simulation8 pages
- Peripheral Remote IO Adapter BMXPRA0100 User ManualNo ratings yetPeripheral Remote IO Adapter BMXPRA0100 User Manual48 pages
- Control Unit: The Control Unit Is A Sequential Circuit Which Initiates All Micro-Operations in The Data ProcessorNo ratings yetControl Unit: The Control Unit Is A Sequential Circuit Which Initiates All Micro-Operations in The Data Processor14 pages
- Athlon II x3 440 3ghz Unlocked To Phenom II x4 B40 3ghz: Already Used Shop WarrantyNo ratings yetAthlon II x3 440 3ghz Unlocked To Phenom II x4 B40 3ghz: Already Used Shop Warranty26 pages
- E2 E3 Infosphere Datastage - Introduction To The Parallel ArchitectureNo ratings yetE2 E3 Infosphere Datastage - Introduction To The Parallel Architecture36 pages
- XFX Motherboard Intel Edition Cpu Compatibility List: Geforce X NforceNo ratings yetXFX Motherboard Intel Edition Cpu Compatibility List: Geforce X Nforce3 pages
- Computer Organisation and Arthicture Question Paper and SolutionNo ratings yetComputer Organisation and Arthicture Question Paper and Solution14 pages
- MELSEC-Q/L/F Structured Programming Manual (Fundamentals)No ratings yetMELSEC-Q/L/F Structured Programming Manual (Fundamentals)116 pages
- Question Bank: UNIT I - 8086 Microprocessor Part - A (2 Marks)100% (1)Question Bank: UNIT I - 8086 Microprocessor Part - A (2 Marks)10 pages
- Aldwin SumalabeComputer OrganizationAndArchitectureNo ratings yetAldwin SumalabeComputer OrganizationAndArchitecture20 pages
