“嵌入式軟件”這個名詞很籠統，但一般業內的理解就是直接與硬件打交道的軟件。大部分嵌入式軟件工程師基本工作內容如下：裸機——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呢。