銷售熱線13632930703 13913227693
行業新聞
嵌入式微系統msOS的誕生-嵌入式微系統連載之四
作者: 本站 來源: 本站 時間:2014年09月13日 字體:[]
  嵌入式微系統msOS的誕生-嵌入式微系統連載之四
  為了解決多人協作,多種需求產品的開發,并且還要長期維護,必須要把這些產品的共性提取出來。

  1、 不需要低功耗設計。
  2、 傳感器類和驅動器類屬于單一功能的設備,傳統前后臺架構的MS3即可。
  3、 電源類及控制類設備都屬于功能復雜的,實時性要求高,帶有屏幕顯示,外擴多路傳感器或者驅動器的設備,這兩類可以統一為一類,是設計的重點,需要建立全新的平臺。

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

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

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

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

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

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

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

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

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

  1、優雅的編程風格,簡單易用的長命名命名規范很容易被開發者接受,拋棄復雜的匈牙利命名法。
  2、System這個命名空間概念,可以很好的封裝整個系統層,把應用層獨立出來,這樣可以提高代碼的復用性和穩定性。
  3、C#是面向對象,但比C++簡單很多,完全可以利用C語言中的結構體模擬命名空間和類,把C語言寫成C#風格。
  4、微軟的編程環境,特別適合工業行業,無論PC機還是WINCE嵌入式設備,C#都可以通用。這樣嵌入式端用新平臺開發之后,本身就是C#風格的,很容易掌握PC端的C#編程。

  到了這兒,整個框架基本成型,但是系統層如何進一步細分呢?這時蘇鵬建議參考ARM的CMSIS標準。
  為了提高可移植性,在硬件驅動層與OS、GUI等中間件層引入了設備層,至此整個軟件架構的框架基本建立完成。
分享到:
快3平台首页 黑龙江省11选五任五一定牛 河北快三遗漏一定牛 七星彩技巧和新口诀 辽宁11选5人工 上海有哪些期货配资 十一选五稳赚技巧任三 七星彩有哪些固定规律 南粤风采26选5中奖规则 安徽快三官方网站 股票融资与债券融资