[Diy_efi] PC ECU?

[MWP]

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

Exactly... plus it would be MUCH easier to write on-line tuning as the
equiptment modifying the maps would be the PC doing the ECU work.
I have quite a few very nice LCDs i could use with it.
Also, if theres engough spare cycles, it could even be used for playing
mp3s.

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

Well i was thinking of building a PSU (not too hard) and i already have a
couple of ISA IO cards that could be used.

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

Yes i was also thinking about doing it this way.
Doing it this way would also mean that ints and accurate timing on the PC
could be avioded making things much easier.

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

Yep.

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

Looks like we are thinking the same way, which is quite a relief to me :)
Knowing im not going insane with a project like this.

Oh well... now i will keep looking into this.
Ill keep the list updated with my progress... and im sure ill be asking a
few questions along the way.

Thanks.


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