* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Institutionen för systemteknik Department of Electrical Engineering
Survey
Document related concepts
Oscilloscope history wikipedia , lookup
Radio transmitter design wikipedia , lookup
Operational amplifier wikipedia , lookup
Surge protector wikipedia , lookup
Power MOSFET wikipedia , lookup
Schmitt trigger wikipedia , lookup
Immunity-aware programming wikipedia , lookup
Integrating ADC wikipedia , lookup
Switched-mode power supply wikipedia , lookup
Microcontroller wikipedia , lookup
Valve RF amplifier wikipedia , lookup
Resistive opto-isolator wikipedia , lookup
Power electronics wikipedia , lookup
Current mirror wikipedia , lookup
Rectiverter wikipedia , lookup
Charlieplexing wikipedia , lookup
Transcript
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