[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...
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.
brief description:
- SLOW should be correct now, please test a lot
- further small flash saving of 40 bytes
- higher THROTTLE accuracy not for stock but all other boards as proposed by bsongis
detailed:
while first fix claimed to be correct, it wasn't because the original version was not wrong. I was confused because the simulator in companion9x simulates nearly half of real speed. Is this intended? You will see it also on the seconds measured.
The original code was just a lot confusing and in a silly position. That's why I need your opinion!
I moved now the speed calculation to the last position in mixing calculation. This causes the slow directly operate on the output values. This saves additional 40 bytes flash code.
The original position was after trim, offset, curve, but before weight and differential.
The before weight position makes this confusing weight correction necessary. A simple position change would avoid the weight division.
My opinion for the best position for speed calculation is on the output, because whatever curve, diff, etc. calculation you had before the output will have the defined speed.
However somebody want the output to change speed according a curve? This wasn't possible with the original implementation, but a change could make this be easily possible.
As far as I know the implementation of the expensive Graupner remote controls do it that way. So speed is something like a controlled stickmovement speed and the rest is calculated on the base of it. I asked a lot, and most people do not really care if it is calculated on input or output. An advantage on the output is the easier calculation, which results in higher mixer speed and flash code savings.
What's your opinion? Where is the best place for speed calculation?
a) on the input
b) somewhere in the middle (please specify)
c) at the output
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
bsongis