Report true average task execution time in tasks report

[SteveCEvans]

Fixes #11445

With ELRS connected on a BETAFPVF4SX1280 the tasks command now reports the correct average task loads, but it is noticeable that the max loads are much higher. This is due to tasks being delayed by the peaks of interrupt activity caused by ELRS and is perfectly OK.

The CPU load is a true average whereas the figure being presented as a task average relates (in master) not to the average time the tasks are taking, but the scheduler's estimate of how much time allow for the tasks to run which is more conservative and higher.

# tasks
Task list             rate/hz  max/us  avg/us maxload avgload  total/ms   late    run reqd/us
00 - (         SYSTEM)     10       1       1    0.0%    0.0%         0      0     45      22
01 - (         SYSTEM)    774      64       0    4.9%    0.0%        61     15   3828      29
02 - (           GYRO)   7994      98       4   78.3%    3.5%      3212      0  35630       0
03 - (         FILTER)   3997     162      47   64.7%   18.7%     19853      0  17815       0
04 - (            PID)   3997     201      96   80.3%   38.4%     39281      0  17815       0
05 - (            ACC)    777      31       3    2.4%    0.3%       339     14   3634      19
06 - (       ATTITUDE)     97      48      10    0.4%    0.1%       111      1    436      47
07 - (             RX)    250      50      22    1.2%    0.5%      1824     76   3345      17
08 - (         SERIAL)     98    3746       2   36.7%    0.0%      1031      0    436      29
09 - (       DISPATCH)    820      65       0    5.3%    0.0%        80     19   3843      22
10 - (BATTERY_VOLTAGE)     50       4       2    0.0%    0.0%        11      0    222      32
11 - (BATTERY_CURRENT)     50       1       0    0.0%    0.0%         5      0    222      24
12 - ( BATTERY_ALERTS)      5       2       1    0.0%    0.0%         0      0     22      46
13 - (         BEEPER)     98       7       1    0.0%    0.0%        15      1    436      11
16 - (      TELEMETRY)    242      21       0    0.5%    0.0%        27      2   1076      19
17 - (       LEDSTRIP)     97      14       3    0.1%    0.0%        38      0    434      35
18 - (            OSD)     11      52      19    0.0%    0.0%       620      8   1306      33
20 - (            CMS)     20       7       1    0.0%    0.0%         3      0     89      26
21 - (        VTXCTRL)      5       1       1    0.0%    0.0%         0      0     22      19
22 - (        CAMCTRL)      5       1       0    0.0%    0.0%         0      0     22       2
24 - (    ADCINTERNAL)      1       3       2    0.0%    0.0%         0      0      4      22
RX Check Function                  80       3                       366
Total (excluding SERIAL)                                61.5%

[SteveCEvans]

betaflight_4.3.0_BETAFPVF4SX1280_5bbe500.hex.zip
betaflight_4.3.0_CRAZYBEEF4SX1280_5bbe500.hex.zip

[bike797]

I tried PR betaflight_4.3.0_CRAZYBEEF4SX1280_5bbe500.hex.zip

Average tasks seems to normal between befor binding rx and after binding rx.

• connected
  

• not connected
  

but osd delay when rx not connected.

• power on FC and then radio on
  https://youtu.be/Ek4_3xHeD1A

• binding rx and then radio off
  https://youtu.be/YSS4Xafewwk

[SteveCEvans]

@bike797 Thank you for that testing. You revealed an issue when, when no signal was being received the RX task was performing processing every time the check routine was called (so about 30000 times per second!) and this was making the CPU rather too busy to properly handle the OSD. I've revised this to limit such processing to once every 10ms which is plenty fast enough and still ensures that the RC channels are promptly updated in the event of a failsafe.

betaflight_4.3.0_CRAZYBEEF4SX1280_d118e70.hex.zip
betaflight_4.3.0_BETAFPVF4SX1280_d118e70.hex.zip

[SantiCO19]

15 packs with BETAFPVF4SX1280 5bbe500 on a DarwinFPV, Darwin ELRS2.0 F411 15A Bluejay AIO, and I noticed no issues with OSD, no failsafes. Im flying 1S 3" and frankly, it's absolutely ripping. This board seems more robust than BetaFPVSX1280, and CrazybeeSX1280 (of which I have 1, and 6 units respectively,) somehow consistently showing 10-15% less cpu usage with the same config. Anyway I'll test the latest image d118e70 now. I did rip 4-5 packs on a Crazybeesx1280 5bbe500 and the first pack I failsafed about 25m out, and link never recovered. No problem on the next few packs. Also, the link is not dropping out when I cal or trim the acc with stick commands, which is great! I'll just keep ripping packs unless someone would like to see specific type of testing. I do have video of the above mentioned fs, but seems that may not be relevant now. Oh, also, I'm flying 500hz, 2.67k gyro loop, dshot300, rpmfilter, on everything, and my 1s 3" has a wicked tune, fast, responsive, almost no propwash, 4 min hard ripping on 660mah, seriously never seen 1S like this. You should hear the motors! Anyway, things have come a really long way from a few weeks ago. You guys really blow my mind. Thanks so much for the hard work.

[SteveCEvans]

@SantiCO19 thanks for testing. Sounds like you’re enjoying it! Please do test the latest image and feedback if the OSD is updating correctly with the radio link established or not. Perhaps set a timer with tenths enabled to help confirm this.

[SteveCEvans]

Latest push inhibits the stats display when a disarm occurs due to a failsafe. This allows the RXLOSS and FAILSAFE arming warning flags to be displayed.

betaflight_4.3.0_BETAFPVF4SX1280_667847d.hex.zip
betaflight_4.3.0_CRAZYBEEF4SX1280_667847d.hex.zip

[SteveCEvans]

The fixes related to failsafe CPU load (and thus the impact on OSD performance) and honouring of timing are now moved to #11459.

[CMartin249]

Flew a dozen packs using betaflight_4.3.0_CRAZYBEEF4SX1280_667847d.hex today. Flew great. Keep up the great work.

[hydra]

Some description of what the actual issue was would help understanding here. It's not immediately obvious by looking at the change-set.

[SteveCEvans]

@hydra Description updated

[hydra]

@SteveCEvans ok, that is much clearer now, thank you!

[hydra]

The CPU load is a true average whereas the figure being presented as a task average relates (in master) not to the average time the tasks are taking, but the scheduler's estimate of how much time allow for the tasks to run which is more conservative and higher.

Thinking about it, can we now change the output of tasks so that it's clearer which are estimates, and which are not.

Perhaps one or more of:

• re-ordering the columns to show ACTUAL values on the left, and ESTIMATED values on the right.
• adding a divider character (-) between columns that are ACTUAL and ESTIMATED.
• adding a pre-fix to estimations.
• using brackets [] or () around ESTIMATED values.

Currently people will make comparisons between old values and new values and will not be aware that they are now reported differently, changing the tasks output format, rather than the just the values, would help clarify this change and make direct comparisons obvious.

[hydra]

@haslinghuis Since this has been merged without waiting for further comments / suggestions after the description was updated I have raised a bug report, #11466 so my suggestions above can be tracked and actioned accordingly.