PC's and EFI

[Raymond C Drouillard]

On Wed, 18 Mar 1998 01:23:15 -0600 "Terrie S. Watts" 

>Careful here.  I'm a pretty good programmer myself and I actually tried
to
>write a fuel injection (plus ignition control) on a 100 MHz Pentium
laptop in
>straight assembly code and still found by way of the O-scope that I
wasn't
>servicing multiple events quick enough.  It's much tougher than it would
>first appear.  It can still be done but one needs to throw a little more
>hardware at the problem to really get it working correctly.  The big
problem
>is that the CPU executes but a single instruction at a time and there is
>quite a bit of things having to do with the engine all happening
simultaneously.
>I found myself in a priority battle trying to determine what absolutely
has
>to happen next and what could wait several clock cycles to get around
to.
>This strategy shows up on the scope and leads to quite a bit of head
>scratching when the engine just doesn't seem to run up to snuff.

I would be the last one to try to argue my theory against your
experience.  I based my information on the fact that someone made a
usable system with a 4.77 MHZ PC running BASIC.  Based on what you said,
I suspect that he got away with it because he was running a TBI system
with no spark control.  Also, a 386/25 is many times faster than a PC.

The method I had in mind for controlling eight injecters wouldn't take
much more processer time than running one.  The part of the program that
controlls the would send a string of 1s and 0s to another routine that
would send 00000000 to the parellel port when it receives a 0, and
00000001 or 00000010 or whatever (depending on which injecter is being
fired) to the parellel port.

How did you control the time sharing?  If necessary, some custome device
drivers could be written.

I saw some comments on using SCSI or IDE controllers.  That would
certainly work. The approach I'm going with, howeverl, is the KIS (keep
it simple) approach.  I want to use the devices that are designed to talk
to something outside of the computer.  That saves some potential for
hassle.

If you want to control eight spark coils, for instance, you could have
the computer send out a couple bytes of data through a serial or parellel
port.  The computer would instruct the controller which plug to fire and
when to fire it.  The computer could then go on to other things.

The real trick is to not require the microprocessor to actually fire
something at a specific time.  It should calculate when and how much,
then load that data to something else.

A sound card could easily create a waveform that'll fire an injecter. 
Just route it to the correct injecter (perhaps based on input from an
RS232 port), and amplify it.  If you use a sound card with a programmable
wave table, you can set up a variety of duty cycles and durations. 
That'll offload a lot of processing from the microprocesser.

I don't know how much goofing around it would take to get the computer to
read two game ports at once, but it shouldn't be too difficult.  It might
just be a matter of assigning addresses for each one.  You'll need
several analog inputs.  The output of the various sensors can be
conditioned with op-amps and fed into the game port and sound card.  This
would give you a total of six analog inputs. You will need an input for
the coolant temperature, the air intake charge temperature, MAP (or MAF),
and TPS.  Digitan inputs would be some kind of knock sensor (sound or
ionization) and crank position.

Now you guys did it!  Got me thinking about a project that I don't really
intend to undertake.  Sometimes, it's tough being a compulsive engineer.

Ray Drouillard, BSEE

_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]