PC's and EFI

[Matthew B. Watts]

-----Original Message-----
From: Raymond C Drouillard <cosmic.ray at juno.com>
To: diy_efi at efi332.eng.ohio-state.edu <diy_efi at efi332.eng.ohio-state.edu>
Cc: diy_efi at efi332.eng.ohio-state.edu <diy_efi at efi332.eng.ohio-state.edu>
Date: Wednesday, March 18, 1998 10:05 PM
Subject: Re: PC's and EFI


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


Not to say that it can't be done, I'd just bet that it was cut way
down in terms of accuracy and the number of individual signals
being controlled.  Otherwise, I really need this guy to help me
brush up on my coding skills.

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


Sounds pretty straight forward, it's just the routine that determines
what these bits have to be and when they have to be that way, that
gets tricky.  Reminds me of an old boss I once had, "just a few lines
of code..."

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


There really wasn't any time sharing going on because it took everything
I had just to cycle through my event queing loop.  Any available time went
towards reading analog sensors.  I used basically the same concept found
in most embedded systems.  A routine that gets some data from a sensor
was only allowed to execute when I could guarantee that no event would
need to be serviced within some X timer ticks.  At 12000 RPM this ended
up being one sensor data point for every three revolutions.  I could still get
the spark and the injectors events to happen ontime, but they where based
on old data in most cases.  The engine would run this way, but wasn't
nearly as responsive as I wanted.  Seeing this happen first hand is what
made me wonder if other systems are doing the same thing.  Boy I'd be
pissed to plunk down three thousand bucks for a black box that was pulling
the wool over my eyes.  It's also why I began my development of a modular,
hardware based engine management system.

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


It's sure hard to find the right combination of devices that will do
exactly what you want.  Nothing seems to really be generic enough,
yet powerful enough to generate syncronized pulses of the correct
duration.  One would think that a simple printer port could handle the
job, but again, it's designed for a much different application and leaves
a lot to be desired.

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


What you really need is a controller that can keep the engine
running by itself at some particular setting without anything but
some initial values.  Then as the throttle changes, load changes,
et cetra, the computer outputs new data to compensate for the
changes.  The computer then becomes the error corrector, and
the faster it is able to provide new data, the more responsive the
engine becomes, up to some point where it is truely real-time and
able to provide immediate compensation for every sensor it is
monitoring.

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


Exactly.

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


True.  That's one sound card and associated I/O for each injector,
and in many respects it's overkill, since the wave table would need
to be constantly updated in order to get good engine response.  And
there we are again after one, two, maybe three revolutions have gone
by waiting for the processor to compute, rebuild, and output the new
wave table.  It's really difficult and I don't mean to sound negative.

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


It happens, and there is nothing wrong with saying "what if".  I think
that those HP folks say it all the time and it works for them.

We'd all like to build a simple, 50 dollar engine management unit that
would work even on an Indy car, but gettting from here to there is
going to take some serious work and a bunch of good ideas.
Keep them coming...

Matt
________