我正在学习中断,但无法理解当中断过多到 CPU 无法处理前台循环或完成现有中断时会发生什么。我通读了这篇文章https://www.cs.utah.edu/~regehr/papers/interrupt_chapter.pdf但不完全理解调度程序将如何提供帮助,如果中断太多?
如果不能错过中断,我们是否会切换到更快的 CPU?
我正在学习中断,但无法理解当中断过多到 CPU 无法处理前台循环或完成现有中断时会发生什么。我通读了这篇文章https://www.cs.utah.edu/~regehr/papers/interrupt_chapter.pdf但不完全理解调度程序将如何提供帮助,如果中断太多?
如果不能错过中断,我们是否会切换到更快的 CPU?
是的,您必须切换到更快的 CPU!您必须确保主循环有足够的时间。因此,尽可能缩短中断服务并进行一些 CPU 工作负载测试非常重要。
事实上,任何时候对共享资源进行争用,都有可能出现饥饿。论文中讨论的调度程序限制了中断率,从而保证了每个间隔期间的一些无中断处理时间。在高活动期间,中断处理被禁用,调度程序切换到轮询模式,定期询问中断请求线路的状态,有效地限制中断流。操作系统力求在每个中断处理程序中做尽可能少的事情——任务通常只是简单地排队,以便稍后在不同的阶段处理它们。任何调度算法都有许多考虑和权衡。
总的来说,您需要了解程序的每个部分消耗了多少时间。在实践中使用示波器很容易测量。如果您在进入中断时激活 GPIO 并在离开中断时取消激活它,您不仅可以查看 ISR 消耗了多少时间,还可以查看它启动的频率。如果您为每个 ISR 执行此操作,您将获得好主意他们需要多少时间。然后,您可以在 main() 中执行类似的操作,以粗略估计程序的完整执行周期,即 main + 中断。
至于最好的解决方案,显然是减少中断的数量。如果可能,请使用轮询。使用 DMA。使用硬件缓冲的串行外围设备(UART、CAN 等)而不是中断密集型外围设备。使用硬件 PWM 而不是输出比较定时器。等等。当您为项目选择合适的 MCU 时,需要尽早考虑这些事情。如果您选择了错误的 MCU,那么您显然必须做出改变。玩弄 CPU 时钟听起来像是快速而肮脏的修复。取而代之的是正确的设计。