這個問題我來回復再合適不過了！

我2012本科畢業，專業計算機科學與技術嵌入式方向，學校開的專業就是嵌入式。前後經歷飛思卡爾、51、avr、stm32等微控制器開發。大學時代就熟練51，工作avr,stm系列。還跑過rtos，總之不能說是小白了。

回到主題，為啥工資低？

微控制器開發主要基於c，我相信基於stm等arm系列跑作業系統的我們接觸的估計也不會多，所以大多都是基於微控制器的周邊簡單外圍控制。產品附加值低，產出不高，直接導致錢少。

其次微控制器程式開發一定的階段，硬體知識是個門檻。一般搞程式開發大多軟體專業畢業，對電子電路知識匱乏，所以導致進一步的水平提升困難。

其實，做底層開發本身是個很有技術性的活，但是糧賤傷農，以至於大家紛紛轉行？

我微控制器開發幾年，後來轉app開發，工資直接翻翻，所以有時候選擇也是一種無奈！

從業兩年，覺得從事微控制器相關行業寫程式的人，寫程式的水平普遍不高？不知題主從事的是哪個行業？平時從事的是什麼型別產品的開發？實際上從事微控制器等嵌入式開發的，程式寫的好的人大有人在，寫程式的水平也有很多人水平很高，只是題主可能沒有接觸過罷了。大家能夠看到的微控制器開發的相關的程式碼，要麼是教學為主的微控制器課程教學影片，其程式的講解針對的是初學者，是為了初學者能夠入門，一般程式的程式碼，越簡單越好。還有可以接觸到的程式程式碼，就是一些工程師在部落格，或論壇釋出的經驗程式。但是涉及到產品開發的程式碼，可謂不多。

目前，微控制器相關的產品，從民用，到工業，到軍用產品，只要是涉及到智慧化的無不有微控制器的身影，幾乎我們身邊的電子類產品無不有微控制器的身影，那麼這些產品的開發的程式碼，普通的開發者，大家沒有機會看到其底層的程式碼。微控制器的開發目前C語言開發為主，一般一個簡單的電子產品或工業控制，無外乎是解決資料的採集，顯示，處理，傳輸以及相關的控制等功能，一般並不是需要複雜的演算法，程式的結構和框架也不是十分的複雜。稍微複雜的控制系統或資料採集系統或智慧化系統，基本上需要上作業系統，需要是嵌入式系統。如果題主想看看優秀的程式程式碼，倒是建議可以看看STM32的庫，STM32的庫的程式碼水平不知道在大家的眼中是處於什麼水平呢？個人認為水平還是很高的，大家覺得呢？

從事嵌入式開發8年了，雖說自己覺得還有很多欠缺，但是怎麼也不能算是小白了，稍微能說兩句。

1，寫程式的水平不知道是從哪個方面來衡量的？是因為大家都能看懂所以就認為水平不高嗎？可是有些晶片廠商的庫大家都能看懂啊，但是沒有人會說他們水平不夠啊。

2，受MCU限制。這麼說吧，比如8位機，你能讓它完成怎樣複雜的功能？放一部4K電影嗎？不可能的。MCU的底子在這，註定只能完成一些簡單的任務。那麼上CortexM3，它能幹一些複雜任務了。噯，再上CortexM4，它有DSP單元了，能處理浮點運算了，噯，你再上Cortex A7，那又能完成更復雜任務了。不知道題主是幹哪個方面的？嵌入式有時候真的很無奈，比如我之前做的超寬頻定位，想在程式裡面做複雜一點的演算法都不行，時序要求很嚴格，複雜一點的演算法算下來就超時，只能用簡單演算法。

3，嵌入式有時候程式碼得多。得考慮到各種情況下會不會出故障，比如操作flash，得檢測各種工作狀態和暫存器，這一通下來最後執行就一句程式碼。感覺很臃腫。但是這麼臃腫就是水平高，因為這種程式碼健壯。

4，嵌入式有時候程式碼得少。我用過一個晶片，SPI通訊，晶片限制速率只能3M，但是資料量大，用庫發現來不及，咋辦？精簡一下，自己寫，直接操作暫存器，這樣就快了。但是跟官方庫一比較，那很多狀態都沒檢測，但是能說明我這程式碼不行嗎？不能，只是在做權衡而已。

5，嵌入式的產品多如牛毛，你做一洗衣機，那肯定程式碼複雜不到哪裡去。你做一CT機，那肯定簡單不到哪裡去。

總體來說確實如此，很多做微控制器的人是沒系統的學過計算機軟體設計的，都是電子行業出身，所以程式碼水平就卡在這了！

我早幾年搞桌面軟體開發，後來搞嵌入式軟體的同事離職了，只能由我接手，我看了這些人留下的程式碼，一塌糊塗，全域性量滿天飛看了讓人頭疼，最後花了大半年時間自己重新規劃了一下，按自己的架構重寫了專案……

這很正常。尤其是硬體出身，寫微控制器控制程式的工程師，估計只有他們自己能看清楚自己寫的程式。如果讓他們再寫後臺的高階語言程式，估計他們自己能看明白自寫程式的時間不超過10天。

為什麼這樣？

沒有經過正規的結構化程式的開發訓練，寫程式沒有架構，只要能完成控制功能就可以了。這就是硬體開發者寫的軟體。

在2005年，我們公司軟體開發任務非常多。當時一個硬體設計人員設計了一個控制絲桶轉速的PCB板，其中有電機的啟動加速、減速、急停、調速等等控制，其中用了高速微控制器。人員少，就讓硬體開發者自己寫這塊程式。

這個工程師對微控制器組合語言熟悉一些。很快程式寫好了，除錯也基本過了。

過了半年，我們要用此PCB板。由另一個人接受軟體後期維護工作。這時候，我們才發現了問題，再次測試，發現程式中有很多bug。要進行維護，發現有幾大類問題：

1，整個程式5000多行，沒一個子程式，全是短跳SJMP或者長跳LJMP或聲C語言著名的萬金油goto語句。

一會跳到中間段執行，一會又跳到大致開頭的位置執行。整個程式看的人眼暈。

2，沒有註釋。程式中沒有一行註釋。

3，沒有宏定義。到處都是類似下面的寫法：

MOV DPTR，#20f6H

MOV 54H，#0aaH

諸如此類。猜去吧，就這樣寫，就這樣隨意！

總之，要是讓MS微軟的人看了，是要捱打的節奏！

偏硬體開發者只關注硬體實現邏，不注重程式的最佳化，不善於學習軟體程式設計理論，因而漏洞百出。

軟體開發的一個重要任務，就是處理異常資訊，這是硬體從業者最大的敵人。如果你對他說，程式有可能跑飛，也有可能由於硬體干擾，watchdog沒有及時地進行定時操作，程式會復位。這些，硬體開發者會說，絕無可能，這硬體電源的抗干擾能力，槓槓的，不會產生例外。

對於中斷，不僅有優先順序，而且有執行中斷程式的，可以/不可以響應其它中斷的選擇。對此，他們更暈。

硬體開發者唯一的救命稻草，就是模擬器，他們不是先構建後寫程式，他們開發程式的唯一方法，就是寫兩句，就要用模擬器檢查一下，那怕最簡單的三位元組加/減法，對他們來說，都必須打著模擬器才能完成。

我在想，對於多位元組乘法，乃至浮點運算處理，BCD到十進位制的轉換，對他們來說，就是天書。

總結：術業有專攻，隔行如隔山。微控制器，PC機乃至伺服器、網際網路級別的軟體開發，聽上去有關聯，都叫軟體，實則天壤之別，是跨行業的，要從頭開始學起的。

什麼重構啊複用啊結構化啊多型啊都是伺服器效能慣出來的毛病。微控制器用個多層函式呼叫堆疊都爆了，一條標準c語句用匯編重寫一下效能提高十倍。學學64k記憶體年代的程式設計技巧多少能理解微控制器程式開發。

當年ibm pc xt一統江湖，所有個人計算機外圍裝置都是一個架構繼承下來的，微控制器是一個專案一套外圍裝置，程式通用性差，基本沒人按框架那種方式玩。

你玩框架追求的是程式設計效率，讓人看懂；人家玩微控制器追求的是執行效率，讓mcu懂。

舉個例子，n種資料型別執行自定義加法操作，給每種資料定義各自的處理程式肯定不好看吧？為了讓程式好看，你使用了c++的多型特性，什麼型別資料都能往一個介面塞，寫程式爽吧？可是cpu執行時就要判斷資料型別，才能找到處理函式，這在微控制器環境很可能是不可接受的效能開銷。

大多數微控制器從業者是51入門的，受限於51效能，程式碼不會特別複雜，前期也不注意程式碼規範，所以我看自己以前寫的51程式碼感覺像一坨屎，不過要是程式碼水平高也不會從事微控制器開發，純軟體工資翻番不香嗎

微控制器軟體現在都是C，和計算機也差不多。我是微控制器，，計算機，WinCE都搞，本質上沒什麼區別，要說難點，微控制器的演算法最佳化太難了！

不是水平不高，嗯而是開發環境不同。由於絕大部分微控制器的資源有限，如何在有限資源下完成所需的功能是微控制器開發者最注重的，因此基本上不會採用各種框架等進行軟體開發。

估計題主所從之業，對微控制器控制要求不高，而且為了降低用工成本，所聘員工多為一知半解或半路出家。

微控制器程式設計確實比較兼顧軟體和硬體。硬體方面，要熟悉微控制器內部資源和運用，還有外圍電路的功能效能和控制以及可靠性要求等等。軟體方面，要熟悉指令系統和規範化程式設計。

如果是三幾千條指令的簡單程式都還好說，只要程式透過測試、正常執行就可以了。規模再大，不講究點規範，時間稍長恐怕連自己都懵逼了。

對於純組合語言程式設計，至少做到模組化、結構化，加以註釋便於閱讀。這些，對日後維護或功能擴充套件、系統升級都是不可或缺的。

具體說就是，除了主流程，其餘一律採用子程式（模組），任何跳轉都在子程式內部，便於程式維護和閱讀。子程式規模儘量控制在50條指令以內，規模再大可以子程式巢狀（子程式裡的子程式）。

還有，直接地址和資料常數都符號化（可拼音或英文便於識記與修改），關鍵節點一律加以漢文或英文註釋（便於閱讀理解）。

開宗明義，這個問題很扯淡！

從哪些方面可以體現寫程式的水平高低？

程式程式碼是用來幹嘛的？

某種程度上，程式設計師就像一家大公司的老闆，而程式程式碼，就是他調動各種企業資源，實現企業運作的一套制度規則。

微控制器工程師，他必須熟悉各種硬體原理和應用，並且必須用最高效的方式，呼叫這些硬體資源達成他的目的。

換到企業裡，這就像是一個創業型的老闆。他熟悉公司的每一名員工，每一臺裝置，每一種技術工藝和每一個客戶渠道，總之公司的一切他都必須瞭解並熟悉。而且他必須在資金短缺，訂單匱乏，人員素質低下等等的不利條件下，實現企業的運作和盈利。

題主所謂的程式碼水平，無非是一些資料結構體或者現成框架的運用技巧之類的，這種東西其實都只是拾人牙慧罷了。拾的是誰人的牙慧呢？就是他瞧不起的那些底層技術和硬體工程師的牙慧！哦，在作業系統裡，他們被改了名字了，不叫微控制器程式設計師，被改名為硬體驅動程式設計師。

/*插播一段題外話：C語言相比彙編指令，最大的好處就是集成了各種高階數學運算函式，比如整數/浮點數的乘除法，再或者乘方&方根計算，三角函式計算等等。至於在資料的轉移儲存之類的效能，照彙編差遠了。

比如c語言中的各種資料集合，比如陣列、結構體（struct）、共享體(union)之類的功能，在彙編層面根本就不叫個事。而微控制器工程師的思維方式，往往就是彙編指令式的思維方式。不信你看看工控領域的王牌(梯形圖語言)，對付硬體就遠比C語言要高效的多！*/

而高階語言程式設計師，就像是一個空降型的富二代，公司裡的運作細節他啥也不懂，只能依靠父輩（創業型老闆）留下的那些中層領導（系統API）來管理這家企業。你還必須祈禱這些中層領導不能有二心，必須一心一意的幫你幹活，一旦他們耍點小心眼（留個後門），富二代就得面臨崩潰。有上進心的富二代，會想方設法深入基層，逐步瞭解公司的運作細節，如此才有可能真正接盤。不成器的富二代，就像題主這種，瞧不起這個瞧不起那個，最終被手下人拋棄只會是時間問題。

寫程式碼就好比學說話。題主覺得別人寫的程式水平不高，只能說明題主還是小屁孩，別人的好賴話還都聽不明白。如此 而已

你說得對，因為沒有學習過完整的軟體方面的知識。像是資料結構設計，面向物件程式設計思想，作業系統，軟體工程。有些對c語言的掌握程度也不夠。

問一下，你認為的水平高是哪方面？是程式碼複用率？還是內聚性？還是空間和時間複雜度的完美結合？或者說僅僅是讓別人看懂你寫的程式碼？我這嵌入式老油條說說我的意見吧。

1.微控制器開發一般是一個人獨立進行，不像其他程式開發需要他人參與或者存在配合問題，所以很多人寫微控制器都是根據自己喜好和理解去寫的。所以你會發現同一款微控制器，同一個需求，不同的人寫會出現大不同的效果。從而讓你覺得規範性很差，啥寫法都有，但是事實上每個人都在堅持自己的程式碼風格，只是這種風格因人而異。

2.微控制器資源有限，所以面向物件那一套低效率的方式與思想很多時候並不能實現。或者有些操作必須要進行取捨，否則微控制器無法穩定工作。說明白點，寫微控制器資源不是隨手就有的，因此要讓速度快還需要空間小，所以c語言都不能實現的時候只能用匯編。因此你會發現，有些時候c夾著彙編寫，這不是有意為之，而是無奈之舉。微控制器程式設計非常注重資源重用，跟面向物件注重的程式碼重用是背道而馳的。因為面向物件已經硬體無關了，隨便new，剩下的事情跟他沒關係。但是微控制器不行啊，你隨便寫佔用太多太久資源，到時候估計連記憶體分配都會失敗。

3.嵌入式開發是和硬體打交道的，而我們一般強調的規範性與複用率卻需要硬體無關。因此，程式碼複用率可移植性會差很多，很多時候不經過修改根本就沒法用。所以你會看到同一個人不同微控制器實現同一個功能，他的寫法也不一樣。

4.還是因為硬體相關的特性，使得嵌入式開發有些時候內聚性很差耦合度很高。畢竟嵌入式開發的原則就是資源利用率要高，其次才是其他的，而在功能實現上，為了達到目的，或許選擇全域性變數以及別的破壞性的使用全域性變數變成了必選項。雖然也能封裝的很好，但是那並不利於程式的高效性和程式碼量。

5.雖然很多傢伙都說別人看不懂的程式碼最垃圾，但是我覺得那是面向物件才應該面對的問題。微控制器程式碼就那麼點，還是一個人完成，而且完成以後很少需要改動（你想想你們公司的穩定產品，還有誰會想著去最佳化改進），這需要別人看懂嗎？換句話說，在我看來嵌入式開發中，別人越是看不懂越是牛逼的程式碼，因為那往往是精簡過後非常高效的程式碼。或許一個萌新寫了一大堆程式碼，跟著流程寫程式碼然後備註的很清楚，從哪一步到哪一步，哪一步幹了啥，所以很多人看明白了。但是老鳥十幾行就解決了，已經不是普通的流程了，指標，移位等等一通操作，怎麼快怎麼來，怎麼簡單怎麼來，這時候有人看不懂了。所以在他的認知裡可讀性就很差了，所以就是垃圾程式碼。

6.可維護性一直都是嵌入式的一個短板。面向物件不開心你可以重寫一個類，只需要測試你重寫的類ok那就沒問題。但是嵌入式你沒有理解清楚原有函式的實現原理和作用，就瞎改的話，嘿嘿你等著原地爆炸吧。因為即使內聚性很好的函式，如果涉及到資源爭用（比如對uart的輪流使用，操作原子性，變數互鎖等），你會發現這他麼不是該這個函式這麼簡單，裡邊用到的資源都特麼要重新稽核一遍。你是不是要崩潰？所以一個好的嵌入式程式，或許可維護性會很差，因為事實上根本就不需要維護。研發穩定後，我幾乎就不會做任何修改了，也拒絕別人修改我的程式碼，改進只會在新的專案裡改進。所以在我看來需要維護的嵌入式程式碼都是收拾別人的爛攤子，畢竟一個人做事還做不好那是你水平問題。

所以你可以看到現在很多的嵌入式系統（ucos，freertos等等），都在力求硬體無關以及可移植性，但是卻又尾大不掉，其實目的無非就是為了可維護性和可讀性。

所以嵌入式質量我覺得應該從，資源利用率和穩定性以及程式碼量達到最優，換句話說，只要他硬體需求少，不容易跑飛，bin還不大，哪怕他程式碼寫成狗屎，備註全無，那也是好的程式碼。