C for embedded controllers

Bruce Bowling bowling at cebaf.gov
Tue Nov 28 19:49:20 GMT 1995


~ I would be honored to pick up a gauntlet thrown by such a worthy
~ opponent!

You left off the letters "un" from the "worthy".

~ 
~ I found object-oriented methods to be quite useful in designing a
~ fuel injection system.  I found C++ to be an effective language
~ when used to code the design.
~ 
~ In 1994 I produced a running EFI system for a Formula SAE car.  The
~ software was written almost entirely in C++ (including interrupt
~ handling through virtual functions).  The system featured speed-density
~ fuelling, spark timing and delivery, asynchronous tasks, round-robin
~ tasks, heap management, and graphics LCD display handling with multiple
~ (non-overlapped) windows which displayed various things from graphic
~ tachometers to diagnostic information.  It ran on a 68HC16 at engine
~ speeds over 11,000 RPM.

Some of the things which blows my mind from using C++ are the following:

1) Virtual functions, in which the virtual function tables get set up
at runtime (i.e. the function pointers inside of an object get
set when the object is created) or when an object gets created
using "new".  Virtual functions appear to be an additional layer
to debug through, since addresses are determined at runtime and
can change depending on the inheritance of an object.
I guess I am tainted by virtual functions because they bit me
big time when I used them with multi-processes using shared-memory,
which I can elaborate if people are interested.

2) How does one handle "new" in an embedded system?  Making a "malloc"
function is easy - making a new, which does things like set up
virtual function pointers using the constructor, appears harder.
Does the compiler do all the work?  (I am assuming there is
no operating system).

3) The strong typecasting of C++, while nice for the new or
sloppy programmer, can be a menance to someone who wants
to pass an argument a certain way because they know what
they are doing and are incrementally smarter than the compiler
at that moment.  The compiler protects the average user from
doing something stupid, at the expense of the "power" user
doing something he wants to do for a reason unknown to the
compiler.

~ 
~ I had to jump through enormous hoops to get the C++ code to run on
~ this target, for which no C++ compiler existed at that time.  Some
~ of this caused code ugliness.  There were other inefficiencies, too,
~ which in the future I can go into if this thread keeps up.  However,
~ I did find that the overall system was cleanly compartmentalized,
~ easy to maintain, and suprisingly stable on the first try.

You have dedication!  I would have given up in failure.  Impressive,
and please elborate.....

~ 
~ Curiously enough, I was informed today that the "C/C++ User's Journal"
~ will be publishing an article I wrote about this system.  I am told
~ it should be in the February issue.
~ 
~ More later (if you're interested) when I have all my materials in
~ front of me...
~ 
~ Ed Lansinger
~ GM Powertrain Premium V (Northstar/Aurora) Software & Calibration Group
~ Rensselaer Formula SAE Engine Group Leader '93, '94
~ 
~ 
~ 
- Bruce

--
-----------------------------------------------------
<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------------------------------------------------
               Bruce A. Bowling
  Staff Scientist - Instrumentation and Controls
 The Continuous Electron Beam Accelerator Facility
    12000 Jefferson Ave - Newport News, VA 23602
                 (804) 249-7240
                bowling at cebaf.gov  
        http://devserve.cebaf.gov/~bowling
-----------------------------------------------------
<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
-----------------------------------------------------



More information about the Diy_efi mailing list