说起接触 rt-thread 系统来,也算是慌乱之中的邂逅。从今年 5 月份到这个月底刚好半年,半年前对它是一无所知。我们有一个着急项目,要求使用单片机开发带触屏界面的,对于我这种多年不使用单片机,被 linux “腐蚀”的不爱学习了。突然要换一个陌生的环境,着实让我慌乱地一批。
经过开会商议,大家觉得之前有个项目使用的芯片可以胜任,可以先拿那个项目的硬件搭建基础环境。而那个项目恰恰使用的 rt-thread 系统。这是我第一次接触 rt-thread。
可能因为多年前有过 uCOS-II 系统的底子,在熟悉 rt-thread 的初期没花费多少时间就先找到了内核调度、sysTick 心跳、上下文切换等几个核心的代码实现。我认为,这些部分就像是一部机器的引擎,一个人的心脏。
多任务系统,不可避免地要使用多个线程完成不同功能任务。线程间互斥、同步、通信这些概念性的东西换到任何多任务系统下都一样,也是必不可少的。说到这里,不得不提两个概念 —— “临界区”和“临界资源”。我发现很少有人提到这俩概念,但是多任务系统里,这两个概念很重要,涉及到系统设计是否稳定安全。这一块儿因为有 linux 上多线程使用的经验,不难理解。
一个复杂的,功能繁多的系统,多线程配合上定时器、信号量、互斥锁、邮箱、事件集、消息队列等同步和消息机制一起使用,就像如虎添翼一般。有了它们,线程可以更专注自己的功能实现,线程之间功能实现解耦,同时保证系统稳定性和数据安全。
这也是 rt-thread 的一个亮点,当初看到 rt-thread 的这个特性的时候,感觉眼前一亮了。在这个框架下,我几乎可以继续像在 linux 系统里那样读写文件、访问外设。
open close read write control 函数簇,几乎一样的 api ,一样的操作逻辑。刚开始使用 STM32F4 系列芯片的时候,外设驱动很完善。想添加任何外设,拿来即用。
也正是这个,rt-thread 让我痴迷,勾起了我的好奇心,想深入全面的了解一下 rt-thread ,一探究竟 rt-thread 是怎么实现各种外设接口统一的。
支持到 rt-thread 上的第三方包也是数不胜数。从文件系统,到网络协议栈,还有 py 解释器、xml json 等解析器......
几乎嵌入式平台上可以能用到的组件包都可以找到,这个极大地方便了初学者。
熟练使用才是我们研究一个新系统的第一步,挖掘它的实现原理、工作性能以及潜在的漏洞,反馈到我们的项目中,才能写出高质量、高性能、最优化的代码。
经过大量阅读源代码,一方面,了解了各种内核对象 —— 线程、定时器、信号量、互斥锁...... 等实现工作机制;另一方面,也发现了很多值得再讨论的地方。例如:
RT_ETIMEOUT
超时,有时候 return RT_ETIMEOUT;
,有时候 return -RT_ETIMEOUT;
。struct rt_thread::error
(c++ 写法,仅为说明问题)。除了 RT_ETIMEOUT
这一种错误状态,其它错误就没有扩展空间了?个人愚见,任何阻塞操作都应该处理 RT_EINTR
。今年,无疑是 rt-thread 大爆发的一年。有大量的国产芯片 bsp 被添加到仓库,支持更多的国产芯片。这个时候加入 rt-thread 大军也不算落伍。如果可以,在享受到 rt-thread 带给我们的便利之外,希望我也能尽自己的一点儿绵薄之力,帮助完善 rt-thread。
愿更多的人加入进来,一起助力 rt-thread 尽善尽美。
看了文章,果然我猜的没错,大佬是之前用过ucos的!
这里有两个ucos的兼容层,分别是ucos-ii和ucos-iii的,可以让你之前的ucos代码无缝在rt-thread上跑,求star!
https://github.com/mysterywolf/RT-Thread-wrapper-of-uCOS-II
https://github.com/mysterywolf/RT-Thread-wrapper-of-uCOS-III
@mysterywolf 真是费心了,有ucos项目改造升级了一定用得上。先 star 一波
大佬,就是牛b。过来粉一波、