6811 for me

James W. Swonger jws at mlb.semi.harris.com
Thu May 19 01:33:15 GMT 1994

 The isue of modularity is key to making the things we develop usable
by others. I would love to see a system take shape which has its 
functions and components partitioned so that any given project might
be able to get about 90% of its function from existing, worked-out
modules, leaving only the really powertrain-specific functions to
be massaged. To do this the control unit would have to be a pretty
general-purpose machine, but the interface to it well defined. I
think the processing should be separate from the sensors and the
effectors. I envision a set of building blocks, made on standard
forms for a standard "EFIbus".

 I tend to prefer hardware over software. I think that a system
with well defined, uniform signal values would be ideal. What I
mean by this is that, for example, all analog signals would be
processed from whatever their raw form might be to a standard 
range (e.g. 0-5V) so that they can be digitized uniformly.
All sensor inputs would be proccessed by a sensor module, and
this module would be fairly generic (so that, for example,
simple modifications would permit adaptation to 4,6,8,... cylinder
engines, of different firing patterns, with slightly different
air, temp, ... sensors, but retain the primary function, to 
present a consistent, platform independent set of engine status
signals for the controller.

 On the other end, a injector and spark driver module could likewise
unburden the controller, and also make the control function less
platform dependent, if it were desiged to accept a minimal set of
inputs which are sufficient to define the fuel delivery/timing
and spark. This might consist of a pulse width variable, a pulse
offset variable (from a bussed index pulse clock), and an ignition
offset from master. The rest is counters and timers, which would
vary somewhat from engine/make to engine/make, but again could be
pretty strappable.

 This leaves the computer core to do only the calculation of optimum
operating point, without so much real-time programming burden. The
cycle-by-cycle management could be almost negligible in steady-
state if the effectors are designed to latch the control data. A once-
per-cycle recalculation of state would probably suffice at worst.

 Would this group try to assign an address space for system variables,
and standards for a workable EFIbus, and the ideal partitioning of
hardware and software? Is such a definition something that can become
consensus, or are needs too disparate?

More information about the Diy_efi mailing list