Complicated math, Multi-tasking in ECMs

[Dale Ulan]

> I agree that linear interpolation is the way to go, particularly with
> the controllers that people tend to use these days - 6811s and so
> forth.  I suspect it won't be as big an issue when PowerPC controllers
> (and the 68k job I've heard about here), possibly with floating point,
> come along.

Yes, but running the program loop faster (using the power of the CPU
to increase the speed, rather than the complexity) allows the use of
simple engine models that reflect the engine dynamics in real time.
My ECM runs in 1 ms loops... that's 5 loops per cylinder 'fire'. I use
that time to model the intake manifold and fuel film dynamics using
Elbert Hendricks' equations given in 910258. It turns out that
by moving the equations into the z-domain, the tuning and algorithms
for transient compensation are much simpler, as they require very few
tables, and more measurements than dyno testing. I don't know what
the accuracy is supposed to be like, but Hendricks claims that the
model is normally within 2% of good dyno data.
....
> the company would save $250,000 - many times his salary.  And then
> he'd be hacked off because he didn't get any of that loot.
....
True, I suppose. What I find, though, is that if the code is 24k long
(with tables), there's not much of a reason you:
  a> want to make the code smaller because the next smallest chip
     available is 16k
 and
  b> can't use another 8k of memory, since the smallest common chip
     that fits that amount of code into it is 32k.
...
> This drove me nuts after a while and I secretly wrote a tiny
> multi-tasking exec for our ECM that was referred to as the "secret
> weapon exec" by us software guys.  This was strictly against Delco
....
Did that end up in the 6801-based ECM?

I found a neat address table that is used to call various routines.
There were 16 addresses, and the routine called them in a round-robin
fashion. Was this the thing you're talking about, or....
maybe I should quit asking so many questions...

> So my question is this - do you diy types use multi-tasking, or are
....
> tables!  By gum, these topics are tied together!  Any
> thoughts/comments?

Here's my software design... and coding on it is going ok. Should have
it running sometime in early January. I don't think many people
like the way I do things, but...

  fast calculations are run in a tight 1ms code loop. It consists
     of about ten simple differential equations, and a few interpolations
     as well. This is running the linear fuel-film compensator, although
     I am considering re-coding the compensator to be the more
     complicated multi-state compensator, proposed and tested in
     a later paper. Manifold filling dynamics also contribute two or
     three de's in this section.

  pseudo-slow calculations are run in a 4ms round-robin manner,
     as these calculations are grouped into four sections. Each
     section is called during each main loop. These include tasks
     like sensor filtering, 'tweak' calculations, desired fuel
     mixture calculations, etc. Also, a sliding-mode oxygen
     feedback controller goes in here.

  slow sensors and calculations are run in a round-robin manner,
     and I have 32 spots for these routines. These are called
     immediately after the main code loop. Sensor diagnostics
     and very slow sensor calculations go in this group.

  the MAF sensor is sampled every 60 crank degrees, in an interrupt
     service routine run off of the TPU. This is to enable the
     EABS sampling system covered in a later paper by Hendricks.
     MAP is also treated in this way.

     Other sensors are sampled at a slower rate in the main code loop.

  the diagnostic comm routines are run in an interrupt service routine.
     FLASH re-programming is done in the ISR, as well.... but it's
     wierd. A FLASH PROGRAM command causes the interrupt routine to
     lock the processor up, and begin polling the serial port for
     further special commands. Only the SECTOR_ERASE, SECTOR_PROGRAM,
     SECTOR_VERIFY, and CONTROLLER_REBOOT commands work in this mode.

  in case the FLASH gets blown away, I am placing a connector on the
     board for background-debug mode. This would allow me to re-load
     its brains in case power was lost during the first power-up.
     For this reason, the first sector consists of a simple test
     to verify that the code blocks are ok, and also the diagnostic
     serial routines. Hopefully, the first sector doesn't need to
     be erased, but if it gets nuked, there is a back door.

 That's my approach, anyways. I am trying to use as much engine
 modelling in my code to estimate internal variables, so I can eliminate
 as much of the fuel transient problems as possible. That's why I'm
 using such a high sampling rate in my main loop. And also why I'm
 not using a multi-tasking exec. The pseudo multi-tasker built into
 the main loop is capable of handling anything I would like to do with
 the ECM.

 -Dale