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: Friday, May 05, 2000 02:46
Subject: Re: Old 486 Board for ECU??


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

Sure. Next on the list is traction control (with 4 wheel-speed sensors): you
limit wheel spin to a predefined amount depending on a couple of factors,
including TPS and ground speed, by limiting the engine torque in
closed-loop. This would be the first significant control function above the
basics.

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

Using a PC to build an ECU is kind of a new developement.

> 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

We, at least, fully agree on one point :)

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

Why not make a simulation, using two 486 PCs, one in the role of the engine.
With a few D/A and clever software PWM code it should be possible to
generate the required signals?

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

Yes, I love DOS too :) That said, I believe there is not that many
hw-generated interrupts handled by DOS itself.

> 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 can have more with a satellite up-link :D

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

Actually, I believe we _are_ arguing ECU architectures, purpose-built vs.
generic personal computer.

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

My previous ECU, a Weber-Marelli P8, was running on a 4MHz 68HC11P1 (the one
with 4 PWM channels, 16-bit timer, 4 input captures, 4 output compares and a
pulse accumulator built in) Just add a few 10-bits A/Ds, signal
conditioning, clever code, suitable output drivers and presto, a very
capable ECU! If you put this on an ISA card, there is your PC ECU!

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

I happen to design software systems for a living. That's another story but
that makes me agree with you once more :)

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

It will. But the result may still be good enough depending on use.

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

To me it's like asking why use C++ when you can code in assembly language? A
certain level of abstraction is often a good thing. It helps not getting
lost/buried in the low level details. To be honest, I don't really see the
added value of the best designed, most clever, nearly accurate software PWM
routine when a single call like pwm(chn, freq, duty); in a function library
can make the hw perform the work asynchronously. As I said already, this
kind of facilities will free your mind for more interesting things. You
write your app quicker (with probably less defects), or it does more things.
Either way, you win.

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

Nice peripherals are like any powerful tools. You still need skills to use
them properly and they can often be dangerous when left in unconscious
hands.

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