Do not arm above configurable threshold

[haslinghuis]

Fixes #13290 where the quad did not disarm on user command.

In general it is our responsibility that users can fly safely.

Not sure how we should approach this issue but we need to provide safety first. We should set a safe value where advanced users can override this setting. Limiting 4K loop on F7X2 might be an alternative solution.

We must ensure that disarmament works promptly at every opportunity. That is the mean reason for this proposal.

Further investigation will be required to find the root cause.

See also

• Add F7X2 to the list of limited targets #13292
• Limit STM32F411 to use 32 leds only. #13249
• Don't allow bidirectional DSHOT600 on an F411 #11222

[github-actions]

Do you want to test this code? You can flash it directly from Betaflight Configurator:

• Simply put #13294 (this pull request number) in the Select commit field of the Configurator firmware flasher tab (you need to Enable expert mode, Show release candidates and Development).

WARNING: It may be unstable. Use only for testing!

[blckmn]

AUTOMERGE: (FAIL)

• github identifies PR as mergeable -> FAIL
• assigned to a milestone -> PASS
• cooling off period lapsed -> FAIL
• commit count less or equal to three -> PASS
• Don't merge label NOT found -> PASS
• at least one RN: label found -> PASS
• Tested label found -> FAIL
• assigned to an approver -> PASS
• approver count at least three -> FAIL

[mituritsyn]

if it will be ever introduced - it should be configurable parameter

[ctzsnooze]

I'm not approving anything without a description where it now says "No description provided".
The description needs to make the case for the change, explain the reasons for it, and explain how to test it.
Agree that the value should be configurable.
I regularly fly F411's overclocked at 120Mhz at 8k4kthat are perfectly happy with CPU percentage 65% -75% without task over-run issues, including angle mode and GPS rescue..

[Justicefpv]

I have plenty of whoops running with over 50% CPU at 8k4k and no exceedingly late tasks. This PR appears to be hurried and has no supporting data.

[KarateBrot]

We should rather investigate why the issue appears even though the scheduler is not fully loaded. This just hides the issue at hand.

[haslinghuis]

Open for any solution. We need more info for further investigation.

Betaflight should not allow arming when there is some condition allow disarming to have a delay as safety precaution.

[KarateBrot]

We need to investigate what actually causes the issue and why the disarm is delayed. This seems to be a bug, maybe a racing condition of two tasks. Premature PRs which limit capable CPUs is not the answer. We should first check what the issue is and then open a PR to fix it.

[ctzsnooze]

I'll close this in 24 hours unless there is supporting data

[haslinghuis]

Closing now - as this should be fixed as stated before.

Not sure how tasks will help in this situation as the quad cannot be armed. Have asked for some blackbox logging in the issue.

Please continue investigation.

[ctzsnooze]

Tasks tells us whether the issue relates to CPU load or not, by showing how many tasks are running late over the interval since the lasts tasks run.

If there is no significant difference in task over-runs between 8k8k and 8k4k, then it is unlikely that a CPU load/tasks over-run would be the cause.

On the other hand, if some specific task is running long, it may give us a clue as to what the problem is.