Old 486 Board for ECU??

[Axel Rietschin]

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


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

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

> 3. Lambda heater is not time critical

Right. The signal must still be generated, however.

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

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

We finally get back to timers. How many do you have (you already know how
many I think I'd need) ?

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

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

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

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.

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

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

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

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.

> You don't *need* speed to do it,

'No matter how fast' was in my very first reply to this thread.

>you need a *little* signal conditioning
> electronics and nice software.

..and a handful of Capture/Compare/PWM modules, which a PC don't have.

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

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

Regards,
Axel




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