嵌入式微系統(tǒng)msOS的誕生-嵌入式微系統(tǒng)連載之四

　　為了解決多人協(xié)作，多種需求產(chǎn)品的開發(fā)，并且還要長期維護(hù)，必須要把這些產(chǎn)品的共性提取出來。

　　1、 不需要低功耗設(shè)計。

　　2、 傳感器類和驅(qū)動器類屬于單一功能的設(shè)備，傳統(tǒng)前后臺架構(gòu)的MS3即可。

　　3、 電源類及控制類設(shè)備都屬于功能復(fù)雜的，實(shí)時性要求高，帶有屏幕顯示，外擴(kuò)多路傳感器或者驅(qū)動器的設(shè)備，這兩類可以統(tǒng)一為一類，是設(shè)計的重點(diǎn)，需要建立全新的平臺。

　　那么這個新平臺應(yīng)該做成什么樣子，腦子里還是沒有概念的，只是知道在高頻機(jī)設(shè)計中，傳統(tǒng)的狀態(tài)機(jī)或者函數(shù)指針方式的菜單界面編程方式是要改進(jìn)了。我雖然在手機(jī)公司做過近兩年的手機(jī)驅(qū)動開發(fā)，但此后一直做硬件方面的工作，后來創(chuàng)業(yè)經(jīng)營公司，所以嵌入式軟件水平一直停留在MS3這個層次沒有提高，對于這個新平臺的設(shè)計，首先需要向軟件專家請教，尤其是過去這么多年，軟件開發(fā)也有極大的變化。

　　幸好我公司的底子是做手機(jī)的，主流是MTK手機(jī)方案，此外基于Wince做了一款工業(yè)手持機(jī)，所以有各類專業(yè)軟件人員，對C、JAVA、C#都非常熟悉。在眾多軟件人員中，特別要感謝的是蘇鵬，他擅長Linux，之后是負(fù)責(zé)MTK手機(jī)開發(fā)平臺的維護(hù)，也需要開發(fā)JAVA應(yīng)用，關(guān)鍵那個時候他也恰好參與了基于MS3的紅外溫度傳感器的開發(fā)，所以對嵌入式有一定的概念，對大型軟件編程又很擅長，所以當(dāng)我提出我的需求的時候，他很清楚我想要干什么。

　　蘇鵬認(rèn)為MS3是一個很好的東西，簡單、易用，不能輕易拋棄，所以第一步在MS3上重構(gòu)，引入當(dāng)前主流的面向?qū)ο蟛藛谓缑婢幊趟枷?，這個重構(gòu)花了將近一個月，因為MS3是前后臺的，只有一個大循環(huán)，基于消息機(jī)制，很多事件都是在大循環(huán)中處理，菜單界面放在大循環(huán)中解析的時候，因為菜單界面顯示屬于是低速事件，會嚴(yán)重影響高速的事件，讓MS3中的消息機(jī)制失效，所以無法完美的實(shí)現(xiàn)面向?qū)ο蟛藛谓缑婢幊蹋皇切问缴系膶?shí)現(xiàn)了一些功能，沒有實(shí)際使用這個代碼，但這也為后來的真正實(shí)現(xiàn)面向?qū)ο蟛藛谓缑婢幊檀蛳铝嘶A(chǔ)，并且也認(rèn)識到MS3這種只有一個大循環(huán)的架構(gòu)無法實(shí)現(xiàn)真正的面向?qū)ο蟛藛谓缑婢幊蹋仨氁霌屨际蕉嗳蝿?wù)操作系統(tǒng)，把菜單界面放在最低優(yōu)先級的任務(wù)中，其他的消息事件處理(消息事件處理，也叫業(yè)務(wù)邏輯處理，后續(xù)用業(yè)務(wù)邏輯表述)放在一個高的優(yōu)先級中，這樣最少需要兩個任務(wù)，所以接下來的事情就是選擇RTOS，并且深入理解它。

　　首先考慮的是uC/OS-II，因為它的資料最多，用戶群體廣泛，并且之前也接觸過一點(diǎn)，雖然沒有深入，但感情上首選它。此外有同事推薦了FreeRTOS和國內(nèi)的RT-Thread，F(xiàn)reeRTOS跟uC/OS-II類似，但知名度太低，資料及客戶群體都很少，雖然它是免費(fèi)的，還是放棄了。RT-Thread編程風(fēng)格是Linux的，我不喜歡Linux風(fēng)格，感覺不好看，不夠優(yōu)雅，其次知名度也遠(yuǎn)不如uC/OS-II，并且可靠性、穩(wěn)定性如何也值得懷疑，它帶的GUI適合彩屏，相對復(fù)雜，也不適合黑白屏的工業(yè)場合使用，所以也放棄了。

　　選定uC/OS-II后，必須要深入理解它的每一個細(xì)節(jié)，首先碰到的就是uC/OS-II有太多的宏定義，因為要可裁剪、可配置，但實(shí)際上有大量的功能是用不到的，所以我就從精簡入手，把在新平臺中可能用到的函數(shù)保留下來，其它的一律去掉，這樣就沒有了煩人的宏定義，有很多網(wǎng)友也抱怨這些宏定義，嚴(yán)重的干擾了uC/OS-II的代碼閱讀。

　　通過精簡uC/OS-II，深刻掌握了它的原理，并且這個時候新平臺的需求也越來越清晰，絕大部分的需求只要兩個任務(wù)即可，一個為菜單界面任務(wù)，一個為業(yè)務(wù)邏輯任務(wù)，根本不需要64個任務(wù)，所以對uC/OS-II大做修改重構(gòu)，去掉了空閑任務(wù)和統(tǒng)計任務(wù)，把菜單界面解析安排在最低優(yōu)先級上，業(yè)務(wù)邏輯放在高優(yōu)先級上，這樣只需要兩個任務(wù)即可。

　　為了考慮今后任務(wù)的擴(kuò)展性，還是保留了任務(wù)表，只是精簡為支持8個任務(wù)。為了降低OS的內(nèi)存占用，進(jìn)一步精簡OS內(nèi)核，把原來基于鏈表結(jié)構(gòu)的任務(wù)塊改成數(shù)組結(jié)構(gòu)。這樣一個非常簡單的uC/OS-II就出爐了，僅僅兩個文件即可。

　　精簡、重構(gòu)后的內(nèi)核只是保留了uC/OS-II的任務(wù)切換功能而已，而所有的RTOS都有這個功能，并且都是類似的，所以已經(jīng)脫離了uC/OS-II，只是這個內(nèi)核開始源自uC/OS-II，風(fēng)格一樣，所以還保留其名，但本質(zhì)上已經(jīng)不屬于uC/OS-II了，所以也不存在版權(quán)問題，若想進(jìn)一步避開，也可以參考其它的RTOS精簡或者直接用其它的RTOS。若只需要用兩個任務(wù)，新平臺還提供了一種軟中斷的方式實(shí)現(xiàn)雙任務(wù)，完全不需要RTOS。

　　引入RTOS實(shí)現(xiàn)了多任務(wù)之后，新平臺的架構(gòu)有些浮現(xiàn)，接下來要做的是確定軟件架構(gòu)，而這個必須要從現(xiàn)代成熟的軟件架構(gòu)中尋找。在跟同事交流后，他們都提到了面向?qū)ο笤O(shè)計，但這個需要采用C++，而嵌入式中C++卻不流行，我也不會，所以不可能選擇C++。后來想到用常規(guī)的C語言寫成類似C++的面向?qū)ο箫L(fēng)格，但參考了網(wǎng)上的代碼之后，覺得把C語言弄的更復(fù)雜了，很別扭，變成了四不像。之后又了解了JAVA，但感覺這個風(fēng)格也不是很適合，直到有一位負(fù)責(zé)C#的同事侯德平，他建議采用C#，并且給我演示C#的好處的時候，讓我眼睛一亮，這就是我想要的東西。

　　1、 優(yōu)雅的編程風(fēng)格，簡單易用的長命名命名規(guī)范很容易被開發(fā)者接受，拋棄復(fù)雜的匈牙利命名法。

　　2、 System這個命名空間概念，可以很好的封裝整個系統(tǒng)層，把應(yīng)用層獨(dú)立出來，這樣可以提高代碼的復(fù)用性和穩(wěn)定性。

　　3、 C#是面向?qū)ο螅菴++簡單很多，完全可以利用C語言中的結(jié)構(gòu)體模擬命名空間和類，把C語言寫成C#風(fēng)格。

　　4、 微軟的編程環(huán)境，特別適合工業(yè)行業(yè)，無論P(yáng)C機(jī)還是WINCE嵌入式設(shè)備，C#都可以通用。這樣嵌入式端用新平臺開發(fā)之后，本身就是C#風(fēng)格的，很容易掌握PC端的C#編程。

　　到了這兒，整個框架基本成型，但是系統(tǒng)層如何進(jìn)一步細(xì)分呢?這時蘇鵬建議參考ARM的CMSIS標(biāo)準(zhǔn)，如下圖：

　　為了提高可移植性，在硬件驅(qū)動層與OS、GUI等中間件層引入了設(shè)備層，至此整個軟件架構(gòu)的框架基本建立完成，如下圖：