Old 486 Board for ECU??

[Mike from West Australia]

At 09:44 PM 1/5/2000 +0200, you wrote:

>More than a PC can handle: one for the EGR valve, another for the air bypass
>valve, two for the variable distribution (in case the engine has that), one
>for the wastegate control, maybe one for the lambda heater (depending on the
>type of sensor)... Also, I can think of water injection, intercooler spray
>bar, thermostat, banked injection (2 injectors per cylinders with different
>pulse width and different crank-related timing)...

1.	PWM's are all *low* frequency - easy to handle in software.
2.	Most sedan ECU's do not have water injection, or IC spray
3.	Lambda heater is not time critical
4.	Events for ignition/injection can be cased on CAS

>> 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.
>
>It not only make it much easier, it actually leaves room for more
>interesting things, in the code space and the developer's head.

Sure, but you can *still* do all that a normal ECU requires with
a 486 m/b and ADC and signal conditioning.

>> Engine at 9000 rpm = 150 per second = dist 75 per second
>> For a CAS with 360 deg pulses/rev thats 75*360 = 27KHz
>
>This gives you a base resolution of 37 microseconds. *Far* too coarse to run
>any engine at low speed. Forget driveability and low emissions :)

No.
Because nobody in their right mind would use CAS as a timing clock for
injector or ignition operation. You use the CAS to initiate injector
opening or ignition. You obviously use the on board timers and use
the interrupt code on each 1deg ref to determine when to turn off injector
etc. The timers on a 486 are programmable and from what I've seen down
to better then 1us.

>Of course, you can always interrupt at 54KHz, this will give you 18.5us
>resolution (still too coarse) and leave you with ~400 instructions. Since
>you say you need only about 300, you'll consume "only" 75% of your CPU
>cycles in the crank pulse ISR. Not much room left for 'background'
>processing , let alone extra 'intelligence' :)

Not relevant as you use the CAS for interrupt to *start* injection
after whatver preset delay you require - the int routine checks for
end of period by reading the hardware timer. Max int need only be
equivalent to full engine speed at 27KHz is more then enough.

>Also, if you have 360 teeth, how do you detect TDC and cylinder number?
>Sequential injection requires 720 deg. sync. That's already two interrupts
>(unless you sense missing or extra teeth, something better left off to a
>TPU), more jitter and less available cycles.

The average CAS has a output coincidence on an alternate input line.
When an int comes in you can read another port in a following instruction
to see if that pulse is present if so its either a TDC 'coincident'
pulse or a 120deg ref.

Dead easy.

>> 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
>
>Certainly, within the constaints mentionned above, but you keep ignoring
>frequency and PWM *inputs* :)

Listen, most AFM's and MAPs are analog. If you are unlucky to have a
freq AFM or MAP - then use a F to V converter - comes under signal
conditioning. Otherwise use one of the other on board timers as a gated
counter to achieve the same result.

Also dead easy.

Also for O2 sensors that are frequency (and I ain't seen many) you
can also use one of the on board gated timers etc etc 

>More and more sensors (AFM, MAP, temp) seems to use this type of signals
>nowadays, probably because of the improved immunity to interferences. Some
>even use CAN.
>
>> 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.
>
>OK, I'd say that if you don't want to do anything beyond the capabilities of
>the simplest ECU you can think off, can live with only one or two analog
>inputs and only injectors output, are not concerned about peak performance
>nor strict emissions, you can probably work out some experimental thing
>based on a PC motherboard. That said, we have yet to hear from someone that
>successfully ran an engine past idle speed using such an ECU ;)

You are forgetting that for several years 8 bit ECU's at 4 to 12MHz were
handling sequential injection, ignition and handling emissions requirements
quite well. Yet here we have a CPU that can reach 140MHz (AMD DX4 etc)
and onboard timers and plenty of ram/rom etc etc

You don't *need* speed to do it, you need a *little* signal conditioning
electronics and nice software.

Surely you can see that engine speeds result is slow int requirements
for the CPU and that PWM outputs for all injectors can be done in software.
Background processing  at normal RPM is more then enough to make yes/no
decisions and perform maths. At highest RPM's you still have time for
background - sure it might take more then a couple of engine revs to get
the same order of b/ground processing as at cruise but still well within
the response time of your sensors.

Do the math - it works out.

Rgds

Mike

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