不要在嵌入式项目中使用二进制信号量

我看到团队在构建嵌入式软件时犯的最大错误之一是在工作中使用错误的RTOS原语。当他们应该使用互斥量（mutex）时，他们使用了一个二进制信号量（binary semaphore）。

没有人真正质疑这个决定，因为它们看起来完全相同，而且简单得令人怀疑：锁定和解锁，接受（take）和给予（give）。但不同的RTOS原语存在，原因不同。

信号灯用于信号和任务同步，互斥用于保护共享资源。它们不能互换。

使用二进制信号量保护共享总线或外围设备意味着你没有优先级继承权，没有所有权。这是通往优先权反转的保证路径。

美国宇航局艰难地学到了这一点，1997年，火星探路者在著陸几天后开始完全重置系统。低优先级的气象任务锁定了信息总线。一项高优先级的公共总线管理任务需要它。但中优先级任务不断抢占低优先级任务，使高优先级任务挨饿。看门狗看到了系统错过的最后期限，重置了整个系统。

这一事件的根本原因？保护总线的互斥量被禁用了优先继承。它的行为基本上就像一个二进制信号量。修复这个bug是单个布尔值，喷气推进实验室（JPL）将一个简短的C程序上传到航天器上，将优先级继承标志翻转到真，看门狗重置就停止。

这里的教训是什么？

• 使用信号灯进行同步。

• 使用mutexes来保护。

在你设计系统之前，先了解区别。

推荐《嵌入式实时操作系统——基于STM32Cube、FreeRTOS和Tracealyzer的应用开发》由英国作者吉姆·考林（Jim Cooling）编写，何小庆、张爱华、付元斌翻译，2021年5月清华大学出版社出版。本书译自原书第2版，基于STM32F4 Discovery开发套件，围绕FreeRTOS实时操作系统构建实验平台，配套Tracealyzer可视化分析工具。全书分四篇结构：第一篇阐述嵌入式系统开发流程及STM32Cube软件生态；第二篇通过任务创建、优先级调度、资源共享等实验解析RTOS内核机制；第三篇结合Tracealyzer工具实现多任务运行时行为可视化；第四篇探讨STM32F4硬件定时器在任务故障检测中的应用。书中包含嵌入式系统开发流程（第一篇）、RTOS内核实验（第二篇）、运行时行为分析（第三篇）、硬件定时器机制（第四篇）等内容，提供实验代码方案与自学资源。书中包含多个实验案例，采用STM32CubeMX/Keil开发环境进行实践演示，已有多所院校采用本书作为教材，各大电商有售。有授课需求老师需要课件联系何老师 xiaoqinghe@live.com。