Resets to defaults if not.
If the min/max were set to the same value then this will lead to div-by-zero errors.
If the min was set to a greater value then this would lead to negative values and underflow in the battery remaining calculations. This would affect the OSD, dashboard, various telemetries, LED strip, and the Configurator.
Improves menu readability by changing the background from a transparent display of the camera image to a static opaque gray background.
The behavior is controlled with the `osd_menu_background` parameter which defaults to `TRANSPARENT` to preserve the previous behavior. Other opaque options are available:
```
osd_menu_background = TRANSPARENT
Allowed values: TRANSPARENT, BLACK, GRAY, LIGHT_GRAY
```
The background setting is available in the CMS OSD menu and the user can cycle through the various options with the display updating in real-time.
Currently only the onboard MAX7456-based OSD is supported, but the implementation adds `displayPort` support so it can easily be extended to other OSD devices if those manufacturers want to add support. Also can be extended to other background types (like colors, varying transparency, etc.) for future device support.
Makes use of the built-in MAX7456 feature to display all transparent pixels as "gray". The MAX7456 display area seems to be a few scan lines smaller than the actual camera video image so it's normal for some of the camera image to "leak" at the top/bottom of the display. The OSD display area can be adjusted up/down using the `vcd_v_offset` setting if desired.
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.
Michael Keller
Bruce Luckcuck
Thomas Stibor
ctzsnooze
jflyper
LinJieqiang
ligenxxxx
Ivan Efimov
phobos-