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
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
[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)
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
bernet.andre@gmail.com