DIY_EFI Digest V4 #465
Pat Ford
pford at qnx.com
Fri Aug 13 13:11:09 GMT 1999
Previously, you (DIY_EFI Digest) wrote:
>
> DIY_EFI Digest Friday, August 13 1999 Volume 04 : Number 465
>
>
>
> In this issue:
>
> Re: DIY_EFI Digest V4 #464
> New Project - 514
> 9V power supply
> Signetics N82S2708N
> Re: DIY_EFI Digest V4 #462
>
> See the end of the digest for information on subscribing to the
> DIY_EFI or DIY_EFI-Digest mailing lists.
>
> ----------------------------------------------------------------------
>
> Date: Thu, 12 Aug 1999 16:43:20 -0400 (EDT)
> From: William T Wilson <fluffy at snurgle.org>
> Subject: Re: DIY_EFI Digest V4 #464
>
> I hate digest mode.
>
> Somebody please fix it. :}
>
> > The most common pitfalls are not coming to terms with writing "real
> > time" applications and how very "real time" the engine management
> > game is.
>
> Something that is extremely lacking - not just in engine management but in
> many technology applications - is people actually quantifying what they
> want the stuff to do.
the missing spec stage. You have to specify what you want before you get going
>
> 10,000 RPM is equal to 166 RPS. Since you have one pulse for every other
> revolution for each cylinder (assume 4) you'll have 4 * 166 / 2 = 332
> pulses per second. Now, that doesn't seem all that bad, but consider all
> the stuff that has to be done for that pulse and how precise it has to be.
> It's easy enough for a computer to do 332 things per second but for it to
> do one thing precisely every 3 msec is a little different.
The hardware needs to run that fast, Not the program. Al Lipper did a PC
based efi, I used that as a starting point for a pc104 (industrial pc) based
efi. Using a 386ex 16 with 8M ram it worked. Think and look and Ludis's
page
( http://www.cruzers.com/~ludis/1227748sheet1.gif )
and look at u15 you just program the capture channels and read the registers
th cpu only sets it up then sets back and reads at will .
>
> First you must sense the current RPM. You can't do this in the same
> thread that does anything else because by the time you get the RPM sensed
> you'll have missed a pulse. If you have 6 teeth with one missing on your
> sensor widget (that's a technical term) you'll be getting 50,000 pulses a
> second, which means you need resolution of 100,000 pulses a second (so you
> can find the missed one) which means you need additional hardware to help
> with this, *already* your laptop is by itself inadequate.
not so if you hook into the 8253/4 timer chip your code only has to set it up.
Software and hardware guys tend to try what they know, this is something to
do in hardware.
>
> Assuming you have a unit which sends you a 16-bit value (adequate for any
> RPM) 10,000 times a second. You need to read your serial port at a bit
> rate of 19,200 bps just to make 9600 RPM max. 38,400 if you want to be
> safe. The good news is that if you miss one of these it's not the end of
> the world.
>
> Then you need to send the injection pulse. First you need 3msec timer
> accuracy. The hardware clock can do that, but if your system is too
> heavily loaded, you'll lose out. This is where Windows really falls over;
> it's simply not that precise. Most of the time Windows can't even play
> mp3's and run Netscape at the same time without cutting out even though
> the total cpu load is less than 25%.
again easy in hardware to avoid this overhead, Al Lippers PC based efi is
an excellent starting point. He made good h/w vs. s/w choices.
SNIP
> Somewhere in there you have to find time to check the TPS, correlate it
> with the RPM and boost level (if applicable) and find out how much fuel
> you're going to squirt for the next pulse. If you are running closed loop
> you'll have to check the value of the O2 sensor... oh, bad news. A/D
> converters are slow - so you can't do that read instantaneously. But you
> need to know this ahead of time because otherwise you don't want to go
> lean accidentally.
sample the analog signals at the start, then do it after each read
>
> Any of this stuff is easy enough to do, but getting all the scheduling
> right is the hard part.
>
not if the right decisions are made about whats h/w and whats s/w tasks
> > On the Engine Management side things are a lot more difficult.
>
> You can get a good handle on things just by connecting an A/F meter to see
> how much fuel is being pushed in at various RPM's. You can then simply
> capture this data for a good starting point.
>
> > Let us know what you find out ? Can a 300mHz 32 bit wintel run an
> > engine ?
>
> No chance. Windows cannot do this.
AGREED windows is a nice TOY ( try reading from an empty floppy drive
while doing anything else)
> Linux probably can if you are
> comfortable with programming for real time applications, but you would
> probably be safest with a genuine real-time OS, which of course is a very
> specialized skill and probably expensive for the software.
There are free rtos's but with dos you can set up a fairly good system
for this type of load just don't run any windows stuff, avoid himem.sys
...
Or you can go OS less. Compile your program as a .com and patch the bios
signature and jump to the front and the post will take and run it before
any os starts
>
> You kind of reach a point of diminishing returns with PC hardware. The
> CPUs today are designed for computationally intensive applications which
> engine management is certainly not. Your real bottleneck is the I/O,
> most PC systems are very poor at this and it's the most important part of
> engine management.
>
I agree to a point, the stock io is poor BUT its easy to extend the io.
Think of a pc as the small block chev of computers, easy to add stuff to,
lot of off the shelf stuff, not hard to graft home made stuff to. One of
QNX's customers does engine management on a turbine engine test bed( like a dyno)
, using a PC.
--
Pat Ford email: pford at qnx.com
QNX Software Systems, Ltd. WWW: http://www.qnx.com
(613) 591-0931 (voice) mail: 175 Terrence Matthews
(613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
More information about the Diy_efi
mailing list