RTOS和非RTOS比得到了什么牺牲了什么？

事实上，有不少基本功扎实的工程师花上个把月，都能手搓一个简易版的RTOS，RTOS本身绝不是那么的高不可攀。目前我们使用的几款主流的RTOS，例如FreeRTOS，RT-Tread等，只是因为他们是组织化运营，商业化运作，在早期使用的群体较多，源码得到了大量的测试验证，从而能不断完善自身，成功搭建起了用户生态。RTOS绝不是一个技术门槛很高产品，相反题主只要稍微浏览一下FreeRTOS的源码，便可得知一二。

事实上确实存在一些非理智的声音，觉得只要程序移植了RTOS就能凸显自身技术水平，而鄙视一切的裸机程序，但这绝对是非常狭隘的看法。因为RTOS不过是一种基于MCU的开发手段而已，很多时候杀鸡是无需用牛刀的。如果只是利用MCU做一些简单的硬件控制以及命令收发，使用裸机方式进行开发明显是更优的选择：

• RTOS是需要根据MCU的资源情况进行适配和裁剪的，这会带来额外的前置工作量；
• RTOS本身也是一个程序，它也会占用MCU的资源，也会带来固定的运行开销；
• RTOS会频繁的进行多任务调度，裸机开发常用的单步调试往往会失去实际意义，提高了代码调试的难度；
• 开发人员需要对多任务程序开发有正确的理解，否则代码的质量难以保证，尤其是任务间的数据同步问题。

那什么时候使用RTOS？答案其实跟技术本身无关，纯粹还是一个投入产出比的问题：若你接受上述的代价后依然觉得要上RTOS的，那就果断上。当程序的功能庞杂，外设众多，尤其时带有图像显示需要进行人机交互时，使用RTOS的收益就会大大提高。

• 原生的多任务的程序架构能明显降低程序员的思维负担，有利于实现功能模块间的解耦，提升代码可读性；
• 提供多种高效的数据传递机制，如消息队列，事件组等，可有效降低各种全局变量的管理难度；
• 任务调度机制可有效提升MCU的运行利用率，同时改善系统对各种外部事件的响应速度。

总体而言，是否使用RTOS，主要取决于程序的复杂度：程序功能越多，业务逻辑越复杂，基于RTOS的开发就越有性价比。而且关键的是，RTOS是帮助程序员降低编程难度的，能使用RTOS进行开发，绝不是编程水平高的体现。