SHAMELESS EFI332 PROMOTION - was Re: ECUs

[Paul E. Campbell]

> On 19 Jan 96 at 12:33, Gavin Walker wrote:
> >   My soldering skills are best not talked about in polite circles so
> > an ideal development platform would be one like.
> > 
> >     - ECU running a multitasking operating system

This is possible..BUT,

You'd want a real time and/or event-driven OS. If you happen to be running a
huge number cruncher like the mean value engine model as a flat out
nonoptimized system strictly for optimizing the lookup tables on the fly, then
I can potentially SEE the possibility of running that during the idle times
available when the real time requirements don't pre-empt your model right off
the system.

> >     - Services available to access input and manipulate outputs
> >     (like timing, etc). - Each service would have a local butter to
> >     store/read data cyclicly so the optimization can be done
> >     externally. - Persistent code/data storage such as FRAM chips. -
> >     Laptop interface

Laptop is no problem. Know what RS-232 is? Good, know what a MAX232 is? Costs
about $2-$10 for the laptop interface (serial port), depending on just how much
you want to spend on your DB-25 or DB-9 for gold plating, better connectors,
etc.

Now, as far as the "FRAM" goes, ARE YOU OUT OF YOUR MIND? Do you realize how
expensive that stuff is? It will not kill you to maybe use something dirt cheap
like SRAMs with a "power shutdown mode" while the engine is off or even using
a nice serial EEPROM for ultra-low power.

> >   So you'd have some, say Java, firmware on the FRAM and more bulky
> > code on the PC.  Adding new drivers would create new Java objects to
> > manipulate them.

What is this fascination with Java? Native code runs way faster and speed is
the key any day with engine controllers..I can argue the merits of a 32 bit
processor running every timing loop vs. using a cheap 8 bitter using PLL's
to handle the faster timing requirements and offsetting the processor load,
but running Java? I really fail to see the point of Java even for it's
intended purpose..there are tons of other better already existing languages
for the purpose Java is used for (Postscript Level 2, TCL/TK come to mind)
as well as if you are actually going to stick a byte coded interpreter in
the box just to make your life harder (Forth has much better support in
the microcontroller world).

> The EFI332 project is a step towards what your dreaming about - it 
> uses a 32 bit processor and will use RTEMS - a real time multi 
> tasking OS. The real time bits are controlled by a fancy timer system 
> and there is FLASH memory and battery backed RAM, all you'd need to 
> do is write the java firmware!

I'll bite this time. Why use flash memory over a serial EEPROM? I can only
think of three reasons:

1. You've got a PCMCIA slot for the world's easiest reprogramming.
2. Faster read/write times (overkill if it already uses battery backed RAM).
3. Denser storage.

I used a serial EEPROM in my last project (a 6 month data logger)...

I needed power failure protected memory.

It has a whopping 8 pins on it, and you don't need 4 of them (address select
lines..tied to power or ground).

The serial stream format is kind of awkward but trivial to use once you get
working subroutines written.

They cost about $5 for a 4K chip, which equates to about 3 months for my
data logger purposes. That's also about the size of the storage requirements
I've seen quoted on the EFI list for their engine lookup tables.