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年開發歷程 樂與苦）