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
Let me explain the fixes:
1.)
Safety channel fix should avoid throttle being pushed the first few PPM outputs. Also the throttle counters are affected. Mostly noticable, the THt starts, even no throttle is given during startup. This fix should prevent this. Its just a new position for evalFunctions as proposed by bsongis
2.) Slow fix
Not so sure about this. I noticed the speed of Slow options in the mixer was always too fast for me. Wathever slow value I gave the movement was quite quick. Then I noticed I have always a small weight for that mixes. A bigger weight makes the movement faster. I thought what is the sense of this? Shouldn't it be vice versa? Then I realized the most useful way is just make it independ from weight. The speed just defines persentage of full movement per second. I think that is the most useful way to calculate it. And additionally this would simplify the mixcalculation a lot.
3.) Last but not least I found further code and data savings
- Additional 198 bytes code saved with avr-gcc 4.7.2 compared to last release. So this is in addition!
- Reduced data about 4 bytes
- Potentially there is also a slight mixer speedup possible. Not measured yet.
My first tests showed everything is now working as intended. Please test and report bug.
This change should avoid setting all output channels to 0 for the first few outputs generated.
Also this prevents the throttle triggered timers to start not intended after power up.
This occurs when you set throttle timers to output channel instead of stick. (By the way, is there any reason, this should be the source at all?)
Because reset of safety channels is only moved, this do not cost any additional bytes of flash.
However the reinitialisation in evalFunctions() may be missing somewhere?
Please comment...
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
This branch holds changes to improve speed and code size of stock and other versions of open9x. Some of the changes might be dangerous, that's why it is in a branch. After proper testing this branch may die, and will be merged into main trunk
[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
After some practical testing I lowered the vale to 16 for the 9XR. 32 does not work well. The sticks of the 9XR are really, really sloppy. I defined a new constant in the middle of the calib function, which is not very clean. Feel free to move this to a better place.
[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
open.20.fsguruh@xoxy.net