當前嵌入式的門檻分工及重難點

一、從科學技術發(fā)展史看技術門檻的降低

以前總是聽有經驗的工程師或者學長學姐告訴我們，嵌入式有多難學，門檻有多高，既要懂軟件，也要懂硬件，還要懂各種xx原理，xx協議，xx算法。在學習嵌入式的過程中也走了不少彎路，無的放矢地學了各種雜七雜八的知識，盡管現在有一份還湊合的工作。但是面試應屆生以及和群里一些還在校的學生交流的時候，發(fā)現他們能學習和掌握一些我們有2-3年工作經驗才懂的知識，明顯這一代的佼佼者可以花更少的時間學習到我們在不斷踩坑和彎路中才得到的知識。

正因如此，我對以前老工程師總結的那套嵌入式Linux門檻很高，需要很多的經驗，長期積累才能培養(yǎng)出合格的工程師，越老越吃香的說辭產生了懷疑，進而聯系科學發(fā)展史和唯物辯證的思維，發(fā)現那些老工程師的意識和觀念由于受他們成長的環(huán)境和時代的影響，由于他們技術成長過程中所經歷的困難使他們的主觀意識對嵌入式技術的認知上產生了一些偏見(就像是物質匱乏時代給老一輩人帶來的偏見，使得他們在小康的新時代還要省吃儉用，舍不得浪費一粒米一樣)，這些主觀偏見有一些時代局限性，和當前社會普通學生能接觸的信息和資源是有差異的(這也是所謂代溝)，但是他們卻意識不到自己的主觀偏見，也很少能以客觀的態(tài)度看待這種意識差異，他們把帶有主觀偏見的經驗傳授給新一代的工程師，也使得新一代工程師發(fā)現其中與當前實際情況不符的地方，產生很多困惑。

嵌入式相關的技術，說到底也只是電子信息與計算機交叉的一種應用性的技術，其本身的地位遠遠不如了人類發(fā)展史上的幾大科學進步的里程碑，比如:牛頓力學體系，歐姆定律，法拉第電磁感應，洛倫茲力，麥克斯韋方程，布，微積分等等……

像牛頓力學，元素周期表，歐姆定律，高斯分布等這些科學理論知識，是人類中杰出的精英探索研究了幾百上千年才得到。這些知識在200-300年前，只有人類社會中*杰出的精英才能掌握?？扇缃?，我們從一無所知的嬰兒到掌握這些200-300年前精英科學家的前沿理論，只需要18歲讀到高中畢業(yè)就行，不需要我們再沿著前人的老路再探索上百年了。上一段提到的其它幾個近100多年的科學里程碑，我們也只要讀到大二也能學懂。這要是在200年前，那些偉大科學家可能會說，你們高中和大學基礎知識是他們窮盡了畢生心血才弄懂的。

所以從科學技術的發(fā)展史可以明顯看出，踩在巨人的肩膀上，學習過去已有的知識，我們已經不用跨過那么高的門檻，不用在黑暗中摸索，走那么多的彎路。

同理，在嵌入式領域，相比于20年前入門的嵌入式工程師，我們有了X寶，可以購買到各種各樣的開發(fā)板以及價格相對便宜的低頻示波器，萬用表，有了更多專業(yè)領域的中文資料，能夠使用各種方便的IDE環(huán)境直接采用C語言編程(他們入門用匯編)，相比于10年前入門的嵌入式工程師，我們有了更多專業(yè)方面的網絡視頻培訓資料，能有人手把手帶你做項目，調試，我們有了Github，在上面能獲取Linux內核源碼，看到全球公司提交的產品級的驅動代碼，我們有了更多的開源應用軟件和生態(tài),有更多的人在網絡論壇上回答你的專業(yè)問題，教你一步一步配置環(huán)境，遇到很難的專業(yè)領域算法(比如使用小波變換做得視頻有損編解碼算法)，我們一時半會寫不出來的時候，往往可以找到別人寫好的開源庫，稍微修改移植過來。

這個移動互聯網時代帶來的這一切，不知不覺中侵蝕了嵌入式所謂的高門檻，讓那些老工程師在信息相對匱乏年代所經歷的很多困難，在當下，都算不上困難和門檻。

所以網上那些復制粘貼的文章中所謂的嵌入式高門檻，放到當下的時代環(huán)境，可能并不是什么難事。我們應該學會用發(fā)展的眼光看待技術的進步，而不該被嵌入式高門檻的教條所束縛，以正常的心態(tài)，把它看成是一種普通的技術活，和應用軟件開發(fā)，硬件開發(fā)，結構設計同等對待，技術本身并沒有啥鄙視鏈和優(yōu)劣之分。

二、嵌入式領域分工的變化

有很多所謂有經驗的人認為，嵌入式底層軟件和硬件技術是不怎么變化的，經驗越多越值錢，越老越吃香。其實這是一種主觀機械而又狹隘的經驗主義，缺乏全局視野，只看到自己所在領域的一些基礎性技術，看不到整個行業(yè)和相關領域的變化，一葉障目。

其實就拿現代足球和籃球運動作為類比，也是同樣的道理?，F代足球和籃球的發(fā)展歷史比什么嵌入式軟件，硬件等高科技的發(fā)展史還要長久，那種機械經驗主義狹隘的觀點肯定會認為，打籃球就是學運球，突破，傳球，投籃，踢足球就是學傳球，停球，帶球，鏟球，射門，跑位，這都是50年前甚至100年前就有的東西，和現在一樣是不變的。然后他們沒有看到的是，籃球和足球的戰(zhàn)術和位置分工，每隔5-10年就會發(fā)生很大的變化。

比如籃球領域從之前的強內線，肌肉棒子的中鋒時代演變成小球三分射手時代，內線球員對中遠投和三分球能力要求越來越高，以前那種沒有射程的大個內線越來越不吃香。

足球領域的分工和戰(zhàn)術變化就更多了，從遠古一點巴西群星的424 WM陣型個人技術流到意大利鏈式防守，從經典442陣型，雙前鋒一高一快或者雙高的英式長傳沖吊，到第*代433全攻全守的踢法。從4231傳統的邊鋒加經典10號位前腰和掃蕩防守型后腰再到西班牙式Tiki-Taka傳控足球短傳滲透的盛行，再到現在高位逼搶，經典前腰和防守型后腰的消失，全能型B2B中場的吃香。其它位置的球員，例如，逆足邊鋒內切踢法，偽9號無鋒陣，邊后衛(wèi)對助攻能力要求越來越高，而不只是防守對方邊鋒，中后衛(wèi)對出球能力要求越高，不只是會防守搶斷。而過去那些有了很多*和榮譽但是位置單一，不符合現代高位逼搶，靈活換位要求的球員，越來越沒有市場。

像現代足球，籃球這種發(fā)展了50年到100年的體育運動，看似不變，實際上都經歷了如此多的戰(zhàn)術和位置分工變化，不同時代對不同位置球員的要求都不一樣，更何況近二三十年經歷了高速發(fā)展的電子信息和嵌入式技術呢？回到正題，分析一下硬件工程師和嵌入式軟件工程師的分工和技能要求變遷。

1. 硬件工程師

一開始沒有集成電路和數字芯片，要設計一個系統需要用三極管，電阻，電容，電感等分立器件來搭，那時候硬件工程師對模擬電路設計的要求是非常高的，既要精通應用業(yè)務邏輯，也要精通模擬電路設計，大家可以看看模電書上經典uC741放大器里面的模擬電路圖的復雜程度。

后來有了小規(guī)模的模擬和數字芯片(比如uc741放大器,74LS04數字門電路，ne555時鐘發(fā)生器)，硬件工程師就可以使用這些芯片加上一些外圍電路來搭建自己的系統，硬件設計門檻有所降低，做出的產品也更加豐富，但是自己還是要精通應用業(yè)務邏輯。

再到后來，ASIC和大規(guī)模集成電路以及嵌入式編程芯片的出現，很多算法和邏輯控制功能都集成在ASIC芯片里面或者在嵌入式處理器中用編程軟件實現。硬件工程師對業(yè)務應用業(yè)務邏輯的要求大大降低，同時所做的外圍電路設計也越來越少，比如電源方面，可以買TI的開關電源芯片加上少量的外圍電路，就能實現自己高性能開關電源，無需精通里面各種復雜的控制算法和功率因素補償等技術。這個時候，有些硬件工程師開始往單片機編程技能方面發(fā)展，還有一些硬件工程師往EMC，PCIE,WIFI，USB,DDR等數字和模擬等接口標準認證方面發(fā)展，硬件的分工開始細化專業(yè)化。

再到當前，芯片原廠提供的不再僅僅提供單獨的芯片讓硬件工程師設計電路，而是提供現成的基于芯片設計的模塊或者turn key解決方案，即插即用，不需要自走PCB打板的流程，就能快速驗證自己想法和產品方案。并且原廠提供的這些模塊和解決方案，已經做好了安規(guī)，車規(guī)與EMC等標準認證，更加降低了硬件開發(fā)的門檻，提高了開發(fā)效率，很多硬件工程師的工作也變成在原廠方案板上修改，驗證，摳掉一些冗余器件節(jié)約成本，或者剩余的時間要負責供應鏈和生產管理相關的工作。而從前那些高深的數字，模擬混合電路，分立器件電路設計技術和經驗顯得無太大用武之地(除了少數芯片設計場合)。

2. 嵌入式軟件工程師

20多年前的嵌入式工程師大部分都是用C語言和匯編在8位單片機上開發(fā)驅動程序和相對簡單的控制和通信系統。那時候單片機功能沒有現在這么高級，里面甚至沒有ADC, PWM等常用模塊，需要搭建很多外圍或者電路來豐富產品的功能。那時候的單片機嵌入式開發(fā)除了要會編程，對硬件也相對較高，要自己設計通用的硬件原理圖，甚至畫2層左右的PCB板，只有碰到電源，射頻，EMC專業(yè)硬件問題的時候，才會需要雇傭專門的硬件工程師來處理。

后來使用復雜一些的32位MCU開發(fā)，MCU功能開始變得強大，系統需求也開始復雜化，嵌入式工程師需要開發(fā)多個平臺驅動乃至上位機應用程序，這個時候，公司一般會雇傭專門的硬件工程師做PCB layout和部分原理圖設計工作。嵌入式軟件工程師只需要設計硬件原理圖的核心功能I/O部分，看懂芯片手冊，對嵌入式工程師硬件能力的要求開始降低，大部分精力用于軟件開發(fā)上。

再后來的嵌入式開發(fā)使用DSP處理器和RTOS實時操作系統，硬件部分也變得集成度更高更復雜，嵌入式工程師對硬件方面的掌控和要求也越來越低，僅限于看原理圖，配置一些I/O引腳和寄存器，原理圖設計基本都交給專門的硬件工程師。但是嵌入式軟件這塊，做DSP的需要熟悉一些業(yè)務算法，做RTOS的要懂得數據結構，操作系統、計算機網絡方面的知識。驅動開發(fā)也開始變得框架化，模塊化而不僅僅限于裸機開發(fā)，配置寄存器和簡單的業(yè)務邏輯。

再到當前，嵌入式大規(guī)模使用SOC，跑Linux/Android等復雜操作系統，DSP等專用CPU核也可以集成在SOC中，通過驅動進行調用。嵌入式工程師基本不用參與硬件原理圖設計，硬件能力基本不是啥門檻，只要學過電路，模電，數電等教科書知識，看得懂別人I/O部分的原理圖就行了。讀數據手冊配置修改寄存器的活也只有偶爾會用上，因為芯片原廠和Linux開源社區(qū)為了推廣生態(tài)，已經將很多產品級的芯片的驅動程序集成到Linux內核，配置好了寄存器，降低了系統底層軟件的使用門檻(這其中有少數嵌入式工程師在原廠從事門檻較高的專業(yè)領域驅動開發(fā)，比如音視頻，GPU，Display,Security等)，使得嵌入式工程師把更多的精力集中在具體應用和業(yè)務邏輯開發(fā)上。

通過上述的一次次技術領域分工的變化，使得嵌入式工程師入行門檻和工作重點也發(fā)生了變化，從硬件到原理圖I/O設計，到驅動開發(fā)到應用業(yè)務邏輯。可以說每個部分都有它的技術難點，沒有哪個技術比其它技術高尚，我們應該關注當下的重點，善于從各種矛盾中抓主要矛盾，有的放矢地學習提高自己，善于思考主流技術的發(fā)展趨勢和變化，千萬不要被過去的教條所束縛。

三、當前階段嵌入式技術的重難點

當前階段嵌入式技術的重難點小編認為有三個方面:

1. 以C/C++語言為主的編程能力。

原本C語言編程也不是啥門檻性的大問題，但是因為國內大部分電子信息專業(yè)都是以C語言入門，然后選用的國產教材質量參差不齊，代碼風格不規(guī)范，這就人為地給入門菜鳥創(chuàng)造了門檻。但是只要肯花時間下功夫，學習豆瓣上推薦的幾本國外經典的C語言教材，進而學習數據結構，面向對象等計算機基礎知識，多練習多寫代碼來熟練編程技巧，小編相信這個不會是大問題。

C++方面，以前做單片機，做RTOS的老嵌入式工程師可能基本上都是寫C程序，用不上C++。但是現在基于Linux系統的嵌入式開發(fā)，重點將會聚焦在復雜業(yè)務邏輯應用編程上。在大規(guī)模復雜業(yè)務邏輯和GUI編程中，使用純C語言已經力不從心，使用C++開發(fā)的嵌入式應用程序的地方將會越來越多。但是C++這個語言本身比較復雜，不能強求像C語言那樣掌握95%以上的特性，C++總會有很多語言特性用不上或者不熟練，需要找到合適的項目，在實踐中反復練習再回頭看書鞏固，循序漸進。熟練掌握C++會需要較長的時間，目前一般的要求是掌握基本的面向過程，面向對象編程的編程方法，多用智能指針，復雜的模板編程能看懂就行，不要求掌握所有奇巧淫技。

2. 對計算機體系結構和操作系統相關問題的掌控能力

這一塊知識算是計算機基礎理論上的難點，雖然相關書籍資料已經汗牛充棟，商業(yè)級的Linux內核源代碼也能從網上下載，但是要啃下它還是需要耐心。很多做單片機裸機，RTOS開發(fā)的嵌入式工程師無法進入Linux開發(fā)的世界，多半也是因為Linux操作系統確實有一定難度。對這一塊知識，其實并不要求你掌握Linux內核每行源碼(這是不可能的)，也不要求你能夠獨立寫出一個復雜的產品化的操作系統(也不現實)，但是操作系統底層和計算機體系結構基本的工作原理和機制還是要搞清楚，要知道操作系統大概做了什么，是如何處理你的API調用的。

小編知道這是一塊硬骨頭，但事在人為，有了這么多資料和實驗資料的今天，肯花時間，有耐心，也不應該是大問題。

3. 業(yè)務應用能力

為什么我們需要做嵌入式計算機系統，因為嵌入式計算機系統可以根據不同業(yè)務場景需求進行裁剪和定制。說到底，業(yè)務才是嵌入式系統真正的命根子，不同業(yè)務方向嵌入式工程師薪資差異可能會比較大(當然在少數公司，開發(fā)操作系統也屬于他們的業(yè)務)。在企業(yè)有話語權有地位的嵌入式工程師所掌握的業(yè)務技能一定和企業(yè)當前盈利的業(yè)務方向高度匹配，充分滿足企業(yè)的業(yè)務需求。

當前嵌入式軟件工程師要想提高收入，一定要跟著主流有盈利能力的業(yè)務走，提升相關的業(yè)務應用技能。當然很多細分業(yè)務，不去相關的企業(yè)是根本沒有機會接觸的，熱門業(yè)務相關的高級資料也不是能夠通過網絡和入門培訓視頻輕易獲得。所以說當前階段的業(yè)務門檻才是嵌入式在不同領域的真正門檻。學會自己分析，把握當前主流前沿的業(yè)務方向，有的放矢地學習提升自己，讓自己掌握的知識發(fā)揮*大的“錢”力。

四、如何調整自己的學習和職業(yè)發(fā)展方向

分析了嵌入式領域的現狀和重難點之后，那么嵌入式工程師調整自己的學習和職業(yè)方向，小編認為有以下三點:

1. 不用過于糾結硬件門檻與寄存器配置

毛選《矛盾論》告訴我們事物的背后要搞清楚哪些是主要矛盾，哪些是次要矛盾，處理問題要善于抓主要矛盾。

同理，在當前的嵌入式學習和開發(fā)中，硬件門檻與寄存器配置已經不再是主要矛盾，而是影響你解決問題眾多次要矛盾之一。真正的主要矛盾是應用業(yè)務開發(fā)，是對操作系統工作流程的掌控，讓操作系統能夠很好地支持和配合應用業(yè)務實現系統的功能。

那么對待硬件和寄存器配置，固然還是要以客觀嚴謹的態(tài)度分析和解決相關的問題，但是不要把太多時間花在硬件原理和數據手冊寄存器的學習上，否則這將是一個高投入，低產出的工作。小編認為硬件相關問題，嵌入式工程師能把大概定位出來，交給專業(yè)的硬件工程師處理就行。這點對硬件知識的要求只需要懂得教科書上基本模擬和數字電路知識就行，相對于自己獨立設計硬件電路，通過各種標準認證的要求完全不是一個層次的。

2. 不能把編程僅限于嵌入式端

目前的嵌入式復雜業(yè)務應用編程和PC端，服務器應用編程的界限其實越來越模糊。嵌入式端應用編程除了某些時候需要利用一些平臺特有的硬件和驅動特性，來提升和優(yōu)化程序性能之外，大部分的工作也是堆業(yè)務邏輯代碼，只是在不同平臺上堆業(yè)務代碼，用不同的編譯器編譯而已。

從編程的角度考慮，就不要把編程范圍僅僅限制在嵌入式端，在以應用業(yè)務為中心的前提下，可以主動嘗試開發(fā)PC端，服務器端甚至web端的應用程序，還可以把在PC端，服務器端編程用到的新技術因地制宜地移植部署到嵌入式端，做到取長補短的作用，同時也把自己的職業(yè)道路越走越寬。

目前，嵌入式端也引入了python編程搭建整套自動化測試系統，很多嵌入式端的測試用例也是用python編寫的。很多做STM32, RTOS開發(fā)的嵌入式工程師，也不僅限于嵌入式端編程了，因為他們開發(fā)的產品很多需要通過物聯網接入到云端服務器，有時候他們也要兼顧一些云服務器的應用業(yè)務邏輯以及云端和嵌入式端通信協議開發(fā)的工作，不再是以前傳統意義上的嵌入式開發(fā)工程師。

按照這個發(fā)展潮流和趨勢，小編可以預言，未來的對嵌入式工程師的技能要求將會弱化硬件技能，在有扎實的操作系統基本功前提下，以業(yè)務導向的應用編程為核心，有云端服務器到嵌入式終端的端到端垂直開發(fā)能力。

3. 跳槽的時候要有業(yè)務升級意識

最后就是要有目的地跳槽，不只是考慮薪資問題，更要考慮下一份工作能接觸到的業(yè)務知識是不是主流賺錢的業(yè)務，未來有沒有賺錢的盈利模式，能不能讓自己的路越走越寬？平時多關注招聘網站的需要，看看什么樣的公司，什么樣的業(yè)務提供的招聘需求是*多的，要敢于和打價格戰(zhàn)，不賺錢的業(yè)務和公司說再見，及時跳坑。不要把時間耗在了重復性基礎性工作(比如小編鄙視的萬年嵌入式點燈,spi,i2c開發(fā))和不盈利的業(yè)務上。

*文章內容和圖片均來源于網絡，如有侵權，請聯系刪除。