<delect id="xdj5x"><menu id="xdj5x"></menu></delect>
<sup id="xdj5x"><label id="xdj5x"><nav id="xdj5x"></nav></label></sup>

    <em id="xdj5x"><tr id="xdj5x"></tr></em>

    <dd id="xdj5x"><tr id="xdj5x"><kbd id="xdj5x"></kbd></tr></dd>
    <div id="xdj5x"><ol id="xdj5x"></ol></div>

    關于嵌入式軟件開發的內容進階詳述

    2019-02-22 10:00:28分類:嵌入式軟件開發設計69

      “嵌入式軟件”這個名詞很籠統,但一般業內的理解就是直接與硬件打交道的軟件。大部分嵌入式軟件工程師基本工作內容如下:裸機——RTOS——Linux,以及一些新生的概念。
     

    嵌入式軟件開發
     

      1、裸機開發

      裸機開發看起來隨意性很大,因為沒有固定框架、固定接口,從驅動、算法、界面、頂層應用都是自己做。但這往往就是初學者的心態,或剛入行的格局。

      裸機開發的平臺雖然不如隔壁互聯網那些千變萬化的框架多,但數量還是有很多:STM32、AVR(MicroChip)、瑞薩、飛思卡爾(NXP)、新唐電子……開發平臺大部分都由芯片廠規定。但這只是表面看起來豐富,對于嵌入式老司機而言,這些雜七雜八的所謂平臺都逃不出:編輯器、編譯器、鏈接器、燒寫調試器、芯片電路板。在STM32上配置寄存器,難道在RH850上就不會了嗎?并不是,嵌入式軟件的開發套路是比較固定的,開發工具大同小易。比互聯網跳框架難度應該不會大,如果感覺很大,多看幾遍芯片的datasheet吧。這幾年隨著芯片越來越統一化(比如ARM Cortex生態系統),有些廠推出了圖形化配置的工具比如STM32CubeMX,其實不過是做了層封裝和調用而已,而且僅僅限于引腳、時鐘配置、驅動、加載協議棧,對于中間層、應用層幫助不大。但至少配置沒那么繁瑣和容易出錯了,但產生的程序代碼可能并不符合很多公司的代碼規范和框架。我知道有些公司是自己開發這類配置軟件的,當然要項目足夠大和穩定才行。

      裸機開發的第一個套路是框架。合理的框架有助于程序閱讀、修改、移植。裸機程序的框架一般只有三層:驅動、中間層、應用層。中間層往往被忽略,其實它作為應用和驅動的對接層,寫得好對于程序移植和理解好處多多。很多業內的很喜歡把三個攪在一起,因為趕項目所以不太在乎。而且大部分做嵌入式的都是硬件出身,沒有軟件出身人的滿腦子框架束縛。設計可變模塊用#ifdef來靈活使用,在應用模塊用回調函數控制被調用模塊改變。這些都是基本套路。嵌入式軟件本質上還是軟件,軟件那套低耦合、強內聚、模塊化等概念是要一脈相承的。這里不拓展講,業內人士要多看看軟件相關書籍,雖然沒有幾本寫的好的。很難找到單純討論嵌入式軟件的書,那些掛名號的大都是結合硬件講的,且就講個驅動設計,連框架、語法、構建都懶得說。這或許還是大家都出身硬件的緣故。如有朋友知道有這方面寫的好的書,請推薦。嵌入式軟件工程師也要所學學軟件的理論,那些封裝、面向對象等軟件設計基本套路還是要掌握的。

      裸機開發第二個套路是任務調度。因為沒有操作系統加持,任務調度要自主實現。嵌入式軟件任務調度要考慮硬件性能,放一個while(1)大循環、前后臺中斷,理想情況下看是所有任務都會即使執行的,實際上芯片壓根性能沒那么強勁,中斷多了任務就不執行了。一般這里有兩個分類,一類是基于(中斷)事件、一類是基于時間。基于事件基本都是理想主義,認為美好的事總會發生,而基于時間則是物理規律——任一時間芯片只做一件事,并且認為外界的事件發生是有時間間隔的(瞬態無時間間隔的任務,芯片只能說臣妾做不到啊!)。當然一切都要基于需求,假設芯片就是只做一兩個任務,那就是一個while(1)+前后臺有什么所謂。多任務程序框架就必須要考慮基于時間了。

      裸機開發的第三個套路是狀態機。猶記得第一份工作時,面試官的第一個問題就是讓我談談狀態機。狀態機在裸機程序設計里應用非常廣,也是一種優秀的設計模式。狀態機集合了任務調度、程序框架的概念。甚至業內優秀的狀態機框架被商業化了比如QT量子狀態機框架。狀態機不是程序流程圖,程序流程圖一般是基于用戶一步步操作的,狀態機是基于系統運行狀態的,所以流程圖一般用于做需求,狀態機用于做開發。狀態機程序設計首先要用UML工具畫好程序狀態圖,要明確某一時刻系統智能處于某一狀態,以及狀態跳轉的條件。把狀態機和任務調度結合,就是用時間輪詢不斷執行一個個狀態機。狀態機內部設計方法非常重要。當熟稔后,狀態機就是愉悅的switch case,if else了。

      業內一直有一些偏見認為做裸機程序的人軟件水平不行,甚至揚言在目前硬件性能爆炸的年代不應該在乎代碼量。這依舊是初出茅廬的人說的,任何開發都要基于明確的需求,那些能用少了幾塊錢的芯片、少了一兩個級別軟件復雜度做出產品的工程師才是公司需要的。一個發貨量十幾萬的產品,能提前一周上市,公司盈利很可觀了。工程師要做的是用最快的速度滿足需求,而不是比較什么技術比較高超,那是象牙塔的理論。
     

    嵌入式軟件開發
     

      2、RTOS

      RTOS本質上僅僅是個任務內核,對于硬件驅動僅僅涉及到RAM、時鐘等這些與任務調度直接相關的驅動。這不就是裸機任務調度那套玩意放大版么。但RTOS任務調度更加復雜,涉及到任務切換、任務通信、內存管理等。看起來RTOS好像內容很多,但其實,其實也就只有這些內容了。作為實時操作系統,RTOS如果涉及太多會拖慢任務調度速度,因此實際上它僅僅扣出操作系統最基本的東西——任務管理和內存管理來實現。如果能結合操作系統知識來學習RTOS收獲應該更大,體會為了實現理論家口中的操作系統,RTOS做了怎樣的妥協和靈活。RTOS本質上僅僅是個中間模塊,把它拿掉,自己設計一個任務管理和內存管理模塊,即使糙一點也還是能用的而且還能非常小心地把控硬件資源。但在經過N多項目考驗的FreeRTOS、UC/OSII等優異的RTOS面前,加上項目需求的多樣,恐怕很少工程師會抵制住誘惑。

      正是因為RTOS僅僅實現了操作系統一部分功能,因此設計一個RTOS好像不是那么難。于是RTOS市場風起云涌,專用的、通用的、內部用的、開源的……但是其實用什么RTOS只要你不是技術總監,選擇跟你沒有關系。當然DIY除外,筆主比較推崇FreeRTOS、UC/OSII、UcLinux,這些案例多,健壯的RTOS。

    嵌入式軟件開發

      3、Linux

      本來起個通用操作系統的標題,但發現毫無意義,Windows不開源、Android內核本來就是Linux,兜這么大個圈還不是只能講Linux,所以還是叫Linux好了。

      Linux作為通用操作系統,在業內是為實現任務種類多、界面多、造價高這類項目準備的。Linux完整實現了操作系統的所有理論,包括驅動管理、文件管理、任務管理、內存管理、網絡協議、安全管理等等。雖然看起來好像內容好多,但僅僅就內核而已,除了開發驅動(還要去掉直接與CPU相關的驅動,這些內核已經適配了)、做做中間包、做做應用程序,很多工程師無能為力。真正的內核開發是Linus、intel公司那些大牛做的,我們只能用用。但就是這么少的一部分,已經夠折騰人的了。

      對于Linux標準的要求就是會移植、會開發驅動和拼湊進Linux去、會shell C開發調用。做應用層的多的就是QT 環境開發了,這玩意和Java JVM是差不多的邏輯,就是在shell上面再放一層解釋器或加入調用包一起編譯而已。
     

    嵌入式軟件開發
     

      4、協議棧、中間包

      這幾年嵌入式領域因為硬件性能提升和任務多樣化,涌現了很多專一功能的協議棧、中間包。比如藍牙協議棧包、WIFI協議棧包、STemwin GUI包、安全棧、神經網絡加速包等等。很多棧和包實際上已經超出了傳統的嵌入式軟件領域了。比如無人機姿態控制的PID包、手機人臉識別NPU加速包等,這些對數學的要求高于代碼,也不是一般工程師能做的,要有數學功底。當然并不是高不可攀,再說誰不會調基本的PID呢。

    上一篇:下一篇:
    辽宁十一选五技巧