Note: The EFI332 project is defunct, and these pages are no longer being actively maintained.

Home
FAQ
Hardware
Algorithms
Software
Other Info
Links

Q. What is the EFI332 Project ?
Q. Who started it ?
Q. Does anyone have a system running their car ?
Q. What is this 2-layer and 4-layer business all about ?
Q. What is the BDM board ?
Q. What is the Driver board ?
Q. What is the I/O Board ?
Q. What is the 'Stimulator' board ?
Q. What Sensors are used ?
Q. What Trigger Wheel should I use ?
Q. What about Software ?
Q. Can I build code under Windows '95/98/NT or do I have to use Linux ?
Q. What if I want to use Linux as a development environment ?

Q. What is the EFI332 Project ?

The EFI332 project is a group project to design, build, program and implement a 'home-brew' Electronic Fuel Injection system for a motor vehicle. The project was started sometime in 1995, and has progressed slowly since. The group is supported by this web site and a mailing list which allows the members to communicate.

return to top

Q. Who started it ?

In the early days there were 3 boards CPU, IO, and Driver. The CPU board used the Motorola MC68332 processor. The driver board was set up to be used to spray or spark in arbitrary combinations, and this board is still in use in the current configuration. The IO board on the other hand was complex and suffered from periodic loss of TPU/crank wheel sync leading to the development of the current configuration.

At this point list members Bruce Bowling and Al Grippo decided to combine the IO and CPU board functions to reduce the susceptibility to noise. At some expense, new sketches were made, with increased attention to routing and details, and the result was a new board called the 4-layer, This board is the basis of the current configuration and incorporates separate power and ground layers to aid in handling EMI.

Details of the boards:

CPU - MC68332 @ 20Mhz + 256K static ram + 256K flash rom + 1 serial port + BDM connector + connectors for IO & driver boards + expansion connector.

IO - A/D converter for throttle pot, maf, map, temp, baro + 2 variable reluctance sensor amps for crank & cam + driver for idle stepper motor.

Problem: 332 TPU connected to VR sensor amps would loose syncronization randomly.

Driver - 4 channels of ignition coil drivers and/or injectior drivers in any combination.

Next came:

BDM - The 332 incorporates a debugging unit that can halt the main processor, read/modify/write memory/registers, restart the processor. The BDM board connects the CPU board to the parallel port of your PC so that the PC can download programs into the flash memory, debug the program...

4 layer CPU - To cure the syncronization problem Bruce Bowling and Al Grippo spent a lot of time and money combining the CPU board and IO board into a single, four layer (two signal layers, a power layer, and a ground layer) board that is currently running without loss of sync. The extra power and ground layers provide noise immunity in this harsh environment. Other modifications were (from what I can remember) to limit the trace lengths, worry about routing, segregate the noisy stuff from the sensitive stuff, use non-obsolete parts, worry about unused connections, and add extra noise suppression (probably others as well).

return to top

Q. Does anyone have a system running their car ?

At the very least, Al Grippo is running a 4-layer board in his Camaro.  At the moment it is running spark only, however the fuel side has been debugged and may be running now.

Greg Tully : I am running the two layer cpu board and the i/o board in my car. Just doing spark for the moment. I am picking the signal off of the distributor with the TPU PPWA and setting advance, retard. I am looking for the mystery reset/sync problem with the two layer board. So far it works good (Greg has had some problems with static ram chips that has gone bad)

Various others have bits and pieces of the puzzle working.

return to top

Q. What is this 2-layer and 4-layer business all about ?

There are currently two CPU board designs in circulation. The first, referred to as the '2 layer board' has been superseded by the '4 layer board' (also known as "Bruce & Al's Board"). The 2 layer board does not contain any I/O cicuitry to connect to external sensors.  There was a separate I/O board for that purpose.  The new 4 layer board merges the old I/O board into a new design. The boards get their names from the number of layers within the circuit board.

The 2 layer board suffered from interference, which could not be removed or filtered out.  Bruce and Al designed a completely new layout that does not suffer from this problem. The 2-layer CPU board contained the following components:

  Motorola MC68332 @ 20Mhz
  256K static ram 
  256K flash rom 
  1 serial port
  BDM connector 
  connectors for IO & driver boards 
  expansion connector

return to top

Q. What is the BDM board ?

The BDM board (BDM stands for 'Background Debugger Module') is used to communicate to the CPU board from a PC.  You won't be able to do much without one of these. Currently, there are about 3 or 4 different BDM boards floating around.  The oldest is known as the '2 chip' and has (surprise, surprise) 2 ICs on it. The newest is the '5 chip' board, and is generally regarded as being a better design.

There is also a BDM board floating around that is based on a GAL (General Array Logic??). This BDM is built around an In-System-Programable (ISP) GAL.  The logic had been worked out, but there were inconsistencies between the hard burned GAL and the ISP GAL chips.

To quote Gunter Magin (the designer of the GAL BDM): "The intent behind the ISP solution was that people should be able to build the interface even if they don't have equipment to burn a GAL.  The PP of the PC (and some software) would be their poor-man's GAL programmer.  And: it would be flexible for using the PP for other BDM-alike protocols, like JTAG, Xilinx-Download, etc. because of reprogrammability."

return to top

Q. What is the Driver board ?

The driver board (in it's current form) can drive 4 output devices.  A clever design allows you to build a board that can drive an ignition system, or fuel injectors, or any combination of the two by changing some components. For a V8, for example, you'd need 2 injector driver boards and 1 ignition driver board.

return to top

Q. What is the I/O Board ?

This board has almost been rendered obsolete by the new 4 layer CPU board with it's inbuilt I/O circuitry.  But, if you have one of the older 2 layer CPU boards, then you'll need one of these to connect your CPU board to the outside world. The I/O board contains the following circuitry:

A/D converter for
Throttle Position,
Mass Air Flow (MAF),
Manifold Air Pressure (MAP),
Temperature,
Barometric Pressure
2 variable reluctance sensor amps for crank & cam position
Driver for idle stepper motor

return to top

Q. What is the 'Stimulator' board ?

The 'stimulator' is a piece of circuitry designed to mimic the signals the CPU board would receive during normal operation. These inputs include the synchronisation signal from a toothed wheel mounted on the engine's crankshaft, temperature inputs, air flow readings, etc.

return to top

Q. What Sensors are used ?

To properly run an EFI system, you need some sensors to get the current state of the engine into the CPU.

Mass Air Flow (MAF) Sensor

The MAF sensor measures how much air is flowing into the engine. These sensors are generally a bit restrictive (especially the 'flapper' types, the 'hot-wire' ones are much better) and can cause problems with airflow.

Manifold Air Pressure (MAP) Sensor

The MAP sensor is another method of measuring airflow into the engine.  By using Bernoulli's Theorem, you can accurately measure airflow through the air pressure within the manifold chamber.

Throttle Position Sensor (TPS)

So that the CPU can determine how much fuel to inject, we need to know what throttle setting we're at.  The TPS is usually a simple potentiometer.

return to top

Q. What Trigger Wheel should I use ?

The trigger wheel is used to determine the position of the crankshaft.  A special tooth on the wheel tells the CPU when piston 1 is at Top Dead Centre (TDC). There are currently two trigger wheels - a 48+1 and a 60-2. The 48+1 has the advantage that Al Grippo's code is built around it, whilst the 60-2 will require special code for the CPU's TPU unit.

The TPU in the 332 has several different operating modes. Two of importance to us if is the "missing tooth mode" and the "added tooth mode" Either mode will support different tooth numbers. You pick one or the other. There is another TPU code for missing tooth mode, available on the efi332 website, which is a beefed-up version of the missing tooth code, specifically for 60 teeth, minus two. This code will not do any other mode unless one goes into the guts and starts modifying (not a trivial or pleasant task to do). This new TPU code is uploaded into the 332 on-board RAM during startup, and the TPU can operate with this new function (see the 332 manual on this). You use this function instead of the built-in method.

Many manufacturers and aftermarket efi companies use the 60-2 tooth wheel setup. This will give an TPU update for every 6 degrees of crankshaft revolution (except during the two missing teeth, when the tpu does not get updated until 18 degrees). The TPU interpolates between teeth based on the time it took between toon N and N-1 (linear interpolation). or the 60-2 tooth setup with the TPU, the RPM can range up to over 15,000 before the pulses coming in are too fast to keep up with.

The other TPU mode, the "added-tooth" mode, is fully functional as it is delivered on the TPU.

If one uses the added-tooth mode, then one now has to look at rate of pulses coming in more carefully, since there is an added tooth coming over every once in the while.  Doing the math, to be able to rev up to 8000RPM, the maximum number of teeth is 48 (plus the one added). This is one pulse every 7.5 degrees of crankshaft revolution (opposed to 6 degrees with the 60-2 setup). Also, there is no period of 18 degrees of interpolation like the missing mode with 60-2, and in fact there is one time (the 49th tooth) when the TPU is updated at 3.75 degrees.

The code that Al Grippo wrote uses the added-tooth TPU function with the 48+1 tooth pattern.The code that Al wrote can be modified by anyone with the inkling to do so to be able to run the TPU in other modes. Realize that this is not a trivial task.Anyone is free to write their own software and to use any wheel they want, within the constraints of the TPU.

If one wants to use the TPU code on the efi332 site, then they have to first trust that it works as advertised and/or modify if needed, and also work out the code to upload this to the on-board RAM on the 332 every time one reboots (not real hard to do).

Selection criterion:

A) If one *really*, *really* thinks that there will be a great            RPM change between sampling every 7.5 crank degrees vs. every            6 degrees, then they should use the 60-2 tooth wheel. Also,            if there are emotional reasons to use the 60-2 wheel, then            one should use it.

B) If one wants to use the TPU code for missing tooth mode on the    efi332 site, wring it out and verify it so that they can    fulfill criterion (A) above, then they should use the 60-2    setup.

C) If one wants to use Al's code with minimal fuss, and wants to            be able to implement updates from Al on this code, then they            should use the 48+1 tooth wheel.

D) If 8000 RPM is a realistic limiting factor for anyone, then            they should use the 60-2 wheel and heed (B) above.

However, the final word on the matter comes from Bruce Bowling:

"The 555 timer oscillator is set up for a wide RPM bandwidth, from around 800 RPM to 20,000 RPM (which the TPU happily accepts with the 48+1 tooth mode, so the upper RPM limit is higher than I advertised before)."

return to top

Q. What about Software ?

The prototype version of code developed by Al Grippo and Bruce Bowling does not use an operating system of any kind.  It is implicitly written for a V-8 and assumes the use of specific sensor hardware. One key item is that the TPU code assumes the use of a 48+1 wheel crank wheel and will not function correctly with any other wheel without modification.

The other version was developed by John Gwynne and is written around the RTEMS operating system and is based on the use of a 60-2 tooth crank wheel.  The choice of which to use is personal preference.

For people without embedded programming experience, learning and debugging with an OS is just one more layer of things to learn and to go wrong.  In general, things are simpler without an OS, however this can be a controversial subject (no flames please). If one desires to run functions at different rates (eg. inner and outer control loops), the added complexity of an OS can pay off in the long run.

The code will be different for different people, depending on the number of cylinders in the engine and the trigger wheel they elect to use (ie, 60-2, 60+2, 48+1).

return to top

Q. Can I build code under Windows '95/98/NT or do I have to use Linux ?

Yes, you certainly can.  There are several options available for WIN32 development. 

The win32 environment is a port of the GNU toolset for windows as provided by the people at Cygnus.  Both are provided under the GNU public license and are freely distributable.  The win32 based cross compiler is somewhat more difficult to build and is less mature than the equivalent Linux version but it is still relatively easily done.  Once built, it should produce identical code. See the writeup on the development environments page on this website.

return to top

Q. What if I want to use Linux as a development environment ?

There are several RedHat Package files (aka RPMs) that contain a pre-built set of development tools.  All you have to do is install them, and you are able to start developing code.

There is a quick FAQ on getting the 2.7.2 tool set up and running under Linux available from the old EFI332 website.

For users of non-Redhat systems, there are tools available to convert the .rpm files into other package formats. The best one around is called 'alien', and can convert pretty much anything into pretty much anything else.  Others include 'rpm2cpio', and 'rpm2tgz'.

Point to note: do _NOT_ include 'lp' support in your kernel, otherwise you won't be able to talk to the BDM module. If you need to use a printer on your Linux machine, compile 'lp' support as a module, and be sure to 'rmmod lp' before you try to use gdb and the BDM module.

return to top