f3a02f0f4ea617e79463a83710d91105486aad90
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.
Languages
C
71.9%
C++
25.4%
Python
0.9%
CMake
0.6%
Shell
0.3%
Other
0.7%