This combines now the changes from branch PerformanceOptimizations to trunk
Mainly this change should do following:
- Flash savings should be around 224 bytes for stock
- Added option ARITHMETIC_OVERFLOW_CHECK to prevent overflows.
Still not bulletproof, but codecost is about 50 bytes
- Increases mix speed about 25 - 30% depending on task for stock
Also increased for other boards, but they may not notice...
- Increased ranges for weight and offset from +-125% to +-245%
- Easier now to increase number of GVARS if needed; Just increase GVAR_MAX in myeeprom.h.
But!!!! EEPROM layout changes and may not be compatible. Do this for own proposes.
Till now we do not know how we handle this in future.
- Corrected Timer for stock if used together with AUDIO or VOICE option
- See comments below, what I potentially forgotten...
Be aware this version is currently not compatible to companion9x. But the version before wasn't either. Work is current in progress to tie this up.
I would like Bertrand to check this version. It's currently my proposal for the merge. It holds following changes:
- Introduced constant RESERVE_RANGE_FOR_GVARS to make number of MAX_GVARS independent.
- NEGATIVE_SHIFT_CORRECTION is now set by makefile by default instead inside the code
The would at least give the option to save code and have less precise calculation.
- ex_chans is included like in trunk. No change here, because it would break output as input.
Actually this version would reduce the effort to merge:
- We stay with the GVARS defines we had till now
- We reserve for ranges space for 10 GVARS, which do not hurt, because we doubled ranges anyway.
- We stay with 5 GVARS in the moment. According my poll not many people currently use GVARS.
Therefore there is plenty of time finding here a better solution. I expect the number of
people will increase soon, but up to this moment 5 GVARS are more than enough.
- The layout of EEPROM for the values is already the new format. That means when we allow more GVARS in future, at least the parameters like weight, offset, etc. needs no additional conversion.
What do you think. Should we go this way?
Warning!!!
==========
Be aware this version is in branch and is not supported currently by Companion9x. Whatever you configure will be lost in final version!
Because EEPROM interpretation changes anyway because of higher offset and weight values possible in this branch, I tried to align the bits a little bit different to allow a higher number of GVARS. The code change is nearly flash neutral. It costs only 18 bytes flash, but would us allow to either increase range for weight and offset further, or allow more GVARS.
I set it to 9 for this branch now. Please try and report.
It's very easy now to adjust the GVARS number by changing the constant in myeeprom.h. Just change the MAX_GVARS constant for your build in myeeprom.h in the beginning of the file.
The lower MAX_GVARS the higher is the possible number for weight and offset and vice versa.
That is quite likely too complicated for conversion so we need to agree maximum for GVARS.
Not sure in the moment, but this is a branch only and is just to play with it.
Not sure how Bertrand would like this anyway, so may be removed at all.
I need Bertrand for this change, but also testers.
I removed ex_chans[] array, because I am the opinion it can be easily replaced by chans[].
According history ex_chans was there first, after that chans[] are introduced. Now we can use chans instead of ex_chans and get rid of this part to have savings. I am incorrect?
My tests are all OK. The only area I can imagive this change is influenced are flight phases changes. And only if output channels are used as input. But I think this way is even better. Please test and report.
[stock] Port from a part of Andreas patch relative to timers. Thanks Andreas! It allowed me to implement the configurable beeps for timers at a almost 0 flash cost.
[stock] Port from a part of Andreas patch relative to timers. Thanks Andreas! It allowed me to implement the configurable beeps for timers at a almost 0 flash cost.
This change makes both weight and offset range bigger for all 32 possible mixers.
Instead of -125 to 125 now -245 to 245 is allowed for weight and offset in mixer.
No additional EEPROM is needed. Conversion of EEPROM follow soon...
Now the expo function is explained properly. Expo execution speed should be again better.
Codesaving this time only 8 bytes.
Added EXTENDED_EXPO define for a wider range of expo. So around 0 the curve is more flat and the edges increase faster. This change costs about 84 bytes.
I noticed the curve doesn't much change especially for smaller k values.
Now the range is extended. From 0 to 80 it gives the old curves from 0 to 100.
From 81 to 100 a higher raising curve is used. There is a small break between 80 to 81.
If this is a problem I can change it to be smooth and even less code size, but loose the old curve form.
I moved SLOW function back to old position, because it might be not a good idea if differential is actived, and the end positions are reached at different times. Therefore the smaller movement needs to be slower. Please try and test and report your opinion.
Please also test more about overruns. I was able to generate a overrun by added about 4x a 125% value with 125% offset. (output each above 200%, in total more than 800%) The overruns occurs earlier compared to original version. Could this cause a problem? I can change the internal calculation to be more like the original version, but would cost more flash.
Issue 204 fixed (Tx Batt spoken)
[X9D] It was impossible to avoid a Format on EEPROM Alert
[all] Function v1==x modified to v1~=x (needs to be tested)
Developers list updated
Needs testing!!! Volunteer please come in.
Benefits of change:
-248 bytes code generated used gcc 4.7.2
-huge performance increase. My measurements:
simple mix goes down from 2,87msec to 1.93msec
middle complex mix goes down from 3,37msec to 2,00msec
complex mix (with phase change) goes down from 6,87msec to 4,18msec
[all] Change in Switches order (to match the Mixer sources order and save some flash)
[all] New menu in MODELSEL when a ROTARY_ENCODER_NAVIGATION enabled
[all] Add REs (short) and REl (long) in Custom Functions screen. Will be needed later to reset the Rotary Encoder (for example)
[all] Expo function rewritten and many other flash savings (thanks Andreas)
[stock] LONG key press duration is longer
[stock] Rotary Encoder bugs fixed
[stock/gruvin9x] Play Both function added
!!! TRANSLATIONS ALL NEED TO BE UPDATED BEFORE NEXT RELEASE
Issue 193 fixed (PWM Backlight)
[stock] Rotary encoder bug fixes
[stock / '128 / gruvin9x] Play Both function. Translations needed, who wants to add them in all language files?
[stock] 40bytes flash saved
[ARM] No SD support after a Tx reboot on ARM flavors
[all] Issue 194 fixed (negative GVARS - on all boards!)
[all] Vario small change on center high limit
bsongis