This mod adds an arrow symbol showing the location of the up/down on the OSD. The arrow direction points in the direction of up or down.
Update osd_elements.c
Making the Up/Down OSD reference its own element
Removing the Up/Down reference from the artificial horizon and making a specific element for this feature. Activation via CLI (for now)
Updates to Up/Down refernce OSD element
Changed the up/down reference so that it is its own separarte element. The position is absolute on the screen and immutable by the user for consistent operation. Updated settings to include CLI option for turning the feature on and off.
Update cms_menu_osd.c
Updated file to add Up/Down reference selection from OSD menu
Updates to simplify/correct Up/Down OSD element
Simplified/corrected logic and removed arcsine function. OSD up/down reference is now positionable by the user in the configurator.
Tweaks and codestyle updates
Feedback from Michael Keller
Updates to Up/Down OSD indicator
Created a bounding box of +/- 25 degrees for indicator
Coding style correction
minor correction to match BF coding style
Enable Up/Down reference in OSD
This mod adds an arrow symbol showing the location of the up/down on the OSD. The arrow direction points in the direction of up or down.
Update osd_elements.c
Making the Up/Down OSD reference its own element
Removing the Up/Down reference from the artificial horizon and making a specific element for this feature. Activation via CLI (for now)
Updates to Up/Down refernce OSD element
Changed the up/down reference so that it is its own separarte element. The position is absolute on the screen and immutable by the user for consistent operation. Updated settings to include CLI option for turning the feature on and off.
Updates to simplify/correct Up/Down OSD element
Simplified/corrected logic and removed arcsine function. OSD up/down reference is now positionable by the user in the configurator.
Tweaks and codestyle updates
Feedback from Michael Keller
Enable Up/Down reference for artificial horizon in OSD
This mod adds an arrow symbol showing the location of the up/down on the OSD. The arrow direction points in the direction of up or down.
Update osd_elements.c
Making the Up/Down OSD reference its own element
Removing the Up/Down reference from the artificial horizon and making a specific element for this feature. Activation via CLI (for now)
Updates to Up/Down refernce OSD element
Changed the up/down reference so that it is its own separarte element. The position is absolute on the screen and immutable by the user for consistent operation. Updated settings to include CLI option for turning the feature on and off.
Updates to simplify/correct Up/Down OSD element
Simplified/corrected logic and removed arcsine function. OSD up/down reference is now positionable by the user in the configurator.
Tweaks and codestyle updates
Feedback from Michael Keller
Coding style correction
minor correction to match BF coding style
Enable Up/Down reference for artificial horizon in OSD
This mod adds an arrow symbol showing the location of the up/down on the OSD. The arrow direction points in the direction of up or down.
Update osd_elements.c
Making the Up/Down OSD reference its own element
Removing the Up/Down reference from the artificial horizon and making a specific element for this feature. Activation via CLI (for now)
Updates to Up/Down refernce OSD element
Changed the up/down reference so that it is its own separarte element. The position is absolute on the screen and immutable by the user for consistent operation. Updated settings to include CLI option for turning the feature on and off.
Updates to simplify/correct Up/Down OSD element
Simplified/corrected logic and removed arcsine function. OSD up/down reference is now positionable by the user in the configurator.
Tweaks and codestyle updates
Feedback from Michael Keller
Corrections to unit tests
Corrected unit tests link failing due to not being able to find rMat[3][3]
Extends the OSD element position setting to include a 2 bit selector for alternate representations of the element. So up to 4 variants of an element can be supported. Meant to be used instead of adding new elements when the request is a mutually exclusive variant of an existing element. If there are no variants of an element then the logic falls back to "type 1" (`OSD_ELEMENT_TYPE_1`) which is the only representation of the element.
As an example, in this PR the "Battery usage" element has been extended to 4 types:
1. The original capacity remaining graphical bar (shrinks as battery is used) - this is the default.
2. Capacity used graphical bar (grows as battery is used).
3. Remaining capacity numerical percentage (goes down as battery is used).
4. Capacity used numerical percentage (goes up as battery is used).
When extending an element it is not necessary to support all 4 types and the element rendering code should default to the original type 1 version for unsupported types.
Will require Configurator support. Since the 2 high bits of the `uint16` were previously unused the setting will default to the "type 1" original variant in all cases where an incompatible Configurator is used.
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.
