一个十余年历史的国产RTOS，从RT-Thread中我们能学到什么？

柴胡，目前在九安医疗从事物联网智能设备的开发和单片机及嵌入式驱动的开发工作，是RT-Thread和嵌入式技术爱好者。

本文将为大家简要介绍一下笔者使用和学习RT-Thread过程中的体会和感悟，希望能帮助初识RT-Thread的人建立一个初步的印象，避免产生入宝山而空回的遗憾。笔者水平有限，目前也正在学习和使用RT-Thread的过程中，希望本文的拙见能抛砖引玉，如有纰漏，还请不吝赐教。

现在是一个快节奏的时代，技术领域也是如此。近些年，IoT备受资本青睐，各种新技术新方案层出不穷，质量也参差不齐，这边唱罢那边登台，以至于有些技术还未被人熟知，就被淹没在长河中了。客观的说，RTOS领域玩家众多，仅笔者短短的从业时间，国产RTOS就听闻了五、六款之多。

RT-Thread作为一个有十余年历史的国产RTOS，经历了长时间的考验和用户的青睐，目前发展趋势蒸蒸日上，也即将发布RT-Thread 3.0，其中必然有值得我们思考和学习的地方，我们也可以从中汲取到不少宝贵的经验。

软件工程管理

软件工程管理对于软件研发是十分重要的，甚至可以说是开发过程的基石。公司中有高水平的嵌入式软件程序员，也有刚入职的实习生，水平难免参差不齐，当共同协作开发一个项目时，如何彼此协调也是一个难题。

时至今日，很多公司仍然在使用落后的代码管理方式。有些甚至使用把代码压缩成一个个的压缩包来做版本管理。同事之间的协作依靠互相发送文件，每次接收到同事的新文件首先要花半天时间解决编译error，甚至还要在本地对同事的代码进行修改，这样，软件基本处在半失控的状态，某次改动产生问题，就要从浩瀚的压缩包海洋里挑选一个，进行版本回退。在开发一个大项目的时候，这种情况下甚至会出现人数越多，开发难度和周期越大的情况。

而RT-Thread，提供了一个教科书级的范例。RT-Thread由13000多个文件构成，支持各类设备和芯片近70款，从代码量和组织方式上来说，是一个相当庞大的软件工程。在近十年的时间里，至少有将近100个开发者参与到了RT-Thread的开发中，使得RT-Thread稳步迭代，而这也是有一定的维护难度的。RT-Thread将代码部署在Github上，并在此基础上使用了Travis CI进行自动化编译测试，使得开发者可以有条不紊的进行迭代开发，并将自己的成果提交至master分支，在提交代码的第一时间通过Travis CI进行自动化编译测试，使得一些无法编译通过的问题，在第一时间就被发现。

RT-Thread使用scons自动化代码构建工具。初识RT-Thread，很难想象RT-Thread通过一个代码仓库，对近70个芯片的IAR、MDK和GCC的工程和工具链提供支持。RT-Thread使用了scons，使得只要敲几行指令，就可以生成所需环境和工具链的对应的工程。也就是说，对于大多数芯片，所谓移植RT-Thread，只需要几个scons指令进行自动化构建。我相信对于大多数中小公司的软件项目，无论从规模还是参与人数都没有RT-Thread这么庞大，维护难度也远小于RT-Thread。但尽管如此，工程维护也是软件工程管理的老大难问题，无疑，从RT-Thread中，我们可以借鉴不少经验。

代码风格与技术

RT-Thread的代码风格是十分优秀的。在工作中，很多时候嵌入式软件工程师尤其是单片机软件工程师使用的芯片资源相对比较匮乏，RAM和ROM也略显局促，节省资源也成了优先级比较高的事情，而这也成了许多工程师代码不规范的借口。鲁棒性、模块化、可拓展、高内聚、低耦合，这种高大上的名词总是不绝于耳，相信大家也在各种场景下听过不少次。可抛去这些高大上的名词，到底什么才是优秀的代码呢？

RT-Thread虽然没有强调过这些高大上的名词，但是他毫无疑问用代码对这些名词进行了解释。RT-Thread的代码风格是类Linux/Unix的代码风格。这种风格不仅仅体现在函数、变量的命名规范，而是深入到了RT-Thread的核心。例如，RT-Thread实现了一个设备驱动框架，将设备类型分为了字符设备、块设备、网络接口设备、内存设备、CAN设备、RTC设备、声音设备、图形设备、I2C总线设备等等等等。初始化时通过字符串（用户可自定义的一个易于记忆的名称）与设备驱动绑定，并将驱动注册到内核，使用时只需调用一个字符串，即可匹配到该设备，无需通过各种头文件包含和二次封装，即可实现隔离和解耦。

RT-Thread提供了Finsh和msh组件，这是非常有特色组件，可以在调试和开发中与系统内核进行便捷的交互，使用十分方便。如何在资源紧缺的嵌入式软件开发中，写出优秀的代码，RT-Thread十分值得我们思考和学