DIY_EFI Digest V5 #80

[John Dammeyer]

>
>Date: Thu, 2 Mar 100 09:45:00 +0800 (WST)
>From: Bernd Felsche <bernie at perth.dialix.com.au>
>Subject: Re: Multi-processor EFI
>
>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. ;-)

Depends on the level of controllability desired I guess.  For emissions control I suspect
that is true but for engine control less so.


>>>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.


This is what I was referring to later on in my previous posting.  By the time you add the
input filtering for each of the sensors for the individual boards your costs and
complexity go way up.  If you have common filters for the sensors and supplied the values
to the individual processors as linearized and scaled all on one board you're at the point
where the question is... why bother with a bunch of little processors and just use a big
one instead.

>[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

[snip]
>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've always considered 'proper' fuel injection as multi-port sequential so I tend to
forget that it's also possible to bank fire on each 360 crank stroke.

>>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.
[snip]

>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 who does the broadcast?  Another PIC?  That's 7 PICs for a 6 cylinder engine.

>
>>Now let's talk cost.

>Read about internal packaging option below.
>
>>Just throwing two MAP sensors into the engine for two controllers


>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.


Well... that same scalability is also there with a C167C 16 bit RISC processor
architecture though and it has a heap of
OCR type timers.  It has enough to dedicate one to each event (injector and ignition) and
is fast enough to handle everything.

I used the Philips 80C592 because it had 5 OCRs.  Even then I ran into timer sharing
problems because I used sequential injection and there are times when the new pulse width
for cyl. X will suddenly need to start before the pulse for cyl. Y by 5 or 6 clock ticks.
By the time the new compare values are installed and handled cyl X injector may turn on
but the turn on point for cyl Y is passed so the injector misses a cycle and results in an
engine miss.

>
>I initially brought up the possibility of using multi-processors as
>a means of expanding capabilities of the specialised chips which,
[snip]

Most of the smaller specialized chips (PIC in particular) are really poor at 16 bit math
operations and if your counter needs to handle timing between TDC and BDC at Cranking and
at 7000RPM you need to be able to manipulate 16 bit values.  Add to that the math to
handle enrichments and 32 bit results become a reality and the small 8 bit processors fall
flat on their face.  It can be done.  I just had to write a specialty 32 bit library of
routines for  a PIC used in a Oil Well Down hole operation (sin, cos, arcsin and square
root).  Physically the board was large enough to hold a C505C from Infinion but without
the Flash ability there would need to be a large program storage device.

>
>>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?


I'll do the leap in architecture.  The C167C can use an 8 bit external bus for program
storage and there are some nice FLASH parts around for holding code.  So if I do another
ignition/injection system,  I'd use the 167.  I'd have the RISC speed like a PIC,  large
program addressability and 16 bit math operations plus the built in A/D and OCRs.

For the bigger 8 bit family check out www.lawicel.com for the C505C with WSI
FLASH/EEROM/RAM/PLD as an example of what can be done inexpensively.  With the Keil or
Tasking compiler 32 bit longs (and floats) (although still clumsy) are available.
>

>The trick may be to gaze into the crystal ball and see where that

>wall is located - and see if it matters.


I have one of those....  but it's opaque.
>
>- --
>Real Name: Bernd Felsche


Cheers,

John


----------------------------------------------------------------------------
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