The logic that uses the sample table size is:
```
```
So a setting of 1 would result in div-by-zero later in the code. A setting of 0 would result in division by -1 causing altitude measurements to be inverted. This could lead to a safety issue with GPS Rescue and a flyaway as it attemts to climb to altitude.
The default value is 21 and fortunately this was a setting that users were unlikely to have changed.
Function SD_Init() is called as follows:
./main/msc/usbd_storage_sdio.c: if (SD_Init() != 0) {
./main/drivers/sdcard_sdio_baremetal.c: if (SD_Init() != 0) {
./main/drivers/sdcard_sdio_baremetal.c: if (SD_Init() != 0) {
and checks whether return value is != 0, that is != SD_OK.
Previous implementation is working, however, cannot handle proper
SD_Error_t handling. In addition the code was refactored and simplified.
Previous logic was always registering CRSL and SRXL as CMS displayPort devices regardless of whether the user was actually using that type of radio and telemetry.
The problem this caused is that if the user accidentally (or intentionally) used the CMS invoke stick command while already in the CMS on the MAX7456 the logic interprets this to mean "switch to the next registered displayPort device". So in this case the CMS would appear to exit based on what the user could see. But in reality it's still active and simply switched to the next (nonexistent) device. The user is then stuck and can't arm because the `CMS` arming disabled will be active and they have no way to interact with the CMS. They can technically blindly do the CMS stick command 2 more times to get back to the MAX7456, but how would they know that?
So this change only registers the CRSF and SRXL displayPorts when the user has selected those receiver types and enabled telemetry.
This is actually only a partial solution since it prevents registering the devices when they're impossible to work, but doesn't do anything for the actual CRSF or SRXL user that may be using equipment not capable of displaying the CMS. So it's still possible for them to get stuck in this situation. But I don't see any reasonable way to prevent this.
Perhaps it's time to rethink this "Switch to next CMS device" logic? It's something that nobody really knows about and seems to be more trouble than value. Maybe there are some edge cases where it's useful like using the OLED dashboard along with a MAX7456, but that's a rare use-case. Or possibly we need some explicit control where the user has to enable the particular displayPort device to be eligible for CMS?
Improve the logic to be table-based and add validation of the rc_rates and expo values. The previous logic only validated the super-rates and the rc_rates can also be out-of-range when changing rates types. The expo values are also checked but currently all the rates types have the same constraints so there's no possibility currently of them being out of range. But this will allow for possible new rates type that have different constraints.
Since version 4.0.0 CLI variables:
* acc_cut_hz,
* accxy_deadband,
* accz_deadband,
* acc_unarmedcal
are removed from settings.c and thus can be also removed
from the CLI documentation page.
Fixes logic errors in #9574
For RACEFLIGHT rates the applicable `case` was missing so the logic defaulted to the BETAFLIGHT rates logic which incorrectly limited the maximum rate value to 100. RACEFLIGHT values range to 255.
For KISS rates the limit was set to 100 but the Configurator constrains to 99.
