合肥网站优化方案wordpress qq挂件
“消失的中断”
1. 前言
在嵌入式开发过程中，中断必不可少。道友们想必也经常因为中断问题头疼不已，今天来说说一个很常见的问题，“消失的中断”。最近项目在使用第三方MCAL的时候，就遇到了I2C中断丢失的问题，排查起来耗费了许多的时间。这里我通过一个例子来简单描述一下这个"消失的中断"是怎么回事。
2. “消失”的串口中断
道友们对串口肯定不陌生，串口数据使用FIFO+中断采用异步的发送模式。如下图所示是整个数据发送流程：上层应用调用串口驱动发送数据，串口驱动将数据填入到FIFO中，然后开始发送数据。当第一个数据发送完成后触发发送完成中断，利用中断去FIFO中取下一个数据接着发送，然后清除中断标志位。在这样的流程下，当串口的波特率在9600的时候，数据能够被完整的发送，当波特率调到115200的时候，就开始出现数据丢失的情况（只发送了前面一部分数据后，后面的发不出去了）。
好，看到这里，好像整个流程并没有什么问题，进入中断后首先对数据进行处理，在退出中断前清除中断标志位。其实这里面有一个很大的讲究，就是针对清除中断标志位这个动作，也要根据中断的实际情况来决定它执行的“时机”，要不然中断就有可能会“消失”咯。
上面这个张图，存在我们平常很容易忽略的地方，完整的流程应该是如下图所示，相较于上图，下面这张图多了发送时间A和执行时间B。
中断为什么会“消失”？是因为中断标志位没有被置起来（当然是在全局中断打开、外设中断也是使能的前提下），针对上述的流程，发送完数据后，中断标志肯定会被置起来，那为什么中断没有触发呢？关键在于发送时间A和执行时间B。OK，这里我们回到之前说的在9600波特率的情况下传输是正常的，在115200波特率下传输就会发生中断的情况，我们的流程都是相同的，为什么会存在不同的情况？这是因为9600波特率的数据发送时间是长于115200的数据发送时间的，因此在9600波特率下中断的触发时间是会比115200波特率下触发中断的时间来的晚，在中断触发之前我们的执行时间B已经执行完，中断标志位已经被清除，因此不会影响下一个中断标志位的置位，因此下一个中断依旧能够被触发。但是对于115200波特率来说，发送时间A变短了，在上一个中断服务函数的执行时间B还没有结束的时候，再次触发了中断（中断标志位置1），然后上一个中断服务函数执行完后把中断标志一清，好了，相当于这个新的中断就没有触发，因此后续的数据发送也就断了。这就是为什么中断会“消失”的原因。
3. 结尾
在开发过程中，很多情况下我们都会在中断中再触发新的中断，面对这种情况，我们要在触发新的中断之前就去清除中断标志，这样才能避免中断“消失”问题发生。