【发布时间】:2017-02-06 12:36:01
【问题描述】:
当可能涉及其他变量和因素(如硬件)时,如何确保中断延迟不会超过某个值?
【问题讨论】:
-
标题问一件事,正文问另一件事。中断延迟与 RTOS 行为没有特别的关系,并且在很大程度上独立于它。所以根本不清楚你在问什么。似乎是两个不同的问题。我会给出答案,但我不知道要解决哪个问题。
标签: rtos
当可能涉及其他变量和因素(如硬件)时,如何确保中断延迟不会超过某个值?
【问题讨论】:
标签: rtos
硬件延迟是可预测的。它不必是恒定的,但它肯定是有界的——例如中断进入通常是 12 个周期,但有时可能需要 15 个周期。
RTOS 延迟是可预测的。它也不是恒定的,但例如您可以确定 RTOS 在任何时候都不会阻塞中断超过 1000 个周期。通常它会在更短的时间内阻止它们,但永远不会超过规定的时间。
如果您的应用程序没有做一些奇怪的事情(例如在线程中具有最高优先级的while (1);),那么整个系统的延迟将是硬件延迟和 RTOS 延迟的总和。
这里的重要事实是,使用实时操作系统编写您的应用程序并不是应用程序也是实时的唯一要求。在您的应用程序中,您必须确保不违反实时约束。 RTOS 的主要工作是不妨碍您这样做,因此它可能不会引入随机/不可预测的延迟。
通常,RTOS 中“可预测”的最重要的事情是未被阻塞的最高优先级线程正在执行。时期。在 GPOS 中(如台式计算机、平板电脑或智能手机上的 GPOS),这是不正确的,因为调度程序通过允许低优先级线程运行一段时间来主动防止低优先级线程饥饿,即使有更重要的现在要做的事情。这使得应用程序的行为不可预测,因为有一天它可能会在 10us 内做出反应,而在另一天它可能会在 10s 内做出反应,因为调度程序认为这是将日志保存到硬盘驱动器或进行一些垃圾收集的好时机.
或者,您可以认为对于 RTOS,延迟在微秒范围内,可能是单毫秒。对于 GPOS,最大延迟可能是几十秒。
【讨论】: