Hello Paul & Group,

There was an "Ultra-squirt" project going on about two years ago. Seems
that it didn't materialize, but the hardware choice was interesting:

Freescale MPC55xx - 32-bit PowerPC core, programmable eTPU timer for
ignition + injection, DSP knock indication built-in, CAN bus, plenty of
i/o, good set of driver/sensor circuits.

What's interesting here, is that - if i understood correctly - the eTPU
unit offloads the ignition/injection timing task from processor, and it
is still fault-tolerant (ie. missing teeth, no CAS signal etc.)

Here's some video clips. Not really a proper product introduction, but
gives an idea how eTPU works.

Using the Engine Position eTPU Functions - Freescale Application Note: 3769
http://www.youtube.com/watch?v=a1NplNEAaww

eTPU Set 2 Simulator Demo
http://www.youtube.com/watch?v=Mu_zBkoByVQ

Link to Freescale eTPU user guides:
http://tinyurl.com/2wzw45p

Back then, the required CodeWarrior version cost $5000, now it is $955
or $1955 - the difference seems to be the "Optimizing C/C++ compiler"
Runs on Linux or win2k - 7, new version 10.0 within Eclipse. Yes that's
more than OSS price, but... it ought to be good.

It seems that this is the best platform to develop a really capable
FADEC product for rotary engines.
...Just that there should be someone involved who could (and will ;)
make neat C code...

Anyone tried 55xx / 56xx?


 Petri Flander


I have code warrior for some of the smaller Free Scale chips but what
I don't like about it is the  C or assembly language required.

Atmel ZBasic is an order of magnitude easier to learn and
faster to program. There are some trade off as a bit more hardware
is required. It is fast enough for simple AC engine EFI and EFIS.

Paul Lamar

Yes, that Freescale route is laborous... but the end product could be
just wonderful. Knock sensor alone is very appealing...
Personally, i don't enjoy to clear my way through a maze of interrupt
vectors and badly behaving pointers ;) - but some fellas have become
very good at it. It's just how to attract them to work with something
like this...
sometimes open source approach can solve this kind of dilemma.

What's your current configuration with Atmel, how did you solve the
timing issue? By using hardware timers? Then i guess you have a bit
similar setup as Freescale's MCU + eTPU, right?

Cheers,
Petri

Yes I agree true real time processing requires one to know
precisely how long any series of instructions require to
execute. This normally eliminates or discourages the use of any
higher level programming language such as C or BASIC.

I avoid the critical timing situation wherever possible
and use an easy to learn and quick to program BASIC.

The ignition timing is done with capacitor discharge circuits
rather than inductive circuits.  Inductive system requires the
software to anticipate when the coil current will be interrupted
to form the spark.  If this is not done the present coils
available tend to over heat due to excessive long term current
flow.

A CD system on the other hand merely discharges a capacitor
that can stay charged for as long as necessary. This is achieved
my multiple low cost Hall Effect sensors and a small rotating
magnet. Also the capacitor can be recharged nearly instantaneously.
Ignition advance is a manual advance system which is only needed
when on long cruise periods at high altitudes. 90% of the time
a fixed advance of 22 degrees BTDC can be used.

The RPM module is stand alone as RPM determination in a timely
manner is one of the toughest things to do.

Also multiple processors are used to distribute the computing
chores using existing software. For an example; a low cost netbook
PC is used as the display device for an EFIS and data gathering
or acquizition system. This processor is indepentent of the engine CPU
so future rapid developments and cost reductions in netbook PC's
can be taken advantage of. This is a big picture holistic approach.

The Atmel BASIC has means to  encourage this approach
by a single simple command that sends any data to the PC using the USB
interface. It is up to the PC software to format and display
the data using existing serial terminal software or Visual Basic
or other software.

This is a classic trade-off of hardware verses software.

Paul Lamar