Old 486 Board for ECU??

[Mike from West Australia]

At 05:47 AM 4/5/2000 +0200, you wrote:

>> >I've yet to see that. Interrupt activity will screw your timing badly.
>>
>> No it won't. Because interrupts are synchronous.
>
>???

Synchronous with engine cycle and synchronous with timers and I am using
the term in relatively broad context.

Happy ;) ?

>> And interrupt overhead
>> is the same to +- 1 instruction, unless you want a problem with MSDOS.
>
>As far as I know, not all instructions have the same duration on a x86 so
>interrupt latency cannot possibly be fixed.

Oh yeah sure, to reduce the std deviation spread of variables, its best not
to use instructions which have a much longer execution time. Such as
FDIV double precision in the b/ground etc.

Though note that at 25MHz, thats 40nS per instruction, you can tolerate
up to about 1 usec dither - thats about 25 instructions, easy to confirm
the amount of dither and there's no need for double precision floating
point. A DX4/100 is rather quicker - so why are you concerned with that
as any asnyc issue is very short in comprison with functional requirements ?

>> 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 ?
>
>One of the reasons why I'd consider a custom ECU is to be able to control
>more things than the existing ECU already in the car, and one of the reasons
>why I'd consider building an ECU is to control more things than the most
>sophisticated ECU I can purchase is able to control. Water injection and
>intercooler spray are on my wish list, among other things (plenty of ECU
>doing just that are available, by the way, but that's a completely different
>story).

Well if you must integrate WI and spray into an EFI ECU then this trivial
requirement has minimal b/ground processing - *very* easy to do, I think
most on this list would agree, they are not time critical anywhere near
the requirement of fuel. 50mS would be more then tolerable for WI and
spray is fine to even 500mS. And yes the 486 m/b could handle this
easily - unless you want an acceleration profile for each drop ;-)

>> >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.
>
>I'd use an MPC555 and spend most of my time writing high level engine and
>drivetrain control code :)

Fine. Though I realise you are probably of the impression I have suggested
using a 486 architecture for new development - nop not in any way at all,
I wouldn't.

To be clear. I've mentioned you *can* do EFI and ignition with a run of
the mill 486 m/b with an ADC and signal conditioning. And I've described
that its fairly straightforward if you give some attention to software,
I might add rather more then most people have the patience for, sorry
for being so smug ! :)

Obviously its clear the form factor is lacking but it could very well be
a cheap way to learn about EFI and what to do and what not to do, given
the stuff is given away or even left on the front nature strip for kids
to play with !

Personally, for a production development at a high level, it makes sense
to go custom all the way. ie CPU core in ASIC etc etc

>> See above point. Just use the more common analog AFM's to start with.
>
>You don't always have a choice.

<groan> for the *most* part AFM and MAP are analog, its trivial to
handle F to V and compensation, see note above anyways.

>> 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.
>
>I don't, really. I just question the feasibility and performance of a PC
>ECU.

Sure. Clearly, contrary to many (outside this group) a PC *can* handle
the timing requirements of a conventional production car with a little
work. Its obviously not feasible to do this for production, the only
reason I'd do it is as a teaching project to illustrate the practicalities
of why EFI systems are developed the way they are and why the form-factor
of a 486 m/b could not be suitable for anything but a training exercise.

>> (Just don't use MSDOS to do all your int processing.)
>
>You keep mentionning MSDOS while I suggested to write the control code on
>top of the BIOS, and even to write a special purpose BIOS. Note that I never
>attempted to discourage those wanting to run a multitasking, multiuser OS
>and also a GUI, next to the EFI code all on the same 486 ;) I'd love to hear
>you on that aspect of the 486PC ECU, by the way.

Yep - I have mentioned MSDOS, because you have indicate the 486 has interrupt
latency problems - this is *because* of MSDOS not due to 486 cpu core in
the low resolution requirement of driving injectors.

There would be nothing wrong with booting into MSDOS even from a nice
hard drive, switching to the EFI program which traps all the interrupts,
drives the car as required and during this period data logs to DRAM.
When engine turned off, 486 holds power relay, resets int traps,
dumps DRAM logged data to hard disk, checks drive for completion and
releases power relay.

This way you can have the same BIOS, same hard drive with MSDOS file
system - you just need to write your EFI program so it agressively
traps all the MSDOS int vectors in such a way it can release them
without upsetting the MSDOS return to dump the data to hard drive
in a first in first way mode. Wouldn't it be nice to have 8 Gigs
worth of travelling window of vehicle data :))

>> >> 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 ?
>
>No. But I could be saying saying that a humble 4Mhz PIC (for example) with a
>CCP module or two is much better than any x86 PC at generating jitter-free
>PWMs or reading a frequency input.

We are not arguing architectures unless you want to go off on a tangent,
recall I mentioned I did a Z80 based system with a CTC. The point I've
always maintained is that a 486 m/b could do it - and not just a trivial
idle either - but up to even 6000 or more rpm - its a straightforward
systems analysis and investigation issue, with appropriate consideration.

The problem is a lot to do with many who find the need to use hardware
peripherals because they would rather code software then design software.
And designing software is something very few people know how to do even
passably - I know of many programmers who cannot design software, other
then jumping in and writing code by trial and error and these programmer's
tend not to know how to document and maintain through simple technical
documentation principles. The functional block tendency is well and good
for many but it does tend to result in trial and error developers it
does not (by itself) promote and expand on human intellect - other then
giving us more rope or allowing us to dig ourselves deeper into greater
complexity without the paradigm of understanding the outcome and any
limitations inherent in the conception of complex relationships.

>> 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 !
>
>You may not see many PWM sensors/actuators around you but I do. You say you
>can do it all in software and I have no reason not to believe you. However,
>this will use a lot of your coding energy and a lot more CPU cycles for a
>less accurate result compared to hw generated/measured signals. I believe
>that if the hw does more for you, you'll have more time to make the sw do
>more too.

There's not necessarily a less accurate result - it all depends on the
analysis at the time. I do concur that clever peripherals allow you to
write software more quickly - but realise also that clever peripherals
defray the need to design software as its far easier/quicker to use trial
and error programming techniques if you have clever and highly integrated
peripherals, I trust you understand what I am saying here.

>> 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.
>
>"semi co marketing" must be pretty good since they successfully convinced
>the entire automobile industry to use specially designed components and
>systems instead of using inexpensive off the shelf commodities like PCs to
>make ECUs ;)  ;)  ;)

Yes, understand, I am using marketing in a broad and yet technical sense
and perspective far beyond the mere illusion of advertisements and public
relations issues.

Human design functions are very thin on the ground and the average technical
intellect is still 'new' to programming notions.  Most 'software'
programmers tend to launch into software via trial and error and this is
so much easier with the type of specially designed components for this
very purpose. Its easier and quicker to get a result using trial and
error programming with functional block peripherals then with tortuous
algorithmic combinatorial software not suited to the feeble minded.

Back in 82 or thereabouts I used to teach Macro-11 on the PDP-11 and
also played with UALC's in Cybernetics on a KL-10 processor, what used
to be frequently apparant is that computer professionals were far more
comfortable with jumping in and coding without due care and attention.
Nice peripherals allow this to occur more often, its much like the TV
tends to stultify thought and we become more often watchers then thinkers.


>I'll watch this thread with great interest, looking forward to hear from
>successful 486PC ECU implementations

I think there's been one already, if I had time I'd get a class together
to look at this very issue, fortunately there are more interesting and
lucrative opportunities to pursue at the moment,





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