rtthread源码

1. rt-thread是否是免费的

RT-Thread实时操作系统遵循GPLv2+许可证，实时操作系统内核及所有开源组件可以免费在商业产品中使用，不需要公布应用程序源码，没有潜在商业风险。
放心大胆的用吧 我觉得比freertos还要好,又是国产的.

2. RT-Thread RTOS的RT-Thread / uCOS / FreeRTOS 简单比较

1 、任务管理及调度：
RT-Thread - 32/256可选优先级抢占式调度，线程数不限，相同优先级线程时间片轮转调度；支持动态创建/销毁线程。
uCOS - 256优先级抢占式调度，不允许相同优先级任务存在
2、 同步/通信机制：
RT-Thread - 支持semaphore, mutex, mailbox, message queue, event。mailbox可存储多条消息，任务等待可按优先级进行排队。
uCOS -semaphore,mutex, mailbox, message queue, event。mailbox只能存放1条消息
3、内存管理：
RT-Thread -固定分区内存管理，小内存系统动态内存管理，大内存系统SLAB内存管理
uCOS - 固定大小内存块管理
4、定时器：
RT-Thread - 挂接到系统OS定时器的硬定时器
uCOS - 只能使用OSTimeDly进行时间间隔处理
5、中断嵌套：
RT-Thread - 允许
uCOS - 允许
6、源码许可证：
RT-Thread - 遵循GPLv2+许可证。可用于商业产品（只需要注明使用了RT-Thread）
uCOS - 商业收费

3. RT-Thread workqueue 详解

在学习之前可以先去了解一下工作队列的使用场景： 工作队列 ( workqueue ) 。

简而言之，工作队列就是将一些工作任务的执行延迟，交由内核线程异步执行。

最简单的使用方式就是开启 RT-Thread 的系统工作线程（System workqueue），而我们往系统工作线程里提交工作项（work item）即可。

RT-Thread 其实给我们提供了一个系统工作线程了，但很少有人知道。配置选项路径如下图所示：

依次选中上述这些选项，就能够开启系统工作队列了。而且还可以看到工作队列线程的栈大小默认为 2048，优先级为 23 。

这样系统在初始化的时候就创建了系统工作队列了，名字叫作 sys_work ，在终端输入 ps 能够看到该线程。

如何向系统工作线程里添加工作项呢？

rt_work_submit() 用于向系统工作队列添加工作项， rt_work_cancel() 用于从系统工作队列中取消某一个工作项。

当然，在提交工作项时，需要初始化该工作项，绑定相应的回调函数和用户指针，接口如下：

这样，我们就可以随时随地地提交工作任务执行了，极大地方便了程序的组织。

用一个小例程测试一下：

在 qemu 项目里的 main.c 里输入：

然后执行就能看到下述效果，与工作项绑定的任务被异步执行了，而且工作项 1 延迟了 2 个 tick 才执行。

rt_workqueue 的接口有很多，我们只需要关注常用的即可。

首先使用 rt_workqueue_create() 创建一个工作队列，然后使用 rt_workqueue_submit_work() 提交工作项，使用 rt_workqueue_cancel_work() 取消工作项，当然还可以使用 rt_workqueue_destroy() 销毁一个工作队列。其他的接口有兴趣的可以了解，但常用的就是上面这四种。

这里提交任务与上述使用系统工作队列的唯一不同之处就是我们需要手动指定工作队列，其他的都是一模一样的。

用一个小例程测试一下：

在 qemu 项目里的 main.c 里输入：

然后执行就能看到下述效果，与工作项绑定的任务被异步执行了，而且工作项 1 延迟了 2 个 tick 才执行。

关于实现部分我这里不介绍具体细节，做了一些动画给大家展示一下内部过程

工作队列里面有一个线程(workthread)，这个线程的任务就是不断地从挂载链表(worklist)里提取工作项执行，若没有则休眠。

然后提交工作项时，若延迟时间 time 大于 0，则启动该工作项的定时器，定时结束后再加入挂载链表(worklist)。

若提交工作项时延迟实际等于 0，则直接将该工作项挂加入到挂载链表(worklist)。

当然，工作项的定时器超时后，会自动将该工作项加入到挂载链表(worklist)。

4. 有人移植过RT Thread 上的那个modbus主站程序么

1、目前项目已经在Github中开源
2、主机的相关的框架已经修改完成，初始化、配置Modbus主机相关接口与原有从机接口基本相同；

3、移植主机相关硬件配置与原有从机方式一致，需要修改FreeModbus源码中port文件夹中后缀带_m相关文件；

4、Modbus主机请求主机请求功能目前实现了所有与保持寄存器、输入寄存器、线圈及离散输入相关的功能，并测试通过

5、目前的Modbus主机请求功能是异步模式，后期考虑方便上层调用，可以同时给上层提供同步模式的控制方法；

6、主机的异常处理任务还未添加，只留了接口，后期考虑给上层提供回调接口，相关异常功能上层也能自动做处理；

7、目前最新代码同时支持Modbus主机及Modbus从机两种模式，两者互不干涉，用户可以在/FreeModbus/modbus/mbconfig.h中自行裁剪。

5. rt_thread编程指南里讲解C 语言风格的面向对象编程：多态 的一个例子 求大神从头到尾详细解释下这个程序

1.该函数是一种宏定义，一般用于RTT内核代码。
2.多态指一个对象同时具有多种形式，一般可以通过定义子类重写父类方法，然后用父类引用指向子类对象来实现。
3.至于self->vfunc(self, a); 就是调用对象本身的虚拟函数。。。还要怎么解释。。
4.标识符定义的一种，你可以从头看一遍书了。
5.网络讲的比我清楚。

6. 如何移植RT-thread官方的系统源码到STM32F10x特定的MCU平台中

RT-thread官方源码1.0.1的bsp目录中已经包含了STM32F10x平台的移植好的源码，
但却是以STM32F103ZE为平台构建的。如果需要移植到其它STM的MCU上，需要做以下几步：

1.解压官网的1.0.1源码；

2.修改晶振（官网的默认使用8M的外部晶振，我的板子是12M的)：
第一步，打开stm32f10x.h，将
#define HSE_VALUE ((uint32_t)8000000) /*!< Value of the External oscillator in Hz */
修改为：
#define HSE_VALUE ((uint32_t)12000000) /*!< Value of the External oscillator in Hz */
第二步，打开system_stm32f10x.c，修改PLL参数，将
/* PLL configuration: PLLCLK = HSE * 9 = 72 MHz */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE |
RCC_CFGR_PLLMULL));
RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL9);
修改为：
/* PLL configuration: PLLCLK = HSE * 6 = 72 MHz */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLXTPRE |
RCC_CFGR_PLLMULL));
RCC->CFGR |= (uint32_t)(RCC_CFGR_PLLSRC_HSE | RCC_CFGR_PLLMULL6);
第三步，打开你已经建立的STM32工程，选择Projects-〉Options for target ***，
找到Target标签，外接的晶振默认还是8MHz，将外接的晶振参数修改为12MHz.
3.修改board.h里的SRAM大小（官方的默认是64K）：
#define STM32_SRAM_SIZE 20
#define STM32_SRAM_END (0x20000000 + STM32_SRAM_SIZE * 1024)
4.修改led引脚；打开led.c文件：
#else
#define led1_rcc RCC_APB2Periph_GPIOE
#define led1_gpio GPIOE
#define led1_pin (GPIO_Pin_2)
#define led2_rcc RCC_APB2Periph_GPIOE
#define led2_gpio GPIOE
#define led2_pin (GPIO_Pin_3)
5.烧写运行，就能看到led闪烁了;
如果想进一步裁剪官方系统源码，可以参考rt-thread裁剪示例 位于wiki网络的->RT-Thread组件使用->其它。

7. RT-Thread RTOS的RT-Thread 开发者自述

1、诞生
一切东西还得从头谈起。RT-Thread RTOS，Kernel部分完成于2006年上半年，其IPC部分甚至是年中时才具备相应的雏形。最开始时是因为要为朋友做一个小型的手持设备，而我本人起初又是另一国内老牌RTOS：DOOLOO RTOS开发人员，但这个团队在2005年底已经解散。但朋友的系统要上，用ucos吗，一不熟悉，二看不上。答应朋友的事，总得有解决方法吧，即使是原来的DOOLOO RTOS，因为其仿VxWorks结构，导致它的核心太大，包括太多不必要的东西（一套完整的libc库），这些方案都否决了。怎么办？当时朋友那边也不算太急，先自己写一套内核吧。这个就是源头！（后来虽然朋友的项目夭折了，但这套OS则保留下来了，并开源了，万幸）当然RT-Thread和原来的DOOLOO RTOS差别还是很大的。DOOLOO RTOS是一种类VxWorks风格的，而RT-Thread则是一种类NucluesPlus风格的，小型、实时、可剪裁。这三个方面RT-Thread可以骄傲的说做得比DOOLOO RTOS都要好很多，小型：RT-Thread核心能够小到4K ROM，1K RAM；实时：线程调度核心是完全bitmap方式，计算时间是完全固定的；可剪裁性，配置文件rtconfig.h包含多种选项，对Kernel细节进行精细调整，对各种组件（文件系统，使用EFSL、ELM FatFs；网络协议栈，finsh shell）进行可选配置。2、艰难的发展期在第一个公开板发布后（0.1），RT-Thread意识到了一个问题，光有核心不行。别人如何使用：虽然采用了doxygen风格的注释，并自动产生相应的API文档，但能够使用的人寥寥，有这个功底的人不见得认可你的系统，没相应功底的人也玩不转你的系统。所以下一个系列，考虑如何让系统能够支持更多的平台。首选ARM，为什么？应为ARM正处于发展的前期，使用的人也广泛，而RT-Thread第一个支持的平台就是s3c4510，这个是lumit开源项目赠送的平台。在其后，支持了包括s3c44b0，AT91SAM7S64，AT91SAM7X256，s3c2410，AT91SAM9200，coldfire，x86等一系列平台，编译器统一使用GCC，这个时期无疑是最艰难的时期（真的艰难吗？呵呵，但肯定是迷茫的），这个就是0.2.0、0.2.1、0.2.3、0.2.4版本等，不同的版本支持不同的平台。猜猜我这段时间是干什么工作的？不知道大家对这个领域是否熟悉，手机2G，3G协议栈开发。每天都和协议栈打交道，而且最痛苦的是上千页的25.331 RRC协议，都是英文的，所以RT-Thread算做是工作之外的苦中作乐吧。而也正是这个时候，shaolin同学出现了，帮助完成了RT-Thread/x86的移植，他当时还是学生。这其中还有一件郁闷的事，当时RT-Thread团队还有几个人，只不过主要是shaolin和我。当0.2.3发布时，我建议开始微内核的道路，嗯，可能很多人还比较困惑，RT-Thread后面跟着的为什么是“启动下一代RTOS演化”，当时就是因它而感慨：把微内核引入进来，把内核态和用户态分开来，并且建立一个类似于L4的微内核。当然最重要的是，其中有一个强实时核心。而且L4实际上是把页表操作放到内核之外的，如果内核是一个强实时内核将对整个系统的实时性提升很大，而因为微内核的缘故，也能够运行linux的应用程序，并且当时RT-Thread也提出了一种，线程即IPC的概念。。。只是，最后的提案被大家否决了。团队开始有数人，只是能够坚持的没几个。3、一年增加0.0.1本人很早就接触了Linux，算是国内资深的Linux接触者（早期也算一个Linux开发人员吧），KDE 1.0几乎是看着发展起来的（大家有谁用过RedHat 5.1？）。个人算是很多方面有一些自由软件的习惯：软件的版本号是非常重要的一个标志，宁愿增加一个细微的版本号也不轻易的增加一个大的版本号，因为大的版本号是需要对用户负责的。1.0版本更代表了系统的稳定性，健全性。例如mplayer到1.0版本就经历众多小版本，0.99的beta版本亦无数。RT-Thread也把这点体现得淋漓尽致，0.2.2到0.2.3一个版本的增加，整整花了一年多的时间。但这个小版本号的增加，却带来了开源社区嵌入式环境中最完善的TCP/IP协议栈：LwIP。当然，开始时并不算稳定。在这几个版本中，RT-Thread也终于从迷茫中走出来，RT-Thread需要自己的特色，一个单独的RTOS Kernel没太大的用处，因为你并没有上层应用代码的积累，并且一些基础组件也非常重要，有这些基础组件基本上意味着，在这个平台上写代码，这些代码就是你的，甚至是你哪天也可以把它放到另外一个硬件平台上运行。同样，0.2到0.3版本号的变更，花费的时间会更长^-^ 版本号的长短，是和计划的feature实现是密切相关的，没到设定的目标如何可能进行发布呢？4、Cortex-M3的变革RT-Thread的变革因为Cortex-M3而来，因为ST的STM32使用的人太广了，当然还有非常重要的一点。RT-Thread已经开始支持Keil MDK，armcc了。GNU GCC确实好，并且也由衷的推崇它，使用它，只是调试确实麻烦，阻碍了更多人使用它（ARM平台上）。当RT-Thread + Cortex-M3 + Keil MDK碰撞在一起的时候，火花因它而生，越来越多人使用RT-Thread了，当然这和RT-Thread厚积薄发是离不开的，因为这个时候，RT-Thread已经有一个稳定的内核，shell方式的调试利器finsh，DFS虚拟设备文件系统，以及LwIP协议栈。而RT-Thread/GUI则在密集的移植到CM3上，RT-Thread/GUI成型于2008年底，但为了Cortex-M3分支，这个组件停下来很多，但这种停留是值得的。另外就是特别感谢UET赠送的STM32开发板了，RT-Thread/STM32的分支都是在UET赠送的STM32开发板上验证的。5、RT-Thread为什么是对象化的设计方法可能这个话题太偏技术化了，说说其他，呵呵。面向对象编程有它的好处，例如继承。可以让具备相同父类的子类共享使用父类的方法，基本可以说是不用写代码就凭空多出了很多函数，何乐而不为呢。另外，对象的好处在于封装。当一个对象封装好了以后，并测试完成后，基本上就代表这个类是健全的，从这个类派生的子类不需要过多考虑父类的不稳定性。这里着重提提另外一个人，我工作后的第三年，曾向当时的同事也是好友，L.Huray学习面向对象的实时设计方法：Octpus II。深刻体会到了面向对象设计的好处（需求分析，体系结构设计，子系统分析，子系统设计，测试，实时性分析），但鉴于嵌入式系统中C++的不确定性，所以个人更偏向于使用C来实现。所以，L.Huray算是我的老师了，一直希望能够有时间把他老人家的思想更进一步的发扬光大，希望以后有这个机会。（Octpus I最初起源于Nokia，然后由M.Award, L.Huray发展成Octpus II，现在几乎见不到踪影了，唉）。
（作者原文：实时线程操作系统（RT-Thread）4年开发历程 乐与苦）