Zephyr RTOS 简介与历史背景
从一次现场调试说起
去年冬天，我在一个工业网关项目上被一个问题折磨了整整三天。设备在实验室跑得好好的，一到客户现场就随机死机——不是看门狗复位，而是彻底挂死，连串口都不响应。我用JTAG挂上去，发现任务调度器停在了某个临界区里，而那个临界区的锁居然被一个优先级更低的任务占着。更诡异的是，这个低优先级任务明明在等一个信号量，而信号量的释放者——一个高优先级的中断服务程序——却因为系统滴答定时器的优先级配置问题，被另一个中断给抢占了。
我盯着FreeRTOS的源码看了半天，最后发现问题的根源在于：这个系统里同时跑着多个中断优先级，而FreeRTOS对中断嵌套的支持需要开发者自己小心翼翼地维护一套规则。那天晚上我就在想，有没有一个RTOS能从一开始就把这些坑给填上？
后来我遇到了Zephyr。它用一套统一的中断管理机制，从架构层面解决了这个问题。那次之后，我陆续把几个新项目都迁移到了Zephyr上。今天这篇笔记，就从它的来龙去脉说起。
它从哪里来
Zephyr RTOS最初是2015年由Wind River（风河系统）内部孵化的小型物联网内核，当时叫“Rocket”。2016年，Wind River把它捐给了Linux基金会，更名为Zephyr。这个时间点很有意思——正好是物联网概念从“连接一切”的狂热期，转向“怎么让这些设备可靠工作”的务实期。
和FreeRTOS、RT-Thread这些由社区或个人驱动的RTOS不同，Zephyr从诞生起就带着“正规军”的基因。它的代码审查流程、文档规范、测试覆盖
