建立系统滴答率所涉及的基本权衡

　　许多 RTOS 内核在设置内核的周期性滴答中断方面为开发人员提供了很大的灵活性。不幸的是，这种灵活性有时会导致混乱。似乎是许多问题根源的刻度的一个可配置方面是频率。我将尝试消除与频率有关的常见神话，并尝试解释建立系统滴答率所涉及的基本权衡。

　　也许由于其他内核或特定硬件平台中存在的限制，似乎有一个广泛的共识，即 µC/OS-II 和 µC/OS-III 限制了应用程序代码可用的滴答频率范围。然而，内核本身应该能够支持在给定 MCU 上可行的任何滴答频率。我已经看到应用程序以远低于 100 Hz 的滴答率运行，而在频谱的另一端，则远远超过 1 kHz。

　　如果内核对系统的滴答频率没有任何特殊影响，那么在设置此参数时应该考虑哪些因素？除了会产生滴答声的外围设备施加的限制之外，您的主要关注点应该是开销和分辨率。使用相对较高的频率，您将能够以比其他方式更小的增量建立延迟，但是您将为此能力付出代价，增加的开销是以处理滴答的 CPU 时间的形式。较低的频率会减少滴答处理时间，但当然也会限制系统延迟的分辨率。例如，在每 10 毫秒发生一次滴答的系统中，内核将无法提供低至 1 毫秒的延迟。

　　为了在开销和分辨率之间取得适当的平衡，您需要考虑硬件平台的功能和应用程序的时序需求。以 µC/OS-II 或 µC/OS-III 为例，在以 300 MHz 运行的 32 位处理器上，任一内核每秒处理 1，000 个滴答所需的开销可能不会超过 CPU 周期的 1%。但是，具有 24 MHz 时钟的 16 位 MCU 可能是另一回事。同样，仅使用时间延迟来轮询按钮按下的应用程序在 50 毫秒的滴答分辨率下可能不会遇到任何问题，但对于截止日期较紧的任务来说，这样的设置可能是不可接受的。

　　关于最后一点，重要的是要注意，滴答声可能不是解决系统中所有延迟的最佳解决方案。例如，如果您想每 500 µs 从 A/D 转换器读取数据，那么最好的方法可能是让您的转换器由中断驱动并使用定时器触发转换（与滴答中断无关的定时器） 。 换句话说，基于滴答的函数旨在用于严重延迟——例如，负责大约每 10 毫秒输出一条消息的状态任务可能需要这样——并且你应该转向专用的硬件定时器，当需要更准确的延迟。我将在第 3 部分中提供与此主题相关的更多详细信息，其中我解释了内核节拍的另一个有时令人困惑的方面：优先级。

　　审核编辑：郭婷