If the gyro supports it, the temperature is read as part of the telemetry task to be supplied in several protocols. There's absolutely no reason to read the gyro temperature at 250hz for this purpose and the temperature shouldn't be changing rapidly anyway. Revise to read a new temperature every 3 seconds which should be more than sufficient.
Has no impact at the moment as no actively used gyro supports temperature reads but may be used in the future.
Adds a dynamically constructed menu that will appear before the main menu when the user enters CMS if there are any outstanding setup items to complete. Currently only includes entry to calibrate the ACC if required, but provides a framework for other setup reminders as needed. The user can choose to exit this menu without remedying the problems, but the menu will reappear when they next enter CMS. If there are no required setup items then the menu will be skipped and the user will go straight to the main menu.
This is a workaround for a validation bug in configurator 10.6 where the user can enter an invalid value, immediately click "Save" and that value will be stored before the value is range-checked. Added validation to the MSP message processing to constrain the range to prevent a dangerous result.
This is a revision and partial revert of #9545.
While the previous version improved the behavior for non-8K gyros, it had some unfortunate side effects on the defaults and how they affected the output of the `diff`. Basically the problem is that in most cases the default value will end up getting adjusted during the first boot to work with the default low-speed motor protocol ONESHOT125. So if an appropriate default was originally set (like in the other PR) it shows up changed in the `diff` with default settings. The only workaround is to set the default to be the expected "corrected" value when ONESHOT125 is taken into account. This unfortunately reverts to the not so great behavior for gyros that have a sample rate < 8K, but that's unavoidable.
The inappropriate logic based on the `USE_` for various gyros being defined is still removed. This makes no sense in the unified targets context and was trying to determine if there's an SPI-connected gyro so that means it's going to run at 8K, but if not then it's going to be I2C and 2K, etc. This no longer makes sense.
Bruce Luckcuck
Michael Keller
jflyper
Nicola De Pasquale
jflyper
TheIsotopes