Set next state expected time on per element basis #13706
Conversation
|
Do you want to test this code? You can flash it directly from Betaflight Configurator:
WARNING: It may be unstable. Use only for testing! |
|
I can confirm that the OSD is smoother than before this PR. Before this PR, with my config, the OSD was unusable (one refresh each 4 seconds). Now it refreshes without problem. |
src/main/osd/osd.c
Outdated
| uint8_t osdCurrentElement = osdGetActiveElement(); | ||
|
|
||
| timeUs_t startElementTime = micros(); | ||
| uint8_t osdNextElement = osdGetActiveElement(); |
There was a problem hiding this comment.
'next' od slightly confusing, it is mostly used for element that is already rendered. maybe just 'osdElement'?
* Set next state expected time on per element basis * Rename osdNextElement to be clearer
…#13706) (betaflight#13713) Set next state expected time on per element basis (betaflight#13706) * Set next state expected time on per element basis * Rename osdNextElement to be clearer Co-authored-by: Steve Evans <SteveCEvans@users.noreply.github.com>
|
I flew this PR on 4.6 yesterday (about 40 packs). The First 10 were with 8k Loop, the rest I switched back to 4k. On 8k the refresh is definitely smoother than without this PR, as sometimes the whole OSD would remain at its last update for many seconds. But it still had a worrying tendency to miss the battery/cell voltage from the screen when it begins flashing for low battery. Sometimes the word "armed" is still on the screen for a few seconds after takeoff as well. |
|
To add to the above. I have black box currently set to always logging (for some other testing) under the assumption that when full, the logging process would stop. Is my assumption wrong on that? Am I still choking up the already limited resources with blackbox when the memory is full? |
May fix: #13656
The ability to schedule the OSD task is based on knowledge of the likely time for each state to execute.
This is OK typically, but when in the
OSD_STATE_UPDATE_ELEMENTSstate there is some variation in the required time to render elements. This PR therefore sets the expected next state duration for this state based on the element to be rendered. It also removes any attempt to render elements in groups. As a result, rather than always having to find a time slot big enough for the most complex element, smaller time slots can be utilised.Note that previously the OSD state machine would render as many elements as possible in a target 20us, however on a heavily loaded F7 this has proven too great, so rather than attempt to render many items at once this PR instead renders them one at a time, which makes the OSD much more schedulable, at the cost of some efficiency in scheduling overhead.
Tested on
ZEEZF7V3andMATEKF405TEwith Walksnail.I'd be grateful if somebody could test on analog as my video capture card is playing up.