All it wants is to use the main trigger state, so don't bother copying it. Instead, change
PwmConfig to take a const pointer to a Multi.*Sequence, then make all the users adapt. Worse
fallout is that SimplePwm now has its own Multi.*Sequence, but PwmConfig is downgraded to a
pointer, so that's only a net +4 bytes. And we can make the overhead of Multi.*Sequence much lower
using embedded arrays, which only the caller can do since it knows the maximum size... (for another
day...)
Also remove SimplePwm's 2nd copy of SingleChannelStateSequence. It served no purpose.
Saves 1992 bytes of BSS and 24 bytes of RAM4 (latter probably due to SimplePwm change)
Memory seems more valuable than CPU; use the O(lg n) lookup by angle. A side effect is that it
seems to fix trigger lookup for the second phase of TRIGGERTYPE 53 544 TT_TRI _TACH 0.00
Having to remove the precompiled header when switching from firmware to simulator to unit_tests and
back again is annoying. Use a directory to store the precompiled header output. Turn off
precompiled header warnings as GCC still complains even if it finds a valid one eventually.
The last version is already much better than the original, mostly because it doesn't call
CriticalSectionLocker, which has a ton of overhead due to debug tracking. But this version is
another 4 instructions / 12 bytes shorter. Does as much match in 32-bit land as possible, and
avoids math operations that span 64-bits (i.e. either operate on the lower half or upper half, but
not both). The result is only 3 instructions not including the necessary 4 loads (ptr to now, now,
ptr to upper, upper), 1 store (upper), and 1 return/branch.
Track the top two bits of the 32-bit time field, along with the bits that comprise the top half of
the 64-bit time field. We can detect when the 32-bit field is advancing or falling back from the
global time counter as long as the change is less than about 1 billion ticks. This shows up as
either 01 or 11 in the top 2 bits of the 32-bit time field relative to the 64-bit field. Or is
there is no change it shows up as 00. Changes of 2 billion or more cannot be discerned as +2
billion and -2 billion both show up as 10.
Change the simulator to use this logic to make sure it gets some exercise.
* common_make: rusefi.* should be functional image
OpenBLT used: rusefi.* is bootloader plus RusEFI
OpenBLT not used: rusefi.* is RusEFI only.
In both cases flashing of rusefi.* image to blank device should be
enough.
rusefi_update.srec does not include bootloader and this image should
be used for CAN update.
* Boundle generation: include bootloader and update image
* Update hex2dfu, deliver composite bin file