PC's and EFI

Terrie S. Watts terriesue2 at email.msn.com
Wed Mar 18 07:24:05 GMT 1998


-----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 esl.eng.ohio-state.edu <diy_efi at esl.eng.ohio-state.edu>
Date: Tuesday, March 17, 1998 10:59 PM
Subject: Re: PC's and EFI


>That's an interesting diatribe - true, as far as I can tell.  I, too, am
>experienced with PCs.  I'm writing this on a Cyrix 200 MMX with 64M of
>static RAM, 2.5 gig HD, 24X CD, etc. that I put together myself.  I write
>programs for a living.
>
>The point that may have been missed is that you don't need even a 486 to
>run a fuel injection system.  I have a 386/25 board in my basement that I
>am going to give away, and a couple of 286 boards that I can't even give
>away.  Any of those would be sufficient for the job.

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'm pretty much convinced at letting an embedded system or even
programmable logic (as in my case) handle the low-level details and
then using a PC compatible to data log and generate improved fuel
and spark maps on a semi real-time basis.  A PC really isn't designed
for real-time control applications but can be fudged with to get a
pretty good data logging and monitoring system.

>If I needed another hobby and wanted to build my own controller, I would
>probably use a PC, since all the interrupts and memory handling and
>stuff like that is already done.  You can control eight injectors with
>the parallel port and a handful of transistors.  You can add a couple
>more parallel ports if necessary, or use a couple of the handshake lines
>on the serial ports.  The game port will provide for some variable
>voltage inputs, such as the MAP sensor, the O2 sensor, the TPS, etc.  I
>believe that you can get four analog inputs.  If you need more, get a
>sound card.  If you want some digital inputs, the game port has a few of
>those.  So far, I have discussed nothing that would require that you mess
>with the ISA bus or actually modify the computer.  It would require a
>minimal amount of electronic knowledge that can be learned from some of
>the small "engineer's notebooks" that you find at Radio Shack.


If anyone is dying to try this, get some opto-isolators in between the
computer and the engine, so I won't have to say I told you so later on.
PCs are digital machines and really don't have optimum methods of
gathering analog data.  One can always use resistor/capacitor circuits
with the internal timer to get rough data, but it takes some knowledge
in electronics and some trial and error to get it to work the way you
want it to.

>As far as a monitor, you would only need that for the initial setup.  You
>could get one of those $20.00 DC/AC inverters that they sell in the
>Damark catalog and power up the monitor until you have it all tuned.


Anything that gives you enough information during a run will do.
If you can fit your monitor screen on an LCD display, that will work
fine.  I'd match my display to the type of keyboard you decide to
use.  If you're trying the keep the whole unit fairly small, a big
clumsy keyboard will really seem out of place.  Having the
computer boot right into your application with some custom
buttons may be a better solution.  You can always attach the
keyboard again when you get back in the shop.

>The software wouldn't necessarily be very big.  You could probably load
>it from floppies.  A couple of 1.2 or 1.44 floppies would make a good
>backup if the board loses its power and you need to reload the program.


My assembly code was tight and fast, about 5k--storage shouldn't
be a problem.  I would recommend a Flash chip since it's fast and
straight forward.  Even battery backup will work out well to keep
everything you need resident in memory.  If you're going to do data
logging then you'll likely need some sort of disk drive unless you
compress your data as you collect it.  If you try to store everything
in memory, remember that you'll have some limited amount of
recording time to get the data you're after.

>That's the dirt-cheap method.  Most of the stuff I mentioned could be
>gotten for free or very cheaply.  If you want to spring for a used
>laptop, you could use the same methods and the same program.  I bought a
>486-50 for less than $400.00 and used it to program my Holley Pro-Jection
>system.  I power it with its 110V power supply and an inverter that I got
>from Damark.
>
>The advantage of using a used laptop is that you can set up a display
>that gives you the outputs of the sensors, the O2 correction, the
>injector volume, etc.  You could also store that data to the hard drive
>for later analysis - much like the Holley Pro-Jection 4Di system does.
>Best of all, you could load the system on the laptop that you normally
>use for business or whatever and have an emergency backup if the laptop
>that runs the car ever dies.
>
>I would probably use MS DOS 6.22 as the operating system because there
>is so much software available for it.  If you're using an old 386 or 486,
>you can get the older software really cheap or free.  If you are using an
>old motherboard and a couple of floppy drives, I would suggest an old C
>for DOS compiler so that the resultant executable will be small.  If you
>are using a laptop, go with whatever you're used to.


I'd bet that you end up writing the code in assembly language or at
least tweaking the assembly code produced by your favorite compiler.
The OS will only be a boot strap to your custom program which will
take over the entire processor when it executes.  The OS will only
be used for "handy" system calls and what not, so don't worry about
it too much.  The program I wrote took over all the interrupt routines
and reconfigured the interrupt and DMA controllers to do exactly what
I needed and then put everything back when it exited.

>Another option is to use Unix, or one of the shareware Unix work-alikes.
>That way, you don't need a monitor.  Just load the system and talk to it
>with a laptop and an RS232 cable and nullmodem adapter.  That would make
>the system quite similar to the Holley Pro-Jection 4Di system.


You can always redirect the DOS standard I/O to a COM port
as well.  This works pretty well if you don't want to pack around
a lot of baggage on the system you're building.  A Linux kernel is
a bit bigger than DOS which you'll end up overriding most of
anyway.

>After you get the basic system working, you could start playing with
>other stuff.  You could control your automatic transmission with it.  You
>could put a pushbutton on your steering column that would lock up the
>torque converter for compression braking, and program the computer to
>release it if the engine is in danger of dying.  You could make your own
>antilock brakes.  If you have a 4WD vehicle, you could use the system to
>slow down the spinning when one wheel of the four loses traction.  If
>you're really a glutton for punishment and want to do some tricky
>programming and testing, try to duplicate the skid control system that
>one of the German auto manufactures developed.


Again, remember that all of this processing doesn't happen simultaneously.
If you don't have any idle clock cycles to take on more work, then
something is going to give.  I learned the hard way when I tried to
add in a self tuning algorithm and ended up missing a spark event
which finally happened about 90 degrees BTDC on the next cycle.
Needless to say the engine quit quite abruptly--broke a bolt right
off the Dyno mount when the engine kicked back.  Them little
Honda engines are pretty tough--wouldn't try it with a 20 gran
race motor on my first attempt.

Building a system like I did is a very useful exercise, but you'll be
hard pressed to end up with a "ready for primetime" unit.  If anyone
would like more info let me know.

The system I'm building now uses a USB microcontroller which
interfaces to a newer PC very nicely and allows you to see and
modify what's going on inside as it runs.  It's kind of like a
multipurpose CPU with a built-in serial link.  It runs at 12MHz
and requires practically zero additional hardware to make it do
something useful.  So far I'm very impressed with it.


Matt Watts (mwatts at facility.cs.utah.edu)
University of Utah
Department of Computer Science
Formula SAE Racing
___________________









More information about the Diy_efi mailing list