Ignore time taken to update EEPROM as otherwise stick commands can ups…

[SteveCEvans]

Fixes: #11226

Issue was caused by write of config to FLASH (THR_LO + YAW_LO + PIT_LO + ROL_HI) which took ~20ms and upset the RX task scheduling. tasks command run after this showed the issue.

# tasks
Task list             rate/hz  max/us  avg/us maxload avgload  total/ms   late    run reqd/us
00 - (         SYSTEM)      8       5       4    0.0%    0.0%         0      1     49       4
01 - (         SYSTEM)    497      11       6    0.5%    0.2%        90      2   4888       6
02 - (           GYRO)   7491      14       5   10.4%    3.7%       571      0  48385       0
03 - (         FILTER)   7491      25      22   18.7%   16.4%      2838      0  48385       0
04 - (            PID)   7491      51      43   38.2%   32.2%      8082      0  48385       0
05 - (            ACC)    497      13       9    0.6%    0.4%       105      4   4887       9
06 - (       ATTITUDE)     53      18      16    0.0%    0.0%        42      0    490      16
07 - (             RX)     41   19642   19640   80.5%   80.5%       296      9   2502   19640
...

[JBKingdon]

Fantastic! Many thanks.

[JBKingdon]

I think the issue ref has a typo, correct ref is #11226

[etracer65]

A design fundamental of the previous scheduler is that a task could never be "starved" of it's execution and locked out. That seems to no longer be the case as multiple fixes have had to address this. This is dangerous - particularly when it can affect critical tasks like RX and impact disarming, failsafes, etc.

[SteveCEvans]

The previous scheduler would starve tasks with a priority of idle. The new scheduler does not. The old scheduler would allow ill behaved tasks such as RX and OSD to way overrun and delay time critical tasks. Such tasks are now deterministic and the new scheduler does not allow such errant behaviour except when a task has “aged” in which case it will ensure that the task is called albeit at a reduced rate. This provides the necessary safety net whilst greatly improving scheduling performance.

[SunjunKim]

Unfortunately, this PR doesn't resolve #11226 issue yet.

[SteveCEvans]

@SunjunKim Updated as per #11226 (comment). Please retest.

[SunjunKim]

@SunjunKim Updated as per #11226 (comment). Please retest.

Could you post a compiled image for STM32F7X2 target again, please? I have no IDE for compiling a BF firmware.

[KarateBrot]

@SunjunKim You don't have to compile it. It gets compiled automatically by Azure.

https://dev.azure.com/Betaflight/Betaflight%20Nightlies/_build/results?buildId=5348&view=artifacts&pathAsName=false&type=publishedArtifacts

[SunjunKim]

@SunjunKim You don't have to compile it. It gets compiled automatically by Azure.

https://dev.azure.com/Betaflight/Betaflight%20Nightlies/_build/results?buildId=5348&view=artifacts&pathAsName=false&type=publishedArtifacts

Oh I get it. Thanks

[SteveCEvans]

Also included in mashup at #11198 (comment)

[haslinghuis]

Merged with #11198

[haslinghuis]

Merged with #11198