Download Institutionen för systemteknik Department of Electrical Engineering

Institutionen för systemteknik
Department of Electrical Engineering
Examensarbete
A study of efficient sensor I/O interface and signal
acquisition techniques for electrical control units.
Examensarbete utfört i elektroniska komponenter
vid Tekniska högskolan i Linköping
av
Michael Pettersson
LiTH-ISY-EX--10/4400--SE
Linköping 2010
Department of Electrical Engineering
Linköpings universitet
SE-581 83 Linköping, Sweden
Linköpings tekniska högskola
Linköpings universitet
581 83 Linköping
A study of efficient sensor I/O interface and signal
acquisition techniques for electrical control units.
Examensarbete utfört i elektroniska komponenter
vid Tekniska högskolan i Linköping
av
Michael Pettersson
LiTH-ISY-EX--10/4400--SE
Handledare:
Professor Atila Alvandpour
isy, Linköpings University
Examinator:
Professor Atila Alvandpour
isy, Linköpings University
Linköping, 12 April, 2010
Avdelning, Institution
Division, Department
Datum
Date
Division of Electronic Devices
Department of Electrical Engineering
Linköpings universitet
SE-581 83 Linköping, Sweden
Språk
Language
Rapporttyp
Report category
ISBN
Svenska/Swedish
Licentiatavhandling
ISRN
Engelska/English
Examensarbete
C-uppsats
D-uppsats
Övrig rapport
2010-04-12
—
LiTH-ISY-EX--10/4400--SE
Serietitel och serienummer ISSN
Title of series, numbering
—
URL för elektronisk version
http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-54797
Titel
Title
En studie av effektiva sensor-I/O-gränssnitt och signalhämtningstekniker för elektriska kontrollenheter
A study of efficient sensor I/O interface and signal acquisition techniques for electrical control units.
Författare Michael Pettersson
Author
Sammanfattning
Abstract
Agricultural vehicles use electronic control units (ECUs) as control system. Historically ECUs have only been equipped with a minimum of features. With the
recent progress in electronics, which have made components faster, smaller and
cheaper, the trend is now to integrate more advanced functionality into the ECUs.
Agricultural vehicles are present all over the world and they have to operate
under a wide variety of conditions. This put high requirements on the system and
it is critical that a modern ECU can detect and locate errors. For an ECU to be
able to operate on a world-wide market it is required to be flexible, expandable
and robust. In addition to these requirements it is also wanted that an ECU have
a long lifespan and a low cost.
In this thesis different problems that modern ECUs have to face are investigated. Suggestions of how to solve these problems are also presented. There
are two focuses in the thesis, 1) how ECUs can acquire information from its inputs/outputs; and 2) the requirements of the ECU hardware.
This thesis does not aim to deliver a fully specified system description but
rather to provide an overview of how an ECU can be designed and which problems
that it has to face.
A selection of areas of ECU design which are investigated in this thesis are,
1) typical inputs/outputs; 2) analog-to-digital converters and their application; 3)
how multiplexers can be used; 4) requirements of general purpose inputs/outputs
(GPIO); 5) monitoring of a controller area network (CAN); 6) power-supply requirement and monitoring; 7) monitoring of the vehicle’s battery; 8) memory; 9)
requirement of the microcontroller (MCU);
Nyckelord
Keywords
ECU, Electrical control units, Agricultural vehicle, I/O interface, CAN, MCU,
Multiplexers, ADC, Solenoids, Sensors, Motors
Abstract
Agricultural vehicles use electronic control units (ECUs) as control system. Historically ECUs have only been equipped with a minimum of features. With the
recent progress in electronics, which have made components faster, smaller and
cheaper, the trend is now to integrate more advanced functionality into the ECUs.
Agricultural vehicles are present all over the world and they have to operate
under a wide variety of conditions. This put high requirements on the system and
it is critical that a modern ECU can detect and locate errors. For an ECU to be
able to operate on a world-wide market it is required to be flexible, expandable
and robust. In addition to these requirements it is also wanted that an ECU have
a long lifespan and a low cost.
In this thesis different problems that modern ECUs have to face are investigated. Suggestions of how to solve these problems are also presented. There
are two focuses in the thesis, 1) how ECUs can acquire information from its inputs/outputs; and 2) the requirements of the ECU hardware.
This thesis does not aim to deliver a fully specified system description but
rather to provide an overview of how an ECU can be designed and which problems
that it has to face.
A selection of areas of ECU design which are investigated in this thesis are,
1) typical inputs/outputs; 2) analog-to-digital converters and their application; 3)
how multiplexers can be used; 4) requirements of general purpose inputs/outputs
(GPIO); 5) monitoring of a controller area network (CAN); 6) power-supply requirement and monitoring; 7) monitoring of the vehicle’s battery; 8) memory; 9)
requirement of the microcontroller (MCU);
v
Acknowledgments
I would like to thank the following people who have been of great help when writing
this thesis:
• My supervisor and examiner Atila Alvandpour for letting me do this thesis
with his group at the department of electronic devices. I am grateful for the
insightful advice and feedback that I have received during the work with this
thesis.
• My contact person at the business partner of this thesis. Thank you for all
your useful advices and technical help during this thesis, without you this
thesis would not have been possible.
• Daniel Svärd for proof-reading my thesis and improving its readability.
Michael Pettersson, April 2010
vii
Contents
1 Introduction
1.1 Purpose . . . . . . . . . .
1.2 Method . . . . . . . . . .
1.3 Anonymity . . . . . . . .
1.4 Typical ECU Model . . .
1.4.1 ECU Requirements
1.5 Limitations . . . . . . . .
1.6 Structure of the Report .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
2
3
3
3
4
2 Input/Output Overview
2.1 Solenoids . . . . . . . . . . . . . . . . .
2.1.1 Solenoid Driver . . . . . . . . . .
2.1.2 Conclusion Solenoid Driver . . .
2.1.3 Solenoid Signal . . . . . . . . . .
2.2 Sensors . . . . . . . . . . . . . . . . . .
2.2.1 Sensor Power-Supply . . . . . . .
2.2.2 Conclusion Sensor Power-Supply
2.2.3 Sensor Output Monitor . . . . .
2.2.4 Conclusion Sensor Monitor . . .
2.3 Motors . . . . . . . . . . . . . . . . . . .
2.3.1 Motor Driver . . . . . . . . . . .
2.3.2 Conclusion Motor Driver . . . .
2.3.3 Motor Signal . . . . . . . . . . .
2.4 Input/Output Signal Summary . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
7
9
11
13
14
14
16
18
19
19
23
25
28
3 System Research
3.1 ECU Overview . . . . . . . . . . . . . . . . . .
3.1.1 MCU Overview . . . . . . . . . . . . . .
3.2 Analog-to-Digital Converter (ADC) . . . . . . .
3.2.1 Requirements . . . . . . . . . . . . . . .
3.2.2 Survey of MCUs . . . . . . . . . . . . .
3.2.3 Conclusion Analog-to-Digital Converter
3.3 Multiplexer . . . . . . . . . . . . . . . . . . . .
3.3.1 Structures . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
31
31
33
34
34
35
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
x
Contents
3.3.2 Requirements . . . . . . . . . . . . . . . . .
3.3.3 Survey of Multiplexers . . . . . . . . . . . .
3.3.4 Multiplexer Delay . . . . . . . . . . . . . .
3.3.5 Fastest Conversion Rate . . . . . . . . . . .
3.3.6 Conclusion Multiplexer . . . . . . . . . . .
3.4 General Purpose Input/Output (GPIO) . . . . . .
3.4.1 Requirements . . . . . . . . . . . . . . . . .
3.4.2 Survey of MCU GPIO pins . . . . . . . . .
3.4.3 Flexibility Vs Hardware-Resources . . . . .
3.4.4 Chip Select Signal . . . . . . . . . . . . . .
3.4.5 Conclusion General Purpose Input/Output
3.5 Controller Area Network (CAN) . . . . . . . . . .
3.5.1 CAN-Bus Description . . . . . . . . . . . .
3.5.2 Survey of MCU CAN Controllers . . . . . .
3.5.3 Requirements on Error Detection . . . . . .
3.5.4 Short Circuit . . . . . . . . . . . . . . . . .
3.5.5 CAN-Line Interrupt . . . . . . . . . . . . .
3.5.6 Termination Resistors . . . . . . . . . . . .
3.5.7 Incorrect Pulse-Width . . . . . . . . . . . .
3.5.8 Slow Slope . . . . . . . . . . . . . . . . . .
3.5.9 Problems with the CAN-Driver . . . . . . .
3.5.10 Conclusion Controller Area Network . . . .
3.6 Power Supply . . . . . . . . . . . . . . . . . . . . .
3.6.1 Power-Supply Generator . . . . . . . . . . .
3.6.2 Low-Voltage Detection . . . . . . . . . . . .
3.6.3 Power-Supply Monitor . . . . . . . . . . . .
3.6.4 Conclusion Power-Supply . . . . . . . . . .
3.7 Battery Health . . . . . . . . . . . . . . . . . . . .
3.8 Environment . . . . . . . . . . . . . . . . . . . . .
3.8.1 Temperature . . . . . . . . . . . . . . . . .
3.8.2 Water . . . . . . . . . . . . . . . . . . . . .
3.8.3 Acceleration . . . . . . . . . . . . . . . . . .
3.8.4 Conclusion Environment . . . . . . . . . . .
3.9 Memory . . . . . . . . . . . . . . . . . . . . . . . .
3.9.1 Survey of MCU Memory . . . . . . . . . . .
3.9.2 External Memory . . . . . . . . . . . . . . .
3.10 Summary System Research . . . . . . . . . . . . .
3.11 MCU . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11.1 Requirements . . . . . . . . . . . . . . . . .
3.11.2 MCU Choice . . . . . . . . . . . . . . . . .
3.11.3 Conclusion MCU . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
38
38
39
39
40
41
42
45
45
45
46
47
47
48
49
49
50
52
52
53
53
54
56
60
63
63
65
65
66
68
70
71
71
72
74
75
75
76
77
4 Summary
4.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
80
Bibliography
83
Contents
xi
A CAN-bus Measurements
87
xii
Contents
List of Tables
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
Solenoid driver PROFETs . . . . . . . . . .
Solenoid driver ICs . . . . . . . . . . . . . .
Solenoid driver pin requirement . . . . . . .
Solenoid I/Os . . . . . . . . . . . . . . . . .
Solenoid A/D signals speed-rates . . . . . .
Sensor power-supply specification . . . . . .
Sensor power-supply pin requirement . . . .
Sensor power-supply I/Os . . . . . . . . . .
Sensor power-supply A/D signals speed-rate
Sensor monitor specification . . . . . . . . .
Sensor monitor pin requirement . . . . . . .
Sensor monitor I/Os . . . . . . . . . . . . .
Sensor-monitors’ A/D signal speed-rates . .
Motor specification . . . . . . . . . . . . . .
H-bridge requirement of switches . . . . . .
Motor driver PROFETs . . . . . . . . . . .
Motor driver ICs . . . . . . . . . . . . . . .
Motor driver pin requirement . . . . . . . .
Motor I/Os . . . . . . . . . . . . . . . . . .
Motor A/D signals speed-rates . . . . . . .
Summary I/Os . . . . . . . . . . . . . . . .
I/O ADC speed-rate . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
9
11
11
11
14
15
16
16
16
18
19
19
20
21
23
23
24
24
25
28
28
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
Suitable MCUs . . . . . . . . . . . . . . .
A/D signals overview . . . . . . . . . . . .
ADC subsystem requirements . . . . . . .
ADC overview . . . . . . . . . . . . . . .
ADC structure 1 . . . . . . . . . . . . . .
ADC structure 2 . . . . . . . . . . . . . .
ADC structure 3 . . . . . . . . . . . . . .
Multiplexer overview . . . . . . . . . . . .
GPIO requirement . . . . . . . . . . . . .
GPIO overview . . . . . . . . . . . . . . .
A/D signal requirements . . . . . . . . . .
Multiplexer signal distribution . . . . . .
Multiplexer pin requirements . . . . . . .
GPIO subsystem pin requirements . . . .
MCUs’ CAN protocol support . . . . . . .
Can-bus short-circuit behavior . . . . . .
MCUs’ support for external interrupt . . .
CAN subsystem pin requirements . . . . .
MCUs’ power-supply requirements . . . .
Switched power-supply generator overview
MCUs’ low-voltage detection functions . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
33
33
36
36
37
38
40
41
43
44
44
46
47
48
51
54
55
56
57
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29
3.30
3.31
3.32
3.33
3.34
3.35
3.36
3.37
3.38
3.39
3.40
3.41
3.42
3.43
3.44
3.45
3.46
Low-voltage detection pin requirements .
Voltage drop required action . . . . . . .
Power-supply supervisor overview . . . . .
Power-supply monitor’s pin requirements
Power-supply’s subpart conclusions . . . .
Power subsystem’s pin requirements . . .
Battery health subsystem pin requirement
Temperature survey . . . . . . . . . . . .
Temperature pin requirements . . . . . . .
Water pin requirements . . . . . . . . . .
Overview accelerometers . . . . . . . . . .
MCU I 2 C support . . . . . . . . . . . . .
Acceleration pin requirements . . . . . . .
Environment subsystem pin requirements
MCUs’ internal memory overview . . . . .
Parallel interface overview . . . . . . . . .
Serial interface overview . . . . . . . . . .
GPIO overview . . . . . . . . . . . . . . .
Memory pin requirements . . . . . . . . .
System requirements A/D signals . . . . .
System requirement GPIO signals . . . .
System requirement summary . . . . . . .
MCU requirements . . . . . . . . . . . . .
Possible MCU choices . . . . . . . . . . .
LPC2939 specification . . . . . . . . . . .
xiii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
61
61
62
63
63
64
66
67
68
69
69
70
70
71
72
73
74
74
75
75
76
76
77
77
xiv
Contents
List of Figures
1.1
1.2
1.3
Agricultural vehicles . . . . . . . . . . . . . . . . . . . . . . . . . .
ECU example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Typical ECU Model . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
Input/Output overview . . . . . . . . . . . . . . . . . . . . . .
Duplomatic solenoid . . . . . . . . . . . . . . . . . . . . . . . .
Schematic solenoid driver . . . . . . . . . . . . . . . . . . . . .
Schematic solenoid driver . . . . . . . . . . . . . . . . . . . . .
Waveform of ”SafeTrack lock valve” . . . . . . . . . . . . . . .
Waveform ”SafeTrack proportional valve Duplomatic” free . . .
Waveform ”SafeTrack proportional valve Duplomatic” blocked .
Proximity sensor . . . . . . . . . . . . . . . . . . . . . . . . . .
Schematic sensor power-supply . . . . . . . . . . . . . . . . . .
Schematic sensor monitoring . . . . . . . . . . . . . . . . . . .
Schematic sensor monitoring . . . . . . . . . . . . . . . . . . .
Motor photo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H-bridge example . . . . . . . . . . . . . . . . . . . . . . . . . .
H-bridge with motors that share common stage . . . . . . . . .
Schematic motor driver . . . . . . . . . . . . . . . . . . . . . .
Schematic motor driver . . . . . . . . . . . . . . . . . . . . . .
Waveform motor rotating forwards . . . . . . . . . . . . . . . .
Waveform motor rotating backwards . . . . . . . . . . . . . . .
Schematic differentiator . . . . . . . . . . . . . . . . . . . . . .
How the differentiator works . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
8
10
12
12
13
13
15
17
18
19
20
22
22
24
25
26
27
27
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
System overview . . . . . . . . . . . . . . . . . . .
A selection of MCUs . . . . . . . . . . . . . . . . .
ADC black-box . . . . . . . . . . . . . . . . . . . .
Multiplexer approach to ease A/D pin requirement
A/D conversion with and without multiplexers . .
Multiplexer layer approaches . . . . . . . . . . . .
GPIO black-box . . . . . . . . . . . . . . . . . . .
Multiplexers sharing control pins . . . . . . . . . .
Detailed CAN bus . . . . . . . . . . . . . . . . . .
CAN message . . . . . . . . . . . . . . . . . . . . .
Peak detectors . . . . . . . . . . . . . . . . . . . .
CAN-line interrupt . . . . . . . . . . . . . . . . . .
Detection of incorrect pulse-width . . . . . . . . .
Slow slope detector . . . . . . . . . . . . . . . . . .
CAN-driver monitor . . . . . . . . . . . . . . . . .
Power-supply . . . . . . . . . . . . . . . . . . . . .
Low-voltage detection . . . . . . . . . . . . . . . .
MCU’s low-voltage behavior . . . . . . . . . . . . .
Shutdown I/Os . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
32
34
35
36
40
42
46
48
49
49
51
52
53
54
58
59
62
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
Contents
xv
3.20
3.21
3.22
3.23
3.24
Battery internal resistance . . . . . .
Measure battery’s internal resistance
Temperature measurement . . . . . .
Water measurement . . . . . . . . .
Water-sensor placement . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
64
67
68
68
4.1
System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
A.1 CAN-bus 4m cable with termination resistor mounted . . . . . . .
A.2 CAN-bus 4m cable with termination resistor unmounted . . . . . .
88
89
Acronyms
A/D
ADC
CAN
CPU
EBI
ECU
FET
GPIO
I/O
I2 C
IC
LVD
MCU
NTC
PCB
POR
PROFET
PTC
RAM
RISC
SMC
SPI
Analog-to-Digital
Analog-to-Digital Converter
Controller-Area Network
Central Processing Unit
External Bus Interface
Electrical Control Unit
Field-Effect Transistor
General-Purpose Input/Output
Input/Output
Inter-Integrated Circuit
Integrated Circuit
Low Voltage Detection
MicroController Unit
Negative Temperature Coefficient
Printed Circuit Board
Power-On Reset
PROtected FET
Positive Temperature Coefficient
Random Access Memory
Reduced Instruction Set Computer
Static Memory Controller
Serial Peripheral Interface
Chapter 1
Introduction
Figure 1.1. Two examples of agricultural vehicles. [1, 2]
This report is a part of my master thesis done at the department of electronic
devices at Linköping University. The goal of this report is to investigate how an
electrical control unit can be designed and to investigate potential problems that
the electrical control unit has to be able to deal with.
An electrical control unit, or an ECU, is an embedded system that controls an
electronic system or subsystem in a motor vehicle.
Figure 1.2. An example of an ECU used in the motor industry. [3]
1
2
Introduction
Historically ECUs have only been equipped with a minimum of features. With
the recent progress in electronics, which have made components faster, smaller
and cheaper, the trend is now to integrate more advanced functionality into the
ECUs. Modern ECUs should not only be able to control the electronic system, it
should also be able to diagnose and locate errors. The ECU should then be able
to present these errors to the user in an understandable way.
An ECU for agricultural vehicles has to be robust since it is used in harsh
conditions. Normal problems that the ECU face are e.g. salt, water, chemicals
and temperature shifts. It is critical that the ECU can detect when it is exposed
to a condition that might affect its performance so the user can be informed and
take countermeasures.
1.1
Purpose
The purpose of this report is to investigated problems that have to be faced when
developing an electrical control unit.
The aim is not to give a fully specified ECU but rather to investigate potential
problems and see which ones could be issues and, equally important, which ones
will not be issues. The report will discuss pros and cons of different solutions to
the investigated problems.
1.2
Method
The department of electronic devices at Linköping University and a business parter
have decided to collaborate in these investigations. The business partner, with
experience of development of ECUs for agricultural vehicles, provide information
of what kind of problems a modern ECU has to be able to deal with.
This report investigates problems that are identified after discussions in the
business collaboration. After potential problems are identified, solutions to these
problems will be investigated. To make the results of this report easier to understand an ECU system is purposed during the investigations. The business partner
has provided information of how a modern ECUs can look like (see section 1.4)
and some errors that can occur in agricultural vehicles.
Much of the work will be done by surveys and investigations of datasheets and
application notes.
One thing that has been noticed during this report is that there exist very few
books that cover design of ECUs. Therefore the references list mostly consists of
datasheets and application notes.
1.3
Anonymity
The business partner wants to be anonymous and therefore this report does not
contain any information that can identify the business partner.
1.4 Typical ECU Model
1.4
3
Typical ECU Model
The business partner has provided with an model of how a modern ECU can
look like. This model will be used when problems, that the ECU has to face, are
investigated and also when the requirements of the ECU are specified.
Sensors Solenoids Motors
Memory
Microcontroller
CANOther
Interface MCUs
ECU
Figure 1.3. A model of how a typical ECU can look like. The different parts of this
model are explained in Chapter 2 and Chapter 3.
This model should only be seen as a overview. More parts, than the ones presented in the figure, will be added and discussed later. This model’s only purpose
is to provide a foundation from which this report can start its investigations.
1.4.1
ECU Requirements
The following properties are desired of an ECU:
1. Long lifespan. This is to avoid having too many products on the market
simultaneously and to lower the development cost in the long run.
2. Extensive error detection. This is to make the agricultural vehicles more
robust and also to decrease the maintenance cost.
3. Expandable. The ECU should have capacity for extra functions to be
added in the future. This makes it possible to add new functionality without
a redesign (e.g. change the MCU for one with higher performance) of the
ECU.
4. General design. A general design makes it easy to change something in
the system, e.g. sensor type (see Chapter 2).
5. Low cost.
1.5
Limitations
The following areas will not be considered in this report. These limitations have
been chosen according to suggestions from the business partner of what are critical
issues in ECU design.
4
Introduction
1. The system’s power consumption.
2. The PCB area of the system.
3. The software implementation.
1.6
Structure of the Report
This report is divided into four chapters:
1. Introduction: Presents the goal, method and purpose of the report. A
short introduction an ECU is also presented.
2. Input/Output Overview: The system’s I/Os are presented and the requirements of them are investigated.
3. System Research: The subparts of an ECU are discussed and different
solution of how to use them are also presented.
4. Summary: A summary of the results of the report and suggested future
work is presented.
Chapter 2
Input/Output Overview
An ECU is responsible to retrieve and interpret information from the Inputs/Outputs
(I/Os). It is also responsible to provide I/Os with the correct power so that these
devices can function properly.
The goal of this chapter is to investigated how an ECU can operate I/Os
which are common in agricultural vehicles, and also how the ECU can detect if
any problem with the I/Os occur. Another goal in this chapter is to see which
requirements the handling of the I/Os inflicts on the ECU.
Our business partner has provided with a model of an ECU that has 10 motors,
10 sensors and 14 solenoids that will be used in the investigations in this chapter.
System
14
Solenoids
10
Sensors
10
Motors
Figure 2.1. An overview of the I/Os in the system.
In this chapter it is investigated how the ECU can operate these devices. All
three types of I/Os have to have a driver in order to operate. In addition to
these drivers, the I/Os also have to be equipped with monitor functionalities. The
monitor functionality is needed to provide the ECU with diagnostic features which
increase the system’s robustness.
Each type of I/O is investigated in a separate section. This chapter consists of
four sections:
• Solenoids
• Sensors
• Motors
5
6
Input/Output Overview
• Input/Output Signal Summary
In the first three sections, i.e. Solenoids, Sensors and Motors, solutions are
proposed of how to use the I/Os. A solution usually consist of a recommended
schematic or a recommended device. The signals of interest are presented in each
schematic. Some of these signals need to be analog-to-digital converted before the
ECU can read them. The signals, that need to be analog-to-digital converted,
are classified into three categories according to which frequency they have to be
sampled. These are:
• Slow : 10 Hz
• Intermediate : 100 Hz
• Fast : 2 kHz
The categories are specified as a result of discussions with the business partner.
In the fourth section information about the system’s signals found in the previous three sections is summed up.
Schematics used in Chapter 2 are based on sketches provided by the business
partner. When a schematic is presented it should not be considered to be anything other than an illustrative solution. This report will not make any deep
investigation of these schematics to see if they can be improved or simplified. The
schematics will only be investigated to see which requirements they inflict on the
rest of the system.
The I/Os in this chapter are not all the I/Os that the ECU have to deal with.
More I/Os are investigated in Chapter 3. This is done because no other I/O is
known at this stage of the report.
2.1
Solenoids
A solenoid is a device that converts electric power into mechanical movement. An
example of a solenoid is shown in Figure 2.2.
Figure 2.2. A solenoid from Duplomatic. Inside of this solenoid there is a valve for
hydraulics which moves when the solenoid operates. [17]
2.1 Solenoids
7
A solenoid driver is the circuit/device used to provide the solenoid with power.
The solenoid driver does not only have to drive the solenoid but it also needs to
monitor its output signal to the solenoid. The monitoring is needed for the ECU to
be able to locate problems with the solenoid, which is needed to make the system
robust.
2.1.1
Solenoid Driver
A solenoid driver provides the solenoid with the correct power-supply. The requirements of the solenoid driver are discussed in this section. After this discussion it
is investigated how the system can reach these requirements.
To specify the requirements of the solenoid driver the requirements of an agricultural vehicles commonly used solenoid are needed to be investigated. The Duplomatic 41150A solenoid is used for this purpose.
Requirements
The Duplomatic 41150A [17] has the following requirements:
• Current capability up to 2.72 A.
• Runs at 12 V power-supply.
Two approaches on how the system can reach these requirements are investigated. These two approaches are:
• Circuit with PROFET
• Integrated circuit
A PROFET is a transistor that is special designed to be used in high voltage
and high current applications.
In order to detect a problem with the solenoid, the solenoid has to be monitored.
Our business partner has suggested which signals that need to be monitored
and at which sampling frequency the A/D signals have to be sampled. These are
specified as following:
• Solenoid input : Slow-rated (10 Hz)
• Feedback current : Fast-rated (2 kHz)
Circuit with PROFET
The schematic in Figure 2.3 use a PROFET to drive the solenoid. As can be
seen in the figure, the schematic contains a BTS5236 [19] device which is the
driver circuit. The reason why this device is chosen as a driver is discussed in the
conclusion of this section.
The schematic also contains two A/D signals (ADC_1 and ADC_2) and one
GPIO (IN_1) signal. The IN_1 signal turns the BTS5236 device on and off.
8
Input/Output Overview
VBAT
IN_1
ADC_1
Solenoid Input
BTS5236
ADC_2 (IS1)
Figure 2.3. The figure illustrates how a solenoid driver circuit with the BTS5236 device
could look. The output voltage of the BTS5236 is monitored with an ADC. The BTS5236
has one output (IS1) for the feedback current from the solenoid. This output is connected
to a resistor so that the value can be measured with an ADC. The reason why the feedback
current has to be measured is discussed in section 2.1.3 (page 11).
The output of the driver is monitored with one A/D channel (ADC_1) while
the feedback current from the solenoid is monitored by the other A/D channel
(ADC_2).
To monitor the feedback current with an ADC, the resistor is needed to convert
the feedback current into voltage. The reason why the feedback current has to be
monitored is discussed in section 2.1.3 (page 11).
Survey of PROFETs
A survey has been done to see which PROFET devices are available on the market.
The result of this survey is presented in Table 2.1.
Device
BTS5236
Producer
Infineon
Price
$1.3
MC10XS3412 [33]
Freescale
$4.5
L6370D [34]
STMicroelectronics
$6.5
Note
Dual channels high-side
driver.
Two diagnostic
pins.
Quad channels high-side
driver. 16-bit SPI for diagnostic.
High-side driver
Table 2.1. A selection of PROFETs which fulfills the requirements to drive the system’s
solenoids.
The goal of the survey was to find devices that fulfill the requirements of the
solenoid driver, and to give an estimation of how much they cost.
All the devices in Table 2.1 fulfill the requirements of the solenoid driver. All
devices also have built-in protection against e.g. overload, overtemperature and
short circuits.
2.1 Solenoids
9
Integrated Circuit
The second approach of how to construct the solenoid driver is to use an integrated
circuit instead of a PROFET. This approach is investigated in this section.
First of all, what is the difference between a PROFET and an IC?
• PROFET : Works as a power switch. Has basic built-in protection against
e.g. overload, overtemperature and short circuits. Does not have any built-in
support for signal diagnostics.
• IC : Has one or several integrated power switches1 . Has built-in protection
against e.g. overload, overtemperature and short circuits. Usually have a
larger variety of functions than the PROFETs. Have intelligent built-in error
detection which the IC usually communicates to the MCU over an SPI bus.
Survey of Integrated Circuits
In this section it is investigated which ICs on the market fulfill the requirements
of the solenoid driver.
Device
L9950 [36]
TLE8201 [18]
Producer
STMicroelectronics
Infineon
Price
$6
$6
Note
SPI for diagnostics
SPI for diagnostics.
Table 2.2. A selection of ICs that fulfill the requirements to drive the solenoids. The
approximate prices of the devices are also presented.
The result of the survey of ICs is presented in Table 2.2. The devices in
the table offer built-in functions as undervoltage and overvoltage detection, short
circuit protection etc. Both ICs in Table 2.2 communicate with the MCU over an
SPI bus and will inform the MCU if any problem is detected.
2.1.2
Conclusion Solenoid Driver
In this section it has been investigated how to construct a solenoid driver. Two
approaches have been investigated. The first approach uses a PROFET device as
a driver while the second approach uses an IC as a driver.
The PROFET approach requires fewer pins to operate but it does not have
any built-in support for error detection. If the PROFET approach is chosen as a
solution extra pins are needed to monitor the device externally. As can be seen
in Figure 2.4 (page 10), one A/D signal is needed to monitor the output to the
solenoid and one A/D signal to monitor the feedback current from the solenoid.
The IC approach requires more pins to operate but it has built-in support for
undervoltage and overvoltage detection. The ICs found in the survey do not have
enough error detection for the ECU to rely on the IC’s error detection only. It is
not enough for the system to have undervoltage and overvoltage detection. The
1 At
least the ICs that are considered as choices for solenoid driver in this report
10
Input/Output Overview
system must be able to monitor the output to the solenoid. The reason why this
is the case is discussed in section 2.1.3 (page 11). Since none of the found ICs
monitors the output voltage or the feedback current, two additional A/D signals
are needed to monitor these signals. Note that these two additional A/D signals
are needed in both the PROFET approach and in the IC approach.
Which approach is the best choice for the system? Since it is desired that the
system should have a low cost, it is logical to choose the PROFET approach since
it is the cheaper of the two approaches.
If the PROFET approach is chosen, I recommend using the BTS5236 since it
offers a cost-effective solution and it fulfills the system’s requirements.
The ICs found in the survey contain many built-in functions but many of these
functions are not required of the system. E.g. the L9950 offers 10 different drivers
but only four of them fulfill the system’s requirements.
It is possible that the IC approach could be a better choice if an IC with more
application-specific features could be found. This was however not the case in the
survey and the IC approach is therefore not recommended.
Pin Requirements When Using the Recommended Solenoid Driver
The schematic in Figure 2.4 is the recommended solution for solenoid driver.
VBAT
IN_1
ADC_1
Solenoid Input
BTS5236
ADC_2 (IS1)
Figure 2.4. The figure illustrates how a solenoid driver with the BTS5236 device could
look. The output voltage of the BTS5236 is monitored with an ADC. The BTS5236 has
one output (IS1) for the feedback current from the solenoid. This output is connected to
a resistor so that the value can be measured with an ADC. The reason why the feedback
current has to be measured is discussed in section 2.1.3 (page 11).
If this schematic is used as a solution and if requirements of sampling frequency
must be fulfilled, the system has to be able to handle the signals in Table 2.3.
As mentioned in the beginning of this section, the system will have 14 solenoids
and each solenoid will have one driver. The required number of pins needed is
presented in Table 2.4.
According to Table 2.4 the solenoids in the system require 42 pins in total and
28 of these are ADC pins. As known from the classifications done in Table 2.3,
2.1 Solenoids
Signal name
IN_1
ADC_1
ADC_2
11
Type
GPIO
ADC
ADC
Speed rate
Slow (S)
Fast (F)
Function
Activate BTS5236 driver
Solenoid input
Solenoid feedback current
Table 2.3. This table presents a summary of the MCU pin requirements of the solenoid
driver. This numbers are only valid when the BTS5236 is chosen as driver.
Type
Number of solenoids
GPIO pins
A/D pins
Amount
14
14
28
Table 2.4. This table presents the required number of pins that the MCU needs to have
if the recommended solution is chosen.
each solenoid driver contains one fast-rated and one slow-rated A/D signal. This
information about the A/D signals’ speed-rates is summarized in Table 2.5.
A/D speed-rate
Slow
Intermediate
Fast
Amount
14
0
14
Table 2.5. This table presents the signals’ required sampling frequencies. This information is summed up from Table 2.3 and Table 2.4.
2.1.3
Solenoid Signal
In this section it is investigated which type of information it is possible to get from
the solenoids.
Two types of solenoids with different waveforms are investigated:
• SafeTrack proportional valve Duplomatic
• SafeTrack lock valve
In order for the system to fulfill the requirement of robustness, the system has
to be able to detect if the solenoids are operational or not. Can this be done and
in that case what are the requirements on the system to do this?
Requirements
One way to monitor the solenoids is to analyze the current waveforms that the
solenoids produce.
As can be seen in Figure 2.5, the ”SafeTrack lock valve” has a characteristic
dip in their waveforms. This dip occurs as a result of movement of the valve inside
12
Input/Output Overview
180
160
140
Voltage (mV)
120
100
80
60
40
20
0
0
5
10
15
time (ms)
20
25
30
Figure 2.5. This figure shows the waveform of the ”SafeTrack lock valve”. It has a
characteristic dip which indicates that the valve inside of the solenoid has moved.
of the solenoid. If the valve inside of the solenoid is supposed to move but no dip
is detected, the system must be able to signal that a faulty behavior has occurred.
The ”SafeTrack proportional valve Duplomatic” has a different waveform, which
can be seen in Figure 2.6. Instead of a dip when the valve moves, it has a slower
slope.
160
140
Voltage (mV)
120
100
80
60
40
20
0
0
10
20
30
40
50
60
70
time (ms)
Figure 2.6. Waveform of the ”SafeTrack proportional valve Duplomatic” when it is
moving freely. Compared with the waveform of when the solenoid is blocked (see Figure
2.7) this curve has a slower slope.
If the ”SafeTrack proportional valve Duplomatic” is blocked, the waveform will
look as in Figure 2.7 and as can be seen this waveform is missing the slower slope
that occurs when the valve inside of the solenoid moves (as in Figure 2.6).
2.2 Sensors
13
160
140
Voltage (mV)
120
100
80
60
40
20
0
0
10
20
30
40
50
60
70
time (ms)
Figure 2.7. Waveform of the ”SafeTrack proportional valve Duplomatic” when it is
blocked. As can be seen this curve has a faster increasing slope than when the valve
inside of the solenoid is moving freely (as in Figure 2.6).
Both types of solenoids can be monitored with an ADC. When the signals are
sampled, the dip-detection can be done in software.
2.2
Sensors
Figure 2.8. A proximity sensor from Omron. [28]
The system will consist of several types of sensors. All sensor circuits have to
be equipped with:
• Power-supply
• Monitor functions
Why a power-supply is needed is self-explanatory. The monitoring functionality
is needed so that the system can read the sensor’s value.
14
2.2.1
Input/Output Overview
Sensor Power-Supply
In this section the sensor power-supply is investigated.
Requirements
A selection of sensor types are presented in Table 2.6. These sensor types are
regarded as the types that the system has to be able to use.
Sensor
E2A [29]
424.00A [15]
424.06A [15]
Producer
Omron
Elobau
Elobau
Type
Proximity sensor
Angle sensor
Angle sensor
Supply voltage
12-24 V
10-30 V
4.5-5.5 V
Table 2.6. This table contains the specifications of a selection of the sensors. The
system needs to be able to use all these types of sensors.
A requirement is that the system must use a general design which in case
of sensor power-supplies corresponds to that all power-supplies must be able to
provide power to all types of sensors listed in Table 2.6. This is required so that
the sensor type can be changed without redesigning the system.
How can the sensor power-supply be designed so it fulfills the requirements?
Since the power-supply is only required to have basic power-supply features, it is
logical to use a discrete circuit rather than a more advanced IC.
In discussions with the business partner it has been decided that it suitable
to monitor a sensor’s power-supply with a sampling frequency of 10 Hz (that is
slow-rated).
Discrete Circuit
One straightforward design that fulfills the system’s requirements is to use a discrete circuit. The schematic in Figure 2.9 can be used for this purpose.
The schematic contains a manual switch which position is set depending on the
type of sensor it is supplying with power. If a sensor that requires 5 V power-supply
is connected, the switch has to be in downwards position. If another sensor type is
connected the switch has to be in upwards position. The schematic also has three
A/D signals that are used to monitor the different voltages in the power-supply
circuit.
One could argue that it would be enough with either ADC_1 and ADC_3
or only ADC_2. The reason why three A/D signals are in the schematic is to
simplify pinpointing of potential errors and to provide redundancy.
2.2.2
Conclusion Sensor Power-Supply
In this section it has been investigated how to fulfill the requirements of the sensor
power-supply. The power-supply is required to have a general design that can
deliver power to different types of sensors presented in Table 2.6.
2.2 Sensors
15
VBAT
ADC_1
PTC
Output
5V
Switch
ADC_3
ADC_2
Figure 2.9. This figure shows an example of how the schematic of the sensor’s powersupply could look. This schematic should only be considered as an example and its
structure will not be explained in detail. The PTC device is explained later in section
3.8.1 (page 65).
It is recommended to use a discrete circuit to solve this problem. A discrete
circuit fulfills the requirements of a general design and provides a low-cost solution.
Pin Requirements When Using the Recommended Sensor Power-Supply
It is specified that the power-supply needs to be monitored with a 10 Hz sampling
frequency. If the schematic in Figure 2.9 is used and if the requirement of sampling
frequency is fulfilled, this requires the system to be able to handle the signals in
Table 2.7.
Signal name
ADC_1
ADC_2
ADC_3
Type
ADC
ADC
ADC
Speed rate
Slow (S)
Slow (S)
Slow (S)
Note
VBAT
Output voltage
5 V battery
Table 2.7. This table presents the requirements on MCU pins if the schematic in Figure
2.9 is chosen as sensor power-supply.
As mentioned in the beginning of this section, 10 sensors will be used in the
system. Each sensor requires one power-supply circuit and therefore the system is
required to have no GPIO pin and 30 A/D pins as described in Table 2.8.
To sum up, 30 A/D pins are required for the sensor power-supply. According
to Table 2.7 all these are slow-rated signals. This information is summed up in
Table 2.9.
16
Input/Output Overview
Type
Number of sensor power-supplies
GPIO pins
A/D pins
Amount
10
0
30
Table 2.8. This table presents the number of I/Os that the sensor power-supplies require
the system to have.
A/D speed-rate
Slow
Intermediate
Fast
Amount
30
0
0
Table 2.9. This table presents the required sampling frequency of the A/D signals in
Table 2.8.
2.2.3
Sensor Output Monitor
To read the sensor’s value all sensor outputs have to be monitored. How this can
be done is investigated in this section.
Requirements
As mentioned earlier, the system is required to have a general design, which in
the case of sensors corresponds to that the system must be able to handle several
types of sensors. A sensor monitor has to monitor the outputs of different sensor
types.
A selection of different sensor types that the system has to be able to monitor
is presented in Table 2.10.
Sensor
E2A [29]
424.00A
424.01A [15]
424.06A
Producer
Omron
Elobau
Elobau
Elobau
Type
Proximity sensor
Angle sensor
Angle sensor
Angle sensor
Output
Frequencies up to 2kHz
1-5 V
4-20 mA
0.5-4.5 V
Table 2.10. This table presents a selection of sensors that the system has to be able to
monitor. The table presents the requirements that the system must fulfill in order to be
able to monitor the sensors.
The sensor monitor, as the sensor’s power-supply (see section 2.2.1 on page 14),
is required to have a general design that allows the sensor type2 to be changed
without requiring to redesign the system.
It has been specified in the business collaboration that a sampling frequency
of 100 Hz (that is intermediate-rated) is enough to monitor the sensors’ current
outputs and voltage outputs.
2 Within
the types listed in Table 2.10
2.2 Sensors
17
How can the system reach these requirements? One direct approach is to use
a discrete circuit.
Discrete Circuit
The schematic in Figure 2.10 could be used to monitor the sensor outputs.
TTL
Sensor
Output
Switch
ADC_1
MCU
ADC_2
Figure 2.10. This figure shows a discrete circuit which is suggested as sensor monitor.
The lower part (below the switch) of the schematic is used for current output sensors. The
upper part (above the switch) is used for voltage output sensors and also for frequency
output sensors.
The schematic contains a switch which is set depending on which type of sensor
is monitored. The functionality of the part below the switch is to handle current
output sensors. The functionality of the part above the switch is to monitor voltage
output and frequency output sensors.
It is possible to question if it would not be better to separate the schematics
for frequency monitoring and voltage monitoring. It might seem like a waste of
resources to have two pins (ADC_1 and MCU) connected to the output in the
top part of the schematic, because the sensor will either have voltage output or
frequency output. No sensor in Table 2.10 requires the system to monitor both
frequency and voltage to read the sensor’s value. However to split the frequency
monitoring and the voltage monitoring into two parts is not a good idea for the
following reasons:
• Reduces the degree of general design
• Takes away crucial error detection functions
The first point is easy to understand but the second point needs to be further
explained. The reason why a separation of the schematic would take away crucial
error detection is that, for example, the sensors with frequency output are required
to have voltage monitoring capabilities since this is the only way to detect if the
sensor is functional. How this works depends on the sensor. One example is a
sensor that has an internal pull-up which pulls the signal up to VBAT if the sensor
is broken. The only way to detect this is to monitor the sensor’s output voltage.
18
2.2.4
Input/Output Overview
Conclusion Sensor Monitor
In this section it has been investigated how to monitor the sensor outputs. It is
known that the system will have several different types of sensors. The system is
required to be designed generally enough so that the sensor type can be changed
without requiring a redesign of the system. To fulfill this requirement the schematic
in Figure 2.11 is proposed as a solution.
TTL
Sensor
Output
Switch
ADC_1
MCU
ADC_2
Figure 2.11. This figure shows a discrete circuit which is suggested as sensor monitor.
The lower part (below the switch) of the schematic is used for current output sensors. The
upper part (above the switch) is used for voltage output sensors and also for frequency
output sensors.
This schematic fulfills the system’s requirement of generality since it can monitor all required sensors. The schematic also fulfills the system’s requirement of
low cost since it only uses cheap discrete components.
Pin Requirements When Using the Recommended Sensor Monitor
If the schematic in Figure 2.11 is used as a solution, this requires the system’s
MCU to have the pins listed in Table 2.11.
Signal name
ADC_1
ADC_2
MCU
Type
ADC
ADC
GPIO
Speed rate
Intermediate (I)
Intermediate (I)
-
Note
Sensor output
Sensor output
Output frequency
Table 2.11. This table presents which signals the MCU has to have if the schematic in
Figure 2.11 is chosen as sensor monitor.
As mentioned in the beginning of this section, 10 sensors will be used in the
system. One monitor circuit will be connected to each sensor. As can be seen in
Table 2.11 each monitor circuit requires two A/D signals and one GPIO signal.
The required number of pins for all 10 sensor circuits can be seen in Table 2.12.
As can be seen in Table 2.12 the sensor monitor circuits require a total of 30
pins, of which 20 are A/D pins. According to the information in Table 2.11 all
2.3 Motors
19
A/D speed-rate
Number of sensor monitor circuits
GPIO pins
A/D pins
Amount
10
10
20
Table 2.12. This table presents the number of I/Os that the system has to handle to
use the proposed solution.
these 20 pins are of intermediate speed-rate.
A/D speed-rate
Slow
Intermediate
Fast
Amount
0
20
0
Table 2.13. This table presents the required sampling frequencies of the A/D signals in
Table 2.12.
2.3
Motors
In the beginning of this section it has been specified that the system will have 10
motors. One type of motor that will be used in the system is shown in Figure
2.12.
Figure 2.12. A photo of the DME34 motor from Nidec servo that will be used in the
system. [4]
This section about motors is divided into two parts:
• Motor driver
• Motor signal
2.3.1
Motor Driver
All motors require a driver in order to function. In this section the motor driver
is investigated.
20
Input/Output Overview
Requirements
Table 2.14 presents a selection of motors that the system has to be able to use.
Motor
DME34SA [13]
DME34BA [13]
Producer
Nidec servo
Nidec servo
Power-supply
12 V
12 V
Current
0.2 A
0.65 A
Table 2.14. This table presents the types of motors that will be used in the system.
One requirement on the motors is that they must be able to rotate both forwards and backwards. A very popular circuit for driving motors is the h-bridge
[12]. An h-bridge and its functionality are presented in Figure 2.13.
Figure 2.13. The area marked red in the figure presents an h-bridge. An h-bridge
provides functionality to rotate a motor both backwards and forwards. For forward
rotation switches S1 and S4 are closed while S2 and S3 are opened. For backwards
rotation switches S2 and S3 are closed while S1 and S4 are opened. [8]
Motors can be in three modes:
• Rotating forwards
• Rotating backwards
• Stopped
In a system with several motors it is possible that a group of motors always
will be in the same mode. If this is the case it is possible to reduce the number
for switches by letting some motors share common stage (i.e S1 and S2) in the
h-bridge.
To make the system robust the motor driver is required to be monitored. Both
the driver circuit’s output and the feedback current have to be monitored. The
following specification of sampling frequencies has been decided after discussions
with the business partner:
• Driver circuit output: 10 Hz (slow-rated)
2.3 Motors
21
• Feedback current monitor: 2 kHz (fast-rated)
Two approaches on how to fulfill the requirements of the motor driver are
investigated. These two approaches are:
• Circuit with PROFET
• Integrated circuit
Circuit with PROFET
It is known from the requirements of the motor driver, that motor drivers are
required to be able to rotate motors both forwards and backwards. This feature
can be provided with an h-bridge.
As discuss earlier it is possible that not all motors are required to have full
independent control. If e.g. some motors always will be in the same mode it is
possible to let these motors share common stage in an h-bridge. By doing this
several switches can be saved as can be seen in Table 2.15.
Type
Independent h-bridge
H-bridge with shared common stage
Required switches
4n
2+2n
Table 2.15. This table shows how many switches are required for an independent hbridge and for an h-bridge with common stage. The ”n” is the number of motors. Note
that the numbers of required switches for the shared common stage are only valid when
all motors are in the same h-bridge.
In Figure 2.14 it is illustrated how an h-bridge can look when two motors share
common stage. One limit due to this structure is that all motors in the same block
have to run in the same direction or not run at all.
The schematic shown in Figure 2.15 can be used to drive a motor. This
schematic will then correspond to one h-bridge stage.
The schematic in Figure 2.14 is simplified in order to give an overview of the
functionality of an h-bridge block. Figure 2.15 contain a more detailed schematic
of circuit used to drive a motor. The dashed black line in the figure corresponds
to one h-bridge stage in Figure 2.14. As can be seen in the figure this schematic,
as the solenoid driver, uses the BTS5236 device as a driver. Why this device is
chosen is discussed in the conclusion of the motor driver.
Survey of PROFETs
The devices found in the survey are shown in Table 2.16. During the survey it has
been noticed that it is difficult to find a PROFET that is better than the BTS5236
that was found in the survey of solenoid drivers.
Integrated Circuit
Another approach to construct a motor driver is to use an integrated circuit. Are
there ICs on the market that fulfill the requirements on the motor driver?
22
Input/Output Overview
VBAT
Motors
Figure 2.14. This figure illustrates how motors can share common stage in an h-bridge.
One limitation of this solution is that all motors in the same h-bridge block have to run
in the same direction or not run at all. The common stage is marked with the dashed red
line. Note that this figure is simplified and it does not provide the whole motor driver.
A detailed schematic of the area marked with the dashed black line is shown in Figure
2.15.
VBAT
IN1
IS1
BTS5236
Output
ADC_1
MCU
ADC_3
ADC_2
Figure 2.15. This figure illustrates how the motor driver could look if the PROFET
approach is used. The area marked by the dashed black line corresponds to the area
marked by the dashed black line in Figure 2.14.
Survey of ICs
The result of the survey is presented in Table 2.17.
2.3 Motors
23
Device
BTS5236
Producer
Infineon
Price
$1.3
MC10XS3412
Freescale
$4.5
L6370D
STMicroelectronics
$6.5
Note
Dual channels high-side
driver.
Two diagnostic
pins.
Quad channels high-side
driver. 16-bit SPI for diagnostic.
High-side driver
Table 2.16. This table presents a selection of PROFETs that fulfills the requirements
to drive the system’s motors. Note that this is the same devices as were found in the
survey of solenoid drivers (Table 2.1 on page 8).
Device
L9950
TLE8201
Producer
STMicroelectronics
Infineon
Price
$6
$6
Note
SPI for diagnostics
SPI for diagnostics.
Table 2.17. This table presents a selection of ICs found in the survey. Note that the
found devices are the same as the ones found in the survey of the solenoid driver. See
Table 2.2 (page 9) for more information.
Both ICs in Table 2.17 have built-in h-bridges. Both ICs also fulfill the requirements listed in Table 2.14 (page 20).
One big disadvantage of the ICs are the price. No cheaper ICs which fulfill the
system’s requirements were found in this survey.
2.3.2
Conclusion Motor Driver
The motor driver has been investigated in this section. The requirements of the
motor have been presented and also two approaches of how the system can fulfill
these requirements. The first approach is a circuit with PROFET and the second approach uses ICs with built-in h-bridges. For information of the difference
between PROFETs and ICs, please refer to the conclusion of the solenoid driver
(Section 2.1.2 on page 9).
Both approaches fulfill the system’s requirements. My recommendation is to
use the circuit with PROFETs which is illustrated in Figure 2.16. This approach is
cheaper than the IC approach, which goes well along with the desired requirement
of a low-cost system.
Pin Requirements When Using the Recommended Motor Driver
If the recommended PROFET approach illustrated in Figure 2.16 is chosen, the
system is required to be able to handle the signals presented in Table 2.18.
The hardware requirements of all 10 motor signals in the system can be seen
in Table 2.19. The table shows that there are 10 motors in the system and it is
known from Table 2.18 that each motor driver circuit has three A/D signals and
24
Input/Output Overview
VBAT
IN1
IS1
BTS5236
Output
ADC_1
MCU
ADC_2
ADC_3
Figure 2.16. This figure illustrates how the motor driver could look if the PROFET
approach is used. The area marked by the dashed black line corresponds to the area
marked by the dashed black line in Figure 2.14.
Signal name
ADC_1
ADC_2
ADC_3
MCU
IN_1
Type
ADC
ADC
ADC
GPIO
GPIO
Speed rate
Slow (S)
Fast (F)
Fast (F)
-
Note
Output voltage
High-side driver current
Low-side driver current
Low-side motor driver
Activate BTS5236 driver
Table 2.18. This table presents which signals the system has to handle if the PROFET
approach is chosen as motor driver. The signals can all be seen in the schematic in Figure
2.16 (page 24). Note that this numbers exclude the GPIOs needed to control the common
stage(s) in the h-bridge(s). Two GPIO pins per h-bridge are required.
two GPIO signals. The total pin requirement of the motors is presented in Table
2.19.
A/D speed-rate
Number of motors
GPIO pins
A/D pins
Amount
10
20
30
Table 2.19. This table shows the required number of pins if the schematic in Figure
2.16 is chosen as motor driver.
According to Table 2.19 a total of 50 pins are required for the motor I/Os and
30 of these pins are ADC pins. Of these 30 ADC pins, 20 are fast-rated and 10
2.3 Motors
25
slow-rated. This information is summarized in Table 2.20.
A/D speed-rate
Slow
Intermediate
Fast
Amount
10
0
20
Table 2.20. This table presents the required sampling frequency for the A/D signals in
Table 2.19.
2.3.3
Motor Signal
The motor signal is investigated in this section. The goal is to see what kind of
information it is possible to get from the motor signals. It is also investigated which
requirements the system has to fulfill in order to get the necessary information from
the motors.
Motor Waveform
Figure 2.17 presents a waveform of when a motor is rotating forwards and Figure
2.18 presents a waveform of when a motor is rotating backwards. From Figure
2.16 (page 24) it is known that the motor outputs will be monitored. What kind
of information will the system be able to monitor?
160
140
Voltage (mV)
120
100
80
60
40
20
0
0
5
10
15
20
25
time (ms)
30
35
40
45
50
Figure 2.17. Waveform of when a motor rotating forwards.
First of all, it will be possible to determine if the motor is working properly by
measuring the voltage. This because a broken motor is likely to have a voltage of
VBAT or of 0 V depending on the internal structure.
26
Input/Output Overview
160
140
Voltage (mV)
120
100
80
60
40
20
0
0
5
10
15
20
25
time (ms)
30
35
40
45
50
Figure 2.18. Waveform of when a motor is rotating backwards.
Our business partner has specified that it is possible to calculate traveled distance3 if the system is able to count the number of waveform ripples. What are
the requirements that the system has to fulfill to be able to count the number of
ripples?
Requirements
Measurements in Figure 2.17 and Figure 2.18 shows that the smallest ripple swing
occurs when the motor is rotating forwards. This smallest ripple swing sets the
toughest requirements on the system and it is therefore interesting to measure this
swing to see what the requirement for the system is count the ripples.
Measurements of the waveform in Figure 2.17 gave the following waveform
properties:
• Fastest ripple-frequency ≤ 500 Hz
• Ripple peak voltage ≥ 2 mV
The measured maximum frequency of 500 Hz is no problem4 for the system
to handle. The ripple swing of 2 mV can however be problematic to detect. One
ripple has to be sampled several times in order to safely detect the swing (or at
least a sufficiently accurate approximation of the swing). It is hard to say how
small voltages the system has to be able to measure to accurately measure the
swing. I assumed that the system has to be able to detect voltages that are at
least four to five times smaller than 2 mV to be able to count ripples accurately.
How small voltage differences can the system detect?
3 In fact the traveled distance is then calculated indirectly by counting the number of motor
turns.
4 See section 3.2.1 on page 32
2.3 Motors
27
Assume that one ripple has to be sampled five times and that off-the-shelf
ADCs typically have an A/D resolution of 10 bit5 . If it is assumed that ADCs
measure a swing of 3.3 V, this means that the smallest voltage that the ADCs can
detect is 3 mV (see equation 2.1). This is not even close to be enough to detect a
2 mV peak accurately.
3.3
3.3
=
≈ 3 mV
(2.1)
210
1024
If these assumptions are correct it is not possible to measure a 2 mV ripple
swing directly with an ADC. If it is wanted that the system can measure this swing
this issue has to be solved in another way.
One other approach of how to measure the swing is to use a differentiator (see
Figure 2.19) to get the derivative of the voltage waveform.
R
C
Vin
Vout
Figure 2.19. This is a differentiator. This circuit makes it possible for the system to
measure the derivative of the input signal. In this way any resolution problem of the
ADC will not be an issue since the output voltage can be scaled to a desired value (see
Equation 2.4).
The differentiator circuit uses the capacitor’s properties to derivate the input
signal. By using this circuit the system is not required to be able to measure small
voltages to count the number of ripples in the motor waveform. An illustration of
how the differentiator works can be seen in Figure 2.20.
Phase
1
2
3
(a) Output without differentiator
Phase
1
2
3
(b) Output with Differentiator
Figure 2.20. This figure illustrates how a differentiator works. The differentiator can
be used in the system to ease the requirement of ADC resolution. Note that the output
with differentiator can be scale to a suitable range according to Equation 2.4.
According to Equation 2.4 it is possible to scale the output by changing the
resistor’s size in the circuit. In this way it is possible to scale the output to a range
where the ADC can detect the voltage level.
5 See
Table 3.4 on page 33
28
Input/Output Overview
dV
dt
V
Ohm’s law: I =
R
dV
2.2, 2.3 ⇒ Vout = −RC
dt
Capacitance current to voltage relationship: I = C
2.4
(2.2)
(2.3)
(2.4)
Input/Output Signal Summary
In Table 2.21 below there is a summary of the I/O investigations done in this
chapter. As can be seen in the table, the system is required to have a total of 152
pins (108 A/D pins and 44 GPIO pins).
Most modern MCUs have 8 to 40 A/D pins6 . Based on this information it is
clear that it needs to be investigated if it is possible to lower the required amount
of ADC pins or if it can be solved in another way.
Type
GPIO pins
ADC pins
Total number of pins
Amount
44
108
152
Table 2.21. A summary of the I/Os needed for the sensors, the solenoids and the motors.
Note that in addition to the GPIOs listed in this table, two GPIO pins per h-bridge are
required.
It is also important to know the nature of all these 108 ADC pins. Therefore
the information about the A/D signals’ speed-rates is summed up in Table 2.22.
Type
Total number of ADC pins
A/D speed rate
Slow
Intermediate
Fast
Amount
108
Amount
54
20
34
Table 2.22. Known from Table 2.21 is that the system will have at least 108 ADC
signals. In this table the required sampling frequencies of these signals are presented.
6 See
Table 3.4 on page 33
Chapter 3
System Research
In this chapter the requirements of an ECU are investigated. The previous chapter
focused on the I/Os and this chapter will focus on internal parts of the ECU.
Problems that the ECU has to face is also investigated. After the presented
problems, it is examined how to solve these problems.
The problems are divided into sections according to which subsystem of the
ECU they belong to.
As the report continues it will become clearer which subsystems have to be
focused on more deeply than others. The depth were then decided after discussions
with the business partner.
Each subsystem will, if suitable, be approached according to the following steps:
1. The subsystem will be regarded as a black-box. Inputs, outputs and the
functionality of the black-box will be described.
2. Requirements of the black-box will be investigated.
3. Problems that need to be solved or investigated will be specified.
4. A survey will be done to see what kind of off-the-shelf devices are available on the market. The performance and the cost of these devices will be
investigated.
5. Solutions to the specified problems will be investigated. My recommended
solution will be presented.
6. An overview of the subsystem’s requirements of MCU pins will be presented.
Each section of a subsystem will also contain a conclusion where the results of
the investigations are presented.
29
30
System Research
3.1
ECU Overview
A black-box representation of the ECU is illustrated in Figure 3.1. The main
subsystems can be seen in the figure (that is the MCU, the ADC and the sensor).
Note that these subsystems themselves can contain more subsystems.
The figure also shows which external I/Os that is connected to the ECU. The
MCU’s task is to control these I/Os so that the ECU work as intended. If anything
in the ECU does not work as intended, it is crucial to detect the incorrect behavior.
Solenoids
Sensors
Motors
I/Os
Temperature
Sensors
Multiplexers
Acceleration
Sensors
ADCs
Water
Sensor
Memory
Block
MCU
Power-Supply
Block
CAN
Interface
Other
MCUs
ECU
System Battery
Figure 3.1. An overview of the system. The illustration shows the ECU’s main components and the system’s I/Os. Note that this figure only gives an overview of the system.
3.1.1
MCU Overview
(a) The LPC292x
from NXP [5]
(b) The MPC5567
from Freescale [6]
(c) The STM32 from
STMicroelectronics
[7]
Figure 3.2. A selection of MCUs that are possible choices as the MCU in the electrical
control unit.
Discussions in the business collaboration have resulted in list of which MCUs
3.2 Analog-to-Digital Converter (ADC)
31
that are suitable for an ECU. The list is presented in Table 3.1. The prices listed
in the table should not be considered as exact numbers. They are only listed here
for comparison purposes only.
MCU
MPC5534 [31]
MPC5554 [32]
MPC5567 [30]
LPC1768 [25]
LPC2939 [26]
STR912 [35]
STM32F103 [37]
Producer
Freescale
Freescale
Freescale
NXP
NXP
STMicroelectronics
STMicroelectronics
Approximate price
$15
$35
$40
$10
$15
$15
$10
Table 3.1. Suitable MCUs that can be used in an ECU. The table also lists the producer
of each MCU and the approximate market price of MCU.
Our business partner has informed that the MCUs in Table 3.1 are common
choices within the agricultural industry. No other MCU, than the ones in the
table, is investigated in this report.
3.2
Analog-to-Digital Converter (ADC)
The analog-to-digital converters are a crucial part of the system. This section
aims to give a first (rough) estimate of the requirements of the A/D converters.
This estimate will also give an idea of what kind of performance (speed, number
of pins, resolution etc.) is possible to receive from the A/D converters.
It is likely that more requirements will be added after investigations in later
sections but this first estimate is still necessary in order to decide where the focus
should be in this report. As an example, if investigations later in this chapter
show that requirements from Chapter 2 are too demanding for a straightforward
solution, the focus will be to investigate whether it is possible to lower these
requirements.
3.2.1
Requirements
What are the requirements on the ADC subsystem? As a start, the ADC subsystem will be considered to be a black-box as can be seen in Figure 3.3. Note that
the ADC block in the figure could contain several A/D converters.
From section 2.4 (page 28) it is clear that the system has to have support for
at least 108 ADC channels. Speed requirements of the slow-, intermediate- and
fast-rated signals are also described in that section. This information is compiled
in Table 3.2.
32
System Research
28
30
ADC Block
108
20
30
Solenoids
Sensor
Power-Supply
Sensor
Monitor
Motors
I/O Block
Figure 3.3. A black-box illustration of the ADC subsystem. The figure shows the
number of A/D signals, from the I/O block, that are specified so far in this report. (see
Chapter 2 for more information about these A/D signals.
Type
Total number of A/D pins
A/D speed rate
Slow
Intermediate
Fast
Amount
108
Amount
54
20
34
Table 3.2. This table shows the number of A/D signals that the system has to interact
with. The sampling-speed requirements of the signals are also shown in the table.
Speed Requirement
The slow-rated signals are required to be sampled with a speed of 10 Hz. This is
equivalent to a sample period of 100,000 µs. According to Table 3.2, the system has
54 slow-rated signals. The system therefore has to sampled one slow-rated signal
at least every 1850 µs in order to sample all slow-rated signals in the required
sampling period of 100,000 µs.
The intermediate-rated signals are required to be sampled with a frequency of
100 Hz, which equivalent to that the intermediate-rated signals have a required
maximum sampling period of 10,000 µs. The system has 20 intermediate-rated
signals according to Table 3.2. Thus the system needs to sample one intermediaterated signal at least every 500 µs.
The fast-rated signals are the ones setting the limit for the maximum sample
period of the system. They are required to be sampled with a speed of at least 2
kHz. This is equal to a maximum sample period of maximum 500 µs.
To sum up, one slow-rated signal has to be sampled every 1850 µs and one
intermediate-rated signals every 500 µs. According to Table 3.2 there are also
34 fast-rated signals in the system. All these have to be sampled in one sample
period. Since the minimum requirements are of interest, I assume that 36 signals
(34 fast-, one intermediate- and one slow-rated) signals have to be sampled within
one sample period.
The system has to sample 36 signals in 500 µs and the system therefore needs
3.2 Analog-to-Digital Converter (ADC)
33
to be able to perform an A/D conversion in at least ≈ 13 µs. This is if the system
has one ADC core. If more cores are available, the required conversion speed will
be lower.
Pin Requirement
It is clear from Table 2.22 (page 28) that the system requires a minimum of 108
ADC pins. As mentioned before in this chapter, this only states a minimum
requirement. It is likely that even more ADC pins will be required after investigations in later sections.
Resolution Requirement
The required ADC resolution is hard to specify since not all applications, where
an ADC is needed, are investigated at this point. It is however clear that the
higher resolution the better it is. As was shown in 2.3.3 (page 26) it is sometimes
possible to design a custom solution which lowers the resolution requirement.
The ADC’s requirements are compiled in Table 3.3.
Type
Total number of A/D pins
Minimum A/D conversion time
Amount
108
13 µs
Table 3.3. The requirements of the ADC subsystem. Note that these numbers are
based on the investigations up to this point. It is likely that the A/D pin requirement
will change after coming investigations.
3.2.2
Survey of MCUs
The results of the survey of MCUs are presented in Table 3.4.
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
ADC cores
2
2
2
1
3
1
2
ADC pins
40
40
40
8
16
8
32
Information
2.5 µs, 10 bit resolution
2.5 µs, 10 bit resolution
2.5 µs, 10 bit resolution
1.0 µs, 12 bit resolution
2.44 µs, 10 bit resolution
0.7 µs, 10 bit resolution
1.17 µs, 12 bit resolution
Table 3.4. An overview of the performance of the available MCUs (that is the MCUs
listed in Table 3.1 on page 31).
34
3.2.3
System Research
Conclusion Analog-to-Digital Converter
The system is required to have at least 108 ADC pins (see Table 3.3 on page 33).
This is an extremely high requirement of ADC pins and none of the MCUs in
Table 3.4 satisfies this requirement. This is an issue that has to be investigated
since the MCUs in the table, are the only possible MCU choices.
One way to solve this issue with the high number of required ADC pins, is to
introduce multiplexers. This approach is illustrated in Figure 3.4.
MCU
ADC
Block
I/O
Block
Figure 3.4. One way to solve the problem with the high number of A/D pins in the
system is to introduce multiplexers. This figure shows one possible configuration.
Introducing multiplexers will add additional delay to the conversion times,
shown in Table 3.4, due to multiplexers’ switching times and delay of the control
pins needed to control the multiplexers. Because of the new delay added by multiplexers, it is not yet possible to say which ADCs, if any, that fulfills the speed
requirements.
It is clear that multiplexer approach will have to be investigated to solve the
problem with the high number of ADC pins. This will be investigated in the
following section.
As stated in Table 3.2, a system with one ADC core needs to perform an A/D
conversion in at least 13 µs. If the system has more cores, the available A/D
conversion time will be higher. As can be seen in Table 3.4, the slowest ADC
found in the survey has a conversion time of 2.5 µs. This gives plenty of headroom
up to the minimum A/D conversion requirement of 13 µs.
3.3
Multiplexer
Multiplexers can be used in many situations to increase the total amount of pins
available. In this section it is investigated how different multiplexer choices affect
the total pin-count of the ADC subsystem. This section will also see how the
extra A/D conversion delay, caused by multiplexers’ switching times and ADCs
control-pin’s delay, affect the A/D conversion time requirement.
3.3 Multiplexer
MCU
35
MCU
ADC
Block
108
signals
I/Os
(a) A/D conversion without multiplexers
I/Os
ADC
Block
Multiplexer
Control Pins
108 signals
Multiplexers
(b) A/D conversion with multiplexers
Figure 3.5. A/D conversion with and without multiplexers connected to the ADC.
3.3.1
Structures
It is known that the system has to have at least 108 ADC pins. Different MCUs offers different ADC structures (see Table 3.4 on page 33). For the sake of simplicity
only three different structures are investigated.
These three structures are:
• ADC structure 1: One ADC core and eight pins.
• ADC structure 2: Two ADC cores and 16 pins.
• ADC structure 3: Two ADC cores and 32 pins.
Two solutions for each structure will be proposed; one with a minimum number
of pins and the other with a higher number of pins. The reason why a solution
with a higher number of pins is proposed is that the requirement of 108 ADC pins
is likely to be increase after investigations of other subsystems.
These investigations are based on three assumptions:
• All multiplexers are of 2n -to-1 type.
• Only 8-to-1, 16-to-1 and 32-to-1 multiplexers are available.
• All ADC pins, available from the core, are connected to the same type of
multiplexers.
It is possible to arrange the multiplexers in different structures. These investigations starts with the one layer approach.
Multiplexers in Layer 1
All multiplexers, in this section, are placed in Layer 1.
ADC structure 1
The ADC structure 1 has eight ADC pins and therefore at least a 16-to-1 multiplexer is needed to reach the minimum requirement of 108 pins. To get a higher
pin count a 32-to-1 multiplexer has to be used.
36
System Research
Layer 1 Layer 2
ADC
Block
Figure 3.6. Multiplexers can be arrange in different layers.
Multiplexer type
16-to-1
32-to-1
Amount
8
8
Control pins needed
32 (4 · 8)
40 (5 · 8)
Pin count
128 (8 · 16)
256 (8 · 32)
Table 3.5. This table shows how many ADC pins the system can have when using
multiplexers. This table assumes that the ADC has eight pins.
ADC structure 2
The ADC structure 2 has 16 ADC pins and therefore it is enough with an 8-to-1
multiplexer to satisfy the minimum requirement of 108 ADC pins. To achieve an
even higher pin count, a 16-to-1 (or higher) multiplexer can be used.
Multiplexer type
8-to-1
16-to-1
Amount
16
16
Control pins needed
48 (3 · 16)
64 (4 · 16)
Pin count
128 (16 · 8)
256 (16 · 16)
Table 3.6. This table shows how many ADC pins the system can have when using
multiplexers. This table assumes that the ADC has 16 pins.
ADC structure 3
32 ADC pins are available in ADC structure 3 and therefore it is enough with a
4-to-1 multiplexer. This type of multiplexer is however assumed to be unavailable
and also undesired since very few pins are saved with such a small multiplexer.
The smallest multiplexer available, according to the assumptions, is an 8-to-1 multiplexer. If a higher pin-count is desired, it is possible to use a 16-to-1 multiplexer.
This one-layer solution is clearly a good choice. All three ADC structures can
reach a pin count of at least 256. This is assumed to be enough since the system’s
minimum requirement so far is 108 ADC pins. If investigations of other subsystems
show that more than 256 ADC pins are required, it is possible to add a second
3.3 Multiplexer
Multiplexer type
8-to-1
16-to-1
37
Amount
32
32
Control pins needed
96 (3 · 32)
128 (4 · 32)
Pin count
256 (32 · 8)
512 (32 · 16)
Table 3.7. This table shows how many ADC pins the system can have when using
multiplexers. This table assumes that the ADC has 32 pins.
layer of multiplexers to increase pin count. At the moment it is assumed that
256 pins will be enough and therefore it is not necessary to investigate a two-layer
approach. If later investigations show that a higher pin count is needed, then the
two-layer solution will be investigated.
What can be seen in the tables in this section, is that a high number of control
pins are needed to control the multiplexers. The control pins will consist of the
MCU’s GPIO pins. When using multiplexer many GPIO pins could be saved if it
is possible to group some A/D signals together in such a way that the number of
needed control pins is reduced. This will however not be investigated before it is
known if GPIO pins will be an issue or not.
3.3.2
Requirements
It is known from Table 3.3 (page 33), that an A/D conversion must be done in at
least 13 µs. What speed requirements does this put on the multiplexer(s)? What
are the minimum requirements on the system’s A/D conversion time?
The slowest ADC in Table 3.4 (page 33) performs an A/D conversion in 2.5
µs. The multiplexers therefore have 10.5 µs to execute. This is the time the
multiplexers have to switch to the correct inputs. It is not only the switching
of the multiplexer that consumes time. Additional delays are introduced by the
multiplexers’ control pins delay and the delay caused by wiring.
Pin Delay
The pin delay is the time it takes for a pin to change its output.
Very few MCUs have their pin speed specified in their datasheets or reference
manuals. The STM32F103 is the only MCU found that has its pin speed specified
in the data sheet. The STM32F103’s pin speed is specified to ≤ 0.5 µs. It is likely
that the other MCUs’ pins are approximately as fast as the STM32F103’s pins
and therefore 0.5 µs will be the pin delay used in the calculations.
In addition to the control pin delay, there is also an additional wiring delay. I
assume that the delay of the control signal (pin delay and wiring delay) is in total
1.0 µs.
3.3.3
Survey of Multiplexers
In Table 3.8 a selection of typical low-priced multiplexer can be seen. The most
interesting property of the multiplexers is the switching time because this will
affect the A/D conversion time. As can be seen in the table, these multiplexers
38
System Research
have switching times ranging from 8 ns up to 110 ns. These switching times
can be neglected1 because of their relative size compared to the A/D conversion
time(≤ 2.5 µs). It is clear that the switching time of the multiplexers has little
affect when choosing which multiplexer to use.
Device
Producer
CD74HC4067 [20]
ADG706/707 [14]
SN74LV4051A [21]
Texas Instruments
Analog Devices
Texas Instruments
Channels Switching
time
16
110 ns
16
60 ns
8
8 ns
RON
240 Ω
12 Ω
100 Ω
Table 3.8. An overview of performance of the off-the-shelf multiplexers found in the
survey.
3.3.4
Multiplexer Delay
As stated in Table 3.3 (page 33), an A/D conversion time of 13 µs is enough to
reach the system’s requirements. Is it possible to reach this conversion time by
using multiplexers to increase the ADC pin-count?
If the slowest ADC and the slowest multiplexer are chosen among the ones listed
in tables 3.4 and 3.8, the total conversion will be 3.56 µs according to equation
3.1.
2.5 µs + 110 ns + 1 µs = 3.61 µs
(3.1)
3.61 µs is well below the requirement of 13 µs. It is therefore clear that
introducing multiplexers will not cause the system to fail the A/D conversion
speed requirement.
3.3.5
Fastest Conversion Rate
The fast-rated signals are, as known from Chapter 2, required to be sampled in at
least 2 kHz. What if the system would have to sample a signal in an even higher
sampling frequency? How fast can the system execute an A/D conversion?
To investigate this I consider the case when a new signal is introduced in the
system. How fast is the system able to A/D convert this new signal?
Assumptions:
• The system has one ADC core with eight pins.
• A 16-to-1 multiplexer is connected to each ADC pin.
• The system has a total conversion time is 3.61 µs.
• The sample period is 500 µs.
1 Multiplexer
switching time is only between 0.3% and 2.4% of the ADC conversion time
3.4 General Purpose Input/Output (GPIO)
39
• The system needs to sample 36 signals, in every sample period, before the
new signal is added.
The system requires approximately 130 µs to sample 36 signals with an A/D
conversion time of 3.61 µs.
This leaves 370 µs of available sampling time. If maximum sampling frequency
is wanted, the system can sample the new signal during all the remaining time.
In this time the system can, according to equation 3.2, sample the new signal
approximately 100 times.
370µs
≈ 100
(3.2)
3.61µs
If these sample periods are assumed to be evenly distributed over the sampling
period of 500 µs, it means that the new signal can be sampled every 5 µs.
5 µs corresponds to a sampling frequency of 200 kHz which then is the systems
fastest possible conversion speed.
This investigation shows that it is possible for the system to sample a signal
much faster than the highest A/D conversion speed requirement of 2 kHz.
3.3.6
Conclusion Multiplexer
The investigations done in this section show that it is possible to solve the problem
with the requirement of at least 108 ADC pins. This can be done by introducing
multiplexers connected to the ADC pins.
The use of multiplexers to increase the total pin count of the ADC will not
cause the system to fail the A/D conversion speed requirement of 13 µs. Even
when using multiplexers, there is still plenty of headroom up to the maximum
requirement of 13 µs. Since that there is plenty of headroom up to the maximum
A/D conversion time it is possible to freely choose ADC 2 without any concern to
the multiplexer’s switching time.
What might be an issue is the required number of multiplexer control pins. Investigations in this section have shown that up to 128 control pins can be required,
depending on the chosen ADC structure. This has to be investigated further before it is possible to determine if the required amount of control pins, is an issue
or not.
Since no critical speed deterioration is introduced and since the number of
A/D channels is significantly increased, with the use of multiplexers, I strongly
recommend to use multiplexers to increase the number of A/D channels in the
system. This assumes that the high number of multiplexer control pins will not
be an issue. This will be investigated in section 3.4.3 (page 42).
3.4
General Purpose Input/Output (GPIO)
GPIOs are going to be used in many places in the system. They are needed to turn
switches on and off, to select ICs with the chip-select signal, to switch multiplexers
2 Within
the assumptions done in this section
40
System Research
and so on. An overview of the system, with the respect of GPIOs, can be seen in
Figure 3.7.
Multiplexer
control pins
Sensor
Monitor
10
Solenoid
Driver
14
Motor
Driver
20
X
MCU
PCB
Figure 3.7. An overview of the GPIOs that were investigated in Chapter 2. The figure
should not be considered to be a final GPIO overview since it is likely that more GPIOs
will be added as the investigation of the system continues. The ”X” in the figure between
the MCU and the multiplexer control pins show that the number of GPIOs needed to
control the multiplexers are unknown at the this stage of the system research.
This section deals with the requirements of GPIOs that is known so far. It is
likely that more GPIOs will be required after investigations of other subsystems.
This section’s goal is to give a rough estimate of the GPIO requirements. Only
the requirement of the number of GPIO pins is investigated. The speed of the
GPIO pins is not investigated since their speed is assumed to be fast enough for
basic, non-time-critical, tasks.
3.4.1
Requirements
Requirements from previous investigations are compiled in Table 3.9.
Part
Sensor monitoring
Sensor power supply
Motor circuit
Solenoid circuit
Multiplexer control pins
Total
Amount
10
0
20+2n, n ≤ 10
14
Between 32 and 128
Between 76 and 192
Table 3.9. The required number of GPIO pins. This information is compiled from
previous investigations. ”n” is the number of h-bridges used to drive the motors. See
Chapter 2 for more information about h-bridges.
If all the motors circuits3 are assumed to be placed in separate h-bridges, it
3 Discussed
in section 2.3.1 on page 19
3.4 General Purpose Input/Output (GPIO)
41
increases the requirement of GPIOs from 44 pins to 64 pins (there are ten motor
circuits which all need four MCU pins each when they are in separate h-bridges).
By using multiplexers, in order to increase the number of A/D channels, the
required number of GPIOs is further increased. As can be seen in Table 3.9 between
32 and 128 multiplexer control pins are needed, depending on which multiplexer
and which ADC structure is chosen. In order to investigate if the number of
GPIO pins will be an issue or not, the system is assumed to be required to have
128 multiplexer control pins.
3.4.2
Survey of MCU GPIO pins
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
Producer
Freescale
Freescale
Freescale
NXP
NXP
STMicroelectronics
STMicroelectronics
GPIO pins
≤ 149
≤ 214
≤ 178
≤ 70
≤ 152
≤ 80
≤ 80
Table 3.10. An overview of the maximum number of GPIO pins that the available
MCUs in Table 3.1 (page 31) have.
The numbers of GPIO pins in Table 3.10 are all stated as ”less than or equal
to” because all MCUs have built-in multiplexers. With these multiplexers it is
possible to choose among different functionalities of a pin. As an example, a pin
can be initialized as a GPIO or as a SPI pin.
From Table 3.9 it is known that, depending on system configurations, up to 192
GPIO pins are needed. This is assuming that full control over the multiplexers is
needed and that ADC structure 2 is chosen. Without anything being done about
the high number of control pins, the possible MCU choices is severely limited since
only one MCU can meet the requirement of 192 GPIO pins. It is therefore clear
that the high number of GPIO pins can be a big issue for the system. Therefore
it has to be investigated if it is possible to decrease the required number of GPIO
pins.
Since the multiplexer control pins consumes the most GPIO pins I start with
investigating if they can be reduced.
One way to reduce the number of multiplexer control pins is by connecting all
multiplexers to the same control signals. As an example, if 16-to-1 multiplexers
are used, only four control signals are needed in total. This regardless of how
many multiplexers are used in the system.
Is there any problem with this approach? This is investigated in the following
example.
42
System Research
Example
As before it is assumed that an A/D conversion can be executed in 3.56 µs.
Assume that the system has one ADC core, eight ADC pins and one 16-to-1
multiplexer connected to each pin. This gives a total of 128 pins4 . Can all these
be converted within the required maximum sample period of 500 µs?
128 · 3.56µs ≈ 456µs < 500µs
(3.3)
Equation 3.3 shows that it is possible but it also shows that it is not possible
to use bigger multiplexers than 16-to-1 multiplexers, if all signals have to be converted within one sample period. Of this reason it is not recommended to design a
system with more than 128 A/D channels to each ADC if it is possible to avoid. If
it is avoided, it is known that it is possible to sample all connected signals within
one sample period.
It is possible, as mentioned before, to reduce the 128 needed control pins down
to only four by connection all multiplexers to the same control pins. The drawback
is that it reduces the controllability of the multiplexers down to a minimum. The
pros and cons of flexibility vs controllability are discussed in section 3.4.3.
3.4.3
Flexibility Vs Hardware-Resources
As known from Table 3.9, the multiplexers require between 32 and 128 control pins
depending on which configuration is chosen. It is possible to reduce this number
with multiplexers sharing control pins. This gives the system less controllability
since it can not switch each multiplexer independently. An illustration of two
16-to-1 multiplexers sharing control pins is shown in Figure 3.8.
MCU
Control pins
Figure 3.8. Here it is illustrated how GPIO pins can be saved by sharing control pins
between two 16-to-1 multiplexers.
This section aims to investigate pros and cons with different degrees of controllability and to propose a suitable configuration for the system. This section
only deals with the flexibility vs hardware-resources when considering ADC pins
and the connected multiplexers.
4 16
· 8 = 128
3.4 General Purpose Input/Output (GPIO)
43
Requirements
First of all, it is important to investigate which signals the multiplexers will be
connected to and how often they have to be sampled. This is already done in
Chapter 2 and a summary of the conclusions in that chapter can be seen in Table
3.11.
A/D speed-rate
Slow
Intermediate
Fast
Amount
54
20
34
Frequency
10 Hz
100 Hz
2 kHz
Table 3.11. This table shows how many A/D signals that are present in the system.
The table also presents the signals’ minimum sample frequency. This is a summary from
Chapter 2.
The system does not require these signals to be sampled in any specific order.
The only requirement is the signals’ sampling frequencies.
Full flexibility is not needed for the system since no signal has specific predecessors or successors. It is useful to investigate which degree of controllability that
is needed for the system to have enough flexibility to work.
Degree of Controllability
Which degree of controllability the system needs to have in order to function, is
best investigated with an example.
Example
This example assumes the following:
• The system has one ADC core with eight ADC pins.
• Each ADC pin has a 16-to-1 multiplexer connected to it.
• The maximum sampling period is 500 µs.
• One A/D conversion can be done in 3.61 µs.
In order to decrease the degree of needed controllability, it is beneficial to
distribute the speed-rated signals equally over all the multiplexers. This requires
less switching than if, e.g. all fast-rated signals to a few multiplexers. With even
distribution one multiplexer would have a distribution of signals as in Table 3.12.
If the system wants to sample all its fast-rated signals, it can do so by sampling from position 0 to position 4. If the system instead wants to sample all its
intermediate-rated signals, it samples from position 6 to position 9.
As mentioned earlier the system does not require a specific signal to have a
specific predecessor or successor. The only requirement is the sampling speed of
the different signals (see Table 3.11). If the system is designed so, for example, all
fast-rated signals are connected from position 0 to position 4. It is then possible
44
Position
Ex. 1
Ex. 2
System Research
0
F
F
1
F
F
2
F
F
3
F
F
4
F
_
5
_
_
6
I
I
7
I
I
8
I
I
9
_
I
A
_
_
B
S
S
C
S
S
D
S
S
E
S
S
F
S
_
Table 3.12. Two examples of how the signals could be distributed on a multiplexer.
With an even distribution the number of switches is reduced. The speed-rates are defined
as: F : Fast-rated; I : Intermediate-rated; S : Slow-rated.
to sample these positions, for example, 20 times more often than the intermediaterated signals in order to fulfill the signals’ speed requirements.
Conclusion Flexibility Vs Hardware-Resources
The pros and cons of different degrees of multiplexer controllability have been
investigated in this section. The conclusion of the investigations are that since
signals do not have to be sampled in a specific order, there is no need for the
system to be able to switch each multiplexer independently. Investigations show
that it is possible letting all multiplexer share the same control signals, while
still fulfilling the A/D conversion time requirement. With all multiplexers sharing
control pins, as few as three to five pins are needed5 . This is a significant gain
compared to when all multiplexers have separate control signals which requires up
to 128 control pins.
It is known that the requirement of the number of GPIO limits the possible
choice of MCU significantly, if nothing is done to reduce the number of required
GPIOs.
Of these reasons I recommend a multiplexer structure with minimum controllability since there is no benefit for the system to have more controllability than
the minimum. There is nothing to gain by being able to control each multiplexer
independently. On the other hand there are significant savings of GPIO pins if all
multiplexer share control pins.
Pin Requirements When Using the Recommended Solution
The pin requirements of the proposed solution, with minimum multiplexer controllability, can be seen in Table 3.13.
Type
8-to-1
16-to-1
32-to-1
Control pins
3
4
5
GPIO pins required
4
5
6
Table 3.13. This table shows how many control pins that the MCU needs to control
the multiplexers that are connected to ADC pins. This numbers are valid when using
the recommended solution, that is all multiplexers share control pins, is chosen.
5 Depending on the chosen multiplexer. In this case multiplexers are assumed to be 8-to-1,
16-to-1 or 32-to-1,
3.5 Controller Area Network (CAN)
3.4.4
45
Chip Select Signal
The new system is likely to consist of many ICs (e.g. multiplexers, CAN-bus
driver etc.). All these ICs require a chip select/enable signal. With this signal it
is possible to turn the IC on and off. This main feature, with this signal, is that
it makes it possible to save power by turning off unused ICs. The system’s power
consumption is not an issue but hardware resources are. If it is possible to reduce
the number of GPIOs needed for chip selects, it should be done.
Since power consumption is not an issue while hardware resources are, it is
recommended to connect all chip selects to the same GPIO pin. In this way all
ICs, connected to this pin, will turn on and off at the same time. This does not
inflict any problem for the new system since it has no benefit of activating only a
subset of all ICs. The drawback is that unused ICs will consume more power than
if they were turned off.
3.4.5
Conclusion General Purpose Input/Output
Investigations in this section show that up to a total of 192 GPIO pins are required
so far. 128 of these 192 pins, are multiplexer control signals. Investigations also
show that the multiplexers can all share the same control pins. This reduces the
number of needed control pins significantly (see Table 3.13).
I strongly recommend letting all multiplexers share control pins. It saves many
GPIO pins, while not putting any critical restriction on the system. The system
is still able to sample the A/D signals with enough controllability for the system
to function. If the multiplexers do not share control pins, the possible choice of
MCU is severely limited.
It is also strongly recommended, as discussed in section 3.4.4, letting all chip
select signals to share GPIO pin.
Pin Requirements When Using the Recommended Solution
The pin requirement of the GPIO subsystem is listed in Table 3.14. Note that
the numbers, used in the table, is the maximum requirement according to investigations so far. Further investigations are likely to show that more GPIOs, than
listed in the table, are required.
3.5
Controller Area Network (CAN)
In this section it is investigated how problems on the CAN-bus can be detected.
The CAN-bus is the standard communication protocol in the automotive industry. An agricultural vehicle can consist of several ECUs and in such a system
a CAN-bus is used to communicate between MCUs in the different ECUs.
To investigate the requirements of the CAN-bus a CAN-driver is chosen. This
driver the TJA1041 [24] CAN driver from NXP is according to the business partner
a suitable CAN-driver for ECUs.
46
System Research
Type
GPIO pin
GPIO pin
GPIO pin
GPIO pin
GPIO pin
Total GPIO pins
Part of system
Multiplexer control pins
Chip selects
Sensor monitoring
Motor circuit
Solenoid circuit
Amount
6
1
10
40
10
67
Table 3.14. This table shows how many GPIO pins that the MCU needs to have
according to the investigations done so far. It is likely that more GPIOs are required
after later investigations. This table also shows which part of the system that consumes
GPIO pins. Note that it is here assumed that the motors are placed in a separate h-bridge
each. This is assumed to get the maximum requirement of GPIOs.
The goal of this section is to investigate potential problems that can occur and
how to detect these problems.
3.5.1
CAN-Bus Description
The CAN-bus is an essential part of the system. As mentioned earlier, the CANbus will handle all communication between MCUs in the agricultural vehicle. If
this communication breaks down, it would render the agricultural vehicle unusable
and therefore extensive error detection is needed to prevent this from happening.
As can be seen in Figure 3.9, the system consists of one CAN controller and
one CAN driver. The CAN driver handles the hardware interface to the bus while
the controller works as an interpreter between the MCU and the CAN protocol.
There are termination resistors in each end of the bus. These termination
resistors are essential and if they are removed, it will cause echo images on the bus
that can corrupt bus integrity.
CANH
Termination
resistor
CANL
Termination
resistor
CAN
Driver
Recieve
Transmit
MCU 1
CAN
Controller
PCB
CAN
Driver
Recieve
Transmit
MCU n
CAN
Controller
PCB
Figure 3.9. An overview of the CAN bus. Two MCUs communicate over the CAN
bus with the help of CAN drivers. The CAN driver itself communicates with the MCU
through the MCU’s built-in CAN controller. There are termination resistors in both ends
of the CAN bus.
3.5 Controller Area Network (CAN)
47
The business partner has specified that they want to use the TJA1041 as a CAN
driver. The CAN-bus driver TJA1041 has an error signal (ERR) which indicates
if there is a problem6 on the bus. The error signal only informs the system that a
problem occurred but it does not inform the system of what caused the problem.
To make the system robust it is crucial to monitor the CAN-bus in order to
detect the cause of any problem on the bus. With extra monitoring it might be
possible to detect errors that the TJA1041 is not able to detect itself.
3.5.2
Survey of MCU CAN Controllers
First of all I will investigate which MCUs, of the ones in Table 3.1 (page 31), that
have built-in CAN controllers. The results can be seen in Table 3.15.
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
CAN-bus controller
Yes, up to two controllers
Yes, up to three controllers
Yes, up to five controllers
Yes, up to two controllers
Yes, up to two controllers
Yes, up to one controller
Yes, up to one controller
Table 3.15. This table shows which MCUs that have built-in CAN controllers.
3.5.3
Requirements on Error Detection
The CAN-bus is a crucial component of a system. It is therefore required that the
CAN-bus should be equipped with exhaustive error detection.
The degree of error detection has been discussed in the business collaboration
with the business partner and the following problems have been identified:
• Short-circuit between CAN-lines
• Short-circuit between any CAN-line and the supply rails
• Interruption on any CAN-line
• Broken or unconnected termination resistors
• Incorrect pulse-width
• Problems with the CAN driver
To make the system robust the system should be able to detect these errors.
Since all of these problems can occur during operation of the system it is also
required that as much error detection as possible is performed on-the-fly.
6A
problem that the TJA1041 can detect
48
3.5.4
System Research
Short Circuit
A normal CAN message can be seen in Figure 3.10. What is interesting to look at
is the voltage difference between CANH and CANL (that is ∆V). When ∆V passes
a certain voltage level, the CAN-bus will be regarded as busy. If a short-circuit
occurs, it is possible that the CAN-driver will not be able to take control of the
bus.
Figure 3.10. An example of a typical CAN message. In recessive state the CAN-bus is
available for anyone to use, while the bus in dominant state is busy. [23]
How can a short-circuit be detected? The TJA1041 has built-in features to
detect some short-circuits as can be seen in Table 3.16.
Signal
Short with
∆V
Effect
CANH
CANH
CANH
CANL
GND
VDD
0V
&
%
CANL
GND
%
CANL
VDD
&
Recessive state
Recessive state
Can be stuck in
dominant state
Can be stuck in
dominant state
Recessive state
Detectable by
the TJA1041
No
Yes
No
No
Yes
Table 3.16. This table shows the behavior of the CAN-bus when a short-circuit occurs.
It is also presented which short-circuits the TJA1041 can detect.[23]
As can be seen in the table, all short-circuits can not be detected by the
TJA1041. To detect all short-circuits the system has to be equipped with more
diagnostic hardware.
3.5 Controller Area Network (CAN)
49
With the help of the system’s ADC it is possible to sample both CAN-lines and
with this information it is possible to detect all kinds of short-circuits presented
in Table 3.16.
To sample the value of the CAN bus the system needs to have two peak detectors, one to each CAN-line. How the peak detectors can be constructed is shown in
Figure 3.11. When both CAN-lines are sampled the system can analyze these values in software and determine if a short-circuit has occurred. If a short-circuit has
occurred it is also possible for the system to determine which type of short-circuit
it is.
Vdd
CANLine
Diode
ADC
(a) Positive peak detector
CANLine
Diode
ADC
(b) Negative peak detector
Figure 3.11. This figure shows peak detectors that can detect negative and positive
peaks. These can e.g. be used to monitor the CAN-line voltages.
3.5.5
CAN-Line Interrupt
In case of an interrupt on any of the two CAN-lines, no current will flow on the
interrupted line. This can be detected by transforming the current into voltage in
the same way as it is shown in Figure 3.11.
If no voltage on a CAN-line is detected, when there should be communication
on the bus, it is likely that the CAN-line is interrupted.
MCU 1
MCU 2
CAN driver
CAN driver
Figure 3.12. In the figure one of the two CAN-lines are interrupted. This can be
detected by measuring the current on the CAN-line.
3.5.6
Termination Resistors
If the termination resistors are faulty or disconnected, it could cause echo images to
occur on the bus. Echo images on the bus are likely to disrupt bus communication.
If the termination resistors are faulty or disconnected could be detected by
measuring the voltage on both CAN lines. Simulations, in the appendix, show that
50
System Research
the peak-to-peak values differs from when the termination resistors are working
compared to when they are not working. With working termination resistors, the
voltage is ∆V ≈ 1.2 V7 . With the termination resistors disconnected, the voltage
is ∆V ≈ 1.7 V8 .
The system could detect if the termination resistors are working correctly by
measuring the peak voltage with the same approach as in Figure 3.11 (page 49).
3.5.7
Incorrect Pulse-Width
With incorrect pulse-width it is meant that the ”high-time” and/or the ”low-time”
are incorrect. Here two approaches to detect these errors are presented.
Approach One
The first approach is to use the A/D converters that are connected to the CAN
lines, to determine if a signal is high or low. This value can then be compared in
software with the value (RXD or TXD) received from or sent to the CAN driver. If
these values differs, it means that there could be a problem with the pulse width.
One problem with this approach is that it is not known when the A/D conversion should start in order to sample a bit in a message. Another problem is that it
is hard to synchronize the sampling of the channels with reading the RXD signal.
A small delay between these signals could, for example, signal an error on a fully
functional bus.
Another potential problem with this approach is that the A/D converters might
not be able to convert samples fast enough to determine the pulse width.
As known from Table 3.4 (page 33), an A/D converter can perform a conversion
in approximately 2.5 µs9 . The CAN-bus has a maximum speed of 250 kbit/s which
is equal to a bit period of 4 µs. This is clearly an issue because the A/D converter
will only be able to sample once or twice in every bit-period. This makes it
impossible to use this approach to determine incorrect pulse-width since it would
require the system to sample several times every bit-period.
Approach Two
Another way to detect incorrect pulse-widths is to use a counter in the MCU to
count the length of a pulse. This could be done by using a comparator that signals
if the input is over 90% of the maximum peak value or below 10% of the minimum
value. Each time one of these limits is reached a counter/timer in the MCU starts
to count. The reason why the limits of 10% and 90% are proposed is to avoid
triggering on noise. In this way it is possible to approximate the pulse widths.
This is illustrated in Figure 3.13. This solution requires that the MCU can trigger
on external events and that the triggering is fast enough to make the measurement
accurate.
7 See
appendix Figure A.1
appendix Figure A.2
9 Depending on the MCU choice
8 See
3.5 Controller Area Network (CAN)
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
Producer
Freescale
Freescale
Freescale
NXP
NXP
STMicroelectronics
STMicroelectronics
51
Support for external interrupt
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Table 3.17. This table shows that all MCUs have support for external interrupt. This
can be used for example to detect incorrect pulse widths.
As can be seen in Table 3.17, all MCUs have support for external interrupts.
None of the MCUs’ datasheets specifies which is it fastest detectable input-signal
frequency.
An algorithm to detect incorrect pulse-width work as following:
1. Voltage passes one threshold (10% or 90%) and the comparator’s output
signal that the signal passed the threshold.
2. The MCU recognizes10 the comparator signal and starts an internal counter.
3. After X clock pulses, the MCU checks if the signal from the comparator is
still on the same side of the threshold. This step is to avoid the comparator
to switch signals when it is close to a threshold.
(a) If the signal is still on the same side of the threshold, the MCU starts
to count the pulse width.
(b) If it is not, the MCU will disregard the previous value from the comparator signal.
4. When the comparator signals that the signal has passed the threshold once
again, the internal counter stops and the pulse-width is determined.
counter
start
counter
stop
90%
10%
counter
start
counter
stop
Figure 3.13. This figure illustrates how to detect incorrect pulse-width. This solution
requires that the MCU can trigger on external events.
10 Note
that some MCUs have support for triggering on external events
52
System Research
Conclusion Incorrect Pulse-Width
In this section it has been investigated how to detect incorrect pulse-widths. Two
approaches have been presented and investigated. The investigations show that
only approach two is possible to use. This approach uses two comparators, one to
each CAN-line, that signals if the voltage passes the thresholds 10% or 90% of the
maximum CAN-line voltage. If the signal passes the thresholds the comparators
will generate an external interrupt to the MCU. The MCU starts a counter when
this interrupt is detected.
Investigations in this section show that all MCUs have support for external
interrupts. No specification of how fast frequencies, that the MCU can detect,
have been found. This is a potential issue with this solution. If the input switches
faster than the MCU can detect it can make it impossible to detect a incorrect
pulse-width.
One bonus with Approach two is that it makes it possible to count the bitrate on the bus. This is not a required feature but it could be useful if some
un-foreseeable error occurs.
3.5.8
Slow Slope
It is possible to detect if the slope is too slow by using almost the same approach
as is used to detect pulse-width problems in section 3.5.7. The only difference
needed, to measure the slope, is that the counter is started at 10% and stopped
at 90% (of the expected maximum peak value). This is illustrated in Figure 3.14.
counter
stop
counter
start
90%
10%
counter counter
stop
start
Figure 3.14. This figure shows how the slope can be measured. This solution requires
comparators and that the MCU have support for external interrupts.
3.5.9
Problems with the CAN-Driver
It is necessary for the system to detect if the CAN-driver starts to behave incorrect.
Because none of the CAN-driver’s internal signals can be monitored, the only
feasible way to monitor the CAN-driver is to check the current consumption.
This can be done by connecting a capacitance and a diode to the power-supply
of the CAN-driver in order convert the current into voltage. The voltage over
the capacitance is A/D sampled and that value gives an approximation of the
CAN-drivers current consumption.
3.6 Power Supply
53
Vdd
CAN-driver
TJA1041
ADC
Figure 3.15. This figure illustrates how to monitor the CAN-driver. Since none of
the CAN-driver’s internal signals are available this can only be done by monitoring the
driver’s current consumption.
3.5.10
Conclusion Controller Area Network
This section has investigated how to detect potential problems with the CAN-bus.
At the start of the investigation it was specified after discussions between the
author and business partner that the following problems are important to detect:
• Short-circuit between CAN-lines
• Short-circuit between any CAN-line and the supply rails
• Interruption on any CAN-line
• Broken or unconnected termination resistors
• Incorrect pulse-width
• Problems with the CAN driver
The investigations in this section show that it is possible to detect all these
problems. It is also shown that the hardware cost to detect the problems are
affordable. The hardware cost of all the detection/monitoring of the CAN-bus is
compiled in Table 3.18.
As known from previous investigations, the requirement of A/D pins and GPIO
pins is an issue when designing the system. It is therefore beneficial that the
investigations in this section, show that many potential CAN-bus problems can be
detected with the same hardware.
Pin Requirements When Using the Recommended Solution
The number of A/D pins and GPIO pins the CAN-subsystem will use are listed
in Table 3.18. The number of required GPIO pins for the TJA1041 CAN-driver is
taken from its datasheet.
3.6
Power Supply
The power supply is a critical part of the system. If the power supply experiences
any problem, this will affect the rest of the system. Since the power is critical to the
54
System Research
Type
GPIO pin
GPIO pin
Part of CAN-bus
TJA1041
Incorrect pulse width
Amount
6
2
A/D pin
A/D pin
Short-circuit detection
CAN-line interrupt
2
2
A/D pin
Total GPIO pins
Total A/D pins
Problems with the CAN-driver
1
8
3
Note
Shared with
slow slope
Shared with
short-circuit
detection
Table 3.18. This table contains compiled information of the CAN subsystem’s requirements of MCU pins. This table also show which parts of the CAN-bus that consumes
pin resources. Note that some pins are shared between different CAN-bus parts.
system, it is important that the system is equipped with exhaustive fault-detection
functions in order to detect any problem with the power.
Problems that can occur are under-/over- voltage and a weak-line connection
from the battery. The weak-line connection is when the battery’s output has the
correct voltage but is not able to provide the load with enough current.
Figure 3.16 shows how the power-supply subsystem can be structured.
I/O
Block
Tractor
Battery
1.8 V
Power-Supply 3.3 V
Generator
5V
MCU
Block
Figure 3.16. This figure shows an overview of how the power-supply subsystem can
look. This figure will be explained more in the ”Generate Power-Supply” section. The
voltage levels in this figure should only be seen as a guideline. The required levels differs
depending on which MCU that is chosen.
The investigations of the power-supply subsection are divided into these three
subsections:
• Power-supply generator
• Low-voltage detection
• Power-supply monitor
3.6.1
Power-Supply Generator
An agricultural vehicle is powered by the vehicle’s battery. From this battery the
system has to take all its power. This is illustrated in Figure 3.16.
3.6 Power Supply
55
Requirements
As can be seen in Figure 3.16, the system is equipped with four different voltage
levels. Three of them are generated from the power-supply generator and the last
one is generated directly from the vehicle’s battery though a voltage divider.
The three voltage levels connected to the MCU block have to be generated by
a switched power-supply to reduce heat dissipation [10]. The supply level to the
I/O block does not have to be generated by a switched power-supply since the
I/Os consume very little power. The required supply levels to the MCU block
depends on which MCU is chosen. Table 3.19 contain an overview of the different
MCUs’ power-supply requirements.
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
Producer
Freescale
Freescale
Freescale
NXP
NXP
STMicroelectronics
STMicroelectronics
Required supply (V)
Core
I/0
Analog
1.35-1.65 1.62-3.6 4.5-5.25
1.35-1.65 1.62-3.6 4.5-5.25
1.35-1.65 1.62-3.6 4.5-5.25
2.4-3.6
2.4-3.6
2.7-3.6
1.70-1.89 2.7-3.6
3.0-5.5
1.65-2.0
2.7-3.6
2.7-3.6
2-3.6
2-3.6
2-3.6
Table 3.19. This table contain information of which supply levels that different MCUs
require. The values are listed as minimum-maximum.
The three lowest voltages are required to be generated by a switched powersupply11 . By using a switched power-supply the power dissipation is reduced,
which results in reduced heat dissipation. The supply-line to the I/O block is not
required to be generated by a switched power-supply.
Survey of Switched Power-Generators
What kinds of off-the-shelf switched power generators that are available and what
features they offer can be seen in Table 3.20.
Conclusion Power-Supply Generator
In this section the requirements of the power-supply generator subsystem have
been investigated. It is found that different MCUs requires different supply voltages and it is therefore difficult to give a solution that applies for all MCUs.
Therefore the solution in this section should be regarded as an absolute solution
but rather one possible solution.
The requirement of maximum current is unknown and therefore it is not possible to determine if the devices, in Table 3.20, are able to provide enough current.
However it is extremely unlikely that the MCU will require more than 1.5 A which
11 A
switched power-supply use PWM
56
System Research
Voltages (V)
1.8 3.3 5.0
MCU
LT3507
LM2574
PM6681A
" " "
" " "
" " "
Maximum
current
One 2.4 A,
two 1.5 A
0.5 A
Price
Note
$5
2.5 V also available
$3
100 mA
$1.5
3 different devices
needed. One for 3.3
V, one for 5.0 V and
one adjustable for
1.8 V
1.8 V and 3.3 V can
be generated from
the adjustable outputs. 5.0 V also
available
Table 3.20. This table lists a few switched power-supply generators that were found
during the survey. It is assumed that 1.8 V, 3.3 V and 5.0 V are required.
the LT3507 provide. Therefore it is assumed that the power-supply lines can be
generated from at least one of the devices in the table.
As can be seen in Table 3.20, there are products on the market that can generate
the required voltages by PWM switching.
The cheapest device in the table is PM6681A and it fulfills the requirements.
I recommend using this device to generate 1.8 V, 3.3 V and 5.0 V supplies.
It is important to note that this recommendation does not take maximum
current throughput into consideration.
3.6.2
Low-Voltage Detection
In order to execute instructions correctly, the power-supply needs to be above the
minimum voltage level that is specified by the MCU’s datasheet. If the powersupply voltage drops below the specified minimum voltage, the MCU will start
to work incorrectly (e.g. faulty calculations, writing incorrect data into memory
etc.). For this reason the MCU has to be able to protect itself by powering down
when a voltage-drop occurs.
The survey section investigates what kind of support for low-voltage detection
the different MCUs have.
This section only deals with low-voltage detection of the MCU’s power-supply
line.
Survey of MCU Low-Voltage Detection
All MCUs in Table 3.1 (page 31) have been investigated in order to see which, if
any, low-voltage detection features they are equipped with. This is summarized in
Table 3.21.
3.6 Power Supply
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
57
Low-voltage detection (LVD)
None
None
None
Yes, brownout detection
None
Brownout detection and LVD
None
Table 3.21. This table shows which MCUs that have support for low voltage detection.
A MCU with Brownout detection can detect loss of power.
As can be seen in the table, only the LPC1768 and the STR912 have built-in
support to protect them against a voltage drop in the power supply. Since most
of the MCUs do not have built-in support for low-voltage detection it is crucial to
investigate alternative ways to solve this issue.
Requirements
By using the built-in support for low-voltage detection, the MCU can protect itself
from voltage drops. As found out in the survey, only two of the MCUs have builtin support for low voltage detection. Since the power-supply is a crucial system
component it is very important that the system can monitor its behavior. Can a
low-voltage detection be built with the help of the MCUs’ other features?
To answer this question I will first start with classifying different voltage drops
that can occur. I have chosen to classify the voltage drops into two different
categories according to the speed of the drop.
• Slow drop. The voltage drop follows a decreasing ramp with a small enough
slope for the MCU to be able to detect the voltage drop.
• Fast drop. The voltage drop can be considered to be instantaneously. The
MCU is not able to detect the voltage drop.
In case of a slow voltage-drop, the MCU can use the ADC to sample the supplyvoltage. If a falling voltage is detected, the MCU records the drop and enters a
”safe-state”12 .
In case of the fast voltage drop, the MCU can not use the same approach as
in the case of the slow drop since the MCU is, by definition, not fast enough to
detect the fast drop.
Is it possible to detect the fast voltage drop in another way? And how should
the MCU react if a voltage drop is detected?
12 E.g.
a state where no writing to the memory is allowed.
58
System Research
Fast Voltage Drop
One approach to a solution, illustrated in Figure 3.17, is to place a relatively big
capacitance on the power-supply line. In case of an instantaneously voltage drop
of the power-supply, the capacitance contain backup power which the MCU can
use to power-down.
ADC
Power
unit
MCU
MCU's
Power-supply
diode
cap
Figure 3.17. This figure illustrates how the MCU could handle a fast voltage drop. A
capacitor is used as a backup emergency battery that the MCU will use as power source
in case of a voltage drop.
Is this solution feasible? To investigate this issue I start with the following
assumptions:
• The MCU is a RISC processor with a clock frequency at 100 MHz.
• The MCU has a power consumption of 100 mA.
• The MCU core runs at 1.8 V.
• 10000 instruction cycles are enough to prepare the MCU for a power-down.
Q=I ·t
Q
C=
V
I ·t
⇒C=
V
V = 1.8, I = 100 · 10−3
t
⇒C=
180
(3.4)
(3.5)
(3.6)
(3.7)
(3.8)
(3.9)
To prepare the MCU for a power-down it is assumed that 10000 instruction
cycles are sufficient. The RISC processor with a clock frequency at 100 MHz
can execute one instruction every 10th nanosecond and thus 100 µs is needed to
prepare the MCU for power-down.
How big capacitance is needed to provide the MCU with current during this
time?
3.6 Power Supply
59
100 · 10−6
≈ 560 nF
(3.10)
180
If the assumptions above are correct, it is enough with a 560 nF capacitance
to prepare the MCU for a power-down. This is good news! It is possible to find
capacitances up to 100 µF on the market so there are big safety margins.
To be able to determine with higher accuracy, how many instructions are
needed to power-down safely, more research is required. This research is considered
to be too time consuming to perform within the boundaries of this report13 .
C=
How to React on a Voltage Drop
How should the MCU react to a voltage-drop? It is possible to react according to
Figure 3.18.
MCU warning.
Sample voltage
Threshold reached.
Store voltage in
memory
MCU reset
warning
Safety margin.
No write to memory
during this time
MCU
required level
Figure 3.18. This figure illustrates how the MCU could react in case of a voltage drop.
The black curve corresponds to a voltage drop that will not cause a power failure. The
red curve will cause a power failure.
At the first threshold, the MCU issues a ”soft warning” that the voltage has
decreased below the level at which it is supposed to be. The MCU could then save
the voltage values in memory. These values could be used later to provide with
information of why the system did shutdown.
If the supply-voltage drops to the second threshold, it is time for the MCU to
enter a safe-state where no write operation to memory is allowed. If the voltage
drops even more, the MCU will be powered down, but if it increases, the MCU
will go back to working as before.
Conclusion Low-Voltage Detection
The investigations in this section shows that it is possible to prepare the MCU for
a safe power-down even if the MCU does not have built-in support for it. It is
possible to monitor the supply-voltage by connecting an ADC to the supply line.
13 Seven
different MCUs needs to be investigated
60
System Research
Investigations also show that it is possible for the MCU to power-down safely
even if an instantaneous voltage drop occurs. This can be done by letting a
capacitor work as a small emergency backup battery.
I strongly recommend to use this approach, illustrated in Figure 3.17 (58), with
a capacitor and an ADC connected to the supply-line.
Pin Requirements When Using the Recommended Solution
The MCU’s pin requirements for low-voltage detection, that is discussed in this
section, can be seen in Table 3.22.
Type
A/D
Amount
1
Note
Connected to the supply-line
Table 3.22. This table presents the MCU’s pin requirement of the low-voltage detection
subsystem.
3.6.3
Power-Supply Monitor
The previous section investigated low-voltage detection of MCU core’s powersupply and how the MCU should react if low-voltage is detected. This section
focus on monitoring of the power-supply lines to the I/Os.
The power-supply needs to be monitored so that the system knows if any of
the I/Os experiences a voltage drop. If the I/Os experiences a voltage drop it
will cause the I/Os to work in a faulty way, e.g. the sensors will not be able to
make accurate measurements and the sensors’ measurements should therefore be
disregarded.
It is not always necessary for the I/Os to be shutdown when a voltage drop
is detected. In the case of the sensors it is enough for the MCU to disregard the
sensors’ measurements. The motors and the solenoids are however required to
shutdown when a voltage drop is detected.
Requirements
From section 3.6.1 (page 55) it is known that the system will have following voltages:
• 1.8 V
• 3.3 V
• 5.0 V
• Battery voltage (minimum of 12 V)
All voltage levels except the 1.8 V14 needs to be monitored.
14 This
voltage is already monitored in section 3.6.2 (page 56)
3.6 Power Supply
61
Table 3.23 shows some I/Os should react on a voltage drop. The system will
probably contain more I/Os than the ones listed in the table but how the other
I/Os should respond to a voltage drop is unknown and they are therefore left out
of the table.
I/O
Motors
Sensors
Solenoids
Action
Shutdown
Disregard result
Shutdown
Table 3.23. This table shows how the I/Os (i.e. motors, sensors and solenoids) should
act when the system detects a voltage drop.
Survey of Power Supervisors
In Table 3.24 a power-supply supervisor device is listed along with its functionality.
The reason why this survey only presents one device is because very few offthe-shelf products fulfill the requirements.
Name
Producer
Price
Threshold
AD5100
Analog Devices
$3
Programmable by
I 2 C. Range 2-30 V
Monitor
channels
4
Table 3.24. This table presents the device found, in the survey, that fulfills the requirements of the power-supply monitor.
Devices like the AD5100 is available off-the-shelf. It fulfills the monitor requirements but at the same time it is quite expensive and it also requires the MCU to
be equipped with an I 2 C-bus.
In order to ease the requirements on the MCU it is worth investigating if it
is possible to perform the same functionality as the AD5100 by only using the
features in the MCU?
Power-down of External Devices
One approach to perform monitor the power-supply, without using off-the-shelf
products, is to connect ADCs to all power-supply lines. These supply-lines can
then be periodically sampled and compared with some given values to see if the
voltage is within the required range.
If a voltage drop is detected the I/O can either be shutdown or the MCU can
disregard the I/Os output. This depends on which type of I/O it is, see Table 3.23
for more information.
As can be seen in Figure 3.19(a), a motor is activated with the IN1 or the MCU
signal. In Figure 3.19(b) it can be seen that the IN_1 signal activates the solenoid
driver. If none of these signals are activated both the motor and the solenoid will
be shutdown.
62
System Research
VBAT
IN1
IS1
VBAT
BTS5236
ADC_1
IN_1
Output
Solenoid Input
ADC_1
MCU
ADC_3
ADC_2
BTS5236
(a) Motor schematic
ADC_2 (IS1)
(b) Solenoid schematic
Figure 3.19. This figure shows the schematics of the motor driver and the solenoid
driver. These two figures are taken from Chapter 2 (page 5).
In the case of that a sensor experiences a voltage drop it can not be shutdown.
It is extremely important for the system to know if the sensors’ outputs are valid
or not. If a voltage drop is detected the outputs should be disregarded. This can
easily be implemented in software.
As soon as a voltage drop is detected, on any power-supply line, it is very
important that the drop is logged. If not it will be hard to try to locate errors
since the system can seem to work in a random way if it is not logged when voltage
drops are detected.
Conclusion Power-Supply Monitor
In this section the power-supply monitor have been investigated. From the investigations it is concluded that very few off-the-shelf products fulfills the system’s
requirement. The product, that fulfills the requirements, is also relatively expensive.
Investigations show that it is possible to use the ADC to monitor the system’s
power-supply lines. It is also investigated how the I/Os should react to a voltage
drop. Investigations show that both motors and solenoids can be shut down while
the sensors’ measurements must be disregarded, in the case of a voltage drop.
Pin Requirements When Using the Recommended Solution
The MCU’s pin requirements, when using the proposed solutions in this section,
are listed in Table 3.25.
Type
A/D pin
Amount
3
Note
Connected to 3.3 V, 5.0 V and battery voltage
Table 3.25. This table presents the MCU’s pin requirement to monitor the 3.3 V, the
5.0 V and the battery supply line.
3.7 Battery Health
3.6.4
63
Conclusion Power-Supply
For conclusion of the power-supply, see the conclusions of the power-supply’s three
subparts.
Subpart
Power-supply generator
Low-voltage detection
Power-supply monitor
Conclusion
Page 55
Page 59
Page 62
Table 3.26. This table presents where to find the conclusions of the power-supply’s
subparts.
Pin Requirements When Using the Recommended Solution
The pin requirements of the power subsystem are listed in Table 3.27. The numbers
in the table assumes that four supply lines will be monitored.
Note that the A/D pin, required for the low voltage detection, can be shared
with one of the pins required for power-supply monitoring.
Type
A/D pin
Subpart
Low voltage detection
Amount
1
A/D pin
Power-supply monitor
3
Total A/D pins
Note
Monitors the MCU’s
power-supply (1.8 V)
Monitors the 3.3 V,
the 5.0 V and the
battery power-supply
lines
4
Table 3.27. This table presents the MCU pin requirement for the power subsystem.
Note that these voltage levels can differ depending on which MCU that is chosen.
3.7
Battery Health
The power-supply in the agricultural vehicle is its battery. The performance of the
battery can vary due to many different factors and it is therefore important for
the system to have the capacity to monitor the battery’s health. The parameter
in a battery which reflects the health is the internal resistance.
The output voltage of a battery differs from when a current flows through it, to
when no current flows. This is due to the voltage-drop over the internal resistance.
A model of a battery is shown in Figure 3.20.
Since it is not possible to measure the internal resistance directly (no internal
nodes available), the system needs to measure it indirectly.
One possibility to measure the internal resistance is to draw a specific amount
of current and then measure how much voltage the battery delivers [16]. The
internal resistance can then be calculated with Ohm’s law.
64
System Research
RB
IB
Battery
Figure 3.20. This figure illustrates a model of a battery. The internal resistance RB
reflects the battery’s health.
The more current flows through the battery, the higher the voltage-drop will be
over the internal resistance. If the system always draws approximately the same
current at each measurement, it is possible to keep track of the battery’s health.
To draw current from the battery the system’s solenoids can be used. When
the solenoid(s) is activated a current will be drawn from the battery. To measure
the voltage delivered by the battery, the MCU’s analog-to-digital converter can be
used. This is shown in Figure 3.21.
RB
Ib
IB
ADC
Solenoids
Battery
Figure 3.21. This figure shows how to measure the battery’s health. In the figure the
solenoids are used to draw current from the battery and an ADC will then measure the
voltage drop on the battery’s output. After this the internal resistance can be calculated
with Ohm’s law.
The pin requirements to measure the battery’s health, with the proposed approach in this section, are listed in Table 3.28.
Type
A/D pin
Amount
1
Note
Measure battery’s output voltage
Table 3.28. This table shows the MCU’s pin requirement to measure the battery’s
health.
3.8 Environment
3.8
65
Environment
Agricultural vehicle are used in different terrains all over the world. Agricultural
vehicles therefore have to be able to work under a big variety of conditions. Issues
like temperature, humidity, water, vibrations and acceleration have to be dealt
with. This section will look into these issues and propose a solution on how to
detect these potential problems.
This section is divided into the following parts:
• Temperature
• Water
• Acceleration
3.8.1
Temperature
It is important for the system to monitor the temperature. If the system would
overheat it can start to work incorrectly and might even permanently harmed. The
system therefore has to be able to monitor temperature in order to protect itself
in case of overheating. It is also important for the system to store information if
the it is shutdown due to overheating. With the stored information, it is possible
to see if a power down has occurred due to high temperature.
Both internal and ambient temperature are an issue and both have to be monitored.
Internal Temperature
The PCB will have hot-spots close to the main power-consumers, e.g. close to
the MCU. Temperature sensors should be placed close to hot-spots. Temperature
sensors could also be mounted in cold-spots, e.g. in the corners of the PCB.
Why could this be beneficial? It is not only necessary for the system to know if
the PCB is too warm or not, but it is also important for the system to determine
the cause of the heat problem. The readings from the temperature sensors could
be of help in the future by generating a temperature map of the PCB. This map
could then tell if a re-design of the PCB would be beneficial.
Ambient Temperature
Why is it necessary to measure the ambient temperature? The reason is that it is
helpful to have an approximation of the ambient temperature when investigating
the cause of internal overheating problems. If the ambient temperature is too
high, there is nothing the system can do except warn the user of that the ambient
temperature is too high.
The temperature sensors in the corners of the PCB could give an approximation
of the ambient temperature. They also provide redundancy in case of problems
with a temperature sensor or if, for some reason, one side of the PCB is more
affected to external heat than its opposite side.
66
System Research
Why not place a temperature outside the enclosure? This would certainly give
a more accurate temperature reading of the ambient temperature. The drawback
of having an external temperature sensor, is that it is much more expensive15
compared to an internal sensor. There is also no need for an extremely accurate
reading of the ambient temperature. It is enough if it gives an approximation of
the ambient temperature so the system can determine if a problem is caused by
internal heating problems or not.
Survey of Thermistors
As a temperature sensor the system will use an temperature sensitive resistor,
called thermistor. A thermistor is suitable to measure temperature and it is a
cost-effective solution [27].
There are plenty of different thermistors with different parameters (e.g. resistance, tolerance, maximum current, temperature range etc.) on the market. Table
3.29 presents a selection of companies that provide a wide variety of thermistors.
This table is presented to give an estimation of what a thermistor costs.
Producer
Murata [22]
TDK [38]
AVX [9]
Price
$0.15
$0.16
$0.25
Table 3.29. This table presents a few companies that offer low-cost thermistors. This
table’s purpose is to give an estimation of the thermistors costs.
Conclusion Temperature
I recommend using one temperature sensor for each hot-spot and four temperature
sensors (one in each corner of the PCB). It is not yet possible to determine how
many hot-spots the PCB will have. I assume that five16 hot-spots will be present.
A temperature sensitive resistor, a thermistor, offer a low-cost solution to measure the temperature. The thermistor can be used as illustrated in Figure 3.22.
Pin Requirements When Using the Recommended Solution
The pin requirements, when using the proposed solution in this section, are listed
in Table 3.30.
3.8.2
Water
An agricultural vehicle has to be cleaned with a high-pressure washer and as a
result it is not unusual that water (sometimes also containing different chemicals)
manages to get inside of the enclosure. Water can cause many problems in the
15 Because
of additional wiring, water-proof sockets for cables leaving enclosure, etc.
less but a maximum pin requirement is wanted.
16 Probably
3.8 Environment
67
Vdd
Rs
ADC
NTC
resistor
Figure 3.22. This figure illustrates how to use a thermistor, in this case of NTC
type, to measure temperatures in the system. The thermistor has a close to linear
relationship with temperature which makes it possible to use measure temperature with
this circuit.[27]
Type
A/D pin
A/D pin
Amount
5
4
Note
Hot-spots
Cold-spots
Table 3.30. This table presents the MCU’s pin requirements to monitor the temperature. The presented numbers assume that five hot-spots will be present and that a
temperature sensor is placed at each hot-spot. The numbers also assumes that a temperature sensor will be placed in each corner of the PCB.
system and therefore the system needs to be able to detect if water is inside of the
enclosure.
Water is a better electric conductor than air and thus if water is present between
two contacts, the resistance between the two contacts will be decreased. Since the
voltage over the two contacts is constant the lowered resistance will cause the
current to increase. The current between two contacts could then be measured in
order to detect if water is inside the enclosure or not.
To measure the current, between two contacts, it is possible to measure the
voltage over a resistor. The voltage could then be A/D converted in order for the
system to determine if water is present or not. This is illustrated in Figure 3.23.
In order for this solution to be more effective it would be beneficial if this water
issue could be considered during the design of the enclosure. If the enclosure’s
bottom plate could be made with a slight incline towards the middle it would
result in water being collected there first. This is then a optimal location to place
the water sensor at. This is illustrated in Figure 3.24.
The system could in this way detect if water is present and inform the user
that he/she needs to empty the enclosure of water.
Conclusion Water
It is possible to measure water by measuring the current between two contacts.
This is illustrated in Figure 3.23.
68
System Research
I
ADC
R
Contact
RW
Contact
Figure 3.23. This figure illustrates how to measure if water is present inside of the
enclosure. The dashed line illustrates the resistance between the two contacts. If water
is present between the two contacts this resistance will decrease and therefore the current
will increase. By measuring the voltage drop over resistor R it is possible to detect if the
current has increased or not.
Enclosure
PCB
Place watersensor here
Figure 3.24. This figure illustrates how the enclosure could be made. When water
leaks into the enclosure, the water is collected in the middle of the bottom plate. With
a sensor at this location the sensor would be guaranteed to detect water that has leaked
into the enclosure.
Pin Requirement When Using the Recommended Solution
The pin requirements of the solution proposed in this section are listed in Table
3.31.
Type
A/D pin
Amount
1
Note
Measure voltage over resistor
Table 3.31. This table presents the MCU’s pin requirements for the water detection.
3.8.3
Acceleration
To protect the vehicle from damages it can be helpful to monitor how the vehicle
is driven. This can be done by measuring the vehicle’s acceleration. To measure
3.8 Environment
69
the acceleration it is possible to use a off-the-shelf accelerometer.
With an accelerometer mounted on the PCB, the system would be able to
detect and, if necessary, log the acceleration of the agricultural vehicle.
If the accelerometer is sensitive enough17 , it can also detect vibrations. If
vibrations could be detected, it would be possible for the system to warn the user
if the measured vibrations are large enough to be of danger for the system.
To measure acceleration it is enough to use a two dimensional device but since
it is not known how the PCB will mounted I assume that a three dimensional
device is required.
Survey of Accelerometers
Table 3.32 contain a selection of accelerometers found on the market.
Name
ADXL330
MMA7331L
MMA7660FCR
Producer
Analog Devices
Freescale
Freescale
Price
$8.37
$1.95
$1.52
Note
Analog output
Analog output
Require I 2 C
Table 3.32. This table presents a selection of 3D-accelerometers found during the survey.
The cheapest device, the MMA7660FCR, requires an I 2 C interface. Which of
the MCUs in Table 3.1 (page 31), that have support for I 2 C communication is
presented in Table 3.33.
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
I 2C
No
No
No
Yes
Yes
Yes
Yes
Table 3.33. This table presents which MCUs that have support for I 2 C communication.
The cheapest accelerometer, the MMA7660FCR, found in the survey requires I 2 C and
therefore only if a MCU with I 2 C is chosen it would be possible to use the MMA7660FCR
device.
All the devices in Table 3.32 can measure acceleration in three dimensions. The
ADXL33018 from Analog Devices is a good device that can detect accelerations
down to one hundredth of the gravity force. However, this device is quite expensive
and it is therefore unwanted in a low-cost system.
The MMA7660FCR is the cheapest device but it also requires the MCU to have
an I 2 C interface to read the measurements. As can be seen in Table 3.33, not all
17 page
18 Used
266-267 in [11]
in the Wii motion controller
70
System Research
MCUs have support for I 2 C. Therefore the MMA7660FCR is not recommended
as a general solution. For a MCU with I 2 C support, the MMA7660FCR is the
recommended choice.
Conclusion Acceleration
In this section it has been investigated how to measure the acceleration of the
agricultural vehicle. The approach investigated uses off-the-shelf accelerometers.
If the MCU does not have I 2 C support, I recommend to use the MMA7331L. It
is fairly cheap and it does not require much of the MCU. To read the measurements
from the MMA7331L device, it is enough to connect analog-to-digital converters
to the three outputs of the device. I consider three extra ADC pins, to be a
reasonable cost and I therefore recommend to use chose the MMA7331L device to
monitor acceleration.
One question is if the MMA7331L is sensitive enough to detect differences in
how the agricultural vehicle is driven. To be able to safely answer this question
more research of the agricultural vehicle is needed. This is considered to be too
time-consuming to investigate within this report and it is therefore left to for
future investigations.
Pin Requirements When Using the Recommended Solution
The pin requirements to use the solution discussed here, are listed in Table 3.34.
Type
A/D pin
Amount
3
Note
Measure voltage on the MMA7331L’s outputs
Table 3.34. This table presents the MCU’s pin requirements to monitor acceleration.
This numbers assume that the MMA7331L accelerometer is chosen.
3.8.4
Conclusion Environment
For the conclusion of the environment subsystem please refer to the different subparts of this subsystem.
Table 3.35 sums up the MCU’s pin requirements of the environment subsystem.
Type
A/D pin
A/D pin
A/D pin
Total A/D pin
Amount
9
1
3
13
Subpart
Temperature
Water
Acceleration
Table 3.35. This table presents the MCU’s pin requirements of the environment subsystem. This includes temperature-, water- and acceleration sensors.
3.9 Memory
3.9
71
Memory
This section investigates how much memory the MCUs in Table 3.1 (page 31)
have.
It is likely that the part that consumes the most memory is the error detection.
The system will contain different types of error routines. I have chosen to classify
these different types into two categories:
• Frequently used routines : These routines are running continuously while
the vehicle is operating. They handle basic error detection.
• Infrequently used routines : These routines are used for exhaustive error
detection. The only need to run when the frequently used routines have
found an error. These routines do not have to run while the vehicle is
operating.
The frequently used routines will be small since they only handle basic error
detection of local parts in the system. The infrequently used routines are likely to
be larger since they need data from several parts of the system. On this data the
infrequently used routines will perform more complex calculations.
The frequently-used routines have higher requirements on execution time since
they will operate on-the-fly. The infrequently used routines will not be executed
on-the-fly and thus is not as time critical, as the frequently-used routines.
The optimal solution would be if all routines fit into the MCU’s internal memory. In this way all routines can be executed without any significant time delays.
What if all routines do not fit into the internal memory?
It is then recommended, if possible, to put the frequently-used routines in the
internal memory and the infrequently-used routines on an external memory. When
a error is detected the system should halt and start executing the infrequently used
routines for more exhaustive error detection.
3.9.1
Survey of MCU Memory
MCU
Flash memory
RAM memory
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
1 MB
2 MB
2 MB
512 kB
768 kB
2176 kB
128 kB
64
64
80
48
56
96
20
kB
kB
kB
kB
kB
kB
kB
Support for
external memory
Yes
Yes
Yes
No
Yes
Yes
No
Table 3.36. This table shows how much internal memory the MCUs have. It is also presented if the MCU have dedicated support for external memory. The dedicated support
is more detailed explained in Table 3.37.
72
System Research
3.9.2
External Memory
Can the external memory be used in the same way as the internal memory? This
section aims to answer this question. This section is split into two parts, parallel
interface and serial interface. Pros and cons of the two will be investigated.
Parallel Interface
Table 3.37 shows the properties of the external interfaces of the different MCUs.
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
Address bits
24
24
26
24
16
-
Data bits
16
32
32
32
16
-
Frequency (MHz)
40
66
66
Not stated
96
-
Table 3.37. This table presents the properties of the MCUs’ parallel interfaces.
None of the MCUs can execute directly from external memory. The external
interfaces can not operate in the same frequency as the MCU itself and it is
therefore not possible to execute instructions directly from the external memory.
Since the MCU can not execute instructions directly from the external memory,
it is recommended to copy routines from the external memory to the internal
RAM. If wait states19 are introduced it is not necessary to copy routines to the
internal RAM first. Which solution that is the best depends on the structure of
the routines. Routines with many loops will execute much more effectively if they
are first copied to the internal RAM. Routines with few loops can run slightly
faster if the wait states approach is used.
Generally programs contain quite a few loops and I therefore recommend to
first copy routines to the internal RAM because by executing from the RAM the
MCU will use its internal cache memory which is likely to speed up performance.
To copy routines from an external memory is time consuming and therefore it
is recommended to, if possible, only put infrequently used routines in the external
memory. This since the infrequently used routines are much less time critical than
the frequently used routines that have to be executed on-the-fly.
Serial Interface
An external memory can also be accessed through a serial interface, typically a
SPI-bus. Table 3.38 shows what kind of support for serial interfaces the different
MCUs have.
19 Wait states are periods of time where the MCU (i.e the memory controller) is waiting for
the external memory to become ready
3.9 Memory
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
73
CPU freq.
80 MHz
132 MHz
132 MHz
100 MHz
125 MHz
96 MHz
72 MHz
Serial interface
SPI
SPI
SPI
SPI
SPI
SPI
SPI
Serial interface freq.
25 MHz
25 MHz
25 MHz
9 MHz
25 MHz
24 MHz
18 MHz
Table 3.38. This table shows which MCUs’ that have support for SPI buses. It also
presents the speed of the SPI bus and the MCU. Note that the serial interface frequency
can differ depending on internal software settings.
As can be seen in the table, all the MCUs have support for SPI communication.
All the MCUs’ SPI-buses run at a much lower frequency than the MCU itself.
This makes it impossible to execute instruction on an external memory. The
recommendation is the same as in the parallel interface, that is to put infrequentlyused routines on the external memory and copy them to internal RAM when they
are needed.
Conclusion External Memory
Which of parallel or serial interface to memory suits the system best? A parallel
interface is significantly faster than the serial interface. On the other hand, the
parallel interface requires significantly more GPIO pins than the serial interface.
Neither parallel nor serial interfaces are able to execute routines directly on
external memory. Since serial interfaces are slower, it will require more time to
copy external routines to the internal RAM.
My recommendation is to use a serial interface (i.e. SPI). It is slower than a
parallel interface but I consider the system’s pin requirement to be more critical
than the execution time of exhaustive error routines.
The serial interface requires four to five pins while a parallel interface requires
up to approximately 75 pins. 75 pins would consume a large portion of the system’s
total pins.
In the GPIO subsystem section it was investigated how many GPIOs the different MCUs have. This information can be seen in Table 3.39.
The numbers in the table clearly shows that 75 pins will be a critical problem
for the system and thus it should not be used. This leaves us with the serial
interface. Will the lower speed of the serial interface cause any problem?
To investigate this question I will calculate how long time it takes to fill the
internal RAM. Here are the assumptions:
• SPI transfer speed of 5 MHz
• Internal RAM of 80 kB
74
System Research
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
Producer
Freescale
Freescale
Freescale
NXP
NXP
STMicroelectronics
STMicroelectronics
GPIO pins
≤ 149
≤ 214
≤ 178
≤ 70
≤ 152
≤ 80
≤ 80
Table 3.39. This table contains an overview of the maximum of GPIO pins that the
MCUs in Table 3.1 (page 31) have. The table is the same as the table in the survey of
the GPIO subsystem.
80kB = 80 · 103 · 8 = 6.4 · 105 bits
6.4 · 105
= 128 ms
5 · 106
(3.11)
(3.12)
According to equation 3.12, 128 milliseconds are needed to fill the internal
RAM with data from the external memory through a SPI. If all frequently used
routines can fit in the internal flash memory, this transfer time is acceptable since
the infrequently used routines only have to be loaded from external memory when
the system is in an error-state.
It is important to note, that if all frequently-used routines can not fit in the
internal memory, it is likely to slow the system down considerably, which is not
acceptable. Therefore the internal memory sets a limit on how many instructions
that the system will be able to do on-the-fly.
Pin Requirements for the External Memory
The pin requirements, of the suggested solution, can be seen in Table 3.40.
Type
GPIO
Amount
5
Note
These are not really GPIO pins but the system
has to sacrifice GPIO pins in order to get SPI
pins.
Table 3.40. This table presents the MCU’s pin requirement for the memory subsystem.
These numbers assumes that a SPI-bus is used to communicate with the external memory.
3.10
Summary System Research
This chapter presents the system’s requirements when the recommended solutions
discussed in this chapter are chosen.
3.11 MCU
75
The numbers presented in this chapter should be considered as an approximation. They give an estimate of the system’s requirements and they will be used
when investigating which MCUs that fulfill the system’s requirements.
Table 3.41 presents which A/D signals that will be in the system.
Part
I/Os
CAN-bus
Power-supply
Battery health
Environment
Total
Amount
108
3
4
1
13
129
Note
See Chapter 2
Error detection
Error detection
Error detection
Environment sensors
Table 3.41. This table presents the number of required ADC pins for the system.
Table 3.42 presents the GPIO signals that will be in the system.
Part
Multiplexer control pins
Multiplexer chip selects
Sensor monitor
Motor circuit
Common stage h-bridge
Solenoid circuit
CAN-bus
Memory
Total
Amount
6
1
10
20
20
14
8
5
84
Note
ADC multiplexers
ADC multiplexers
See Section 2.2.3 (page 16)
See Section 2.3.1 (page 19)
Assumes one h-bridge per motor circuit
See Section 2.1.1 (page 7)
CAN-bus driver + comparator signals
SPI interface
Table 3.42. This table compiles information about the system’s required amount of
GPIO pins.
3.11
MCU
This section will discuss the requirements on the system’s MCU. These requirements are investigated in the Chapter 3.
3.11.1
Requirements
The MCU’s minimum requirements can be seen in Table 3.43. In addition to these
requirements, the MCU is required to be fast enough and have big enough memory.
These two requirements are not investigated so it is not possible to determine a
minimum requirement on these two requirements. It is however clear that the
bigger memory and the faster processing power a MCU have, the better it is.
76
System Research
A cost-effective solution is always of interest, which means that the MCU price
is an issue. This is considered when recommending which MCU to choose.
Requirement
A/D pins
GPIO pins
CAN-bus
SPI interface
Amount
129
84
1
1
Table 3.43. This table presents the total hardware requirements of the MCU.
The MCUs’, available in Table 3.1 (page 31), features can be seen in Table
3.44. This table does not consider A/D pins or ADC requirements since it is
known, from Chapter 3, that no MCU can directly cope with the high number
of A/D pins. All MCUs can however solve this problem with the introduction of
multiplexers so this is not considered to be a problem.
MCU
MPC5534
MPC5554
MPC5567
LPC1768
LPC2939
STR912
STM32F103
GPIO pins
149
214
178
70
152
80
80
Features
CAN-bus
Yes
Yes
Yes
Yes
Yes
Yes
Yes
SPI interface
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Table 3.44. MCU requirements
Table 3.44 shows that the LPC1768, the STR912 and the STM32F103 are not
possible to use since they have too few GPIO pins to meet the requirements listed
in Table 3.43.
3.11.2
MCU Choice
The remaining MCUs, after the exclusion in the previous section, are listed in
Table 3.45.
With ”Available GPIOs” it is meant how many GPIO pins that are available
in addition to the required 84 GPIO pins.
All four MCUs in Table 3.45 fulfills the requirements listed in Table 3.44.
Which one should is the preferred choice? This is a difficult question to answer
since it depends on unknown requirements (e.g. memory, speed etc.).
My recommendation is to choose one of the two cheapest MCUs in the table.
The MPC5534 and the LPC2939 both fulfills the system’s requirements and they
3.11 MCU
MCU
MPC5534
MPC5554
MPC5567
LPC2939
77
Available GPIOs
65
130
94
68
CPU freq.
80 MHz
132 MHz
132 MHz
125 MHz
Flash memory
1 MB
2 MB
2 MB
768 kB
Price
$20
$35
$40
$15
Table 3.45. This table presents the possible MCU choices after excluding MCUs with
too few GPIO pins. It is presented how many GPIO pins the MCU have in addition to
the required 124 GPIO pins. The table also presents an approximation of the MCUs’
prices.
are in the same price-segment. Compared with the two more expensive MCUs
they cost approximately half as much.
If a requirement, in Table 3.44, would increase so that none of the MPC5534 or
the LPC2939 no longer fulfill the requirements, it would be possible to use two of
these MCUs and still get a cheaper solution than if the MPC5554 or the MPC5567
is chosen.
Recommended MCU choice
Which one, of the MPC5534 and the LPC2939, is the best choice for the system?
It is a dead heat between the two MCUs and therefore I recommend to choose the
cheapest one of the two, that is the LPC2939. The LPC2939 device offer good
performance relative its low price and is therefore the device that I recommend to
choose.
A selection of the LPC2939’s features is listed in Table 3.46.
Part
MCU
Flash memory
GPIO pins
ADC cores
A/D pins
Specification
125 MHz
768 kB
152
3
16
Table 3.46. LPC2939 specification
3.11.3
Conclusion MCU
In this section it has been investigated which MCUs that fulfill the system’s requirements. Investigations show that four MCUs fulfill the requirements. The
LPC2939 is the MCU that is recommended to use since it fulfill the requirements
and offers a relative low price.
The MPC5534 also fulfills the system’s requirements. This device is also a
reasonable choice and gives approximately the same performance as the LPC2939.
78
System Research
The reason it is not the recommended choice is that it is slightly more expensive
than the LPC2939.
Chapter 4
Summary
The goals of this report were, 1) to investigate problems that have to be face in
the design of an electrical control unit (ECU); and 2) to research the requirements of modern ECUs. Investigations of problems have been made and typical
requirements of a modern ECU have been presented.
The following properties are desired in a modern ECU:
• Long lifespan
• Extensive error detection
• Expandable
• General design
• Low cost
The investigations in this report have focused on how to give the system these
properties. An overview of the resulting system can be seen in Figure 4.1.
Here is a selection of issues that have been investigated during this thesis:
• Inputs/Outputs: It has been investigated which requirements that typical
I/Os1 put on the system and how the system can deal with these requirements.
• Analog-to-digital converters: Speed, resolution and pin requirements
have been researched. Multiplexers are proposed to deal with the pin requirement.
• Multiplexers: Multiplexers were introduced to deal with the required high
amount of pins. Requirements (i.e speed, pin) of the multiplexers were analyzed.
• General-purpose inputs/outputs: Requirements of GPIO pins that the
system has to fulfill have been investigated.
1 motors,
sensors and solenoids
79
80
Summary
Solenoids
Sensors
Motors
I/Os
Temperature
Sensors
Multiplexers
Acceleration
Sensors
ADCs
Water
Sensor
Power-Supply
Block
Memory
Block
MCU
CAN
Interface
Other
MCUs
ECU
System Battery
Figure 4.1. An overview of the system. The illustration shows the ECU’s main components and the system’s I/Os. For detailed information of each subpart, please refer to
Chapter 2 and Chapter 3.
• Controller Area Network: Potential problems that the CAN-bus can
experience have been analyzed. How to detect these problems and which
requirements the detection puts on the system have been investigated.
• Power Supply: Potential problems that can occur with the power-supply
and how to detect these problems have been researched.
• Battery: A solution of how to monitor the health of a battery has been
proposed.
• Environment: Different environment issues have been investigated, e.g.
how to measure temperature and how to detect if water is in the system.
• Memory: Serial and parallel interface memories have been analyzed. Pros
and cons of the two have been proposed.
• Microcontroller: The requirements of the system’s MCU have been specified. A off-the-shelf MCU that fulfills these requirements has been proposed.
This report does not present a fully specified description of an ECU but rather
an overview of how an ECU can be designed and recommended approaches of
solutions to typical problems that an ECU has to face.
4.1
Future Work
• Continue with more detailed research: This report has investigated
many areas of concern when developing an ECU. No fully specified solution
4.1 Future Work
81
has been presented and more investigations are needed to develop the system
shown in Figure 4.1 into a fully specified system.
• Power consumption: No focus has been on the power consumption of the
system. This has not been done since power consumption has not been seen
as a key issue in the development of an ECU for agricultural vehicles. If
an ECU will be used in an application where power is considered to be a
critical issue there is probably many things in the purposed system that can
be redesigned.
• Vehicle measurements: A solution has been purposed of how to detect
the vehicles acceleration. The presented solution use an accelerometer to
measure the acceleration. It has been said that this accelerometer might
be able to measure vibrations in the ECU. To make sure if this is the case
measurements from the actual vehicle have to be performed.
• Memory: No investigations have been made of how much memory the
system requires. To accurately approximate the required amount of memory
more research is required.
• Power capability: The TJA1041 device has been suggested as powersupply for an ECU. To make sure that this device can deliver enough power
more investigations are needed.
• External interrupt: It has been suggested to use a MCU’s built-in support
for external interrupts to detect incorrect pulse-widths (see section 3.5.7 on
page 50 for more information). Since none of the MCUs’ datasheets have
specified how fast they can trigger on external interrupts, measurements are
needed to make sure that the MCU can trigger fast enough.
Bibliography
[1] Internet. http://fotosa.ru/stock_photo/Westend61_RF/p_1764382.jpg.
[2] Internet.
jpg.
http://www.caesar-datasystems.com/Images/Applikationen/JD01.
[3] Internet. http://www.nemotors.co.uk/wp-content/uploads/fiat_ecu_small1.
jpg.
[4] Internet.
http://www.geocities.co.jp/Playtown/3457/jicasv03/images/
dcmotor_dme34.jpg.
[5] Internet.
http://www.arrowne.com/innov/in215/pics/issue14_nxp_lpc292x_
lr_jpg.jpg.
[6] Internet.
http://www.phxmicro.com/Training/Freescale/freescale_Chip/
MPC5567.png.
[7] Internet. http://dev.emcelettronica.com/files/u9973/stm32_01.jpg.
[8] Internet, June 2006. http://upload.wikimedia.org/wikipedia/commons/thumb/
d/d4/H_bridge.svg/461px-H_bridge.svg.png.
[9] AVX. NTC SMD Thermistors. AVX. http://www.avx.com/docs/catalogs/
nc12-20.pdf.
[10] Michael Barr. ntroduction to pulse width modulation (pwm). Internet. http:
//www.netrino.com/Embedded-Systems/How-To/PWM-Pulse-Width-Modulation.
[11] John Catsoulis. Designing embedded hardware. O’Reilly, first edition, November 2002. ISBN:0-596-00362-5.
[12] David Cook. Dc motor-driver h-bridge circuit. Internet, February 2010. http:
//www.robotroom.com/HBridge.html.
[13] NIDEC SERVO CORPORATION. DME34. NIDEC SERVO CORPORATION. http://www.japanservo.co.jp/digital/english/general/pdf/DME34_6.
pdf.
[14] Analog Devices. ADG706/ADG707. Analog Devices, rev.a edition, June 2002.
http://www.analog.com/static/imported-files/data_sheets/ADG706_707.pdf.
83
84
Bibliography
[15] Elobau. Angle sensor with plain bearing. Elobau. http://www.elobau.com/
produkte_1.php4?IDD=178.
[16] Energizer. Battery internal resistance. Technical Bulletin Version 1.1.0, December 2005. http://data.energizer.com/PDFs/BatteryIR.pdf.
[17] Duplomatic Hydraulics. DS3 SOLENOID OPERATED DIRECTIONAL
CONTROL VALVE. Duplomatic Hydraulics. http://www.duplomatic.com/
duplomatic/oleo/pdf/E/41150A.pdf.
[18] Infineon.
Door Module Power IC TLE 8201R.
Infineon, rev
2.0 edition, June 2006.
http://www.infineon.com/dgdl/Datasheet_
TLE8201_Rev20.pdf?folderId=db3a304412b407950112b408e8c90004&fileId=
db3a304412b407950112b409a5f20326.
[19] Infineon.
2007.
BTS
5236-2GS.
Infineon,
v1.1
edition,
July
http://www.infineon.com/dgdl/BTS5236-2GS\DS090707.
pdf?folderId=db3a304314dca389011537739e37155f&fileId=
db3a304314dca38901156014b0e71dcc.
[20] Texas Instruments. CD74HC4067,CD74HCT4067. Texas Instruments,
july 2003 edition, February 1998. http://focus.ti.com/lit/ds/symlink/
cd74hc4067.pdf.
[21] Texas Instruments. SN54LV4051A,SN74LV4051A 8-CHANNEL ANALOG
MULTIPLEXERS/DEMULTIPLEXERS. Texas Instruments, april 2005 edition, May 1999. http://www.ti.com/lit/gpn/sn74lv4051a.
[22] Murata. NTC Thermistors for Temp. Sensor and Compensation Chip Type.
Murata. http://search.murata.co.jp/Ceramy/image/img/w_hinm/L0770E.pdf.
[23] NXP. TJA1041/1041A high speed CAN transceiver Application note. NXP,
rev.03 edition, November 2006. http://www.nxp.com/documents/application_
note/AN00094.pdf.
[24] NXP. TJA1041 High Speed Can Transceiver. NXP, rev.06 edition, December
2007. http://www.nxp.com/documents/data_sheet/TJA1041.pdf.
[25] NXP. LPC1768/66/65/64. NXP, rev.02 edition, February 2009. http://www.
nxp.com/documents/data_sheet/LPC1768_66_65_64.pdf.
[26] NXP.
LPC2939.
NXP, rev.01 edition, June 2009.
http://www.nxp.com/
documents/data_sheet/LPC2939.pdf.
[27] Akiyoshi Okawa. Murata Leverages on NTC Thermistor to Sense Temperature. Murata Manufactoring CO, January 2009. http://www.murata.com/
products/article/pdf/ta08a1.pdf.
[28] Omron.
Internet.
http://images.industrial.omron.fr/IAB/Products/
Sensing/Inductive%20Sensors/Compact%20-%20Cylindrical/E2A/images/
E2A-M18_img400x400.jpg.
Bibliography
85
[29] Omron. Cylindrical Inductive Proximity Sensor E2A Single Sensing Distance. Omron. http://industrial.omron.eu/en/products/catalogue/sensing/
inductive_sensors/compact_cylindrical/e2a/default.html.
[30] FreeScale Semiconductor. MPC5567 Microcontroller Data Sheet. FreeScale
Semiconductor, rev.1.0 edition, November 2007. http://www.freescale.com/
files/32bit/doc/data_sheet/MPC5567.pdf?pspll=1.
[31] FreeScale Semiconductor. MPC5534 Microcontroller Data Sheet. FreeScale
Semiconductor, rev.4.0 edition, March 2008. http://www.freescale.com/
files/32bit/doc/data_sheet/MPC5534.pdf?pspll=1.
[32] FreeScale Semiconductor. MPC5554 Microcontroller Data Sheet. FreeScale
Semiconductor, rev.3.0 edition, November 2008. http://www.freescale.com/
files/32bit/doc/data_sheet/MPC5554.pdf?pspll=1.
[33] FreeScale Semiconductor. 10XS3412. FreeScale Semiconductor, rev 10.0
edition, October 2009. http://www.freescale.com/files/analog/doc/data_
sheet/MC10XS3412.pdf?fpsp=1.
[34] STMicroelectronics. L6370. STMicroelectronics, rev 7 edition, June 2007.
http://www.st.com/stonline/products/literature/ds/4282.pdf.
[35] STMicroelectronics. STR91xF. STMicroelectronics, rev 4 edition, February
2007. http://www.st.com/stonline/products/literature/ds/12274.pdf.
[36] STMicroelectronics. L9950. STMicroelectronics, rev 10 edition, June 2009.
http://www.st.com/stonline/products/literature/ds/10311.pdf.
[37] STMicroelectronics.
STM32F103x8.
STMicroelectronics, rev 11 edition, September 2009. http://www.st.com/stonline/products/literature/ds/
13587.pdf.
[38] TDK. NTC Thermistors. TDK, 010-01 edition, May 2009. http://www.tdk.
co.jp/tefe02/eb221_ntcg.pdf.
Appendix A
CAN-bus Measurements
87
CAN-bus Measurements
88
Figure A.1. CAN-bus 4m cable with termination resistor mounted
Figure A.2. CAN-bus 4m cable with termination resistor unmounted
89