前些年嵌入式程序猿非常难找工作也难招人，但今年不一样了_风闻

【本文来自《告别工业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#的助力之下，如今却成了物联网领域的当红协议。这不得不让人感到可怕。听说前几年伊朗的核电站被人远程整灭了，希望这类故事不要在我们这里出现，不论是国家设施，还是家用设施，都要杜绝这种事故的可能！

解决这类问题也很简单，就是不要让你的设备使用那些通用协议上网，尽量使用原创的自定义通信协议！互联网很危险，裸奔会死人！⚡️⚡️⚡️