rusefi.com

I've notices some nasty jitter even on the bench so I've decided to make some tools so that we can keep an eye on all this.

java console has a gauge which displays the signal dwell as measured by out build-in logic analyzer. triggerinfo would tell us that primary logic input is http://i.imgur.com/e34b5vN.png and showconfig shows that one of the injection channels is http://i.imgur.com/ILq2dgd.png

Now let's reset everything to the default state - that's set_engine_type 20, and also enable self_stimulation to turn the whole firmware logic on.

Perfect, now we put a jumper wire between PA8 and PB8 and start the console, set RPM to a higher value, restart the console and look at the numbers.



I do not like all this at all, to be continued.

I guess we need some methodology.
Test scenario: rusEfi 4647 compiled in Eclipse 'Debug' configuration, with some funny options applied:

set_engine_type 3
disable engine_control
disable map_avg
disable mil
disable fuel_pump
disable tunerstudio
disable wave_analyzer
disable idle_thread
set_rpm_hard_limit 150000
writeconfig
<microcontroller reboot>
rpm 24000

Export PD1 signal (primary trigger emulation) captured with a logic analyzer into .csv, open Excel, create column C - that would be "ON time in ms"
=IF(B3,C2,(A3-A2)*1000)
and column D - standard deviation, length 46
=STDEV(C4:C50)

That gives us (all times in ms)


These would be our reference values - at least we know that we can produce a clean-enough trigger signal in case we are not busy processing that signal (the signal goes nowhere and some of the utility threads are not running)
To be continued...

Now let's make the firmware struggle - same version #4647

set_engine_type 3
rpm 24000
enable self_stimulation

In this scenario we reset settings to default so all the features are active, we generate high rpm signal - the RPM in this test is actually above the RPM hard limit, so no real processing takes place. Yet the numbers definitely look differently:

Made some good progress: version #4718

set_engine_type 3
rpm 24000
enable self_stimulation

- a number of improvements to SingleTimerExecutor. note how ON times are not ~2.42ms but back to ~2.5ms where they should be
- fast ADC is now disabled by default if it's not needed for the particular engine configuration. todo: figure out proper fast ADC frequency, maybe re-enable for everybody
- todo? maybe? it's probably worth migrating from getTimeNowUs() to getTimeNowNt(). Instead of using microseconds we would be using CPU native cycles counter thus saving on __aeabi_uldivmod which is a heavy operation

(all times are still in ms)