Multiprocessor system

[ARTHUR OKUN]

You wrote: 
>
>I have been thinking about a fuel injection system composed of four 
68HC11
>microprocessors.  The first processor would run the ignition system.  
It 
>would have inputs from crank and cam sensors (no missing tooth in the 
crank
>senor for syncronization) and from the map sensor.  It would also 
receive
>6 bits of data from the master controller and 4 bits of control 
information.
>
>There would be two seperate (and identical) fuel injection systems.  
Each 
>would control 4 fuel injectors.  For a 12 cylinder engine, one more 
fuel
>injection subsystem could be added without change to the master 
controller.
>The only change would be in which crank trigger pulse was the "first" 
pulse
>for it.  All of these subsystems would receive 6 bits of data and 4 
bits of
>control information from the master controller.  All of the fuel 
injection
>systems would receive the same data, but it would be different (of 
course)
>than the data system for the ignition module.  These modules would be 
>fed data directly from the various inputs that they need to calculate 
>the correct amount of fuel.
>
>The master controller would cordinate everything for the other 
modules.  It
>would receive data from the cam position sensor (it needs to know how 
fast 
>the engine is running and if it is running at all), the knock sensor, 
>temperature, oil pressure, and others.  It would not be directly 
controlling
>either the ignition or the fuel injection.  Those modules run on there 
own.
>It would be able to tell the ignition system to advance or retard the 
timing
>a number of degrees through the data and control information.  It 
would also
>tell the ignition system if it should run or not.  It interfaces with 
the
>fuel injection modules in much the same way.  It tells then when to 
run, and
>it can tell it to richen or lean the mixture by a certain percentage.  
If
>the master controller tells it to lean out the mixture outside of the 
>boundaries for the mixture, the fuel injection controlers can set an 
error
>flag and keep running rich.  Blubbering rich being preferable to 
"piston
>melting" lean any day.
>
>This system would not use any type of data bus.  Do to the small about 
of data
>going to the sub modules (and data does not go to the master 
controller from
>the sub modules), there is no need for a data bus.  Also, each 
controller 
>runs its own program and deals with learning on its own.  One problem 
with
>this idea is that to change all of the programs (say to redefine the 
data), 
>you would have to pull all 4 eeproms.  Truthfully, this I can live 
with.
>Another advantage is that you could build and test the ignition system 
before
>you had to make the rest of the system.  This would at least let you 
know 
>that your timing information from the cam and crank senors was as you
>predicted.  Also, there is no shortages of input capture and output 
compare
>ports.
>
>One question I do have how should I buffer the various signals that 
need to
>go to multiple modules?  Would I have to?  Would the standard input 
filtering
>be enough of a buffer to feed up to 4 inputs simultainiously?  I would 
love
>to here everyones ideas and opinions on this idea.  I do beleive I 
will be
>looking into it somemore.  And if this idea was brought up in the past 
and
>well and throughly shot down, I appologize for bringing it up again.  
>Thanks for you input.
>
>Clint
>ccorbin at intel7.intel.com
>
tie all 4 micros to a 4 port memory  and youll have a common data and 
program pool ; this has been done before especialy in the old days
when ups ran at 1 megahertz.
question : who uses intel ups in automotive or engine control 
applications.