如果有人能够解释RTOS中刻度率过高的影响，或者将我引导到可以清楚解释它的资源，我将不胜感激？
问题的背景...... 我们使用ucos-ii运行，刻度率为10000（OS_TICKS_PER_SEC = 10000）。这超出了建议的10到100的设置。 在调查另一个问题时，我注意到了这个设置并将其标记为异常。 ucos手册中没有详细说明（我可以看到）解释为什么这是推荐的范围。 我们有8个任务（加上中断）运行不同的优先级，所以我认为更高的滴答率意味着我们更快地切换最高优先级的任务。在我们的例子中，我们将确保通过一些不太重要的维护任务来解决用户界面问题。
从我所看到的共识是建议不要因任何“开销”而将任何RTOS中的滴答率设置为“太高”。建议使用较低滴答率的中断似乎很常见。虽然很公平，但我不清楚滴答率增加时可检测到的缺点是什么。 例如，freeRTOS文档指出“RTOS演示应用程序都使用1000Hz的滴答速率。这用于测试RTOS内核，并且高于通常所需的速度。”它继续说具有相同优先级的任务将经常切换 - 这将导致内核占用大量处理时间，这将是负面的。我认为最终这种通过提高滴答速率而加速的意图会因为内核占用大部分处理器时间而变为负值。 也许这是我需要的唯一答案。但是在我们的例子中，所有任务都有不同的优先级，因此我认为这不适用（如？）。
最终，我正在尝试确定我们的软件是否以过高的滴答速率运行，或者它与某个阈值的接近程度。我认为开发过程中的预期好处是稳定用户界面。 我希望答案不是完全凭经验来的！
答案 0 :(得分：7)
调度程序在每个tick上运行，因此，例如，如果调度程序运行10微秒并且每10ms发生一次滴答，则在没有任何其他调度事件的情况下，调度开销为0.1％，否则每100us发生一次滴答，开销是10％。在极端情况下，滴答率可能非常高，以至于您始终在调度程序中并且从不实际执行任务！
实际的调度开销当然取决于处理器速度。更快的处理器将能够应对更快的滴答，但运行比应用程序需要更快的滴答没有任何好处，因为它占用可用于有用工作的CPU时间。 10到100的建议可能与大多数系统的足够有关;目标是尽可能快。
通过在调度程序中花费的时间超过必要的时间，对于在计时器或延迟之外的事件上调度的任务，可能会发生更大的调度延迟和抖动。例如，如果发生中断并且处理程序触发任务;当调度程序已在处理滴答时发生中断时，该任务可能会延迟。
更快的刻度速率不会使任何事情运行得更快，它只会增加定时器的分辨率和可能使用的延迟，但相反它会缩小范围。一个16位定时器，100us滴答速率将在6.55秒后翻转，而10ms滴答将在10分55秒后翻转。如果定时器是32位，这可能不是一个问题。
你需要问问自己，从计时器和延迟中你需要的分辨率（以及可能的范围）;如果UI是最重要的＆＃34;那么你似乎不太可能需要100us的分辨率。任务（虽然＆＃34;重要性＆＃34;在实时系统中是一种不恰当的优先级分配方法 - 所以它已经敲响警钟！）。
如果您只需要一项任务就能获得更高的分辨率 - 例如以Niquist速率对ADC进行信号采样，那么您可能会更好地使用独立定时器吗？如果快速设置以获得对轮询事件的及时响应，那么在这种情况下，您最好安排此类事件生成中断。
我认为更高的滴答率意味着我们会更快地切换最高优先级的任务。
不快，可能更频繁。滴答速率不会影响上下文切换时间，等待定时器或延迟的任务将在定时器/延迟到期时运行。当滴答发生时，定时器和延迟递减，并且当一个到期时发生上下文切换。通过更快的刻度，您只需增加调度程序运行的次数并决定不执行任何操作！通常，您会将计时器和延迟设置为考虑到滴答率的值，以便更改滴答率不会影响现有任务的时间。
答案 1 :(得分：0)