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