RT-Thread-【12月】+我与rt_thread的“江湖恩怨”RT-Thread问答社区

【12月】+我与rt_thread的“江湖恩怨”

发布于 2020-12-12 23:42:50 浏览：993 订阅该版

[tocm]

大约在2016年下半年，在换找工作的时候，听到rt-thread（有的简称RTT,很容易理解成segger公司的jlink工具组件rtt view/client），当时去一个公司面试，前一个工程师要离就开给我简单介绍了一下，以前接触过ucosii/iii,但rt-thread是第一次听说，优雅的代码引的我惊鸿一瞥。

2018~2019，不断关注各种微操作系统，期间RTT在郑州举办过2次线下培训，都去了（甚至有的是请假，因为感觉时机难得），培训中间的动手操作环节，因为对env等不熟悉，跟着老师操作有的都没完成实验，感觉非常遗憾。19年RTT又推出了线上认证，但因工作繁忙准备不足，差一点就过了。

2020年初疫情期间，我在家里办公，又去搜RTT资料，惊奇发现官网有了很详细的文档，然后就如痴如迷的所有文档过了一遍，再去看它的内核代码，尤其是用C语言去实现C++的思想（设备对象）时深深折服，此时不再彷徨于究竟今后用啥微操作系统了，就它,RTT,没错了。

进入新公司，项目需要在单片机的多个串口同时实现多个modbuRTU主机，从机，还需要modbusTCP,这种情况下，以前自己写的解析协议栈和freemodbus不适合，网上搜到libmodbus可以支持，并且RTT支持以w5500,AT命令集，tcp/ip连接网络，所以就决定了在RTT上用W5500+Libmodbus的架构。但当时对RTT只是看了很多文档，ucos微操作系统使用过，拿一个新项目练手，现在看来怎么说都太疯狂。如果弄不好项目可能就黄了，自己也可能卷铺盖走人。但当时我的真实想法是，我一直在隔靴挠痒，在门外转悠，放又放不下，进又进不去，如果不逼自己一把，自己可能永远没机会项目中用上。RTT作为国产优秀的开源微操作系统的代表，我不能缺席落后。而且我发现其MSH，驱动编写等和linux很接近，我可以通过RTT进入linux世界大门。而不仅仅是一个PC端的体验者。

但回过头来看，这举动风险还是太大，万幸，自己的坚持加上RTT官方的服务态度和能力的提升让自己的项目越过一个个险滩安全着陆。但作为过来人，我对后面学习的网友衷心建议不要冒这么大的风险，在新公司，新项目，在对RTT还不太完全熟悉的情况下，不要贸然上马，因为在项目进度，结果负责等约束下风险太大，你完全可以拿你已经量产的产品，在没有时间进度要求的情况下，尝试去用RTT实现它，因为此时硬件已经保证无误，驱动都已现成弄好的，业务逻辑都已了然于胸，又没有时间要求和要你为结果负责，这样去应用RTT应该是最好的一种模式，等你弄好再和原来产品对比，达到或性能超过就是一大成功，这会给你以后项目独立应用RTT增添很大的信心。

RTT在使用过程中经过了三个阶段，keil裸机，keil+env,studio。因为样机也是首次开发，如果一开始就上系统，如果出问题你不知道是硬件问题还是驱动问题或是系统原因。所以你需要先按自己熟悉的方法开发好裸机驱动程序，验证了硬件电路没有问题，然后用在系统中用任务去调用，熟悉RTT下任务的开发特点，最后按RTT驱动开发的规范文档，修改驱动让它符合RTT系统的特点，尽管不一定那么规范，但至少大体上符合要求，能运行起来。最后在结合内核和IPC通讯适应完全的RTT开发模式。

在开发之初，很多网友会疑惑ENV和studio的取舍，ENV历史悠久，开发比较成熟，资料和了解的人比较多，编译的代码尺寸也比studio高，官方文档的资料很多都是以ENV为基础讲的;studio是个新生事物，还不成熟不完善，编译代码尺寸也稍大，但胜在它是现在RTT主推的，更加直观的组件软件包配置方便了许多。我的理解凡事厂家主推的都是符合发展趋势的，就如我们大多数开发stm32从寄存器开发，再到标准库，最后到HAL/LL库一样，尽管用户对新生事物有很大的惰性不愿迁移，特别是现有的特别经典，但拗不过趋势，特别是在如今，stm32在cubmx大获成功极大提高用户效率的情况下，昔日最执拗的那一部分人也开始慢慢改变。微软的WINXP-WIN7-WIN10是一样的历史发展过程。

搞定了取舍之后就是在studio下的开发了，我又没走寻常路，没有基于BSP开发，直接基于芯片模式开发。中间踩过很多坑，一度压力非常大，怀疑自己能否搞定这一切，但好在，我不是一个轻易放弃的人；RTT也在积极的改变。最终项目量产，RTT的改变也是有目共睹。我想这就是开源软件和开发者和谐共生，共进成长的魅力。下面就结合踩坑计具体讲下在这过程中我和RTT的“江湖恩怨”及“爱恨情仇”。

开始就懵逼：当我基于芯片建立工程安装说明文档一顿操作猛如虎之后，终端居然纹丝不动，一顿抓耳挠腮，当时studio刚推出用的人不多，大家都对ENV熟悉，为此我还专门建立ENV的BSP工程但ENV下没有问题，最后经过追踪发现，对于不常用型号的stm32芯片，且我用的是串口5，studio里面对串口IO的复用定义有误，对照芯片手册该正了这一点就正常了。

W5500驱动：可以说这是我项目中风险的最大变量。当初就是看到官方说明对W5500的支持，想必不会有坑，但现实是理想太丰满。刚开始就报错。后来屏蔽ops函数算是编译通过。

libmodbus是我当初选择RTT的关键，但在modbusTCP时缺遭受了很大的打击，原demo支持多客户端连接，但断开链接感觉很不正常，后来查询各种资料和询问人，将里面的关闭文件网络设备函数改成关闭端口就好了。

最胆颤心惊的一幕：产品开发好后就放在办公室内模拟运行调试。但测试人员发现，将W5500的设备终端和远程子站在一个局域网内不经过路由时就会报错，系统无法运行。经验证确实是这样，只有经过一层路由就没有问题。而我们的设备是用在地下隧道内，都是直接经过交换机没有路由。跟踪发现W5500在远程客户端进来创建socket时出错，刚建立socket就会非关闭状态直接返回。然后就一方面联系W5500官方，另一方面联系软件包作者，RTT官方。但W5500深圳和香港总部都说W5500肯定没有问题，已经有那么多设备在使用不可能有这个问题，而RTT他们没用过，不熟悉；软件包作者不能远程，不能电话，RTT的维护者也不方便建立类似环境来验证问题。为此我将三方人员聚集在一个群里以商讨解决这个问题，眼看项目就用施工安装了，却暴露出这个一个天大问题，如果解决不了，项目整个就泡汤了，这个后果我是无法承担的，早期开发不出来就算了，这已经和第三方商定好了施工日期了突遭变故，这怎么办？后来我自己发现创建socket失败后短延时可以降低失败频率但不能杜绝；最后RTT给出屏蔽RTT的检查网络连接部门代码的方案，暂时算是解决了这一问题。有惊无险的化解了该危机

月满则亏，花满则衰。因为不够完美所以才会有完善，才会有进步。记得有人说过，一个人最好的状态不是圆满，而是含苞未放之时，因为此时有无限之可能，在此过程中的积累将是以后最宝贵难忘的记忆。在与RTT共同成长过程中，自己的一些意见在RTT论坛和studio工具中得到体现，这让人有一种满满的参与感，自豪感也油然而生。

论坛推出认证专家，按擅长领域分类，提高论坛发帖响应速度：新手学新东西最容易从入门到放弃，究其原因就因为当碰到问题时如果没人指点卡在那儿，后面就没信心进行下去。刚开始我也是这样，碰到古怪的问题，群里发声会被淹没在汪洋的聊天信息里，github留下ISSUE很长时间没回应，论坛发帖也只是变成了问题帖。我们也理解，作为开源软件RTT没有那么多人手来服务大家，和付费技术服务自然不能相提并论，但是如果新学着的自信心和信任度受打击也不利于开源软件RTT的发展。所以后来通过渠道向RTT官方提议，既然RTT发展了这么多年，肯定有不少熟练应用和精通的牛人，是否可以将其组织起来，按擅长领域分类，让提问者的问题能和这些专家精准匹配，提高命中把度和服务效率。可喜的是，RTT在接到建议后行动迅速，在论坛快速推出了认证专家，在发帖提问页面可以邀请专家来回答问题，大家可以很明显体会到如今的问题帖子揭帖率有很大的提高。

studio中的JLINK远程TCP/IP调试支持功能：一个月前，我在开发电机过程中，考虑到调试的安全性，需要用到JLINK的远程调试功能，正版的JLINK都是支持该功能的，但出于成本考虑，大伙的JLINK都是淘宝上买的（正版的真买不起），那studio能否支持这个功能呢？然后就和studio开发人员沟通，当时经过施工远程指导配置，可以实现该功能。没想到今天在Studio的V2.0版本就惊喜的发现该功能已经完全体现出来了。

最后还有几点建议：

官网的软件包可以按用户进行收藏管理，用过的，对新增加感兴趣的，可以分类管理。因为同一功能的软件包有多个，自己用过觉得好的（不一定是星数多的）可以有些备注和感悟，并且有时候自己还需要适当“修改一下软件包”以用来避免一些错误和更好的适配。且随着软件包库的增多，没有自己的收藏管理，在汪洋的一个个软件包里面，不知道那些是重要的，好用的，值得关注的。

每个软件包的管理者提高对github的浏览速度，这个是对分类软件包问题的集中之地，可以说比论坛更容易分类查找相关问题，如果长期得不到回应的话，就让使用者和后来者对软件包质量失去信任，不利于软件包的有效利用。

推出或与Tracealyzer合作，让studio或RTT能使用该强大工具进行错误定位，任务瓶颈和优化分析。因为在大家学会内核/IPC通讯同步之后，经常要面临任务设计不合理协调不畅，严重影响系统的效率。在hardfault定位方面，虽然CmBacktrace可以简单定位一下范围，但是还是不直接，使用的难度和有效性没有Tracealyzer好，这么好的工具希望早一点能在RTT上看到，那将是大家的福音。

## 写在最后：

开源软件的发展和繁荣，中国国产优秀软件的崛起需要大家共同的努力，中国不缺乏梦想之人，也不缺实干家，国外人能做好的东西相信在勤奋踏实肯干的中国人面前也一样不是问题。只要我们群策群力，善于革自己的命，勇于学新东西，勇于改变，有一定能将RTT做成国产最优秀的微操作系统，一定能将RTT发扬光大！！！

最后希望大家关注我的博客和论坛位置，以后还会不断更新有关RTT相关的技术问题的文章，抛砖引玉，希望能与大家成为志同道合的朋友，一同成长！