一个跟STM32F0中断优先级有关的话题

     经过跟他深入沟通，了解到STM32F031跟外界有UART数据通信并开启了RXNE接收中断，还有对外的AD采样动作，通过定时器定时触发AD转换，并开启了ADC1的转换完成中断。AD触发间隔为2秒。再就是些其它对外的GPIO操作的东西。他陈述当波特率低于9600，甚至更低时就很难遇到丢包的现象，只要当波特率达到115200甚至更高时，就比较容易丢包，经常丢一个两个不等，波特率越高越容易丢。

     客户给USART1的时钟源配置的是48M系统时钟。按理说，STM32F0芯片的UART的波特率跑个200K是很轻松的事。让他用示波器在芯片RX脚监测外界传输过来的信号，当外界发送方的波特率即使在200K左右时波形还是很干净漂亮，看来不存在信号畸变的问题。

     因为他谈到开启了UART RX中断和ADC的EOC中断，我怀疑他的中断优先级配置可能有问题。察看其代码后，发现关于UARTTX/RX中断与ADC的EOC中断优先级一样的 。

     看到这里，基本算是找到原因了，只待进一步验证。

    外界不定期通过UART发送数据给MCU，当它收到一个数据本该通过RX中断请求去读取数据时，如果此刻碰上ADC的EOC中断服务程序刚刚开始或正在执行途中，由于二者优先级一样，那UART的RX 中断就得至少等待ADC中断服务程序继续执行到弹栈前的时间。若在这个等待期间内UART又收到了第二个数据甚至更多，那就会发生溢出导致数据丢失。

     那为什么会只是偶尔发生而且波特率高更容易发生呢？这也不难理解。

    波特率高意味着传送速度快，相应的每个字符的传送时间就短，即收到一个字符后，下一个字符来得也快。而每次的ADC的中断程序执行时间是相对固定的，最糟糕的情形就是产生UART RX中断请求时碰到EOC中断服务程序刚刚开始，这样等待时间最长。在UART接收到数据等待ADC中断释放CPU期间，新的数据来得越快，丢数据的几率就越高。当然了，不是每次都是碰到那个最糟糕的情形，最好的情形就是碰上ADC中断服务程序刚好执行完毕。

     反过来讲，如果UART传输波特率比较低，意味着单个字符传输时间相对比较长。碰到ADC中断服务程序先得到响应情况下，或许等人家执行完了再来取“待取走”的数据还来得及，尤其不在最糟糕的情形下。

    当该工程师将UART RX中断优先级配置为高于ADC的中断优先级后就再没那个麻烦了。

     顺便说说上面那红色语句“等待ADC中断继续执行直到弹栈前”。

    这句红色的话意思是说，在上面情况下，UART中断请求等待EOC中断运行到执行POP之前的时刻就可得到响应而去执行UART RX中断服务程序，并不急着执行EOC中断的POP弹栈动作，随之的UART中断服务程序也无需压栈操作，UART中断程序执行完毕后再回来做弹栈动作，然后回到主循环的中断处接着运行。这就是平常所说的咬尾中断。不难看出，这样可以大大提升中断响应速度。具体到本案,这个咬尾操作一定程度上减少了丢码机会。

    
    既然提到了咬尾中断,可能很多人听说过晚到中断。所谓晚到中断，简单点说就是低优先级中断服务程序正在压栈或刚压栈完毕时发生更高优先级的中断请求,高优先级中断不再做PUSH压栈操作，等到低优先级中断压栈完毕即直接运行高优先级中断服务程序,随后再返回来接着执行低优先级中断服务程序，之后再做POP弹栈操作。

    前面提到的STM32F0 的两个中断优先级相同情况下，都是假定中断请求在时间上错开了的情况。如果二者同时到达，那CPU先响应哪一个呢？就看二者在中断矢量表的序号，谁的序号小就先响应谁。

     另外，玩过CORTEX M3/M4内核MCU的人，比方STM32F1，STM32F2，STM32F3，STM32F4等芯片的人可能会发现，CORTEX M0 内核的MCU的中断管理跟其它CORTEX M3/M4内核的在中断优先级管理上是有差异的。

    M3/M4的MCU在中断优先级做分组管理，分抢占优先级和响应优先级。只有强占优先级高的中断请求才可以打断低抢占优先级的中断服务程序；抢占优先级相同的情况下，高响应优先级的中断请求顶多可以优先获得响应权。而M0内核芯片的中断优先级不再做分组管理，谁的优先级高就优先响应并可打断低优先级的中断服务程序。

     当在系统里开启多个中断事件时，要合理安排各中断源的优先级，有些时候可能还需精心安排。对于初学者，因为中断优先级问题处理不当而导致麻烦的情况时有发生。再就是对于中断服务程序，如果不是必需，代码尽量精简，不要累赘，能放到中断外部处理的就尽量放到外部去。