前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >该不该用RTOS?

该不该用RTOS?

作者头像
MCU起航
发布2022-03-31 20:24:35
1.9K0
发布2022-03-31 20:24:35
举报
文章被收录于专栏:单片机爱好者

RTOS:Real Time Operating System,实时操作系统。

一些初学者,以及刚工作不久的工程师都有这样的疑惑,今天就来分享一下这个话题:该不该用RTOS?

回顾裸机时代

刚开始学单片机,基本都是从裸机开始,经典的“项目”就是流水灯,也是你学习单片机的开始。但是随着学习的不断深入,裸机所暴露的问题就越来越多,这里我给大家总结下吧:

1、并发性:程序并发工作效率低

在写裸机软件时,不可避免的在主程序中会有一个超级大的 while(1) 循环,这里面几乎包含整个项目的所有业务逻辑。

因为每个业务逻辑里面基本都会有 delay 这样的循环等待函数,这样导致了所有的业务逻辑几乎都是串行起来工作的。

这个时候 CPU 就会有很多时间都浪费在了延时函数里,一直在空转,导致软件的并发效率非常差。

2、模块化:高内聚、低耦合的原则

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

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

举一个非常贴切的例子,在一些使用看门狗的项目中,如果使用 delay 延时函数,那得注意点,万一延时过长,主函数来不及喂狗,看门狗就被触发了。

最后会产生这样一种感觉,一个简简单单的 delay 还得考虑喂狗功能,裸机开发时操的心太多了,自然无法应用在大型项目中。

3、生态:很多高级软件组件,必须依赖于操作系统来实现

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

还有一些软件无法运行在裸机上,比如:乐鑫、Realtek、 ti 和 联发科 提供的 WIFi SOC SDK ,一些蓝牙 SOC 的 SDK 也都是只支持操作系统。

所以,如果你不了解、不会使用操作系统,这些芯片也就玩不转了。

4、实时性:功能复杂的情况下,实时性无法保证

软件的实时性在一些领域会有一定的要求,软件的每个步骤必须在指定的时间被触发。

工控领域就是最常见到的场景,如果实时性无法保证,机械设备可能就无法按照指定时序要求去动作,以至于发生机械事故,甚至会威胁到人的生命。

回过来接着看裸机软件,如果软件变得庞大以后,可以想象到,主程序中那么大的一个 while(1) 循环,代码耦合严重,到处都是 delay 延时,要保证实时性几乎是不可能的。

5、可重用性:软件可重用性差,总是重复造轮子

可重用性与模块化程度有直接的关系。相信大家每个人在工作中都不想做很多重复性的工作,同样在写代码时,也想着尽可能少写一些功能相似的代码。

但在这个嵌入式碎片化极其严重的时代,各式各样的芯片,想要让同样的代码,在裸机环境下同时适配不同的硬件,难度非常大。这样也就导致了裸机的代码会过多的依赖于底层硬件,重复造轮子的过程也就不可避免。

操作系统带来的优势

第一次接触操作系统,是在读大学的时候,那时 STM32 已经流行起来了,这么强大的单片机,有很多人都在上面跑操作系统,我也跟着移植了 ucos ,在上面还跑了 ucgui ,这个时候写应用完全是一种全新的体验。

后面做项目,我基本都都会用到RTOS,除非一些特殊的情况。

用了这面年RTOS,也跟大家也聊一聊操作系统的优势:

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

1、模块化

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

2、并发性

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

3、实时性

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

4、开发效率

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

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

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

5、软件生态

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

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

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

常见RTOS优势对比

μC/OSFreeRTOS、RT-Thread,选择这三款 OS 的原因是,它们的年限都比较长了,在市面上都蛮有知名度,用过的人比较多,更有说服力。

1、基本功能、性能

各家 RTOS 差异很小,可比性并不是很大

2、易用性/可读性

这块 FreeRTOS 应该说是最差,奇葩的匈牙利命名法,代码实现用了很多宏,可读性非常差。

μC/OS 可读性还可以,注释也很全。这块做的比较好的是 RT-Thread ,它是类 Linux 的代码风格,面向对象的设计模式,代码简洁易懂。在保证了体积(最小 ROM:3K RAM:1.5K)的同时,还借鉴了 Linux 的设备驱动框架、虚拟文件系统、Shell 等功能,设计更加优雅。

3、 组件丰富性

RT-Thread 比起传统 UCOS、FreeRTOS 不仅仅在基础功能上多而全,多达 50 个以上的可重用软件组件,还有很多物联网组件,对于物联网产品几乎做到开箱即用。RT-Thread 还可以运行 Python、JavaScript、Lua 这些高级语言的脚本,进一步降低开发难度。

4、 开发资料

这块 μC/OS 做的最好,还有配套相关的书籍,FreeRTOS、RT-Thread 属于后起之秀,网上也有很多相关资料。不过现在 RT-Thread 对这块非常重视,最直观的可以看到官网上的应用笔记越来越多了,还有一些配套教学视频。

5、版权

μC/OS 、FreeRTOS 和 RT-Thread 都是使用了开源协议,版权都很宽松,可以参看:µC/OS、FreeRTOS、RT-Thread、ThreadX开源协议

6、 社区生态

这三款 RTOS 的社区都比较活跃,现在可以感觉到 ucos 慢慢的用的人越来越少了,RT-Thread 和 FreeRTOS 用的人都在增多。RT-Thread 也是开发者最多的国产 RTOS,并且还拥有国内最大的嵌入式开源软件社区。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-02-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 单片机爱好者 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
对象存储
对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档