嵌入式微系統msOS的誕生-嵌入式微系統連載之四

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

　　1、 不需要低功耗設計。

　　2、 傳感器類(lèi)和驅動(dòng)器類(lèi)屬于單一功能的設備，傳統前后臺架構的MS3即可。

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

　　那么這個(gè)新平臺應該做成什么樣子，腦子里還是沒(méi)有概念的，只是知道在高頻機設計中，傳統的狀態(tài)機或者函數指針?lè )绞降牟藛谓缑婢幊谭绞绞且倪M(jìn)了。我雖然在手機公司做過(guò)近兩年的手機驅動(dòng)開(kāi)發(fā)，但此后一直做硬件方面的工作，后來(lái)創(chuàng )業(yè)經(jīng)營(yíng)公司，所以嵌入式軟件水平一直停留在MS3這個(gè)層次沒(méi)有提高，對于這個(gè)新平臺的設計，首先需要向軟件專(zhuān)家請教，尤其是過(guò)去這么多年，軟件開(kāi)發(fā)也有極大的變化。

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

　　蘇鵬認為MS3是一個(gè)很好的東西，簡(jiǎn)單、易用，不能輕易拋棄，所以第一步在MS3上重構，引入當前主流的面向對象菜單界面編程思想，這個(gè)重構花了將近一個(gè)月，因為MS3是前后臺的，只有一個(gè)大循環(huán)，基于消息機制，很多事件都是在大循環(huán)中處理，菜單界面放在大循環(huán)中解析的時(shí)候，因為菜單界面顯示屬于是低速事件，會(huì )嚴重影響高速的事件，讓MS3中的消息機制失效，所以無(wú)法完美的實(shí)現面向對象菜單界面編程，只是形式上的實(shí)現了一些功能，沒(méi)有實(shí)際使用這個(gè)代碼，但這也為后來(lái)的真正實(shí)現面向對象菜單界面編程打下了基礎，并且也認識到MS3這種只有一個(gè)大循環(huán)的架構無(wú)法實(shí)現真正的面向對象菜單界面編程，必須要引入搶占式多任務(wù)操作系統，把菜單界面放在最低優(yōu)先級的任務(wù)中，其他的消息事件處理(消息事件處理，也叫業(yè)務(wù)邏輯處理，后續用業(yè)務(wù)邏輯表述)放在一個(gè)高的優(yōu)先級中，這樣最少需要兩個(gè)任務(wù)，所以接下來(lái)的事情就是選擇RTOS，并且深入理解它。

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

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

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

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

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

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

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

　　2、 System這個(gè)命名空間概念，可以很好的封裝整個(gè)系統層，把應用層獨立出來(lái)，這樣可以提高代碼的復用性和穩定性。

　　3、 C#是面向對象，但比C++簡(jiǎn)單很多，完全可以利用C語(yǔ)言中的結構體模擬命名空間和類(lèi)，把C語(yǔ)言寫(xiě)成C#風(fēng)格。

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

　　到了這兒，整個(gè)框架基本成型，但是系統層如何進(jìn)一步細分呢?這時(shí)蘇鵬建議參考ARM的CMSIS標準，如下圖：

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