GenBoard/CodeFlowChart

targetted for developers - the outline of firmware code:

Mainloop and interrupts

The flow of the code in MS-AVR is extermely simple. We have a mainloop (see megasquirt.c) that loops forever and we have all the timing-sensitive stuff in interrupts (see SIG_PRIMARY_TRIGGER in timing.c and the splitout handler2k.c and OnlineCourse/EventQueue ). The mainloop has some branches that are only executed sometimes, eg. every 100msec (search for softelapsed). Other parts are jumped over on some condition, eg. the lcd.cache[] is not updated while lcd.init is true (the LCD is in initialization mode).

Mainloop scheduler would be simple:

If we need, we can implement a simple scheduler for the non-time-critical stuff (note that all the time-critical stuff are scheduled very precisely with the OnlineCourse/EventQueue ), which gives higher priority to some tasks than others (see the bitfield of the tasks who would like to be run, with a similar algorithm as find_dirty() in 'lcd.c). Maybe run rpmcalc, fuelcalc and wbo2calc parts with a higher priority than LCD related functions. With current functionality a more complex scheduler was not needed (we don't have any very long tasks and mainloop looptime is better than other EFI systems).

SoftPwm?

When a target pwm duty must be maintained, (surprisingly) it can be done from mainloop. See SoftPwm? for how.

FuelCalc? page may at sometime in the near future contain information about the basic functioning of the code base. Visit http://efi332.sourceforge.net/fiequations.htm since it uses very similar fuel calculations.

To get an idea about separate parts:

You can see that most of the implementation is calculations, that are better be done with a microcontroller (AtMega128 or LPC2119 Philips ARM as on BrainStorming?) than a ProgrammedLogic? (FPGA or CPLD). The timing sensitive stuff, which is much less than 10% of the code would benefit a little from TPU (which could be implemented on some ProgrammedLogic?), but it would get unmeasurable engine power before IonSense is implemented (if you know desired ignition advance close to 1..2 degrees due to tuning limitations because of fuel-differences, humidity, etc..., you cannot gain power by timing better than 1/8 degree resolution).


processing the signals in analog and digital domain:

You probably noticed that the '''processing of signals take space in the digital domain. Could an analog controller (eg. using operational amplifiers) be made? Yes. In fact there were such designs (K-Jetronic?) in the old times. Could an analog design compete? Hardly. Maybe see DesignPrinciples?.

Advantages of digital processing:

disadvantage of digital control:

It is no wonder why the analog part is kept at a minimum (not only on GenBoard, but basically every market-mature systems today), implementing only the most necessary IO and some simple filtering in the analog domain. This is especially beneficial when signals are low frequency (in the engine management system all signals are low freq, the highest ones being sound-freq: DetonationDetection and IonSense). The analog way is especially expensive to do right in small manufacturing batches (the quality assurance becomes very big overhead either done manually or semi-automated). The only example of doing analog processing found in recent (10..20 year old design) cars is the electric fan control (switched on above a certain coolant temp) and rarely electric coolant-circulating pump control. Today very rare, since the coolant temperature is also needed in the fuel calculations, and it is also nice to be logged together with other engine data, so even these very simple signals are usually found to be better processed in the digital domain.


The new developers can get a quick feel about how the system operates by visiting the OnlineCourse.