轉自@快資訊用戶1915030548

在2000年前后，嵌入式軟件工程師有著一套非常具體的技能，他們通常是電氣工程師，不僅了解底層硬件的工作原理，還可以再底層編寫匯編代碼或者C語言代碼，以使系統滿足實時需求。嵌入式軟件工程師不僅要了解諸如C語言的軟件開發，還要了解硬件。位、字節、寄存器的世界，正是嵌入式軟件工程師的領域。

傳統的嵌入式C語言程序員快要滅絕了？

但是如今不再那么簡單了。

在早期，嵌入式開發人員通常使用 8 位或者16位的體系結構，這些結構比較簡單，因此開發人員一般在幾個月的開發周期內便能掌握這些結構。

但是近些年來，許多嵌入式開發團隊已經轉向更加復雜的 32 位體系結構，不僅包括一些用于數據采集的采樣傳感器，以及外圍的通信設備，還包括日益繁多的各種協議，例如 USB、DMA、 TCP/IP、藍牙等。這些復雜的體系架構，或者相關的通信協議，開發人員往往需要數年才能真正的完全掌握。

嵌入式系統已經變得復雜

顯然，嵌入式系統已經變得極其復雜。將硬件設備連接到互聯網，以創建物聯網的巨大需求，在以往傳統的嵌入式C語言程序開發中是沒有出現過的。所以，這一“巨大需求”導致了一個真空——相關公司找不到足夠的嵌入式C語言軟件開發工程師了。

為了應對“真空”，有些公司并未大力培養嵌入式C語言軟件工程師，而是開始依賴具有Windows應用程序或者移動設備程序開發經驗的人員來開發他們的實時嵌入式軟件。這會導致另外一個較為致命的問題出現：這些開發人員大都只了解公司分配的任務所需的高層應用程序框架，對底層硬件卻不夠了解。

這樣的公司并不在少數。因此微控制器制造商目前正在大力推動為開發人員提供高層的軟件框架和工具，真正的硬件底層開發，則由制造商完成。這使得嵌入式軟件開發人員，甚至應用程序開發人員更容易在更高層上編寫軟件，他們不必再擔心底層的硬件了，因為相關的“輪子”已經“出廠自帶”了。

相關的“輪子”已經“出廠自帶”了

顯然，這樣的嵌入式程序開發模式更加有利于一些嵌入式公司降低成本，加快產品上市時間。但是我們也可能發現，關心位、字節、寄存器的傳統嵌入式C語言、匯編軟件開發工程師顯得沒那么重要了，可能很快就會“滅絕”。

未來的嵌入式軟件工程師將與傳統的前輩們有著不一樣的技能，他們也不再關心硬件底層，不再關心位、字節、寄存器，也不再關心任務的實時性，事實上，他們可能不再關心任何傳統嵌入式程序員需要關心的東西。未來的嵌入式軟件工程師可能只需要具備應用程序開發技能，知道如何調用一個 API 讓硬件做事。

但是，他們不知道為什么要這么做，以及 API 到底是怎樣命令硬件做事的，所以他們也不具備實時調試硬件的技能甚至概念，無法深入到寄存器中。這些工程師，更像是遠離硬件的 Windows 程序員。

了解底層硬件的傳統嵌入式程序開發人員永遠都不會被“淘汰”

未來嵌入式軟件開發人員不具備底層硬件開發能力不一定就是百分之百的壞事，至少這樣的開發模式允許一些缺乏關鍵技能的開發團隊或者公司繼續發展下去，這一點可以從移動設備領域看出。

了解底層硬件的傳統嵌入式程序開發人員永遠都不會被“淘汰”，否則誰能提供 API，讓上層應用程序開發人員調用，以控制硬件工作？

然而現實是，傳統嵌入式程序開發人員被公司忽略了。很多高科技公司更加青睞機器視覺、機器學習和其他尖端研究領域的開發人員，值得說明的是，這些尖端人才往往不屑于驅動硬件這類“基礎工作”。但是，如果沒有程序員能夠與硬件設備溝通，所謂的“機器”視覺和“機器”學習又怎樣才能實現呢？