前些年嵌入式程序猿非常難找工作也難招人，但今年不一樣了_風聞

【本文來自《告別工業4.0思維----這才是悲傷的技術脱鈎》評論區，標題為小編添加】

我的感覺和作者有些不一樣，近期因為在找工作，所以有些感觸。

(一)需求

前些年，不管是我找工作還是我招人的時候，嵌入式(包括單片機)程序猿是非常難找工作也非常難招人的，即使有，那薪酬待遇也充斥着滿滿的惡意！就那麼幾年，就把這個專業方向給摁下去了，好多人都轉行了(也包括我)。

但今年不一樣了，總是有人給我發消息，要麼讓我接私活的，要麼讓我去應聘的，煩死了。我都很多年沒碰芯片了，再加上年紀也來了，不論是記憶力還是精力都大不如前。搞嵌入式，還個個都要你做系統移植，太燒腦，已經做不來了。感覺今年在芯片應用領域的用人需求大幅上升，而且待遇都非常不錯，可惜我已經吃不上這口熱乎的了。

(二)危險

另一個感覺，就是很多涉及物聯網或者工業互聯業務的公司，都被C#程序猿給帶歪了。作者提到的封閉的技術圈子，應該就和我描述的情況很類似。

通常設備端的控制器(PLC或單片機)對外通信時，絕大多數會首選485作為物理層，然後在應用層再使用各種物聯協議經過物聯網關，嵌入到TCP或者UDP報文中發送給上位機。然後上位機直接解析通信數據。

問題就在於現在的企業(包括很多關鍵基礎設施國企，以及以國企為目標客户的民營設備供應商)，他們不管是招聘上位機，還是招聘嵌入式，都變成了標準格式：“熟練使用modbus、PPI/OPC、canbus、MQTT等通用物聯協議連接上/下位機。”

為啥會這樣？？？因為C#對上面這類通用協議都提供了完善的工具庫。只要設備端用的是這些通用協議，那麼上位機C#程序就可以很輕鬆的實現PC(服務器)和設備控制器之間的數據通信。而如果不用這類通用協議，那麼很難在C#下實現自定義協議。

不管是從微軟的角度，還是從程序猿的角度，這都算不上什麼壞事，這樣的便利大大提升了C#的使用體驗，也將C#在工控領域的地位，從一個邊緣語言推到了幾乎首席語言的地步。過去的工控之王LabVIEW都只能甘拜下風。C語言在PC端更是被擠沒影了，只有我這樣的老不死，才會堅持用C語言幹活。

但這真的是一件好事麼？

不是！不光不是好事，這還是一件非常低效且危險的事！！

MQTT我不算太瞭解，只知道好像是由IBM設計的一款物聯網協議，近幾年一直很紅，幾乎成為了行業標準。通常會將它嵌入http協議中使用，因此這個協議是具備身份識別能力的。注意關鍵詞：身份識別能力！

而據我所知，不論modbus還是PPI，這類專門為485串口設計的協議，都不具備身份識別能力。也就是説，當你的設備在使用這類協議上網通信時，任何通過互聯網發送給設備端的數據，它都會按照標準流程進行解析、應答和執行。

假設你的設備正是採用這類協議上網，而且你還設計了一個遠程關機功能，那麼當他收到來自互聯網的遠程關機指令報文時，它並不會去甄別發送方是否擁有讓它關機的資格。如果這個設備只是你家客廳的壁燈，那當然無所謂？可如果這個設備是某變電站的冷卻水泵呢？或者其他什麼要命的設施呢？？人人都可以遠程關閉它們？？？

另外，PPI也好，modbus也罷，當初都是為了監控PLC產品，而設計的官方串口通信協議。這類協議為了讓PLC編程軟件擁有能夠修改指定變量的能力，所以都被設計為一條報文完成一個動作的形式，按照標準使用規範，他們無法一次傳遞多個數據，這就導致通信效率很低。

所以，modbus和PPI的通信效率根本就不適合用來做物聯網或者工業互聯網。但在C#的助力之下，如今卻成了物聯網領域的當紅協議。這不得不讓人感到可怕。聽説前幾年伊朗的核電站被人遠程整滅了，希望這類故事不要在我們這裏出現，不論是國家設施，還是家用設施，都要杜絕這種事故的可能！

解決這類問題也很簡單，就是不要讓你的設備使用那些通用協議上網，儘量使用原創的自定義通信協議！互聯網很危險，裸奔會死人！⚡️⚡️⚡️