* outer loops

* scheduling

* subsystems' weights

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:

* OnlineCourse/EventQueue is about 400 lines and HeapStructure (for OnlineCourse/EventQueue) is about 140 lines

* InputTrigger handling is about 200 lines

* IgnCalc is about 200 lines (mostly in ve.c)

* FuelCalc is about 2000 lines (more with VElearning)

* LCD low level is about 600 lines

* LCD high level (what to write on it) is about 900 lines

* GenBoard/MenuSystem (user input, also used to upload config) is about 800 lines

* WideBand/Calc is about 1000 lines

* OnlineCourse/UartComm RS232 runtime data, logging, configurations and tables' textual dump is about 800 lines

* GenBoard/FirmWare/BootLoader is about 500 lines

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:

* changing controller (such as PID) parameters is much simpler by SW-configuration than via setting resistors (soldering or trimmer)

* changing the controller algorithm is much much much simpler in the digital domain.

* a digital design is easier to reproduce and test (or even a single part: let it be a simple multiplexer or a complex circuit).

* some useful statistical algorithms (like histogram, outlier elimination) are waaay easier to do in the digital domain

* noise is easier to handle in the digital domain: if you have N iterations (like is common for simulated annealing, genetic algorithm, storing the signal for long time, or just reusing a subsystem for several unrelated signals with time-multiplexing) or subprocesses on the signal, the analog way will become useless (due to noise at each level) as N increases, while the cost of digital processing only increases by a mild N*log(N) keeping the noise at acceptable levels.

* try to send 150 analog signals (of different frequency and other characteristics) to the telemetry center (or to your friend at the other hemisphere for that matter). This is related to the noise issue outlined above, but this application is so important, it worths noting.

disadvantage of digital control:

* interfacing to the world is usually analog. Therefore the IO consists of added steps, like ADC and DAC conversion.

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.