那么，现在的嵌入式开发是怎样的？相比十年前、二十年前有什么发展？“物联网”这一大概念下，应用开发者应从何切入？

 嵌入式操作系统现状

 目前嵌入式设备主要分为两大类：MCU设备和带MMU的CPU设备。

 MCU（MicroComputing Unit），也就是我们常说的单片机，其特点是Micro：主频大概在几十MHz，内存在几KB，Flash非易失存储也是几十KB，资源小，价格便宜。单片机这个领域从80年代、90年代开始就一直有人玩，像是玩具、闹钟、计算器、电子表、工业控制等很多领域都有用到，应用广泛。单片机程序的特点是逻辑简单、实时性强没有等待，不像Linux那样会存在资源被其他程序占用的情况。

 早期单片机程序一般都是裸写C代码的方式，用一个大循环把所有事情搞定，所有的底层功能——如资源分配、进程调度、DNS查询、域名转换等，都要手写实现。前几年开始有一些基于MCU的操作系统，比如μC/OS、RT-Thread等，单片机有了操作系统就相当于资源分配、进程调度等工作不用手写了，可以交给系统去管理，程序员不用去管任务间协调的问题。这可以看作是第二代单片机开发环境。

 近几年有一些新的单片机操作系统，比如Contiki，这套系统的特点是把互联网特征作为基础的构建。这套系统很牛，用10KB以内的内核就提供了对HTTP、TCP/IP等协议的支持，让单片机上来就可以联网，让单片机开发者绕过了每次都要裸写这些基本功能的痛苦。

 现在的单片机有些很神奇的应用，比如图像识别、语音识别，可以做到在视频上识别色块的程度。但是，单片机如果又要做图像识别又要上网，就会非常吃力，毕竟资源十分有限，需要有很高的开发能力把它们协调好，这种情况下就不能用操作系统了。

 以上是单片机的情况。另外一种是更大一些的，就是自带MMU（Memory ManagementUnit，内存管理单元）的设备。这种设备的主频一般在几百MHz以上，内存在几十MB以上，早些年的智能手机就差不多是这个配置，跟十几年前的PC机配置差不多，所以安装运行Linux系统是没有问题的。这类设备其实也做了十多年了，现在用的比较多的架构有两个：ARM和MIPS，都是商业的，现在新的硬件基本上都是这两种架构。

 有很多发行版都专门为ARM做过安装包，比如流行的Ubuntu和Debian。无论是ARM还是MIPS，因为有了系统，开发起来要比在单片机上舒服多了，但也仍然有一个很麻烦的地方，那就是要做交叉编译。开发者一般都是在自己电脑上——大部分是x86架构——完成开发的，因此要用x86上的ARM编译器交叉编译出ARM的二进制文件，用MIPS编译器交叉编译出MIPS的二进制文件，才能在设备上运行，这为调试带来了不小的麻烦。为什么我们这个圈子门槛比较高，就是因为一般都是掌握了交叉编译的开发者才会进来玩。不过好在有一个叫做GDB（GNU Debugger）的工具可以做远程调试，减少一些麻烦。

 物联网终端需要完成的工作

现在在有一种M2M（Machine to Machine）的思路，在终端用可以联网的单片机做最简单的事情，比如开关一个灯泡；终端直接跟家庭网络的网关（路由器）连接，或直接跟公网的云端连接，由云端做更复杂的计算和处理。

 这种思路可以解决一部分问题，但是我觉得还不够。终端需要做更多的事情。

我认为终端需要是智能的，它们需要达到“机器人”的层面。现在我们说的机器人跟以前大家理解的那种人型机器人不同，现在所说的机器人是一种复杂控制系统，是软件，可以跑在各种各样不同姿态的设备上。机器人需要完成三项工作：

· 感知：从传感器采集数据

· 交互：网络传输（如HTTP、TCP/IP）和物理控制

· 智能：如图像识别、语音语义的理解、智能规划，需要抽象成智能的算法

 现在的机器还处于太过依附于人类的状态，需要人告诉他要做什么。我觉得未来的机器应该自己知道要做什么事情。现在的人工智能、知识图谱的建立就是奔着这个方向去的，比如Google工程师训练机器，让机器在Youtube的视频里认识猫，这个涉及到一个很大的知识库和训练过程，需要云端的协助。但最终训练出来之后，其实猫的图像识别特征数据是很小的，可以放在终端的机器人里，他们自己就会认识猫了。这就好像婴儿的学习过程一样。

 但是跟婴儿不同的是，机器天生是执行器。所以结合认知能力，让机器认识猫了之后，加上执行，是不是可以让机器自动的去抓猫或者逗猫玩？机器认识电梯之后，是不是能够自己去按电梯？机器认识无线充电站后，是不是能够自己跑到无线充电站上面蹲着充电？随着知识图谱的建模完善，事物和事物之间的联系能够被机器理解，机器人会变得越来越强大，越来越重要。

其实现在语音语义的知识图谱建设已经相对完善了，机器已经能够理解一些上下文之间的关系，比如你说到吃苹果，他就知道你说的是什么意思。我们现在在语音语义+网络这块直接使用了讯飞的服务，我们把工具链给他，他们帮我们生成了一个二进制包给我们，就很方便了。

技术上的挑战

 上述这些工作当中，有些单片机可以完成的很好，有些不能。单片机可以采集一些简单的数据如位置、高度、重力加速度、四轴姿态、温度、湿度等，进来都是数字，只需要做AD转换。比较复杂的数据如声音、图像，单片机处理起来就比较困难，一般我们通过Linux的USB驱动来跑，需要MMU的芯片。但是单片机有一个特征是Linux无法满足的，就是实时性。很多物理控制对实时性的要求很高，比如四轴飞机的控制，严格要求50Hz的控制频率，即一秒进行50次计算来决定下一帧的动作，如果稍微有点资源抢占造成延迟，飞机就掉下来了。

 为了同时达成实时计算+复杂性这两个目的，我们只好把两个芯片加在一起。但是两个芯片在一起，就成了一个分布式系统，有芯片级的通信问题，同时开发者还需要写两套代码，又要写单片机的交叉编译，又要做Linux开发，各种调试和测试的困难。Arduino现在已经有一套挺完善的思路：首先它的传感器、控制器的库都很全，然后它做了一个ArduinoYUN的板子，就是一个OpenWRT（一个超级精简的Linux发行版）+单片机的双芯片板子，然后它有一个万用固件——一个支持firmata协议的库，算是一个翻译，只要符合这个协议就可以从Linux控制Arduino，算是一种思路。但是我觉得这个思路有两个问题：第一，ArduinoYUN的思路是以MCU开发为主，把OpenWRT当做单片机的透传模块，为单片机提供网络服务。放着强大的芯片在一边，用小小的单片机跑主程序，感觉未免太浪费。第二，firmata协议虽然简化了控制，但是又影响了实时性，在实时性要求较高的时候（比如四轴飞机），这种思路又无法满足需求了。

 现在一些芯片公司已经开始意识到这个问题，开始考虑如何把两者封装成一个芯片，来满足实时性+复杂性的结合。我认为封装后应该要以Linux为主要的开发平台和软件运行平台，以MCU作为辅助以满足实时性需求。

 所以，实时性+复杂性的结合是第一个挑战。第二个挑战是复杂运算的加速，比如H.264/H.265的视频压缩、图像识别的硬件加速，要不要放在机器人的芯片里？我觉得是需要的，但是不需要手机那么强的GPU，有一个视频压缩的芯片放在里面就可以。终端如果能做视频压缩，多半也能做图像识别，那么终端机器人可以做的事情就更多。

 第三个挑战是针对Linux内核本身的，就是在这种级别的计算平台上如何进行更合理的裁剪、做更合理的算法策略、执行策略。OpenWRT的开发版现在我们做到64MB的运行时内存占用，而一般的路由器芯片都是16MB、32MB。其实内存的空间占用倒不是大问题，因为现在内存很便宜，就算用到128MB、256MB也没什么，但是关键在于时间片的占用。所谓省资源其实就是两个意思：少占地儿+少占时间，这样才能低延迟。所以Linux内核如何解决这个问题，也是一个比较大的挑战。

 这三个点可能是未来几年这个产业很多人的努力方向。

 总结

 相比十年前裸写C代码的场景，现在我们有图形化的界面，有RESTfulAPI，嵌入式开发的难度可以说已经大大降低了。虽然有上面提到的基础设施与开发工具的挑战，但我认为用不了几年时间也都能解决。网络连接现在已经基本不是问题，3G、4G、Wifi已经足以支撑大部分智能设备的应用场景。

 但是，仅仅有这些，到“智能的物联网”有很大的距离。机器需要学习更多、建立更多的知识图谱，才能变得更加强大。现在云端还没有太多现成可用的知识图谱，但我们仍然可以先从简单的事情做起，比如让机器人扫地，让机器人把空瓶子扔进垃圾桶，一点一点的改进它们。也希望有更多的开发者能够加入这一进程，让我们的世界变得更加完整。