The Miniboard Again ...

[Dale Ulan]

> 
> 
> On Wed, 18 May 1994, Jonathan R. Lusky wrote:
> 
> > memory, 2) doesn't have adequate inputs, 3) the motor drivers included
> > with it are useless in this application.  I do believe that a 68HC11
> > is the way to go, I just don't think the miniboard is well suited to
> > this application.
> 
> There are hc11s with more EPROM space (8K) but the download run cycle 
> would be slower.

The simplest way to go is with an external EPROM or EEPROM. HC11's with more
than 2k of on-chip non-volatile memory are ceramic EPROMs or plastic
OTPROMs. Except the 811A8, which Motorola doesn't seem to even admit to
ever having.

I used the 68HC11F1 with great success. I managed to port over a complete
6801-based engine controller with hardware-based controls (with the CPU
doing only calculations) to a completely software-based system. I even
have about 65% CPU idle time with my 8 ms loop time and running a 4-cyl
at 25000 RPM. Of course, the engine doesn't actually run that fast...

> 3)  Well, you just don't buy them or put them on the board.  These can
> be used as generic high/low side drivers so they may still find a use.

All drivers for a car with the exception of idle speed motor and ignition
drivers should be low-side drivers. I like the MTP3055EL logic-level MOSFET
from Motorola. I drive them directly off of a 74HC574 latch for my power
outputs. They work great! Just have to put about a 40V zener across them
to absorb switching spikes.

> Of course, I very pleased that Jonathan has agreed that the 'hc11 is the way
> to go :-).  I would not cry too much if we went with the F1 board or something
> like it.

The 68HC11F1 is probably the best HC11 member for this application. Unless you
want to pay $50 to $100 for a single chip mode HC711K1 or E9 with a window,
an external memory device works great. Also, the F1 runs at 4 MHz instead of 2,
which makes software easier, since time constraints are not so big.

You *can* do fuel injection and spark in the E2, but when I did it, there were
no diagnostics, and so little free space that I doubled interrupt vectors
as instructions. That is *NOT* the correct way to write software for engine
control applications.

....car manufacturer reference deleted....
... likes to use 17x17 tables, which take up a lot of space. One for spark,
one for fuel, then add accel enrichment, accel temp comp, decel cutoff, decel
temp comp, a choke system (usually five or so tables), and cold engine spark
advance. This amount of code takes just 2200 bytes, with about 300 bytes of
that reserved for interrupts, etc. Tables on top of that, too.

My approach is to use software to accomplish something until it hurts too
much. Then I change to hardware. Actually, more often than not, I throw
in another processor and continue doing it in software... because software
does not require a PC board re-design at the last minute when you're about
to start shipping your product...

My plans for my F1 board include changing it to a 711K4 in the near future,
using OTPROM. In this configuration, there will be only one real 'chip' on
the board. But this is after a couple years of software development. The
application is for use on motorcycle engines.

My next project is to port that over to the 68332 processor, and move
the product over to a 68F333, if I could ever get them...

-Dale