为什么不将任务上下文置于中断中答案

【问题标题】：Why not put task context in interrupt为什么不将任务上下文置于中断中
【发布时间】：2018-04-23 06:15:00
【问题描述】：

这就是故事。

它是一个安全关键项目，需要以 20KHz 运行时间关键功能例程。现在的设计是将功能程序放在一个20KHz的FIQ中断中，同时安全中断也放在FIQ中。那是系统中仅有的两个 FIQ。（当然MCU中启用了几个IRQ）

我知道将任务上下文放在中断 ISR 中是不好的，这样做的正确方法是设置标记并在 OS 任务中运行。但似乎当前的设计不会伤害任何人。

例程大约需要 10us（主时钟 300MHz），所以基本上不会阻塞 IRQ/FIQ 到不可接受的时间。与使用 OS 任务运行功能例程相比，它甚至可以节省额外的上下文切换时间。对我来说，目前感觉这个设计违背了大学教科书上写的每一条原则，却找不到拒绝的理由。

我如何说服自己将功能性例程从 ISR 转移到 OS？我应该吗？

【问题讨论】：

如果 FIQ/s 足够短，不会影响应用程序其余部分所需的功能，并且不要使用在 FIQ 上下文中非法/不明智的代码/功能，那么很好。当然，你必须小心你做什么/打电话，但如果它安全且有效，那就太好了:)
示例 - 当我将缓冲区结构指针推送到循环队列时，我遇到了问题，虽然从 IRQ 推送并从线程拉出时安全，但当它也从 FIQ 推送时不安全，因为当 FIQ 中断一个 IRQ 时，队列索引可能会混淆：（我通过显式设置软件中断来解决这个问题，因此它的处理程序要么在 FIQ 返回后运行，要么在任何其他被中断的 IRQ 返回后运行。
我不得不问，你在做什么需要 10us？
@MartinJames 好点。抢先式中断确实会导致问题，而关键资源没有得到很好的保护。 10 我们只是一些数学工作。传感器取回数据，MCU 需要快速进行一些计算和响应。数学作品是上面提到的功能例程。我认为在这种情况下没有关键资源。如果我转向操作系统，我会变得更加臃肿。我可以从这些臃肿中获得什么好处？
您已将此标记为安全关键。如果您的应用程序对安全至关重要，那么您必须确保中断是 100% 循环的，并且您的程序是 100% 确定性的。摆脱中断可能会更好，让主程序完成所有工作，然后忙于等待中断源 - 这假设程序除了处理 20kHz 周期之间所需的所有事情之外什么都不做。在不了解规范的情况下，很难说应该如何设计系统。

标签： c operating-system embedded interrupt safety-critical

【解决方案1】：

让我们回忆一下你的情况：

您正在编写一个安全关键系统
未指定软件架构，否则您不会提出手头的问题
系统要求未正确处理，否则 2) 不会有问题
有人告诉您“在安全关键系统中尽可能使用最小中断”
您想将最高优先级和不可中断的代码用于“只是一些数学工作”

抱歉有点苛刻，但我不想在您的安全关键系统中使用/加入。

对于您的实际问题：你必须确保两件事

FIQ 中的代码必须是确定性的并且经过 WCET 测试
定时器的寄存器必须受到保护和监督。为什么？安全级别较低的代码对定时器寄存器进行不必要/错误的操作会导致 CPU 严重拥塞，以至于实际上只处理中断。

所有这些都假设您的安全状态完全取决于外部硬件看门狗。

PS：您的系统用户面临哪些危险？烦恼？受伤？致命？您处于 SIL 或 ASIL 环境中吗？

【讨论】：

确实，缺乏详细的需求和软件架构规范确实很痛苦，并导致了这个问题。该项目处于 ASIL D 环境中.. 很遗憾地告诉你.. 幸运的是它更像是教育目的而不是工业目的..
ASIL D。您知道唯一正确的反应方式是放弃所有任务并要求立即汇总整个项目吗？听起来，没有安全经理和流程经理，所以根据定义，它不是 ASIL D，而是一个旨在提供可能致命功能的测试项目。请不要认为这是一种侮辱，这只是在说真话——我这边没有任何指责。
我不会认为这是侮辱，真的很感谢你的直率。很高兴有人指出留下的东西，这样可以确保所有东西都收拾好。这里的一个问题是内部/外部看门狗可以确保 CPU 没有被中断完全占用。至少可以在事情发生后重置MCU。那么我可以说CPU拥塞在这一点上不是一个大问题吗？（另一方面，似乎减少了计时器 ISR 率是看门狗无法监督的......确实需要监视器）
@Vroomfondel - 你的一些参数真的很有帮助，但 IMO，你明确表达答案的绝对性是不合理的。如果看门狗的概念是合理的（这也意味着看门狗保证安全状态！），则系统在计时器错误方面是安全的。时期。这并不意味着结果很有用。解决另一点 - 安全项目（包括需求和安全经理等）可能有几个阶段，开发人员正在尝试找到一个可行的提议，可以重新进入架构/设计，甚至在所有需求完成之前。跨度>
@HelpingHand 是的，我写了一条评论，但现在似乎没有了。 耸耸肩

【解决方案2】：

将复杂代码从 ISR 中移走的原因正是为了避免在 ISR 中进行冗长的处理，从而避免由此导致的时序抖动和中断服务延迟。

您是在说明您的处理时间不长，因此请在 ISR 中执行！否则你只是在增加膨胀。

【讨论】：

我很难确定 ISR 中的 10us 是否很长，因为它在 20KHz 中断中运行！这意味着只有 FIQ ISR 中的功能例程会关闭大约 1/5 总运行时间的中断！我想有一种数学方法可以确定它是否可以接受......
实施能否及时服务ISR并处理每个结果？（它必须吗？）如果可以，那么你很高兴。如果你把 ISR 和处理分开，你会添加更多的代码来执行。
现在，它工作得很好。但我目前处于开发的早期阶段，所以不太确定未来隐藏的问题。
@Tian 50us 中的 10us 是所有可用处理能力的五分之一。这是相当多的中断延迟。问题是，CPU 有没有比这个任务更重要的事情要做，或者 10us 的延迟会在其他地方搞砸时序？如果是这样，您需要最小化 ISR。如果没有，那么一切都很好。
无论如何，如果您正在做一个时间关键型系统，并且您需要花费 20% 的 CPU 时间来处理周期性任务中断，那么您可能不应该做太多其他事情。 ..

【解决方案3】：

20Khz = 50us 之间的中断，10us 的处理时间为您提供大约 20% 的 CPU 时间，仅用于这个“任务”，并且在您的 CPU 中运行的任何其他例程中的 10us 抖动，它也将总计 10us任何其他任务将消耗的每 40us 的处理时间，如果它适合您的项目，并且您将总 CPU 处理时间保持在 70% 以下（这是关键系统可接受的常见最大值），恕我直言，它应该可以在没有任何问题。

【讨论】：