Old 486 Board for ECU??

[Mike from West Australia]

At 06:52 AM 2/5/2000 +0200, "Axel Rietschin"
<Axel_Rietschin at compuserve.com> wrote:
>> 1. PWM's are all *low* frequency - easy to handle in software.
>
>I've yet to see that. Interrupt activity will screw your timing badly.

No it won't. Because interrupts are synchronous. And interrupt overhead
is the same to +- 1 instruction, unless you want a problem with MSDOS.

>> 2. Most sedan ECU's do not have water injection, or IC spray
>
>Most sedan do not need a reprogrammable ECU either, thinking this way.

What point did you try to make in the first place to bring up the suggestion
that a 486 m/b needs to handle water injection and IC spray ?

>> 3. Lambda heater is not time critical
>
>Right. The signal must still be generated, however.

Easily done by background processing. Does *not* need interrupts.
What makes you think a simple timer in ram and a decision to turn
it on or off is so hard ?

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

Suggest 6 cylinder, sequential fuel injection with ignition control,
sensors are AFM, Engine temp, O2, TPS - to start with. You could add
AAC and lambda heater fairly easily and even a little more in the
background too - such as a boost solenoid etc

>> 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.
>
>We finally get back to timers. How many do you have (you already know how
>many I think I'd need) ?

You only need one or two hardware timers with 1us resolution and of course
the ability to read them - do some subtraction and comparison.
The other 'timers' are in software updated as required.

ie. Preset an active reg for the injection PWM, compare the running timer
with the active value in RAM and decide which injector to turn on or off.
Can be done in about 200 or so instructions with room to spare. Heck you can
even use a mask with shift for the decision making function as to which
injector at what cycle you have - takes about 20 instructions.

Simple to read the timer add/subtract offset, compare with ram value
put there by b/ground assesment from AFM/lookup/engine temp comp.

>> 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.
>
>This is where I don't get it. If you read the timer in the ISR, the int
>frequency gives you the base time increment at which checks are made.

No. That might be how you'd do it - I wouldn't.

>Anyway, 2 deg. res is still too coarse for spark timing purpose and you
>still burn 75% CPU time in one interrupt service routine, compared to say
>0.01% if timing issues were handled asynchronously in hardware.

You have 1deg resolution regardless of engine speed for the start point
for injection or spark *but* you still have 1us resolution for end of
injector PWM etc By simple timer comparison with PWM value put in RAM
by b/ground.

>> 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.
>
>I take your word for it, while I think you describe 360 sync, not 720.
>
>However, 'dead easy' results in a 55 pages data sheet for the 67F687 chip,
>whose main purpose is to aquire and maintain a 720 degree crank position,
>interpolated down to a quarter of a degree, from various possible pulse
>patterns. Something I definitely don't want to emulate purely in software.

This is where semi co marketing comes in - you can do it in software
quite easily. Heck you can even have a 16bit angle to timer offset table
in ROM and use that to do most of the work when you get an interrupt.


>> >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.
>
>You just suggested to convert a digital signal to analog just to convert it
>back to digital immediately thereafter. Wow!

Don't be silly. As mentioned, most AFMs and MAPs are analog, obviously
use them first. If however you have a freq output AFM then whats wrong
with using a gated counter - one of the timers on the 486 to do that.
Handling linearity is easy anyway if you do decide to do F to V conversion,
easily handled by a lookup table. Obviously the 486 m/b can't do signal
conditioning but noone ever said it could.

>While doable, a VCO/ADC combination will screw your linearity and resolution
>big time.

See above point. Just use the more common analog AFM's to start with.

>> 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.
>
>Yes, but NONE of them were x86 CPUs. You know for sure that all those ECUs
>used microcontrollers with built in CCP modules, or external dedicated
>timing hardware.

Nop. Many were variants of 68HC705 devices with timers less complex or
capable then those on a 486 m/b. The x86 architecture is not a problem,
why are you so vehement that x86 architecture is a problem. A cpu that
runs instructions and responds to ints is most of what you need.

(Just don't use MSDOS to do all your int processing.)

>> You don't *need* speed to do it,
>
>'No matter how fast' was in my very first reply to this thread.

Are you saying a DX4/133 is no better then a 25MHz cpu to handle interrupts ?


>>you need a *little* signal conditioning
>> electronics and nice software.
>
>..and a handful of Capture/Compare/PWM modules, which a PC don't have.

Nop. Do it in software. You don't *need* a PWM module to turn on an
injector, check a timer and turn the injector off again - really !

>> 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.
>
>There is more than injectors to control nowadays.

Sure, makes sense to use the latest chip - doesn't invalidate my 
statement that a 486 can do the job - you don't need to add that much.

>> 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.
>
>I think we are talking about different things. You describe a simplistic
>system with only the most basic function, and I think of a more powerful
>system with a lot of spare cycles to run high level control functions.

Granted I am not talking an overly complex EFI system but a common
sequential injection ECU function can be done with a 486 m/b, ADC
and signal conditioning and that applies to most unmodded street cars
of last 10years.


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