Old 486 Board for ECU??

Matthew mivan at ozonia.com
Mon May 1 18:00:08 GMT 2000


Wow.... a little over my head. I was wondering if there are any good
books/sites that you guys would recommend reading to help bring myself up to
speed with some of the ideas/ theories discussed here. Mind you I realize
the no book can replace the years of experience you guys have, but any
knowledge would be more than I have now.
    I would be especially interested in any books that would help my tune an
efi car (specifically forced induction). Something that would give a good
idea what sort of parameters to monitor, a/f ratios and egt's to shoot for,
and what to alter (timing, fuel, both) in order to get the desired
performance. Old hat to some of you maybe, but a new world to me.

Thanks,
Matt
----- Original Message -----
From: "Mike from West Australia" <erazmus at wantree.com.au>
To: <diy_efi at diy-efi.org>
Sent: Tuesday, May 02, 2000 1:57 AM
Subject: Re: Old 486 Board for ECU??


> At 05:08 PM 1/5/2000 +0200, "Axel Rietschin"
> <Axel_Rietschin at compuserve.com> wrote:
>
> >How many concurrent PWMs (that's the WHOLE point of this entire
discussion)?
>
> How many do you want ?
>
> As the PWM frequency is low then you can do it quite well in software,
> you don't need to do it in hardware unless you really want to.
>
> >One is not enough. Consider that you have to fire the spark at the
> >appropriate time (assuming a DIS) and actuate a few valves in PWM all at
the
> >same time.
>
> Firing the plug - at the same relative time for each cylinder can be done
> real easily in software as can sequential injection. The number of
cylinders
> will fit in a single byte - dedicate a CPU register to the current plug
> and another to the active injector etc etc yada yada
>
> Remember you can execute a sizable amount of instructions in an engine
> revolution :)
>
> >> So all this hogwash about 486 boards not having timing is a software
> >> issue around MSDOS not any limitation of the motherboard - the hardware
> >> is much more capable then it needs to be with the exception of ADC's.
> >
> >For your typical low-function-one-PWM ECU, it may. Motorsports ECUs uses
332
> >or even MPC555 microcontrollers with one or two built in Time Processing
> >Units, microcoded for time-related engine mgmt functions, plus a couple
of
> >DSP chips for multi-channels detonation signal processing and, sometime,
> >dedicated chips like the 67F687 to help with engine timing issues. That's
a
> >lot of timing-related hardware added to an otherwise standard CPU. The
CPU
> >runs the high level control functions, PID algorithms for
> >closed-loop-everything and auxillary functions such as data logging.
Again,
> >it all depends of where you want to go.
>
> Of course its obviously sensible to go for the latest hardware to make
> the software development far easier and much more so for higher rpm
> and more compensation/operational factors etc etc Part of this is the
> push from the semi co to get devices into sale - sexy apps, marketing
> etc etc.
>
> Crikey ! The human race sent man to the moon on less computing power
> then is in your average 99 model sedan !
>
> None the less for a typical 6 (or even 8 cylinder) engine a 486 trundling
> along at even 25Mhz can handle sequential injection *and* ignition and
> run interrupts off a crank angle sensor set at 1 deg intervals. Software
> can do wonders if you give it some thought (and it don't take much
either;).
>
> Consider this (street 6cyl RB26DET for example) :-
>
> Engine at 9000 rpm = 150 per second = dist 75 per second
> For a CAS with 360 deg pulses/rev thats 75*360 = 27KHz
> A 25MHz 486 with L2 cache can handle 920 or so instructions between
> 1 deg pulses at max engine RPM. Allow 50 instructions for interrupt
> overhead and you have 800 or so instructions per 'tick' to
> decide which plug to fire (if at all) and which injector to turn
> on or off. I'd say (having 22 years experience in assembler) that
> you could make such decisions in 300 instructions or less and allow
> some bit shuffling overhead to boot Now this is the time critical aspect
> on interrupt, read on,
>
> In the background you no such time critical requirement, you can handle
> 10mS ADC acquisition of AFM or MAP to put a number in a register and
> do a table lookup - even a few multiplies if you want and even if this
> is interrupted at the maximum rate you will still be able to handle
> the rigours in software without the need for 'timing chips' which I
> think most will come to the realisation have a 'marketing' angle (pun;)
>
> Naturally the software will have to be well thought out, its not
> actually a hard procedure to follow. Conventional flowchart design
> will handle it well enough without having to resort to OOP or
> any sort of complexity. CPU's core instructions are all you need to
> handle simple logical decisions a multiply or divide as required,
> which mask to apply to which IO byte - yada yada.
>
> Now take a DX4/100, throw away the DRAM, use SRAM in its place and
> load the kernal into cache on powerup. Only use the slow 70nS Flash
> for table lookups. Crikey if you then keep the 16meg or so of DRAM
> then use that for datalogging :)
>
> >I'm not saying a 486 chip cannot do it. I say a PC won't be very good at
> >this ECU job, unless you complement it with a lot of stuff.
>
> You only need to complement it with an ADC and some thought, we won't
> mention which is thinnest on the ground here ;-)
>
> Don't get me wrong, I would still rather use peripheral features where
> appropriate, I'm just pointing out you don't need to and that the core
> hardware will do adequately with the addition of ADC and signal
> conditioning.
>
>
> Rgds
>
>
> Mike Massen
>
> Pictures of site installation at Mendulong near Sipitang, Sabah (Malaysia)
> Remote Area Power System   http://www.wantree.com.au/~erazmus
>
> Vehicle modifications on GMH Turbo, twin tyres, possible 175Kw at wheels
> Preliminary pictures at
http://www.wantree.com.au/~erazmus/Twin_tyre_vehicle/
>
> Editorial on twin-tyre opinion and good reference about tyres:-
> http://www.geocities.com/MotorCity/2195/ttyreopinion.html
>
> Ancient Sufi saying:
>         "Should your God save you from adversity, choose another God"
> --------------------------------------------------------------------------
--
> To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the
quotes)
> in the body of a message (not the subject) to majordomo at lists.diy-efi.org
>

----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org




More information about the Diy_efi mailing list