I have tried the latest released betaflight firmware with my 3D helicopter to see the main motor spins and controlled by M1 motor, the S1-S3 servos move and control the cyclic swashplate, and S4 servo controls the rudder.
value when DMA was used. For example, if one byte was waiting, the function
returned one less than the size of the buffer.
The reason the bug didn't cause serious problems is that almost all
calls to this function check only whether the returned value is zero or not.
(The only exceptions I found were in "src/main/telemetry/hott.c". Perhaps
that code was tested on a target that did not use DMA.) The case of zero
bytes waiting was the only case in which the correct result was returned.
The detection logic in the MPU6000 and ICM20689 drivers had unnecessary "retry" logic that would try to read the `WHOAMI` register 5 times for MPU6000 and 20(!) times for ICM20689 - with a 150ms delay for each iteration. So the problem is that all the enabled drivers need to be probed in order so on a board that had a LSM6DSO for example (or any sensor further down the list) it would introduce about 4 seconds of initialization delay (dual gyro board would take 8 seconds!). Revised logic completes in about 0.4 seconds in the worst case.
After removing the unnecessary retry/repeat logic for the MPU6000 an initialization problem became visible. The driver was not following the datasheet guidelines and clearing the signal path after resetting the device. This lead to detection issues on warm reboots that were accidentally masked by the excessive delays with the retry logic.
The improvement in boot speed depends on the device's position in the list. So any device with a MPU6000 won't see any difference. All other devices will boot about 1 second faster (like ICM20602, ICM20689). Devices after the ICM20689 (like BMI160/270, LSM6DSO) will boot about 4 seconds faster.
If the RSSI channel PWM values were outside the expected 1000-2000 range, the `scaleRange()` function does not work properly. In particular if the value was below the minimum the result would be negative. Then this would cause an underflow when applied as a `uint16` to `setRssiDirect()`. This fix constrains the input range from 1000 to 2000.
Fixed some code formatting
+fixReorderingArray() for EEPROM load/save and renamings
fix brace new line
moving MOTOR_OUTPUT_REORDERING to MSP2 betaflight specific
validateAndfixConfig now resets reordering motor array to default in case it is invalid
GPS Rescue flight control logic only knows how to fly multirotors and engaging GPS Rescue on a fixed-wing craft would result in an immediate loss of control and crash. For example, when GPS Rescue is engaged it attempts to yaw to the home direction heading and this won't work on fixed wing (particularly the flying wing mixer with no rudder). Next it tries to attain the target altitude exclusively with throttle control - not how altitude is controlled with a fix-wing aircraft.
Also the GPS Rescue no-fix arming prevention logic shouldn't be applied.
The MSP override mode allows for use of MSP togehter with
another RX feature like SBUS. When enabling the MSP override
mode all channels from the `msp_override_channels` bitmask
will be overwritten by data comming from MSP instead of the
main RX.
