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.
Significantly reduces the time the OSD task spends drawing elements that are completely or mostly static. The larger the element the more time savings are realized. Currently implemented support for:
- Crosshairs
- Artificial Horizon Sidebars
- Craft name
- Display name
- Stick overlay
Since the static portions are only rendered once, the static elements add no processing time to the OSD task. As an example, enabling the above elements prior to these changes results in a total rendering time of 47us. After the enhancements they take only 6us (basically the rendering phase minimum overhead). So effectively 41us are removed from the OSD task.
Opens the possibility to add large mostly static elements with no additional overhead. An example would be a camera framing element that might draw a "box" around most of the screen. Previously this would add significant processing overhead to the OSD task, but now it will have no impact.
How it works:
1. Current Meter Source on FC is set to MSP/OSD Slave by user.
2. On reboot FC sends MSP_ANALOG to OSD Slave.
3. OSD Slave listens for incoming MSP as usual.
4. OSD responds to MSP as usual.
6. The FC recevies the data from the OSD Slave and updates the MSP
Current Meter.
* avoiding the use of an unncessesary buffer and memcopy
* the `pushBuf` was a fixed size
* the size didn't correlate to the size of the buffer being passed in.
* avoids repeating the memcpy for each port being used for MSP.
* reduces ram usage.
