This uses the raw stick values instead of the calculated RCCommand values to determine whether or not the stick has moved. The problem was that the RcCommand variable wasn't being reset to the stick position each loop, and so outputs were being treated as inputs.
This uses ints for the sensitivity instead of mapping floats back and forth.
Also the stick position is read directly, without the RC_Rate affecting this value.
I don't think that this will work, as we are manipulating the timer value to trick it into overflowing. Better would be to force an overflow a different way, that would preserve the current timer value. This would then give the proper value to the CC3D PPM routine, provided it was then divided by 8.
Previously, when a looptime of 8300 uS was chosen, the output would be unpredictable. Now the shots are fired only after every loop, not when the timer overflows.
This allows sonar to be used at the same time as parallel PWM for the receiver. If the RX_PARALLEL_PWM feature is enabled, then the sonar system uses motor ports 5 and 6, otherwise it uses receiver pins 7 and 8.
When changing profiles with the sticks, CleanFlight was beeping 0 times for profile
1, once for profile 2, and twice for profile 3. This wasn't intuitive, and was
different to how Baseflight beeps when changing profiles.
This change makes baseflight give the same number of beeps as the profile number
that you change into.
This enables the user to type "get variablename" in the CLI, which then shows the value of that variable (or a message saying "Variable 'variablename' not found").
This is easier for the user when they just want to see a single variable, instead of typing 'dump' and then having to parse a big long list of data. It is also more intuitive than typing 'set variablename', as this feels unsafe.