[Diy_efi] PC ECU?

[Brian Dessent]

MWP wrote:

> Has anyone tried using a x86 based PC as the ign/efi computer?
> I have started thinking about it, and can build the hardware needed to do
> it, but im wondering if theres anything ive forgotten about that would
> make the project impossible. As in some quirks of the x86 system that
> would make timing hard, etc.
> 
> If i do it, itll be running under a stripped down linux install using the
> RT-LINUX kernel which allows for good embedded software support.
> Apparently it has interrupt latencies better than 15uS on an old pentium
> system.
> 
> So what do you guys think?
> Is it worth looking further into?

I've sort of considered this idea for a while.  It would be really neat
to have the ECU functionality on a PC, you could then make all sorts of
cool displays or gauges, and datalogging would be integral... all sorts
of cool stuff abound.

But the problem, as it seems to me, is that if you want to put *all* the
brains on the computer side (which would be nice, since we have
sophisticated tools like gcc available which is much easier than writing
PIC assembler, for example) then you really need an interrupt-driven
architechture.  Serial is out, parallel is out, even USB is out since
it's entirely host-driven -- the host CPU has to initiate all queries. 
I was thinking about this from the angle of a laptop, and so that
doesn't leave much in terms of ports to which you could interface.  It's
not too hard to make a card that could interface with the ISA bus, but
then you would have the additional chore of building a case/power
supply/etc, whereas a laptop would be so much more turnkey.

So the solution that I would implement would have some of the brains in
the custom hardware.  I would build a unit where you tell it a spark
advance in degrees and a fuel pulsewidth in ms, and it will autonomously
trigger spark and fuel with those values until it gets an update (which
would be quite often, of course.)  The controller board keeps track of
which injector to fire, which coilpack to fire, dwell time, etc. This
way, the host cpu doesn't have to get bogged down with the precise
timing details, but still has full control over the details.

So in this scheme the host cpu would receive a defined data stream from
the board, such as rpm (or time between CPS pulses, whatever), TPS, MAF,
MAP, IAT, etc, etc, with some values being sent very frequently (such as
rpm, TPS, and MAF) and others sent only so often (like IAT, coolant
temp, etc.)  The host cpu in turn sends a data stream back to the board
with updated spark and fuel values, and occasionally sending other
commands (wastegate solenoid, idle stepper control, etc).  The idea here
is to make the timing non-critical.  The board would continue to use
whatever the last spark/fuel data it received, so that the CPU has a
little more leeway with its latency.  At 8k rpm on a v8, spark events
occur at 33 Hz, and that's a huge amount of time for the CPU; the update
can be sent to the board any time during that window.  However, if you
were doing all the timing on the CPU host, to get 1 degree accuracy at
8k rpm you'd need a timing precision of about 42us, and with a 40 tooth
flywheel you'd receive a "tooth event" every 188us.  Obviously you want
to offload these tasks to hardware.

I would even go as far as to say that this scheme could be implemented
with a standard serial link (at 115200 bps) between the host and the
controller board.  All of the timing sensitive stuff is in hardware, and
the software just reads a stream of sensor readings and outputs a stream
of constantly updated timing info, with other commands occasionally
thrown in the mix.

I'm sure there are issues that I have not thought of, but this is how I
would start...

Brian

_______________________________________________
Diy_efi mailing list
Diy_efi at diy-efi.org
http://www.diy-efi.org/mailman/listinfo/diy_efi