[stock] Flash saving in AUDIO code. Warning, I had to change some VOICE prompt numbers, check the tts.py to know which ones!
[Taranis] DSM2 protocol added when compiling with DSM2=PPM
[all] Issue 28 fixed (10 beeps on countdown during the last 10 seconds)
[all] Issue 37 fixed (Pwr+) added
[all] Issue 39 fixed (Potscroll too slow)
[Taranis] Bug with delays on 3 states switches
[Taranis/sky9x/gruvin9x] Date & Time not always saved
[Taranis] Bitmap displayed in MODELSEL
[Taranis] Empty EEPROM is not calculated on each keypress in MODELSEL screen
[stock/stock128] Huge RAM saving (thanks Mike!)
[sky9x] Good register used for reboot cause
[Taranis] PPM Center Adjustable
[stock] Issue 225 fixed
[all] Throttle Inverted is now a Model parameter
[Taranis] Issue 15 fixed (when >5 GVARS)
[Gruvin9x] Issue 16 almost fixed
[all except '64] Trainer short and Trainer long in Custom Functions
[Taranis] No Haptic function
[Taranis] Overflow problem in playValue
[Taranis] EEPROM flushed and loaded again before / after USB connection
[all] Font changes for the Custom Switches screen
[Taranis] Channel name in Mixes screen
[sky9x/Taranis] Negative AND switches in Custom Switches screen
[Taranis] Altitude displayed with PREC1
[Taranis] Correct SD size in massstorage
[Taranis] Unmount / Mount SD in massstorage
[Taranis] A1 / A2 displayed in Top Bar depending on Voltage source selected in Telemetry menu
[Taranis] No RSSI / Voltage in Top Bar if no RSSI
Prevent a little bit code increase necessary because of new offset, weight handling.
Saved me 12 bytes flash.
However not sure if md_SetWeight(md, XXXX) is not necessary for all weight settings from template. Currently only for negative values done.
Will try how much code cost this is. Can we rely the memory is 0 for all mix elements?
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.
[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 version holds mainly bugfixes and prepares this branch for merge.
Please test and report.
- gvars didn't work for value ranges usually from -100 to 100 (e.g. diff function)
- gvars shown wrong also in models menu (same in trunk as well)
- gbirkus tested ranges with speed optimizations, overruns occured at half range of trunk version. Now this is fixed and a much bigger range can be used. Still overruns possible. Please test.
- ISR 10msec now safe and code optimized.
This change make ISR masking for 10msec call back to the old solution.
Bugfix for throttle time calculation if limits are changed.
Noticed my optimized recalculation routine was wrong.
Now I changed it and recalculation is done on 32bit basis which cause 16bytes more flash.
I also noticed the original version (in trunk) just does recalculation of 10 base. That means for full throttle range there would be only 10 steps noticed if limits are changed. That leads to a very unpresise calculation if your throttle limit do not match these steps.
I can do something similar but this time only with 8 steps but save 16bytes flash.
What's your opinion.
brief:
------
* added compile options to makefile:
- CORRECT_NEGATIVE_VALUES
- EXTENDED_EXPO_CURVE
* bugfix for Timer calculation if AUDIO or VOICE was selected for stock and Gruvin
* bugfix for Throttle timer calculation
* small flash savings about 28 bytes if SLOW wasn't moved, now only 20 bytes
* SLOW calculation moved to beginning, but no weight compensation
detailed
--------
Makefile options:
Like all other options this is set either to YES or NO. Both are default NO.
This gives the user the possibility to choose themselves about which precision they want.
Or if they want a greater EXPO range, both increases code of course. The code changes are explained in detail in source code and earlier version of this branch.
Bugfix for Timer calculation if AUDIO or VOICE was selected for stock and Gruvin
Need again some reports. I noticed there was a correction algorithm activated for 10msec call generated. For some unknown reasons, the correction was disabled, if AUDIO or VOICE was selected. This fix should make it working again. The clock was actually too fast. It's about 5 - 6 seconds per hours. Should be correct now, please test and report.
Also the IRQ disabled the timer IRQ while it is on. This is wrong as well and saved code.
Bugfix for Throttle timer calculation
Actually the throttle calculations leads to an overrun if full throttle was given. Due to -1 calculation problem this issue was not seen, because it was 1 digit smaller. With the CORRECT_NEGATIVE_VALUE option actually the full range was used, and boom, throttle timer didn't work. This fix actually corrects this and made the code about 28 bytes smaller and faster.
SLOW calculation moved to beginning, but no weight compensation
As stated by bsongis I moved the SLOW calculation to the beginning. This matches to most other remote controls. However I still left the weight compensation out. This would cost 90 bytes flash and a slow division. Basically if we move the SLOW feature to the beginning it changes the meaning for SLOW. It is not actually defining the output speed in percentage per second. It is defining the input speed in % per second. In this case a mix with high weight will move faster as a mix with small weight. That's the same for other remote controls as well.
Doing this compromise only costs 8 additional bytes of flash.
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...
bsongis@gmail.com