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.
Make as many variables as possible private.
Re-work settings application into state machine.
Remove legacy interfaces.
Update OSD interface following implementation rework.
Review updates.
The USE_DSHOT_TELEMETRY_STATS define was is gating a closing bracket '}',
so that the scopes are breaking in case telemetry stats are not enabled.
This commit fixes this behaviour by moving the closing bracket out of the
ifdef.
Signed-off-by: Mimoja <git@mimoja.de>
Previously if the first "arming" was in crash-flip mode then the various features that rely on "first arming" logic would be defeated. While arming in crash-flip mode is technically "arming", it shouldn't disable features that rely on the first "real" arming. For example, vtx low-power disarm, GPS fix arming disabled, `BATT < FULL` warning, etc.
While craft is upside down the GPS receiver may not be able to maintain a fix. As a result the `ARMING_DISABLED_GPS` reason could prevent arming in crash-flip mode preventing the user from flipping back over.
