Allow for quicker updates of OSD element data

[MrD-RC]

This allows X elements to be updated per OSD cycle. From 1 element (current behaviour) to 15 elements. This should allow for plenty of data update speed without causing unnecessary delays or overheads. This defaults to 5, which should be a good value for most OSDs. The OSD is updated at 250Hz, on a low priority, by the task scheduler. The elements are updated at 1/4 this frequency (62.5Hz).

Update rates based on current update method

Number of OSD elements	~Update rate
1	62.5Hz
5	12.5Hz
10	6.3Hz
15	4.2Hz
20	3.1Hz
25	2.5Hz
30	2.1Hz

Update rates based on the new default of 5 elements per cycle

Number of OSD elements	~Update rate
1 - 5	62.5Hz
6 - 10	31.3Hz
11 - 15	20.8Hz
16 - 20	15.6Hz
21 - 25	12.5Hz
26 - 30	10.4Hz

So even on the default setting 5, having 26-30 elements. They would update 10 times per second. Fast enough for any OSD element.

• It maintains the protections for end of loop and no elements enabled
• Will exit automatically if there are less elements to draw than set to be drawn per cycle.
• A check has been added to see if the AHI is enabled before drawing it

Alternative option to #11206
Fixes #9907

[github-actions]

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

---

This is an automated suggestion to help route contributions to the appropriate branch.

[sensei-hacker]

Awesome. Have you run "tasks" on this?

[MrD-RC]

No yet. I've just written it on my laptop. I've published the branch and this draft PR to move to my desktop and test this out on the FC shortly.

[hntirgeam]

The batch based approach is slower in terms of CPU time compared to the Hz-based approach discussed here: #11206 (comment)

[sensei-hacker]

The batch based approach is slower in terms of CPU time compared to the Hz-based approach discussed here: #11206 (comment)

True, but that's measuring something that does not matter, directly. It's measuring the amount of time the CPU is sitting idle, doing nothing. Sitting idle is not advantageous. They key is to finish on time, every time, to avoid blocking the PID task that needs to run every 0.5ms.

Better to say "I never blocked the PID task" than to say "I blocked the PID loop from running, then did nothing for a while".

@hntirgeam

[MrD-RC]

The batch based approach is slower in terms of CPU time compared to the Hz-based approach discussed here: #11206 (comment)

The small different in time for the batch process is spread over multiple loops. So doesn't cause the block to other processes that happen when all the elements are drawn in the Hz method. Also the Hz method is currently missing the call to osdIncElementIndex, which is needed. This will add more processing time to the Hz method and be a more realistic comparison.