rtos - RTOS 中滴答率过高的症状/影响是什么？

Question

如果有人可以解释 RTOS 中的滴答率过高的影响，或者指导我找到清楚解释它的资源，我将不胜感激？

问题的上下文...
我们使用 ucos-ii 运行，滴答率为 10000 (OS_TICKS_PER_SEC=10000)。这超出了 10 到 100 的推荐设置。
在调查另一个问题时，我注意到此设置并将其标记为异常。 ucos 手册(我可以看到)中没有详细解释为什么这是推荐范围。
我们有 8 个任务(加上中断)以不同的优先级运行，所以我认为更高的滴答率意味着我们可以更快地切换最高优先级的任务。在我们的例子中，我们将确保用户界面在一些不太重要的维护任务上得到解决。

从我可以看到的共识是建议不要将任何 RTOS 中的滴答率设置为“过高”，因为“开销”。建议使用具有较低滴答率的中断似乎很常见。很公平，但是，我不清楚随着滴答率的增加有哪些可检测的缺点。
例如，freeRTOS 文档指出“RTOS 演示应用程序都使用 1000Hz 的滴答率。这用于测试 RTOS 内核并且高于通常所需的频率。”它确实继续说相同优先级的任务会经常切换 - 这将导致内核占用大量处理时间，这将是负面的。我认为最终通过增加滴答率来加速的意图最终会变成负数，因为内核消耗了大部分处理器时间。
也许这是我唯一需要的答案。但是，在我们的案例中，所有任务都有不同的优先级，所以我认为这不(作为？)适用。

最终，我试图确定我们的软件是否以过高的滴答率运行，或者它与某个阈值有多接近。我认为开发过程中的预期好处是稳定用户界面。
我希望答案不完全基于经验!

Answer 1

调度程序在每个滴答上运行，因此如果例如调度程序需要 10 微秒来运行并且每 10 毫秒发生一次滴答，则在没有任何其他调度事件的情况下，调度开销为 0.1%，但是如果每 100 毫秒发生一次滴答，则开销是 10%。在极端情况下，滴答率可能会如此之高，以至于您始终处于调度程序中而从未实际运行任务!

实际的调度开销当然取决于处理器速度。更快的处理器将能够处理更快的滴答，但运行比应用程序需要的更快的滴答没有任何好处，因为它会占用可用于有用工作的 CPU 时间。 10 到 100 的建议可能与适合大多数系统的值有关；目标是仅在必要时尽可能快。

通过在调度程序中花费比必要时间更多的时间，对于在计时器或延迟以外的事件上调度的任务可能会发生更大的调度延迟和抖动。例如，如果发生中断并且处理程序触发任务；当调度程序已经在处理滴答时发生中断时，该任务可能会延迟。

更快的滴答率不会使任何东西运行得更快，它只会增加可能使用的计时器和延迟的分辨率，但相反它会减少范围。 100us 滴答率的 16 位定时器将在 6.55 秒后翻转，而 10ms 滴答将在 10 分 55 秒后翻转。如果计时器是 32 位的，这可能不是什么问题。

你需要问问自己你需要从计时器和延迟中获得什么样的分辨率(以及可能的范围)；如果 UI 是“最重要”的任务，则似乎不太可能需要 100us 分辨率(尽管“重要性”是实时系统中不适当的优先级分配方法 - 因此它已经敲响了警钟!)。

如果您只需要为一项任务提供更高的分辨率 - 例如，以 Niquist 速率对 ADC 进行信号采样，那么您最好为此使用独立定时器？如果设置得那么快以获得对轮询事件的及时响应，那么在这种情况下，您最好安排此类事件生成中断。

I would assume the higher tick rate means we are switching in the highest priority task faster.

不是更快，可能更频繁。滴答率不影响上下文切换时间，等待计时器或延迟的任务将在计时器/延迟到期时运行。当滴答发生时，计时器和延迟递减，并且在超时时发生上下文切换。通过更快的滴答，您只需增加调度程序运行的次数并决定什么都不做!通常，您会将计时器和延迟设置为一个将滴答率考虑在内的值，以便更改滴答率不会影响现有任务的计时。