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