该不该用RTOS？我们只做对的选择

Fillmore

笔者：armink

我第一次接触到嵌入式，大概是在 2008 年，那时候还是大二，刚开始学 51 单片机，自然还是要从裸机开始跑。因为自己是计算机系的，以前写程序都是跑在 PC 机上的，现在竟然能在电路板上执行软件，感觉完全不一样，至今还记得我第一次跑通流水灯的喜悦。但是随着写的裸机软件越来越多，裸机所暴露的问题也越来越多，这里我给大家总结下吧：
并发性：程序并发工作效率低

在写裸机软件时，不可避免的在主程序中会有一个超级大的 while(1) 循环，这里面几乎包含整个项目的所有业务逻辑。因为每个业务逻辑里面都会有 delay 这样的循环等待函数，这样导致了所有的业务逻辑几乎都是串行起来工作的。这个时候 CPU 就会有很多时间都浪费在了延时函数里，一直在空转，导致软件的并发效率非常差。

模块化：从软件工程的角度，我们在做软件开发时，都会强调高内聚、低耦合的原则。而裸机的模块化开发难度非常大，模块间的耦合较重，这也导致了无法在大型项目使用裸机来开发。

还是刚才 main 函数中大 while(1) 的例子，可以想象到那么多功能都紧紧的挤在一个函数里，不可拆分，模块化开发的困难重重。

举一个非常贴切的例子，在一些使用看门狗的项目中，如果使用 delay 延时函数，那得注意点，万一延时过长，主函数来不及喂狗，看门狗就被触发了。最后会产生这样一种感觉，一个简简单单的 delay 还得考虑喂狗功能，裸机开发时操的心太多了，自然无法应用在大型项目中。

生态：很多高级软件组件，必须依赖于操作系统来实现

比如说，我前些年开源过一个基于 FreeModbus 的 Modbus 主机协议栈，因为要考虑各个平台适配问题，原本计划支持各种各样的操作系统，甚至是裸机平台。在各个操作系统上的适配都非常容易，但再去尝试着适配裸机时，发现难度重重，有一些函数在裸机上实现起来非常复杂，而且针对于不同的裸机环境，几乎没有通用性可言，太耗费精力了。所以我最终就放弃了裸机适配，一直到现在，在裸机上还是没法用这个 Modbus 主机协议栈。

还有一些软件无法运行在裸机上，比如：乐鑫、Realtek、 TI 和 联发科 提供的 WiFi SOC SDK ，一些蓝牙 SOC 的 SDK 也都是只支持操作系统，所以，如果你不了解、不会使用操作系统，这些芯片也就玩不转了。

实时性：功能复杂的情况下，实时性无法保证

软件的实时性在一些领域会有一定的要求，软件的每个步骤必须在指定的时间被触发。工控领域就是最常见到的场景，如果实时性无法保证，机械设备可能就无法按照指定时序要求去动作，以至于发生机械事故，甚至会威胁到人的生命。回过来接着看裸机软件，如果软件变得庞大以后，可以想象到，主程序中那么大的一个 while(1) 循环，代码耦合严重，到处都是 delay 延时，要保证实时性几乎是不可能的。

可重用性：软件可重用性差，总是重复造轮子

可重用性与模块化程度有直接的关系。相信大家每个人在工作中都不想做很多重复性的工作，同样在写代码时，也想着尽可能少写一些功能相似的代码。但在这个嵌入式碎片化极其严重的时代，各式各样的芯片，想要让同样的代码，在裸机环境下同时适配不同的硬件，难度非常大。这样也就导致了裸机的代码会过多的依赖于底层硬件，重复造轮子的过程也就不可避免。
第一次接触操作系统，是在 2010 年左右，那时 STM32 已经开始流行起来，这么强大的单片机，有很多人都在上面跑操作系统，我也跟着移植了 ucos ，在上面还跑了 ucgui ，这个时候写应用完全是一种全新的体验，爽了很多，玩了一年了 ucos ，后来接触到咱们国产的 RT-Thread ，在它上面有很多现成的、拿来即用组件，试用以后发现更爽，就一直用到了今天，大概有 8 年了。也跟大家也聊一聊操作系统的优势：

线程方式的并发任务处理，解决模块化问题，同时保证实时性

模块化：使用了操作系统以后，整个软件的工作被拆分成了由多个任务来构成（也会被称为线程），每个线程有自己独立的运行空间，即线程堆栈，这个时候每个线程你玩你的，我做我的，咱们大家互补干涉，模块化程度得到很好的提高。

并发性：从并发的角度来看，各个线程在使用 delay/事件等待 这类函数时，会自动的让出 CPU 给其他有需要的线程，不仅书写 delay 延时函数操的心少了，整个 CPU 的利用率也得到了提高，最终提升并发性。

实时性：再来看实时性，像 ucos/RT-Thread 这些 RTOS 本身就被设计为实时的操作系统，各个线程都有不同的优先级别，重要的线程可以设为高优先级，不重要的线程可以降低优先级，做好全局的统筹规划后，这样整个软件的实时性也能得到保证。

开发效率：

由于操作系统提供了统一的抽象接口层，方便了可重用组件的积累，提高开发效率

操作系统其实是一群软件大牛们智慧的结晶，他们站在应用软件、底层驱动的开发角度，对很多常见的软件功能进行了封装、抽象，比如：信号量、事件通知、邮箱、环形缓冲区、单向链表/双向链表等等，这些功能拿来即用，对于开发者方便极了

还有一些操作系统，比如：Linux 和我们国产的 RT-Thread ，他们这些系统对碎片化的硬件，统一封装了一套标准的硬件操作接口，一般称为设备驱动框架。这样我们的应用软件工程师，就可以专攻应用的工作，再也不用怕更换硬件，又需要重复造轮子了。


软件生态：

生态的丰富带来了量变到质变的过程（自己玩->大家一起玩）

使用操作系统所带来的软件可模块化、重用性的提升，也使得我们自己在做软件开发时，可以封装一套基于操作系统、适合嵌入式的可重用组件，这些组件不仅可以用在自己的项目中，还能开源出来分享给更多有需要的嵌入式开发者，把软件的价值最大化。

个人感觉这是一件蛮有意义事情，我自己本身也是一名开源极客，也有在 GitHub 上开源一些嵌入式软件。说实话在做开源软件前，能够深入交流嵌入式软件的地方非常少，毕竟大家的代码不是芯片不一样，就是硬件不一样，你的代码给了他，也不一定能运行起来。但是自从用了操作系统后，软件的可重用性提高了，能够让更多的人很迅速的用起来我的开源软件，这个时候能够有更多的人可以一起交流，还接触到了很多的大牛们，甚至是国外的朋友。俗话说：水涨船高，我的能力也从此得到了快速的提升。所以总结下来，有一个能一起交流嵌入式软件圈子还是蛮重要的，自己闭门造车，可能都是在重复造轮子。

kinsno

方便分亨一下开源东西吗？ 方便让我看看你开源的GIT地址。。。

techbaby

大神的文章啊！

bryan_lia

是的，我们没有很好统一接口的时候，最常做的事情就是重复造轮子。其实如果只是业务层的特定情况，按照统一接口制作，也是可以实现不重复造轮子的情况。但是遇到换个芯片就得重新再来一次，这个不可避免。有个操作系统大神们提供的底层接口，只要保证功能差不多，就可以快速开发。不过，

bryan_lia

不过有一点还是要申明：
1.基于复杂性，这个工具化的框架，需要一定的学习基础才能好的掌握。
2.你要是真的移植完之后还有新问题，你就得好好挖掘里面隐含的一些差异了。这也是很费功夫的。

bryan_lia

以前做裸机最烦的就是重复造轮子，不过无论如何，所有轮子，从底层中层到上层都做了个遍，也就那样了。一个好的规划很重要。
而操作系统，更需要想明白，再做事，要不然麻烦一点也不少。

wuha

顶，大神写的不错。

qq335702318

一直担心RTOS带来的高级坑
比如优先级倒置  优先级死锁  堆栈不足  互斥  等问题
出现问题比裸机环境查起来更费劲
不过处理一些复杂裸机时显得好方便

flash3g

RTOS会用起来，那是相当爽的。
不过玩不好坑也好多，还不如状态机。

Excellence

hzpyl

一直用FLASH 几K的单片机，
电流还只能几uA，
所以，没有做过操作系统。

Doding

没有该不该用，只是需要不需要用，能不能用。
硬件资源有限时，想用现成的系统也用不起来，功能简单时，要系统也没什么用，如果说点个流水灯也非得要用系统，到也不是不行。
看到多处提Delay，就没细看，不管是裸机还是用系统，都要尽量避免阻塞延时。

farfar

想用操作系統，可憐的RAM根本養不起OS。

wye11083

hzpyl 发表于 2019-12-25 13:20
一直用FLASH 几K的单片机，
电流还只能几uA，
所以，没有做过操作系统。

哈哈，加个代码还得看看还剩几字节空间。。

wuguoyan

hzpyl 发表于 2019-12-25 13:20
一直用FLASH 几K的单片机，
电流还只能几uA，
所以，没有做过操作系统。

+1               

1874

加个变量都要数着RAM的空间还剩几个字节

xckhmf

还是要看具体应用的，对于一些负责度高的项目用RTOS是必要

qq78929709

其实楼主提到的裸机的诸多问题都是可以用一定的软件技巧来避免，当然接口肯定不会操作系统那么明了，使用起来会相对麻烦。但操作系统也不是十全十美，除了吃资源之外，还要多考虑很多裸机不需要考虑的问题。光是分配任务栈就是个力气活，不是很多人能做好。

不舍的六年

看到了文章里提了那么多Delay，不知道有没有真正理解裸机编程的思想。

lbhj310

言之无物

snowy

不舍的六年 发表于 2019-12-25 14:23
看到了文章里提了那么多Delay，不知道有没有真正理解裸机编程的思想。

是的祼机也可以用TIMER+回调来delay

stm32_bldc

这两年一直freertos，爽爆了

OOXX110

单价，抠字节的没办法了

我夏了夏天

如果系统功能比较复杂，对系统响应时间要求较高，使用 RTOS 还是很有必要的，RT-Thread 是一个不错的选择。如果开发的系统对资源要求极其严格，那恐怕操作系统很难跑的起来了

retention

不舍的六年 发表于 2019-12-25 14:23
看到了文章里提了那么多Delay，不知道有没有真正理解裸机编程的思想。

   同意。
作者是看郭天祥视频学习mcu的吧，我记得郭的程序就是到处都是delay阻塞的。

XA144F

我用不用，有我的考虑。你用不用，不关我的事。

huangqi412

总在提延时  这不是个好例子

xld826

1、你不会用裸机。
https://www.amobbs.com/forum.php ... C%E7%BB%8F%E9%AA%8C
2、IOT节点对成本敏感，能跑起RTT+各种软件包需要大RAM，钱。

RAMILE

那么问题来了
挖掘机去哪里学
rtthread怎么赢利

qd118118

裸机也有好处，很多时候也只是copy下即可，查起来也方便

qq335702318

qq78929709 发表于 2019-12-25 14:20
其实楼主提到的裸机的诸多问题都是可以用一定的软件技巧来避免，当然接口肯定不会操作系统那么明了，使用起 ...

好像uC/OS, FreeRTOS, RT-Thread都没有比较方便靠谱的方法
给出某个任务实际的栈占用量?

szxszx

没用RTOS，芯片资源有限，裸机程序也从来不用delay

laoyi

程序中大量使用delay我觉得是上大学第一课老师开始教的，包括现在的正点原子也是。我们实际项目delay100us都很心疼的

security

kinsno 发表于 2019-12-25 10:47
方便分亨一下开源东西吗？ 方便让我看看你开源的GIT地址。。。

作者现在是 RT-Thread 的技术总监，戳这里看看：https://github.com/armink

kinsno

security 发表于 2019-12-26 09:16
作者现在是 RT-Thread 的技术总监，戳这里看看：https://github.com/armink

朱天龙？
RTT？
以前用了2次全家桶，然后基本放弃这玩意了，现在只用NANO版本了。。。

kebaojun305

qq335702318 发表于 2019-12-25 19:51
好像uC/OS, FreeRTOS, RT-Thread都没有比较方便靠谱的方法
给出某个任务实际的栈占用量? ...

RTT  FinSH  可以方便的看到每个任务的栈 分配多少 最高占用多少。

Dew_maple

项目复杂度高、多人参与开发的话，建议还是用RTOS，开发便利性和模块化程度要远远超过裸奔或状态机

security

kinsno 发表于 2019-12-26 10:19
朱天龙？
RTT？
以前用了2次全家桶，然后基本放弃这玩意了，现在只用NANO版本了。。。

是的。

RT-Thread 现在就是全家桶、开箱即用，
所谓的：无生态，不 OS，面向 IoT 领域。

行业要是跟 IoT 不怎么搭边的话，对它不感兴趣，是正常的。

yangbo18416

1874 发表于 2019-12-25 14:04
加个变量都要数着RAM的空间还剩几个字节

哈哈，这事我很痛苦啊，扣空间，半天都难得扣几个byte出来