There seems to be more interest in this for aircraft use.
Some people I know are trying to implement Megasquirt
(I think) on some experimental aircraft using the traditional
air cooled aircraft engine.

It can be done but I am not comfortable with Megasquirt.
Currently it seems  it has evolved to be all things to all
car engines while the aircraft engine needs are more limited.

It also relies on feedback from an O2 sensor which does
not work well on 100LL. Yes I know there is a move afoot to
replace 100LL but that has been talked about for the last
ten years with no real movement. The lead emitted is a phony
issue and not a real problem.

The aircraft application needs more display of engine parameter
and historical data acquisition. In other words what is the engine
doing now and what was the engine doing for the entire flight.
In other words it needs to be combined with an engine monitoring
system.

Also Megasquirt is not well documented IMHO.
For example here is a so called flow chart of the main program.
What is missing in most cases is how, when and why.


    Set up Phase-Lock Loop, RTC, Serial, Interupts
    Initialization of Ports / Variables
    Sample MAP sensor and save as Barometer
    Copy Configuration and VE variables from Flash to RAM
    Copy Flash Burn Routine from Flash to RAM
Main Loop:
    Perform Table Lookup for Barometer and Air Density Correction
    Perform Table Lookup for Coolant and MAP Linearization
    Determine if in Fast-Idle Mode
    Compute RPM, Determine if Engine is Cranking or Running and Flood-Clear
    Calculate Warmup and After-start Enrichment
    Calculate Acceleration Enrichment/Enleanment
    Calculate EGO Enrichment
    Calculate VE from 2-D Table Interpolation
    Compute Total Enrichment Value (Accel, Baro, Air Density, EGO, and Warmup)
    Compute VE Contribution
    Compute MAP/Baro
    Calculate REQ_FUEL
    Calculate Battery Voltage Compensation
    Calculate Final Pulse Width
Goto [back to] Main Loop


Yes the info is there in the C source code but C is the fundamental problem.
One must be an accomplished C programmer to really understand what
is going on. I am not. There is a lot of controversy about this but IMHO
C is a terse and cryptic language. C was invented back in the days when one
used a teletype machine to talk to and program computers. That was 40 years ago.
Computers are a million times smarter than they were in those days.
You should be able to tell the computer in plain English what you want it
to do. I am not saying voice recognition here. Just be able to type it in.

What do you think about this?

Paul Lamar


Megasquirt runs happily open loop - no O2 sensor..

There's a learning curve with C. And then some people write crappy C code, that
can be very obfuscated. It's very powerful and efficient, and if well written,
not too bad to understand.  I like that the C compiler is so old and well
developed. New languages might not be as well debugged.


Matt-

"There's a learning curve with C." No kidding :)
There is a version of BASIC that is evolving into a standard
for machine control. Depends on how you define efficient.

http://en.wikipedia.org/wiki/BASIC_Stamp

"The BASIC Stamp is a microcontroller with a small, specialized BASIC
interpreter (PBASIC) built into ROM. It is made by Parallax, Inc. and has been
popular with electronics hobbyists since the early 1990s due to its low
threshold of learning and ease of use (due to its simple BASIC language)."


Paul Lamar


Paul,

Megasquirt is well documented for it's purpose. I suspect well over a 1000
vehicles are running the megasquirt, so pretty large acceptance.

What you are missing with the megasquirt code is Al Gippo's comments.  Al did
the math (who, what, where, when), and Bruce
did the coding (How) that you listed out.  A lot of the original material is no
longer posted (there was a ton of questions on how the formula's were derived...
but the goal was to just get a simple, easy to tune fuel only system, out to
enthusiast). Some of the simple explanations are still here:
http://www.megamanual.com/v22manual/mfuel.htm

The original project was John Gwynne's efi332.  We used a 68332 system for fuel
and spark, and a bunch of control. Bruce Bowling felt that system was way too
complicated, and felt the 6808 was easier to implement for a fuel only system
that became the mega-squirt.
Lot of the documentation is still on the web here:
http://www.diy-efi.org/efi332/faq.htm
http://www.diy-efi.org/efi332/equations/algorith.htm -- Section by Al Grippo

Tom W

Hi Paul,

C is often referred to as a "portable assembly language."  It is
"close to the metal," and so can be cryptic. But, for interfacing with
devices and manipulating memory directly (often required when
interfacing with embedded systems and sensors), it is a reasonable
language.  What I think is missing, is a more abstract layer on top of
the device-dependent interface code.

You can imagine a layer of C code that talks with the controllers and
sensors, but a more abstract layer of code above that in which the
logic and control flow is defined.  I have seen in recent years an
increase in the number of projects in which a powerful scripting
language calls out to C libraries.  This may be what you are looking
for.  An example implementation might be a Python scripted "Main Loop"
calling out to C libraries for sensor readings, etc., but all the
complex decision logic is made in Python (or Ruby or Perl, etc).

What you are describing when you talk about using "plain English" is a
domain specific language.  Computers require precise instructions and
will do exactly what you tell them to do, for better or worse.
English is too abstract and context-sensitive for precise control.  A
language optimized for the ECU domain might be an interesting project,
but is a difficult undertaking.  A good compromise, though, would be a
well defined API written in a high level scripting language that reads
a little like English.  Python suites that purpose quite well.


A little googling revealed the presence of Python on embedded systems
and single board ARM computers.

http://stackoverflow.com/questions/240996/anyone-using-python-for-embedded-projects


I also found 1 open-source ECU system under development, FreeEMS
(appears to be written in C):

http://freeems.org/


I wonder if there is enough interest to start an open-source (hardware
and software) project for an aircraft ECU based upon modern computer
languages and single board ARM computers?


Regards,

Mark Hagood

The problem for me with C is what do I do if I want to add an engine
monitoring display on the front panel? I am real good with 6800 assembly
language but I refuse to learn the cryptic C when I know it can
be done in BASIC. Of course assembly language is a REAL steep learning
curve for most people. It also consumes months if not years.

Paul Lamar

Paul,

One of the best programmers I had working for me had a Masters in English
Literature. Not only did he write some great weekly status reports, but his code
was very well thought out and written. Yes, even in C and C++.  He would discuss
the structure of a written sentence, then compare it with written code.  To him
the key was is just understanding the rules, and following them.

My son has been playing with the Arduino family of boards. Very simple syntax,
but it can produce wonderful results. He wanted a display for his 240SX.  He has
the GPS, data logging to SD card, and display up and running. Total time to
write the code to do that was one afternoon! I had the GPS module from a
previous project, and remember writing code in my spare time for a few months to
get done what he accomplished in an afternoon!

I noticed Digilent has a couple of MicroChip based Arduino boards, which have
much more computing power. For simple "one off projects" using the easiest to
implement and document software does make sense.

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,892,894&Prod=CHIPKIT-MAX32
Note the $49 price.

Tom W

I don't think Chaucer helped :) I hated English Lit :)

That looks like worth buying one and fooling around with it.
Certainly looks like there is a lot of competition for the embedded
market now.
-------------------------------------------------------------
    * Microchip® PIC32MX795F512 processor
          o 80 Mhz 32-bit MIPS
          o 512K Flash, 128K RAM
          o USB 2.0 OTG controller
          o 10/100 Ethernet MAC
          o Dual CAN controllers
    * Provides additional memory and advanced communications peripherals
    * Compatible with existing Arduino code examples, reference materials and
      other resources
    * Can also be programmed using Microchip's MPLAB (along with a PICkit 3 and
our PICkit3 Programming Cable Kit, seen below)
    * Arduino? "Mega" form factor
    * Compatible with Arduino? shields
    * 83 available I/O
    * User LED
    * Connects to a PC using a USB A -> mini B cable (not included)

-------------------------------------------------------------------------

So far I have been fooling extensively with the ZBasic product.
Tons of I/O. The ZBasic language is very fast. As I recall
it can pulse for one micro second.

Sub Main()

Call PutPin(12, zxOutputLow) ' pin 12 CAS 1 will be at logic zero
Call PutPin(13, zxOutputLow) ' pin 13 CAS 2 will be at logic zero
dim x as long
'check and wait for CAS 'Mazda crank angle sensor.

for x = 0 to 3000000 'develop only
If (GetPin(12)=1) then
Call rotor1
end if

if (GetPin(13) = 1) then
Call rotor2
end if
'loop
next x            'develop only
end sub 'main

http://www.zbasic.net/

I'll get one of these chipkit boards and see if I like it better.

Microchip has much better support than Atmel.

Paul Lamar


Hi All,
I am new to this list, but I actually work in the automotive industry at an
OEM.  I don't work on Engine ECU's everyday, but I work with ancillary
controllers for other areas. The basic functions for control systems are the
same.

I am thinking about an embedded Aircraft worthy system myself.  The EC3 system
looks good, but the lack of a serial interface is a bit of a concern.


I looked at Megasquirt.  It looks very interesting, but frankly fine on the
"Ground".  In the air, I would have many reservations

as there are lots and lots of opportunities for failure in software driven
platforms.  Additionally, companies like Bosch have teams of people working on
Engine ECU's.

I am leaning towards a different approach which would be cost effective and also
be supported by professional engine management people. The platform that I am
looking at is called a Mototron
by MotorHawk control systems.
http://mcs.woodward.com/products/ControlCore/ECUhardware/   The specific unit is
ECM5554-112.  It comes with a core OS that is tailored for this type of
application.

The tools needed to develop on this platform can vary, but are readily
available.  The platform has 3 CAN buses and an RS485 bus, which makes it ideal
for connecting to a Glass Cockpit and EMS.

The platform comes with development and production components that can be used
to create an Aircraft worthy system.  It is also set up for a wide temperature
range -40 to 105 C and comes in a cast aluminum frame.
With the right expertise, a pair of ECU's can be put into a redundant system.I
am thinking of working towards this goal

In terms of cost, they are less than $500, because they are produced under
various brand names for production automobiles with unique implementations for
different engines.


If there is any interest in working with me on adapting this to run a 20B or
13B, I am very open to it.

Thanks,
David Goings