embedded - 处理许多中断源

Question

考虑到各种传感器有 100 多种中断方式。也有可能所有事情都同时发生。如何设计软件以有效地处理它？

Answer 1

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

既然你问效率，我猜你在看吞吐量。在这种情况下，一种行之有效的模式是让中断处理程序读取传感器，对命令和状态进行排队，然后立即返回。

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

这基本上就是窗口系统的工作方式。每次鼠标单击、鼠标移动、键盘按下等都会导致命令排队。窗口系统选择命令并调用相应的处理程序。有广泛的逻辑可以在它们被从队列中挑选出来时丢弃不相关的命令，用于组合命令并加速它们。

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

Answer 2

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

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

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

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

Answer 3

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

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

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