“消失的中断”
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. 结尾
在开发过程中,很多情况下我们都会在中断中再触发新的中断,面对这种情况,我们要在触发新的中断之前就去清除中断标志,这样才能避免中断“消失”问题发生。