相对于之前的超时，循环软件计时器应该在什么时候触发？
我认为这是那种"vi‘s emacs“类型的问题，但我还是会问，因为我希望听到人们的意见。
在嵌入式系统中，微控制器常常具有为软件定时器子系统提供定时基础的硬件定时器外围设备。该子系统允许开发人员创建任意数量的计时器(受系统资源的限制)，这些计时器可用于生成和管理系统中的事件。通常管理软件定时器的方式是将硬件定时器设置为以固定间隔生成(或者有时仅在下一个活动定时器将期满时生成)。在中断处理程序中，调用回调函数来执行特定于该计时器的操作。像往常一样，这些回调例程应该非常短，因为它们在中断上下文中运行。
假设我创建了一个每1ms触发一次的计时器，它的回调例程需要100us才能执行，这是系统中唯一感兴趣的事情。计时器子系统应该在什么时候安排该软件计时器的下一次处理？是从中断发生时算起1ms，还是从回调完成时算起1ms？
为了让事情更有趣，假设硬件开发人员来了，他说在某些操作模式下，CPU速度需要降低到最大速度的20%，以节省电力。现在回调例程需要500us，而不是100us，但计时器的间隔仍然是1ms。假设回调中增加的延迟对此待机模式下的系统没有负面影响。同样，计时器子系统应该在什么时候安排下一次处理这个软件时间？T+1ms还是T+500us+1ms？
或者，也许在这两种情况下，它都应该折衷一下，并调度为T+(execution_time/2)+1ms？
回答 3
Stack Overflow用户
发布于 2011-03-24 14:50:04
在实时操作系统中，定时器和延迟都与系统节拍同步，因此如果事件处理所用的定时器节拍少于一个定时器节拍，并且在定时器节拍边界上开始，则使用定时器或延迟之间不存在调度差异。
另一方面，如果处理时间超过一个滴答，您将需要一个计时器事件来确保确定性的无抖动计时。
在大多数情况下，决定论是重要的或必要的，并使系统行为更可预测。如果定时是从处理结束开始递增的，则处理过程中的可变性(无论是静态代码更改，还是通过差异执行路径的运行时)可能会导致行为可变和未测试的情况，这些情况很难调试或可能导致系统故障。
Stack Overflow用户
发布于 2011-03-24 11:26:37
我会让硬件计时器每1ms触发一次。我从来没有听说过硬件计时器会考虑到这么快的例程。特别是因为每次有软件更改时，您都必须重新计算。或者弄清楚当CPU改变时钟速度时该怎么做。或者弄清楚如果你决定升级/降级你正在使用的CPU该怎么做。
Stack Overflow用户
发布于 2011-03-25 09:02:52
在这一点上增加了另外几个原因(计时器应该每1ms触发一次)：
- 如果计时器每1ms触发一次，而您真正想要的是两次执行之间有1ms的间隔，则可以在回调函数退出时将计时器重置为从该point.
- However，触发1ms。如果计时器在回调函数退出后1ms触发，而您想要另一种行为，那么您就有点卡住了。
此外，每1ms触发一次的硬件复杂度要低得多。为了做到这一点，它只是生成事件和重置，并且除了设置时之外，不会从软件向计时器返回任何反馈。如果计时器留下了1毫秒的间隔，那么软件需要有一些方法来通知计时器它正在退出回调。
当然，你也不应该“折衷”。这对每个人来说都是错误的，如果有人想让它做其他事情，那么绕过它是更令人讨厌的。
https://stackoverflow.com/questions/5413034
复制相似问题
腾讯云开发者
