RT-ThreadRTOS是一款來自中國的開源實時操作系統，由RT-Thread工作室的專業開發人員開發、維護。
起初RT-Thread是一個實時的核心(全搶占優先權調度，調度器時間複雜度O(1))，但在發展過程中，RT-Thread實時作業系統得到了來自全國嵌入式開發工程師的鼎力支持，為RT-Thread添磚加瓦，現在它不僅僅是一款高效、穩定的實時核心，也是一套面向嵌入式系統的軟體平台，覆蓋了全搶占的實時作業系統核心，小巧而與底層具體實現無關的檔案系統，輕型的TCP/IP協定棧以及輕型的多視窗多執行緒圖形用戶界面。
RT-Thread是一個平台，您可以把您的創意匯聚在一起，小平台大社區，RT-Thread的開發人員就在您的身邊。
基本介紹
- 中文名：RT-Thread RTOS
- 性質：開源實時作業系統
- 開發者：RT-Thread工作室
- 時間：2006年上半年
開發者自述,簡單比較,版本發布,背景成長,
開發者自述
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 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年開發歷程 樂與苦）
簡單比較
1 、任務管理及調度：
uCOS - 256優先權搶占式調度，不允許相同優先權任務存在
2、 同步/通信機制：
uCOS -semaphore,mutex, mailbox, message queue, event。mailbox只能存放1條訊息
3、記憶體管理：
uCOS - 固定大小記憶體塊管理
4、定時器：
RT-Thread - 掛接到系統OS定時器的硬定時器
uCOS - 只能使用OSTimeDly進行時間間隔處理
5、中斷嵌套：
RT-Thread - 允許
uCOS - 允許
6、源碼許可證：
RT-Thread - 遵循GPLv2+許可證。可用於商業產品（只需要註明使用了RT-Thread）
uCOS - 商業收費
版本發布
發布時間：11/04/2014
RT-Thread 2.0.0發布候選版本（release candidate），同時發布v1.2.3穩定版本
隨著RT-Thread功能越來越多，如何發布版本也成為一件頭疼的事情，因為需要仔細對比最近三個月來的修改記錄。這次的發布距離上一次beta版本依然是三個月的時間，但按照發布計畫已然推遲了一個月進行發布。
在這三個月中，開源社區上也發生了很多有趣的事情：
- RT-Thread做為一個開源組織參與的CSDN開源夏令營結出了豐碩的果實：
- 由hduffddybz參與的IPv6協定棧移植（最新版本的lwIP-head版本移植）在這次發布中已經包括進來，從而能夠在使用RT-Thread的小型設備上實現TCP/IP v4/v6雙棧的支持；
- 由wzyy2參與的GDB stub實現，也完美的支持BeagleBoneBlack開發板和STM32F4平台；
當前智慧型化設備是一個備受關注的領域，針對這一領域的特點，RT-Thread也相應的做出了積極的回響，所以這個版本開始加入sensor的套用框架（APP/算法 <--> sensor framework <--> RT-Thread device driver <--> 硬體外設）。希望在小型化的RT-Thread作業系統基礎上融合智慧型化相關的技術，讓RT-Thread成為這方面可選的OS系統之一。RT-Thread作業系統的sensor框架也嘗試新的實現方式，即採用C++的方式來實現（當然也會考慮C方面的兼容，無疑C++的面向對象特性會更好，所以最終選擇了C++），在這個基礎上也可能融合其他的一些生態技術，例如ARM mbed平台上的一些社區組件技術。所以這個發布版本中既包括sensor框架，也包括了C++底層的一些基礎支撐。
這個版本是RT-Thread 2.0.0系列正式版本的候選版本，正式版本預計會在年底正式發布，距離正式版本還會加入更完善的一些支撐（例如各種感測器驅動）。也計畫2014年11月22日，在上海浦東舉行RT-Thread嵌入式系統沙龍活動，歡迎大家關注並參與進行RT-Thread方方面面的技術交流。具體時間、地點再另行通知，歡迎關注 @RT-Thread 微博獲得最新的訊息。
背景成長
記錄下RT-Thread0.3.x的成長
先解釋幾個常見問題：
1. RT-Thread從哪裡而來？
RT-Thread RTOS，Kernel部分完成於2006年上半年，創始人源於國內一老牌RTOS：DOOLOO RTOS，甚至是BSP 一些結構都源於DOOLOO RTOS。但與DOOLOO RTOS明顯不同的是，Kernel完全重新編寫，突出的是實時性和小而靈活，並且引入了核心 的對象模型以摒棄核心對象的與動態記憶體管理器無關化。
2. RT-Thread用於商業產品&工程，著作權如何界定？
RT-Thread RTOS核心部分完全由我們編寫，無其他著作權問題，可以放心在商業產品 & 工程中使用。對於把RT-Thread使用於商業產品中，我們承諾永久不收費（使用人擁有使用權，使用用途責任請自行承擔）。另外有兩點需要注意：
- RT-Thread RTOS代碼原始著作權屬於RT-Thread所有。
- 在商業產品 & 工程中使用RT-Thread RTOS，請在產品說明書上明確說明使用了RT-Thread，如有串口輸出，請在系統啟動顯示RT-Thread的版本信息。如使用了RT-Thread RTGUI，請保留RT-Thread LOGO。
3. RT-Thread RTOS由誰開發，由誰維護？
目前RT-Thread RTOS由國內RT-Thread工作室開發及維護
4. RT-Thread RTOS是否已經在產品中使用？穩定度 & BUG情況如何？
目前已經有數家公司使用RT-Thread RTOS做為他們的系統平台，在上面進行產品開發，穩定性表現不錯。
就如同沒有100%的完美事物一樣，BUG是存在的，反饋上來我們會努力儘快修正。
5. 我能加入到RT-Thread的開發者隊伍中嗎？
能！
我們歡迎任何對RTOS感興趣的人，不管你是學生或資深嵌入式系統開發工程師。RT-Thread的開發人員通常依賴於論壇、郵件、GTalk進行聯繫交流，由於目前上海的開發人員比較多一些，所以會不定期的在上海舉行開發者聚會。
6. RT-Thread依靠什麼持續發展下去，能夠盈利嗎？
目前RT-Thread的發展主要依賴於大家的興趣愛好，大多數都是在業餘時間進行開發的。以後會通過技術支持、組件定製、組件開發、輔助工具等 方式進行盈利。從幾大開源軟體來看，商業支持是軟體持續發展不可或缺的一部分，所以我們希望能夠有更多的公司選擇RT-Thread RTOS做為系統平 台，這個對於公司、對於整個RT-Thread社區都是雙贏的局面。對於公司，能夠獲得免費的RTOS套件，同時也能夠推動著這個RTOS套件不斷的朝著 穩定的方向發展。對於我們，有公司支持的發展無疑會令RT-Thread的發展更上一層樓，當然也意味著以後的支持費用有著落啦。
=========
問題完了，開始進入0.3.x系列的主題。在對外發布上，相信大家已經看到了，RT-Thread已經進入了0.3.x的密集發布周期。RT- Thread/STM32F103VB已經發布了0.3.0系列的3個beta版本，RT-Thread/STM32F103ZE已經發布了0.3.0系 列的2個beta版本，RT-Thread/LPC2148已經發布了一個0.3.0系列的beta版本。接下來會考慮發布RT-Thread/LM3S 的第一個beta版本(汗一個，剛發過了的板子有些硬體問題，返修了)...
這些版本，大多數上會包含：Kernel + FinSH shell + Filesystem + LwIP等。
0.3.0系列，RT-Thread還包括兩大內容：
- 編程指南文檔
- RTGUI圖形界面系統
編程指南一直在修訂，比較遺憾文筆有限，所以文檔還請大家不要太挑剔，有什麼建議歡迎大家提出來。關於編程指南，還要提一句的是，這份文檔是一份 編程的指南，在RT-Thread上編程需要考慮的地方都會提出來。但是，它並不是一份代碼分析的文檔，雖然它可能會提到內部的一些大致結構框架，但它不 會對代碼進行一行行分析，所以請大家多多注意。
檔案系統這塊現在代碼已經發布出來了，其實裡面還包括另外一個分支的：DFS-FAT，這個分支就如同DFS一樣，是我們自己編寫的，也能夠支持NandFlash等介質上的壞塊管理，寫了很多個測試例子在測，等通過壓力測試後會取代目前的DFS-EFSL發布出來。
