在嵌入式软件中，常用的通信接口例如SPI、I2C、UART等，在MCU与外设的通信过程中，需要确保通信时序不被打断，否则会造成某些不可预料的通信异常问题。
举个例子：
MCU需要发送0xAABB指令操作外设
-
当MCU发送了0xAA后被打断，转而执行其他代码，0xBB未能及时发送，这样一个指令被拆成了两部分，在有时钟信号的通信模块中，可能问题不大，但是如果没有时钟，外设会发生什么异常就不可而知了。
-
当MCU发送了0xAA后被打断，转而执行其他代码，然而此代码也是给当前外设发送0xAABB指令，那么外设收到的指令就变成了0xAAAABBBB。在这种情况下，外设如何处理呢，是报错还是能正确的执行一次通信呢？
那么，常见的通信场景有哪些，并且需要注意的呢？
- 软件初始化过程中通信
软件初始化时，通常需要对外设进行初始化，并且会进行一些查询或者特定的设置操作，此时就要用到通信模块了。
在初始化过程中，命令一般是无法响应的，并且定时任务还未启动，所以此时只需要考虑中断函数的影响。在大多数情况下，我们认为初始化过程中，软件是不需要响应外界的，因此正确的做法一般是：
-
初始化开始
-
锁中断
-
初始化外设
-
解锁中断
-
初始化结束
- 命令交互过程中通信
在软件中通常会设计一套对外通信接口协议，如果存在接口需要对外设进行读写，那么需要考虑互斥问题。
如果存在中断函数对同样的外设进行操作，需要在命令处理函数中，进行锁中断操作；
如果存在定时任务对同样的外设进行操作，需要分两种情况考虑：
-
当定时任务与命令交互的执行逻辑是一个串行流程时，不存在互斥问题；
-
当定时任务是操作系统中的一个线程，并且线程的优先级高于命令处理，则存在互斥问题，需要考虑场景：当命令中访问外设时，被定时任务打断，需要使用信号量进行互斥处理。
- 定时任务中通信
定时任务的设计逻辑与第二点中的命令交互类似，可以合并考虑。
如果存在中断函数对同样的外设进行操作，需要在定时任务中，进行锁中断操作；
如果存在命令对同样的外设进行操作，需要分两种情况考虑：
-
当命令与定时任务交互的执行逻辑是一个串行流程时，不存在互斥问题；
-
当命令处理是操作系统中的一个线程，并且线程的优先级高于定时任务，则存在互斥问题，需要考虑场景：当定时任务中访问外设时，被命令处理打断，需要使用信号量进行互斥处理。
- 中断函数中通信
中断函数一般是优先级最高的，不需要考虑被其他普通场景打断。但是需要考虑一种特殊场景，那就是被更高优先级的中断打断，一般来说，不推荐做这种中断设计，因此不考虑。
- Tips：关于锁中断
锁中断是一个高危操作，有可能会导致中断函数不能及时执行，更严重的甚至会丢中断，因此需要结合软件的业务特点整体设计考虑，是否能锁中断，以及应该在哪里锁中断！