物联网操纵体系几近都是在传统的RTOS（如FreeRTOS、UCOS）增加收集和谈栈成长起来的。因为Linux本身掩护收集和谈栈，以是也有操纵体系是高度裁剪Linux内核而来，可是因为linux须要跑MMU，以是普通须要高等CPU，也须要M级别的RAM。本文转载自知乎手艺博文（//zhuanlan.zhihu.com/p/23618181），并停止局部删减点窜。

一、操纵体系清单

Brillo (a solution from Google for buildingconnected devices)

mbedOS (ARM mbed, The ARM IoT DevicePlatform)

RIOT (The friendly Operating System for theIoT)

Contiki (an open source operating systemfor the IoT)

Zephyr (a small, scalable real-timeoperating system for use on resource-constrained systems)

Nuttx (a RTOS with an emphasis on standardscompliance and small footprint)

除零丁对这些OS先容外，咱们也会来个横向大比拼。方针是让名目担任人，产物司理在对体系选型的时辰能有个公道的参考。嵌入式体系中，固然是Linux。但当体系较小，才能缺乏以跑Linux的时辰，就很轻易纠结，出格是对生态要求很高的操纵。

二、Brillo

//developers.google.com/brillo/

Brillo: Google’s OS for IoT MPU devices

• Targeted at smarthomes

• Expanding to buildingsand industry

• Supports MPU devicesw/ min 35MB of RAM

Brillo须要跑在带MMU的AP上。其实很明显，Brillo基于Android，它再怎样裁剪，也是须要跑在Linux，Kernel上还要打一堆patch。只是它把Android上对图形、JAVA假造机及Framework十足扩充掉。只保留了C/C++运转情况，Binder IPC，SSL等收集必须组件。这也就象征着在Brillo上开辟APP其实是Native的，并且驱动法式都由Android的那套HAL来做笼统，以是操纵法式是间接和HAL、Lib来打交道。

Brillo 架构框图

 

看似Google放了个IoT的操纵体系出来，现实Google今朝专一于操纵处景中功效绝对壮大的节点，或边境节点Border Router如许的脚色。最主要的是Google操纵Weave买通了装备节点到Google云端的通道。Google现实上是用了最小的价格，完成了挪动装备平台Android、物联网节点和本身的云端的互联互通。至于那些跑不了Brillo的节点怎样互联互通，Google交给其余人去斟酌了，归正Brillo也撑持6LowPan, Thread之类的和谈。若是你写过Android HAL/Service，那末开辟Brillo App轻而易举，间接挪用Device HAL去操纵装备；挪用WeaveAPI去做通信。

int ret =hw_get_module(LIGHTS_HARDWARE_MODULE_ID, &module);

if (ret || !module)

err(1, "Failed to load %s", LIGHTS_HARDWARE_MODULE_ID);

ret =module->methods->open(module,

LIGHT_ID_NOTIFICATIONS,

reinterpret_cast<structhw_device_t**>(&light_device));

if (ret || !light_device)

err(1, "Failed to open %s", LIGHT_ID_NOTIFICATIONS);

以上代码挪用HAL同一接口翻开一个LIGHT装备，是否是很熟习？而后起个Daemon,操纵Weave API来领受从收集下去的XMPP要求，对装备停止设置装备摆设或状况监测。在云端和挪动端，可以或许或许或许或许操纵网页版的Weave Developers Console和Weave App来节制监测装备。

Brillo可以或许或许或许或许在资本较少的MPU上跑，35MB内存就行，老的ARM9估量也可以或许或许或许或许。它可成立良多低本钱的装备节点，用来和智能装备、云端通信，或作为PAN内装备对外的桥梁Border router。Brillo可玩性应当很高，家里的PC机，路由器都可以或许或许或许或许拿来跑，生态体系壮大。但致命错误谬误是，咱们在天朝啊，你晓得。信任国际的BAT之类，会斟酌移植，革新，变异。就如对Android普通。

二、mbedOS

2.1 简介

mbed是ARM本身成立的IoT处置计划平台

The ARM mbed IoT Device Platform providesthe operating system, cloud services, tools and developer ecosystem to make thecreation and deployment of commercial, standards-based IoT solutions possibleat scale.

它被ARM分红三大局部

mbed Cloud

mbed Device Connector

mbed Client

ARM竟然也本身搞了个Cloud，可以或许或许或许或许经由过程“mbed DeviceConnector”来拜候毗连到云端的装备。并供给网页版的Connector来办理装备，用户可以或许或许或许或许经由过程RESTful API over HTTP来写本身的APP。

“mbed Client”的界说是如许的：

 a library that connects devices to mbedDevice Connector Service

看似比拟奇异，其实便是一套可以或许或许或许或许移植到各类操纵体系上的，可以或许或许或许或许和mbed Device Connector Service通信的，跑在硬件装备上的软件库。它操纵基于UDP的CoAP和谈来通信，操纵mbedTLS来完成毗连，兼容LWM2M。

2.2 mbed Client 架构

 

说到这里，咱们的配角mbedOS该退场了。ARM为了在基于ARM Cortex-M内核的硬件平台上完成对装备的操纵，及经由过程Device Connector拜候云端，它必须有一套可以或许或许或许或许撑持mbedClient的软件处置计划。mbedOS既是基于RTOS内核，并供给各类ARM SoC硬件平台驱动和BSP的操纵体系，在此之上，完成全部mbedClient库。在PAN的物联地区内，装备与装备的通信都可以或许或许或许或许操纵mbedOS供给的计划来处置，它撑持NFC，RFID，BLE，6LowPAN乃至是Thread。在装备与云端的通信上，mbedOS既撑持以太网，WiFi，也撑持3G。跑mbedOS的装备既可以或许或许或许或许是装备节点，也可以或许或许或许或许是边境路由器（比方6LowPAN转IPv6），也可以或许或许或许或许和智能装备经由过程BLE通信。mbed Device Connector又可以或许或许或许或许操纵CoAP和谈在装备端和云端通信。

2.3 mbedOS对收集的撑持堪称很壮大

LWIP IPv4/v6, TCP/UDP

mbed BLE stack

6LowPAN (host, router, border router)

Thread (ED, router, border router)

BSD socket API

除此之外，它还撑持

文件体系：cfstore,flash-journal等

C++的驱动接口，及驱动笼统层HAL

几近一切操纵ARM CortexM核的大厂硬件平台。广度可以或许或许或许或许，但深度有待进步

 也便是说mbed把每类驱动都笼统成一个基类，真正做驱动移植的时辰，从这个类派生出来，而后完成呼应的HAL函数。使得用户在实例化该驱动派生类后，可以或许或许或许或许挪用呼应的类接口，从而拜候现实的装备驱动法式。比方AnalogIn::read()，是前往ADC的采样成果。

2.4 mbed生态

ARM供给在线IDE，可以或许或许或许或许在线疾速编译

线下的开辟情况也简略易用, mbed cli近似于android的repo

github上的例子良多，参考性强

社区绝对照拟活泼

协作火伴浩繁

ARM搞起了云和RTOS，使人遐想到之前的Linaro，看似远景不错。并且听说国际的BAT也有在操纵mbed做产物，其实就把mbed Cloud换本身的云，革新下DeviceConnector便可。本身也正在研讨mbed，今后会写些操纵心得。

三、RIOT

//github.com/RIOT-OS/RIOT

3.1 简介

The friendly Operating System for theInternet of Things

RIOT官方的标语:)

if your tiny IoT device can’t run Linux,use RIOT

RIOT是面向开辟者的，开源的，合适物联网的操纵体系。它的面前不某个公司的撑持，而是由社区驱动。

他的一些特征：

规范的C/C++编程

规范的gcc编译情况

可以或许或许或许或许跑在8位，16位和32位的嵌入式体系上

局部的POSIX接口兼容（今后的方针是全兼容）

撑持在Linux/Unix的假造机上运转

及时性，疾速的间断呼应（~50 clockcycles）

微内核，组件都可以或许或许或许或许静态加载，并且经由过程message来完成办事

极小开消的多线程撑持（< 25 bytesper thread）

丰硕的收集撑持：6LoWPAN，IPv6，RPL，CoAP and CBOR

高精度的按时器

丰硕的工具 （System shell, SHA-256, Bloom filters, …）

3.2 RIOT 架构框图

 

RIOT的CPU的IP驱动根基都有一套同一接口，可是不笼统层，被放在源代码的cpu\periph中。这象征着在做新的平台撑持时，你要注重驱动的接口要和API文档里的分歧，比方ADC的adc_init(), adc_read()。源代码的drivers则放着板级的驱动，比方NXP的MMA8541，操纵i2c同一接口来拜候。

因为是微内核（microkernel）的完成，一切的体系办事包含时钟、收集和谈栈、收集办事等，都是经由过程建立自力的线程来完成。在线程中都有event_loop来领受办事要求，处置并发送办事成果。RIOT中最关头的是GNRC（Generic network stack）收集和谈栈，它完成了从MAC层一向到传输层的各类和谈，如6LowPan，IPv4/v6，RPL，TCP/UDP。并且这些差别的和谈栈之间经由过程netapi同一接口开放给用户。对操纵层来说，GNRC供给了conn和socket两种API。在方面，貌似802.15.4这层不插手AES的撑持，只供给tinyDTLS在操纵层给用户操纵。因为RIOT的POSIX的局部兼容性，及供给BSD socket的接口，良多操纵都可以或许或许或许或许便利的移植过去，在pkg/你能找到比方libcoap，openwsn如许的操纵。

 RIOT最早是由柏林自在大学开辟的，今朝由社区掩护，貌似欧洲开辟者占多数。从devel maillist里来看，感受社区活泼水平普通。每两周都有一个Virtual meeting，都仍是大学在牵头。

总之，一个很有设法的微内核，加上开辟情况绝对之前熟习Linux的开辟者来说很友爱。应当是个潜力股。

四、Contiki

//www.contiki-os.org/

4.1 简介

以下是维基百科对Contiki的先容：

Contiki is an operating system fornetworked, memory-constrained systems with a focus on low-power wirelessInternet of Things devices. Extant uses for Contiki include systems for streetlighting, sound monitoring for smart cities, radiation monitoring, and alarms

可以或许或许或许或许看得出来，本来Contiki是为智能城市而降生的。撑持的平台无限，根基是内部集成CC24xx/25xx，MC1322x之类Radio的SensorTag平台，或一个很小的MCU加上这些Radio模块的平台。从它所撑持的平台也能看出，Contiki加倍专一于小型传感器节点。它更与PAN内的节点通信，固然他也有传统的IPv4/v6，TCP/UDP撑持，使得操纵CoAP可以或许或许或许或许用来和云端通信。

4.2 Contiki的特征：

完全的收集撑持，HTTP，UDP/TCP，和低功耗和谈6lowpan，RPL和CoAP。全部IPv6和谈栈都是有思科进献

特地为小内存装备设想的内存办理器

玲珑的预算功耗的工具

丰硕的实例

撑持内部Flash的Coffee flash文件体系

Protothreads，事务驱动及多线程的编程模子

Cooja收集摹拟器

Rime和谈栈，比IPv6更轻量级的收集层

Contiki也是个微内核（microkernel），一切的体系办事都是经由过程启线程完成，Protothreads线程整合了线程间事务通信，使得编写体系办事很是轻易。驱动法式方面，Contiki差别一的驱动法式框架，驱动都是各家MCU自带开辟包供给，如许的益处是可以或许或许或许或许保障天生的二进制代码够小。

Contiki有个很有特色的摹拟器，Cooja Network Simulator，可以或许或许或许或许运转良多例子，并且可以或许或许或许或许监控全部收集的包及节点状况。如许可以或许或许或许或许让用户在不充沛硬件装备的前提下做开辟。 

 Contiki社区根基依托maillist会商题目，github做pull request。从maillistarchive里看，社区活泼水平很普通。

五、Zephyr

//www.zephyrproject.org/

Zephyr竟然是Linux基金会的协作名目。应当是由INTEL将WindRiver的商用操纵体系WindRiverRocket局部开源后降生的名目（本年才降生）。今朝可用材料未几，并且撑持的硬件平台较少，ARM的平台就没几个。

Zephyr像极了Linux，它的源代码目次布局Kconfig操纵体例，启动流程，Driver Model都可以或许或许或许或许看出来。用户的操纵法式是启动后建立的一个线程，用户的main()会在一切的驱动，组件及硬件板子初始化后被挪用，驱动操纵DEVICE_INIT()，组件操纵SYS_INIT()初始化，并带有优先品级。驱动城市遵守同一的驱动布局：

struct device {

struct device_config *config;

const void *driver_api;

void *driver_data;

};

以是驱动要本身界说一个设置装备摆设布局，一套API的函数指针，和驱动状况布局。和Linux很像。

收集撑持很奇葩，和谈栈竟然都是用的Contiki的，Bluetooth还算比拟全。子体系方面，文件体系、USB都是很简略，很原始的撑持。mbedTLS和tinyDTLS被拿了过去。

整体来说，Zephyr还处于早期，良多工具都不完美。Owner又是Intel，但愿别重蹈Moblin的复辙。

六、Nuttx

//www.nuttx.org/

Nuttx,及时操纵体系，POSIX接口撑持，Loadable内核模块撑持，BSD socket，MMU撑持，等等。我只能说，长的太像Linux了。Build也是Kconfig，目次布局也根基和LinuxKernel一样。

ARM的核根基都撑持

文件体系也是VFS撑持，大而全。收集的，NAND MTD的，pseudo都撑持

本身的Clib,也可以或许或许或许或许撑持uCLib

收集和谈栈，可是不wireless！

有本身的USB和谈栈

我一起头没筹算谈Nuttx，他的无线撑持很差，就更别谈无线互联了。可是BAT竟然有人用它做云OS。估量是团队其实太熟习Linux了，跑不了Linux也要找个近似的开辟情况。有了BAT的撑持，Nuttx估量可以或许或许或许或许发财了。

七、大比拼

这里用一张比拟简略的表来对照这些操纵体系和生态

 

除Brillo之外，其余都是RTOS有很小的内核。法式所占的内存和代码巨细取决你须要的硬件平台的驱动几多，须要甚么样的和谈栈等等的功效。

八、开头

比来行业趋向有所变更，除互联网仍然炽热外，大师的核心无疑都从手机投向了汽车、产业、物联网。大师都但愿可以或许或许或许或许操纵物联网和互联网将传统行业中的产物完成互联互通，完成信息同享、进步糊口、出产效力和品质。咱们所任务在的半导体行业中，除给市场供给更合适须要的处置器之外，咱们还须要供给基于本身处置器的软硬件处置计划。操纵体系作为操纵的根本、基石，显得很是的主要。本文只是精致的先容和对照了这些物联网的操纵体系，但愿能对读者有所赞助。