The range was underflowing the calculated hue value causing it to loop back to other colors. For example when battery ranged from below 20% the color would shift from red (the correct color for minimum battery) to shades of magenta. RSSI had the same problem.
Now the logic reserves the base color (red in these cases) for the minimum 20% of the range. From 20-100% the color will scale from red through to green.
* Introduce CLI parameter gyro_filter_debug_axis which defaults to 'ROLL',
the previous behavior. When set to either PITCH, or YAW, the debug logging
implementation in the gyro filtering will use that axis instead.
The menu stack counter was not being reset when CMS was initially entered and multiple entries can cause an array overflow/memory corruption and wedge.
Previosuly the problem was accidentally prevented because the user was required to "back out" through the menus to exit which decremented the array index. However with the addition of the popup exit/save menu it became possible to exit without traversing back through the menu structure and this bug was exposed.
Previous logic bypassed optimizations and updated the ws2811 on every task execution - leading to and average of 92us task execution time. Restored the previous optimizations and additionally optimized the new "RACE" and "BEACON" modes so that they only update the led's when there's an actual state change. Task time for these modes is now in the 2-4us range for F405. For the normal "STATUS" profile the performance has been restored to previous optimized levels and typical configurations will generally have task times in the 8-14us range.
Revised the LEDLOW disable mode to function all the time and disable the ledstrip completely. Previously if visual beeper was enabled that would override the disable and the ledstrip would display whatever would be otherwise displayed but only during the duration of the beep. The resulted to a very inconsistent behavior depending on the user's settings.
Added visual beeper support to the new "RACE" and "BEACON" profile modes.
General cleanup and refactoring.
Having the iterm resetting happening in the rx loop causes a sawtooth PID/motor effect while idling since the PID loop is running at a much higher rate and iterm is allowed to grow during this, and then only reset at a much lower rate in the rx loop. This can potentially lead to some oscillation and/or resonance while idling before takeoff as the sawtooth signal can make it through to the motor outputs.
