Logic error would cause the MSP data to be written to every port that had MSP enabled if the selected port was -1 (`SERIAL_PORT_NONE`). Since the (correct) default for `displayport_msp_serial` is -1, this was causing MSP displayPort traffic to be "spammed" to every UART with MSP enabled. Since MSP displayPort is the fallback when no other OSD device is detected (in "AUTO" mode) this could cause large amounts of unnecessary MSP traffic - for example in cases with flight controllers with no MAX7456 and using the DJI air unit connected via MSP. This "might" be related to earlier reports of the DJI OSD no longer working with softserial (even though that's not really a recommended configuration) because of the extra serial traffic.
This was not so much a "bug" but instead a shortsighted design. The only other thing using `mspSerialPush()` is the MSP-based current sensor. In that case the logic does in fact want to "spam" all the MSP ports with the current sensor request. So it was using the `SERIAL_PORT_NONE` identifier to mean "every port". But this conflicts with MSP displayPort logic which really needs a "no ports" identifier. So this PR adds a `SERIAL_PORT_ALL` identifier to explicitly differentiat "all" from "none" and this is used for the current sensor.
Was incorrectly defaulting to 0 which is UART1. Should be -1 (`SERIAL_PORT_NONE`).
Add validation to ensure the selected UART exists, has MSP enabled, and is appropriate (not VCP).
Previously the display rows was hardcoded to 13 (NTSC). Now it will use 16 if the user has explicitly selected PAL. This allows the display to fully use the screen - particularly when in the CMS menus. Since there is no device to "AUTO" detect, this will still default to safer value of 13 rows as NTSC.
Eventually we may want to extend MSP displayPort to add an auto-detect capability. But since the protocol is a one-way "push" from the firmware to the device that's somewhat difficult. Will probably need a MSP message that the displayPort device can use to "register" its capabilities.
Often the user doesn't realize that there are more menu items then displayed and the only way to tell was to try and move the selection to the bottom to see if another page appears.
This PR adds page up/down indicators if there are more menu items than those visible on the current display.
Uses the OSD arrow symbols when possible (for OSD supporting devices), otherwise the `^` (carat) and `V` are used for text-only represenatations.
To determine if the device was capable of displaying symbols the `displayPort` structure has a new `deviceType` set when it is initialized. There have been other times when knowing the type of device would have been useful so that's now supported. Then this is abstracted by a new `displaySupportsOsdSymbols()` function. Devices that support OSD are assumed to support the OSD symbols as the OSD element drawing code always uses them. For devices that don't support OSD function we have to presume the sybols aren't available.
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.
