处理许多中断源

Question

考虑到各种传感器中有100多种中断方式。有可能所有这些都可以同时发生。如何设计软件以有效地处理它？<​​/ p>

Answer 1

这取决于您是否针对延迟或吞吐量进行了优化。

既然你问过效率问题，我猜你会考虑吞吐量。在这种情况下，一个经过验证的模式是让中断处理程序读取传感器，排队命令和状态，然后立即返回。

您有一个非中断软件线程从队列中选择命令并为处理程序发布事件。这可以最大限度地减少任务切换时间您可以使用特定于域的逻辑来组合命令，抛弃不再相关的命令等。

这主要是窗口系统的工作方式。每次单击鼠标，鼠标移动，键盘按下等都会导致命令排队。窗口系统关闭命令并调用相应的处理程序。有一个广泛的逻辑，用于丢弃从队列中挑选出来的命令，用于组合命令以及加速命令。

网络堆栈使用相同的模型。数据包按网络级排队，然后主循环选择它们并使用控制模型的反转来处理每个数据包。

Answer 2

经验法则是中断处理程序应该尽可能少地处理中断。让它们“尽可能短”。

例如，如果您的设备必须在串行端口上接收消息并对它们做出响应：UART串行RX中断处理程序应该只读取传入的字节并将其存储在缓冲区中（并确保没有缓冲区溢出） ）。而已。然后主循环任务应该稍后处理缓冲区中的数据，并在缓冲区中创建任何响应，以便它可以由串行TX中断处理程序传输。

过去，我见过嵌入式软件，中断处理程序处理整个通信协议。它工作，但中断处理程序需要很长时间才能运行，因此延迟了其他中断处理程序的运行。这增加了其他中断处理程序不及时处理事件的风险。

Answer 3

如果您的系统确实有100个中断源，效率可能不是唯一的问题。您可能必须进行“延迟分析”，以确保在最坏的情况下您不会失败。

首先，测量每个ISR的最坏情况时间。 然后，对于每个中断X：

1. 确定截止日期：中断X发生和灾难之间可以经过的最长时间（如丢失数据，缺少通信窗口等等）
2. 确定可以阻止服务中断X的其他ISR的最坏情况。根据处理器的优先级结构，您可能必须考虑在X之前发生的中断，以及在X挂起时发生的中断。 / LI>
3. 将步骤2中标识的ISR的所有时间相加。如果总和大于截止日期，则需要重新设计。

重新设计可以包括使ISR更快，调整FIFO长度，改变中断频率（更少地收集更多数据，反之亦然），调整序列以确保不会同时发生某些中断。没有一个适合所有人的策略。 （尽管更快的ISR几乎总是一件好事。）