Laptop engine management system

[Chris Conlon]

>...What I will try to do is get the basics of a system developed then I
>will open source my code (C++) for all to use and develop if interested.
>This will help me to achieve what I want and also aid others. I'm going to
>try and base it on a standard analogue and digital sampling  / control
>interface for a PC so that nothing is unique unless it has to be.

Let me say up front that I'm not trying to be negative, I think this
idea is well worth pursuing. (Like everyone else here I'm doing my
own engine control stuff too.) I'm just trying to get a clear picture
of why you're making certain choices.

The first thing I would ask is why do you say you want to do this
with a PC/laptop? What benefit is it you're after? Not that there
are none, just that it may help us understand the constraints of your
design.

It doesn't sound like you're aiming for any specific OS. Are you looking
for a system with easy SW development tools? Generic hardware? Do you
want a nice little display that can ride in the dashboard or passenger
seat? Is it primarily an educational/instructional exercise? Would
you specifically like to (or like to avoid!) building any part of the
hardware yourself? Understanding what it is you're hoping to get
by using a laptop instead of an embedded uC will help us make better
suggestions (imho).

Beyond that I have only a few relatively useless words. For the
engine management per se, any OS beyond an RTOS is basically useless,
except as a dev/boot platform. You gonna do a lot of disk io/network
io/memory mapping/UI graphics while driving? You already have to wire
all your code into core; can you imagine what happens the first time
you get a page fault while driving? ;)  (Now your data logging,
mapping and adjustment software is a different story of course.) 
You probably *could* use a full-size OS, if you can lock out other
interrupts, but what is it *gaining* you? Again, understanding this
will help.

Ignition timing is by far the toughest (time-wise) and perhaps the
most critical. Injector timing is not too hard by comparison. All
else is a cakewalk. So consider hardware support for the tough
parts, which could be built-in timer channels in an embedded controller,
or add-ons to a generic PC. The hardware in one lousy little 68hc11
will make up for so much brute cpu power required to do the same things
in software via ints and a generic timer.

If you go with a big OS (non-RTOS), and don't have hardware support
for certain things, you *will* be writing device drivers, and (in the
case of ignition timing) you *will* be having latency problems. Even
at a lowly 8000 RPM, every 20usec is one crank degree. If your OS
thought it was doing anything important come spark time, uhhh that's
how many degrees of retard again? "Oops".  One of the main things
an RTOS guarantees you that a big OS does not is an absolute max
(OS-imposed) interrupt latency, for just this reason.


My personal opinion is that the mechanics of how I manage the spark
and injector timing are a lot less interesting than how I calculate
what those values should be (maps, formulas), and how you condition
the sensor values. Perhaps you could have a somewhat modular design,
where there is a "black box" which deals with the cam sensor, injectors
and spark. It provides info on RPM, delta RPM, misfire, whatever.
You feed it info on spark advance, injector timing and pulse width.
(Maybe this box also handles MAP/MAF/AFM input too; IMHO the filtering
on MAP is important and sometimes tricky.) Pretty much all the other
sensors are less high-speed and thus your "higher level" control code
could deal with them in a less real-time-critical way. Ideally you
would update spark & injector timing once every rev, or once per
spark, but even that is a lot less demanding time-wise than taking
interrupts to fire sparks and turn injectors on and off. Data flow
to and from this box would be easily handled by the bidirectional
parallel port common on PCs, USB, or marginally so by a high speed
serial line.

As an aside, someone said A/D parts are slow. A/D parts are not slow,
they're as fast as you can afford, up to and including sample rates
in the hundreds of megahertz. Sub-5-usec is not hard to get, and if you
use many singles instead of a big mux-ed part, you can almost always
pipeline the reads, so the effective conversion time = 0.

Ok, that's my BS quota for the month. Hope it helped.

   Chris