Zephys OS 基础篇:漫谈Zephyr与Contiki的未来

Zephyr OS 所有的学习笔记已托管到 Github,CSDN 博客里的内容只是 Github 里内容的拷贝,因此链接会有错误,请谅解。

最新的学习笔记请移步 GitHub:https://github.com/tidyjiang8/zephyr-inside

从一接触 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。

Contiki Vs. 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 支持图形化配置。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值