| title | date | categories | tags | ||
|---|---|---|---|---|---|
Zephys OS 基础篇：漫谈Zephyr与Contiki的未来 |
2016-08-26 12:22:24 -0700 |
|
|
从一接触 Zephyr OS 开始，我就不断地将它与 Contiki OS 进行比较，以预测今后的发展趋势，以判断自己今后的学习方向。 Zephyr OS 从 2016 年 2 月诞生，它究竟会如昙花一现般地快速消亡，还是会奇迹般地犹如 Linux 一样长久闪耀。今天，我终于找到了答案。
嵌入式的操作系统何其之多，我所知道的就有：
- Linux, 毫无疑问的巨头，单对于物联网来说，它太庞大了；
- Threadx, 这是我现在的公司使用的操作系统，感觉很小众，而且貌似收费的；
- freeRTOS，简单地接触过一点点，在上家公司做智能插座，就使用的它，但是没有深入研究其内核代码；
- Contiki，专门设计用于物联网的操作系统，现在很火...
- TinyOS，也是设计用于物联网的操作系统，最大的弊端——非 C 语言开发，增加了入门的学习成本；
- mbedOS，arm 公司专门为物联网而设计的操作系统，没接触过，不了解；
- Zephyr，专门设计用于物联网的操作系统，Linux 的孪生兄弟，也是今天的主角；
- uCos-II，没接触过；
- WinCE，没接触过，不过感觉没什么市场了；
- VxWorks，主要用于高端的对实时性要求很高的嵌入式设备，比如航空航天；
- uClinux，没接触过；
在这些众多的操作系统中，现在比较火的、适合于物联网的操作系统有freeRTOS, Contiki, Zephyr(目前还未火)。
对 freeRTOS 的内核接触不多，所以今天讨论的主角是 Contiki 和 Zephyr。
对于一个硬件，我们可以将其分为两部分：CPU 和 外设。对于一个企业，我们也可以分为两部分：芯片厂商和应用厂商。芯片厂商负责生产 CPU，各个应用厂商购买芯片厂商的 CPU 加上需要的外设构成自己的产品。
我们需要注意到一点，即同一颗 CPU 会卖给多个应用厂商，形成多种产品。这对操作系统的可移植性设计有重要的影响：将 CPU 相关的特性用单独的代码实现，将外设相关的特性用另外的代码实现，将两者相互分离。这样做的好处是各个应用厂商可以重复利用 CPU 相关的代码，只需要修改外设相关的代码，减小了开发成本。Contiki 和 Zephyr 都很好地注意到了这点，我们可以从它们的目录结构中看到：
- Contiki 包括两个芯片相关的目录 cpu 和 platform
- Zephyr 包括两个芯片相关的目录 arch 和 boards
在 Contiki中，CPU 相关的代码位于cpu目录下，外设相关的代码位于platform目录下。在 Zephyr 中，CPU 相关的代码位于arch目录下，外设相关代码位于boards目录下。这里的 platform 和 boards 是完全对等的概念，cpu 和 arch 是略有区别的概念，而这个区别对可移植性有重大的影响。
Contiki 为每颗 CPU 单独实现了代码。Zephyr 为每种架构单独实现了代码，这样做的好处是让各个相同内核的 CPU 可以共用一套内核代码，比如 atmel_sam3, st_stm32, ti_lm3s6965 都共用了同一套 Cortex-M3 内核的代码，这大大减小了开发芯片商的开发成本。
因此，从可移植性上讨论，Zephyr 更胜 Contiki 一筹。
注：外设相关的代码还位于驱动目录下，后面单独讨论。
Contiki 和 Zephyr 均支持多线程，但是它们具有本质的区别。Contiki 是经过精心设计，用单线程来模拟的多线程，是一个纯软件实现的多线程。Zephyr 中的多线程是借助于硬件特性实现的，传统的多线程。站在应用程序的角度，只要多个线程能并行地工作，就可以了。
由于 Contiki 的多线程是通过应用程序使用单线程模拟出来的，其应用程序开发必须按照特定的模型，这在很大长度上增加了开发人员的入门学习成本。 Zephyr 采用传统的方式即可开发应用程序，这一点完胜 Contiki。
这一点应该也是制约 Contiki 广泛推广的主要因素。
Zephyr OS 定义了一套统一的设备驱动模型，再为各类设备定义了一套子设备驱动模型，这样做有两大好处：
- 使用统一的设备驱动模型，有助于驱动程序开发。
- 使用统一的设备驱动模型，极大地方便了应用程序使用设备的程序程序。
事实上，Contiki 也为每类驱动定义了一套统一的接口，但与 Zephyr 一比较，逊色多了。
到目前为止，Contiki 的物理层只支持 IEEE 802.15.4，而 Zephyr 的物理层支持 IEEE 802.15.4，Bluetooth 4.0，NFC，WiFi 等多种协议。
Zephyr 提供了模拟器 qemu，支持两种 cortex-m3 和 x86 两种架构的仿真，但是只能仿真内核的功能，其它 I/O 相关的仿真都不支持。
Contiki 提供了模拟器 COOJA，支持多种平台的仿真，且能仿真一些简单的 I/O 操作。此外，由于 Contiki 中的多线程使用单线程模拟的，所以可以在一个 COOJA 软件中进行设备互联性相关的仿真，这也是优于 Zephyr 的地方。
两者都高度可配置，但 Zephyr 使用 Kconfig 支持图形化配置。