Selection of a Microcontroller for an Engine Management System

Chris Vondrachek

EE 433 – 10/1/99

Introduction

An engine managements system for an internal combustion engine is perhaps one of the most difficult microcontroller applications. Modern engine management systems control nearly every part of the engine and do so in a very challenging environment. The temperatures are high, electromagnetic (EMI) and radio-frequency (RFI) interference are present in very high levels, vibrations from the engine and the road constantly shake the system. Despite all this, the system must constantly monitor dozens of sensors on the engine and make thousands of adjustments per second to keep the engine running smoothly and efficiently. To do this a microcontroller selected to implement an engine management system must find the balance between maximal reliability and optimum performance… not an easy task.

In order to optimize for both performance and reliability (at the system level) and ease design, it is desirable to select a controller with the greatest amount of required peripherals integrated on chip. This includes I/O devices like an analog to digital converter or a pulse width modulator. Also included are memory devices like Flash EEPROM, or SRAM. The following section explains what devices or features are required to easily implement an engine management system with a microcontroller.

System Requirement Specification (SRS)

CPU Type and Data Width Capability

When specifying components for a desktop PC’s, the speed of the CPU is among the top concerns, however this is not always the case for an embedded system. For an engine management system it is much more important to have an excess of I/O and peripherals. Regardless the CPU still plays a critical role in the operation of the system. Choosing the type is not difficult; given that the firmware will be developed using low level assembly language, it seems that a CISC type CPU may be a better choice. The long list of familiar commands makes it easy to quickly generate straightforward and readable algorithms. The benefits are sure to be realized when debugging the code.

Again, where PC’s are more concerned with the actual width of the entire data path, embedded system are simply concerned with the maximum width that can be easily handled. In this case we must define the desired accuracy and target a data width accordingly. Given that an engine management system has little need to access more than 64kb of data and code, an address width of 16bits is acceptable. Further given that it is not expected that the microcontroller will need to generate quantities in finer steps than 1/65,535 (eg If 0xFFFF = 10ms pulse width therefore 0x0001 = 1/6553 ms). It is also unlikely that the system will have to regularly count in excess of 65535. There for internal registers that are 16bits wide will be sufficient. Wider data can be handled with special code.

Analog to Digital Converter (ADC)

Most engine management systems today incorporate at least three basic sub-systems. These are: the electronic fuel injection system, the electronic ignition system, and the driver interface system. All three systems depend upon data that must be gathered from analog sensors mounted on the engine. In order to covert the analog signals into a binary format that the core CPU can easily manipulate, an analog to digital converter (ADC) is required. In order to obtain the accuracy necessary for making fine adjustments, a minimum accuracy of 8 bits is required for a 0-5v range. This will yield a step of 19mV per bit, which approaches the average noise level in the automotive environment.

Time Processing Unit (TPU)

In addition to the DC analog signals there are a handful of AC timing signals that the CPU must be able to measure and synchronize outputs to. In order to do this, a 16 bit time processing unit (TPU) is needed to help the CPU measure the pulse width and period of the incoming signals. A TPU is also capable of interrupting the CPU on rising or falling edges of the input signals.

Armed with all the data from the engine, the CPU and complimenting firmware is very capable of calculating all the required output values (timings). However, the CPU is not well equipped to generate the output waveforms itself. Instead a TPU can also be used to output waveforms with the same timing accuracy that it uses to measure incoming signals.

Pulse Width Modulator (PWM)

In order to control various mechanicals like throttle opening, it is necessary for the engine management system to be able to operate electro-mechanical servos. Standard servos require a precisely timed AC signal to indicate what angular position it should seek. A pulse width modulator (PWM) can be used to generate these signals and do so independent of the CPU. For this application, a 8bit, 3 channel PWM is all that is needed.

General Purpose Digital Inputs / Outputs (GPIO)

Aside from the various analog and AC timing signals, a engine management system requires many digital I/O’s to measure conditions like key position or output signals to operate relays etc. This application needs a minimum of 20 configurable digital I/O lines.

Internal Flash EEPROM, EEPROM, and SRAM

In order to store system code and data, it is desirable to use a microcontroller that contains a suitable amount of Flash, EEPROM, and SRAM. The integration of these storage areas greatly simplifies system design and enhances overall reliability. In an application like an engine management system it is important to have semi-volatile storage so that the system can “learn” from its mistakes. Byte-erasable/programmable EEPROM is about the only option for this requirement. It is also important to implement all semi-permanent data and code into Flash, so that it may be easily updated as bugs are found and fixes generated. For an average engine management system, a Flash size of 24kb is more than enough. The size and type of RAM required is dependent upon the expected need, for a average engine management system 2kb of SRAM is adequate.

Serial and Parallel Interfaces

Although the goal is to integrate as much of the engine management system onto a single microcontroller chip, it is still necessary to communicate with external components. For example a driver information LCD module may require data from the core microcontroller. For such an application, a medium speed (10-100kbit/s) serial interface would be perfect. A second serial interface could be used for a diagnostic port designed for system troubleshooting and monitoring.

The presence of a parallel interface / bus is useful if system code and data are expected to consume more memory space than available on chip. The bus could be used to expand either non-volatile or volatile memory.

Clock Speed and a Versatile Interrupt / Exception System

We’ve neglected to define one very important requirement for an engine management system; core CPU speed. Embedded systems usually do not require ultimate processing speed to accomplish their tasks like PC’s do; usually the processes that they control or monitor move too slowly to require anything more than a 50 MHz clock. However, there is still a minimum requirement to control an engine.

In this case, the successful operation of an engine management system is very dependent on the timing of the injection pulses and ignition coil firings. In order to ensure that the injectors and ignition coils are always actuated on time, and for the right amount of time, the firmware for this engine management system models a real-time, interrupt driven operating system. In such a system, critical events like the firing of the injectors or coils are setup to interrupt the CPU when they require attention. This means that the CPU executes a loop of non-critical, information gathering and calculating code while it is waiting for any interrupts.

The requirement for microcontroller clock speed is set by three factors: maximum engine rpm, the non-critical loop execution cycles and desired sensor data update rate (per engine revolution). The minimum clock period can then be determined by calculating the amount of time it takes the engine to complete one rotation at max. rpm, dividing it by the desired sensor data update rate, and then dividing it the number of cycles required by the non-critical loop. The minimum frequency is then just the inverse of the calculated period.

This is only an approximation and neglects many possible sources of delay, including the interrupt routine execution time. However, for an average engine management system running an engine with a max rpm of 7000 and a info gathering code loop of 500 generous cycles, the above formula requires a clock speed of only 583kHz for a sensor data refresh rate of 10 times per revolution. Modern basic microcontrollers run anywhere from 2-16MHz with higher end models spanning the sub 100MHz region. Clearly a simple engine management system will not tax the processing speed of an average controller.

Tolerant to Automotive Environment

While home PC’s enjoy a life sitting on a desk at 20-40C, a microcontroller selected to implement an engine management system must endure a very harsh environment. With a temperature range of –20 - 120C, severe vibration, and maximum EMI/RFI, the selected microcontroller must be able to operate flawlessly. For such conditions, the controller has to be designed from the beginning as a robust unit. It must be able to tolerate droops in supply voltage, clock jitter, and noise on external and internal signals.

SRS Summary – Engine Management System Microcontroller

o  16 bit, CISC CPU, 8MHz

o  Designed with the automotive environment in mind (or equiv MILSPEC)

o  Wide range of integrated peripherals:

o  Analog to digital converter – min 8 channels, 8-10 bit.

o  Pulse width modulator – 3, 8bit channels

o  Timer processing unit – 8, 16bit channels, inputs or outputs, each with separate compare register and individually configurable for interrupt generation

o  Serial interfaces – 2, 8 bit RS-232 compatible, 1 dedicated debugging port for ITP.

o  Parallel Interface / Bus – 8/16 bit with corresponding control signals

o  Integrated memory:

o  24kb internal Flash EEPROM, field programmable

o  1kb internal EEPROM, byte-erasable/programmable while in operation

o  2k internal SRAM

o  General purpose I/O – at least 20 available pins.

And the choice is…..

Before coming to a final decision, microcontroller offerings from Intel, Harris, Microchip and Motorola were considered. The final decision was based heavily on the fact that the author is extremely familiar with a certain brand and family of microcontrollers; Motorola HC11/HC12. Motorola offers the MC68HC912B32 (HC12); a true 16 bit microcontroller that meets or exceeds all of the items in the above SRS. The HC12 is a rare example of a microcontroller that integrates SRAM, Flash, and EEPROM all into one package… an extremely important requirement to the engine management system as defined above. The HC12 also includes fuzzy logic and interpolation instructions that will be useful in determining injection pulse width times from sensor data. The HC12 also runs at 8MHz which allows lots of room for code expansion with out “running out of time”. The only drawback is that the HC12 only integrates 768b of EEPROM which is less than the 1kb required by the SRS. This is of little concern considering the benefits provided by the other features. The remaining specs on the HC12 are outlined below:

o  16 bit CPU, runs DC-8MHz

o  Designed with the automotive environment in mind

o  Integrated peripherals:

o  ATD – 8 channels, 8 bit.

o  PWM – 4, 8bit channels or 2, 16bit channels

o  Timer – 8, 16bit channels, each fully configurable for input or output capture (and interrupt)

o  Pulse Accumulator – 16bit

o  Serial interfaces – 2, one synchronous and one async

o  Parallel Interface / Bus – 8 or 16 bit (narrow and wide mode), multiplexed address/data

o  Integrated memory:

o  32kb internal Flash EEPROM, field programmable

o  768b internal EEPROM, byte-erasable/programmable while in operation

o  2k internal SRAM

o  General purpose I/O – upto 63 available pins.

o  COP Watchdog timer

o  Single wire background debug mode (BDM) for ITP