[Diy_efi] PC ECU?

[Bevan Weiss]

If I was to use an x86 type computer as an EFI system I would remove the
standard motherboard from the design and build a custom support board.  That
way the processor doesn't have to service anything stupid like IDE interupts
or keyboard interrupts or system timer interrupts that aren't mine, etc.
Really all that stuff is only needed when dealing with a whole computer,
which isn't really what's needed.  If anyone is even thinking about needing
a HDD when dealing with an engine management system then they need to look
at the way they are going about the system.  The engine management system
should (IMHO) be used to control the engine systems (EFI/IGN/water/etc)
anything else, like logging facilities is no longer engine management and
should be tasked to a different system, with allowances for this kind of
handing over possibly made on the engine management system.
A design has been made that incorporates the MC68332(EFI332), I can't see a
reason why one couldn't be made using a Pentium 233 or similar.  However, I
guess the real question would have to be... is there really a need??

----- Original Message -----
From: "MWP" <mwp at overclockers.com.au>
To: <Diy_efi at diy-efi.org>
Sent: Monday, May 06, 2002 9:30 PM
Subject: Re: [Diy_efi] PC ECU?


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

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