RT-Thread 3.0发布之际，创始人首谈RT-Thread 设计理念

1. 源自"简单、唯美"的设计理念

诞生于2006年的RT-Thread，最初源于对当时小型RTOS现状的诸多不满。最令人印象深刻的是彼时不同RTOS混乱的命名风格--如果那个时候有一份类似Linux/Unix风格的小型RTOS，也许就没有现在的RT-Thread了。细想起来，正是这一想法成为了RT-Thread创作的一个重要契机。

长期浸润于开源社区，我早已经习惯了Linux/Unix的风格：编程时几乎都以小写命名、以下划线来连接不同的单词--直到现在，我依然认为只有这样的代码阅读起来才谈得上舒服--相信很多人会有类似的感受吧。真正开始动手后，RT-Thread试图遵循更多Linux/Unix优雅、明快的风格--从划分清模块开始，一点一点理清模块、梳理命名--力图保持"程序的简洁"和"脉络的清晰"：小到变量、函数，大到源文件、模块无一不遵守统一的风格。

只做一件事情，并把它做好，而不逾越雷池一步--Do one thing and do it well. 这也是人们常说的"简单、唯美"。这逐渐形成了RT-Thread的设计理念，RT-Thread要做一个精致而优雅的操作系统。

2. 从"0.3"到 "2.1.0"

2010.04.17 0.3.0版本

因为开源理念早就扎根于心，期待同类开发者们更多的分享、交流，所以很早的时候RT-Thread就以社区化、开放方式推进。下面的框图就是当时放于Goolge Code上发布的第一个版本：RT-Thread 0.3.0。后续由于Google Code关闭，转而放到github，持续到现在（国内放在是OSChina的码云上）。

图一：RT-Thread 0.3.0结构框图

0.3.0版是基础设施的搭建阶段：内核、文件系统、网络协议栈和命令行环境的雏形在这个时候已初具端倪。

2011.12.31 1.0.0 ～ 1.2.0版本

紧接着0.3.0版的发布，0.4.0版的开发几乎立即就开始了。当时我们基本保持着一个稳定版本，新特性完全冻结，以bug修正为主；另一个版本，以添加新功能，向着下一个方向推进的方式进行。通过这样的方式可以快速推进、迭代，同时也不失稳定性及后向的兼容性。在0.4.0版本经过数个版本迭代，成为正式版之际，我们宣布发布RT-Thread 1.0.0正式版本。1.0.0正式版本也意味着：RT-Thread不光具备一个嵌入式实时操作系统所必需的全部基本功能，它的稳定性也达到了商用级别。

随着RT-Thread支持的芯片和平台越来越多，如何有效组织工程变成了一个非常棘手的问题。大多数做法是使用Makefile，但对于不同的桌面开发平台，Makefile表现得并不那么友好（例如Windows平台），同时Makefile变化多样、晦涩难懂的语义也导致掌握它有一定门槛。这个时候使用Python语言实现的scons工具进入到我们的视野中来。以从服务开发者角度出发，最终基于scons搭构建工具，的RT-Thread构建系统不仅提供了Windows、Linux和MAC下统一的用户体验，同时也针对不同集成开发环境（IDE）按照配置情况，生成对应的工程文件，这样开发者可以选择最习惯，最顺手的集成开发环境。

应该说RT-Thread 1.x系列已经是一个相对成熟的嵌入式实时操作系统。在一个系统平台上开发代码，另外一个必须要考虑的是软件代码的可维护性。简单、松耦合的设计是软件代码可维护性的一方面，而另一方面是跨平台的软件代码可维护性。如果为了实现一样或相类似的功能，针对Linux、RTOS分别要维护两个版本，这个工作量几乎就差不多要翻倍了！。

在最初设计时，针对文件系统、网络协议栈，RT-Thread都希望用最标准、开放的方式提供API服务接口，甚至是RT-Thread也支持了完整的PThreads接口，使得POSIX 线程和RT-Thread 线程得以无缝结合，用户不再需要再为他的代码额外维护另外一个版本。

抽象外设驱动，形成简单、独立模块。一份BSP移植主要的工作是两个方面，芯片架构移植和外设支持。在RT-Thread逐步的演进过程中，发现当更换芯片时，大部分外设驱动有很大一部分代码是一样的。例如针对串口，基本上都会有一份软件上的环形缓冲区（Ring Buffer）。这个时候把这些公共的部分提取出来，抽象封装形成一份面向设备的驱动，而驱动底层则只需要简单地实现芯片具体相关的操作接口（ops）就可以了。Device Drivers组件就是这样逐渐演变出来的，到目前已经包括串口，网口，IIC，SPI，RTC，WDT，Audio，USB等一系列的抽象设备模型，为方便支持不同的芯片、板卡节省下大量的时间。

2015.02.02 2.0.0 ～ 2.1.0版本

在嵌入式市场中，实时Linux是很早的一支。但因为Linux天生架构的问题，要想获得高实时性并没那么容易，或者说Linux本身这套架构并不适合高实时性应用。另外市场上多核处理器（SMP对称处