我们来看这段程序:
上面这段程序，是串口2的中断服务函数，在这里面完成的是接收一帧\r\n的数据。
这样看来，这段程序保护得挺好，在串口在执行接收的过程中不会被中断打断。但如果不注意的话，会被坑，我们来看下面这种情况。
如果是使用stm32cubeMX生成代码，我们会看到在main.c中调用了串口初始化函数，在代码编写规则制定的区域定义了一个信号量，用于处理传感器数据。
这样看来没毛病，编程思路都是对的，但是灾难就快要发生了，于是我们在msp初始化函数里添加这么一段。
如果在串口初始化过后，传感器设备不通过串口发送数据，在未触发串口接收中断的时候，庆幸你的设备是可以正常开机运行的。
如果在串口初始化过后，传感器立马就上报数据给MCU，这时候你会突然发现，设备开不了机了？What?这是为什么？
断点调试后发现问题了，我们在这里发出了一个信号量，但信号量还没有初始化吧？？
我们跟踪断点，进入xSemaphoreGiveFromISR这个函数，看看是为什么就卡死了呢？
这是一个宏，实际上是调用了xQueueGiveFromISR这个函数，我们继续跟进断点
我们再单步进这个断言：
结果发现死在这里了，这就说明我们并没有创建队列句柄。这就是stm32cubeMX给我们带来的坑爹问题了，既要按照它的要求来定义和编写代码，又要防止这样的问题产生。
那如何来解决这样的问题呢？其实很简单，加一个标志变量就可以了，在os没起来之前，我们不让发送信号量的这句话执行，等os起来以后，才让发送信号量这句话执行，否则会带来灾难性的结果。
在os还没有起来之前，我们还没有使用数据，而且信号量还没有创建，这时就不要使用os的信号量的发送和接收函数，于是想到一个解决办法，定义一个is_use_os变量，在os未起来之前这个标志为false，当os起来以后，这个标志就为true。
在中断服务函数里对标志进行判断：
这样，当os没启动之前，is_use_os这个变量为false，对应的代码不执行，当os启动以后，is_use_of这个变量为true。
我们再来看os启动以后，这个变量还是不是为NULL了?
我们先让代码跑到初始化任务里，这是也就标记着OS已经启动了。
然后再把断点打到刚刚串口中断接收的函数里。
然后单步进入看看
这时候我们发现，这个值已经不为NULL 了。
完美解决问题。
往期精彩
开源按键组件MultiButton支持菜单操作(事件驱动型)
