Multi-processor EFI

[Bernd Felsche]

John Dammeyer writes:

>>------------------------------
>>From: "Jack E. James" <indyjj at indy.net>

>>Hi Bernd,
>[snip]
>>controllers becomes available, it would seem that there might be
>>an advantage to separating cylinders, like two identical 4
>>cylinder controller's for a V8.  Two ignition sensors (like
>>Pertronix modules switching resistor loads to provide position
>>logic) and parallel mass air flow or 2- MAF units for less air

That's actually done in many multi-bank engines. Only recently has
there been sufficient "processing power" been available to run a V8
as well on a single CPU - according to the big makers anyway. ;-)

>>flow loss.  Or one controller for part throttle and another for
>>full throttle.  Just curious about multiple processors, having
>>thought about using some of the faster PIC,s for each cylinder.

Running each cylinder on its own is probably not that good an idea
IMHO as it's the whole engine you need to control. The necessary
interchange of information is probably going to be the limiting
factor.

>>Jack

[interesting bits snipped]

>Fascinating question though.  If absolute position information is
>available for each cylinder then designing a single PIC or ATMEL
>processor on a per cylinder basis would be an interesting project
>and certainly scalable up to V12 engines.  It gets more complicated
>if you wish to use the newer 'waste spark' coils because now you
>need to work with two cylinders at a time and handle overlapped
>injector timing.

Depends how you group the cylinders - space them at 360 degrees
apart and allow for an injector off-on during each rev. That doubles
the minimum close time of the injector which reduces the maximum
delivery by a small margin and decreases injection accuracy by a
small amount.

The VW Digifant starts an injector cycle for each TDC and BDC.
(Much like L-Jetronic.) That's every 180 degrees of crank because it
runs 4 cylinders and 4 injectors at once. There's no absolute
position available.

Nor is it useful because all injectors wired in parallel and
separate wiring would require another output (which is "available")
and a separate harness/connector-pin to group the injectors.

>i.e. With a one cylinder engine and a 720 degree cycle you have a
>total of 4 events to manage; Injector on/off and coil current
>on/off.  A two cyl. engine doubles this along with overlapping
>injector times depending on engine load and the complexity at that
>point isn't any more difficult than 4 or 6 or 8 or 12 assuming the
>processor is fast enough relative to engine speeds.

You could use a common interrupt (clock) for crank position. Each
PIC can be told to watch for a particular clock tick for each event.
There is the constraint of feeding counter information quickly to
the PICs in time.  It's conceivable though, that a "broadcast" to
all the PICs could be used to give base information and to have each
perform some simple arithmetic to determine appropriate trigger
values. Think of it as having a scalable number of counters with
multiple output-compare registers (OCRs). 

With a small number of cylinders and "common" events, that's not
necessary, especially if you can reset the OCRs quickly enough.

>Now let's talk cost.  The four cyl. controller I designed drives
>two coils through a Capacitive Discharge technique and also drives
>4 injectors using two VND05 devices.  So this could be scaled back
>to a two cylinder project at the cost of doubling up the Coil and
>Capacitor storage section which is shared.

>But... The cost of the processor, EPROM and RAM are insignificant
>compared to the cost of the interface circuitry, circuit board, the
>box, the connectors and the CAN network used for debugging.

Read about internal packaging option below.

>Just throwing two MAP sensors into the engine for two controllers
>raises the price far to much compared to what you would gain.  Even
>with single quantity pricing,  a single C167 or Motorola 16/32 bit
>processor on one circuit board is still less expensive than bank of
>8 individual processor boards.

If you look at the possibilities presented by high-speed
inter-processor busses and cheap packaging options such as SIMM,
then a scalable option, at least for the data-acquisition and driver
sections becomes attractive.

The high-level control strategy is probably better achieved by
a "proper" CPU with sufficient address and physical memory space as
well as crunch capability, driving the slave processors.

I initially brought up the possibility of using multi-processors as
a means of expanding capabilities of the specialised chips which,
for example, cannot address external memory directly. Atmel 8535 and
8515 (or 4414) working in tandem provide not only a large number of
analogue inputs, as well as digital I/O, but also direct
addressability of (64kbytes of) external SRAM. There's also the
bonus that they can flash each other in-situ, data provided
externally via a serial port.

>Good idea but not economically viable - especially for a hobby.

Like you, I doubt that one-PIC-per-cylinder is economically viable;
though it is intellectually stimulating.

The question of scalability remains: If you run out of capacity, do
you perform a leap in architecture, or do you use tandem processors
for the required functions?

For the "hobby" situation, the 8-bit (or even PIC) solution is
attractive to get started. Running several in tandem may be a good
way for you to grow a system whilst building on proven subsystems.
Eventually, I guess, you'll "hit the wall" and have to leap to a
more complex base architecture.

The trick may be to gaze into the crystal ball and see where that
wall is located - and see if it matters.

-- 
Real Name: Bernd Felsche
    Email: nospam.bernie at perth.DIALix.com.au
	http://www.perth.dialix.com.au/~bernie - Private HP
----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org