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.
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.
Changes the blink logic to be OSD task loop based instead of time based.
The previous logic used a 200ms time interval for the blinking which didn't align well with the default 12hz OSD update frequency resulting in the logic periodically missing intervals resulting in an inconsistent blinking.
As the revised logic is now tied to the OSD task iterations the blinking will be consistent. However due to the timing the blink will be slightly faster - 167ms (6hz) vs. the previous 200ms (5hz) intervals. Technically the blinking was 6hz before but stuttered every 5th blink.
Since the OSD task rate can be changed from the default 60hz, the logic will fall back to the time-based implementation for non-default task rates.
I did a test and added a lot of osd elements (basically all osd elements I can add, excluding GPS and ESC elements), and even some have overlapped. In this case, there is no problem at all. TxBufferSize is set to 1024. It is sufficient for normal conditions.
