Zephyr系统快评

请保留:【作者:张佩】 【原文:www.yiiyee.cn/blog】

Zephry是Linux基金会托管的一个嵌入式RTOS系统,主导开发的是Intel。我对这个系统进行了学习之后,得到了下面的5条总体认识。

  1. Zephyr的内核模式是宏内核,不是微内核;设备驱动都被集成在内核中;内核编译采用Kconfig脚本配置,资源配置也通过它在编译时指定
  2. Zephyr支持的平台:arm、x86、RISC-v、ARC、NIOS 2、POSIX等
  3. ARM平台支持不完全:只支持arm 32系列的m/r平台,a平台不支持;同时,也不支持arm64
  4. Zephyr支持100多种嵌入式开发平台,嵌入式友好;内核size可以小至8kB
  5. Zephyr只有mpu(内存保护单元)的支持,任务之间的内存是相互隔离的,但不支持虚拟内存;多个用户应用同时运行有一定的困难,目前仅支持单应用的形式

内核实现

Zephyr采用的是标准的宏内核的架构,这对于它面向MCU进行开发是有利的。如果采用微内核的话,需要有稳健的IPC机制,不仅执行效率上有所降低,并且需要更多的代码量。

当前的Zephyr代码结构和Linux十分相似。它有一个架构无关的通用的内核逻辑部分(Kernel目录),架构相关的实现被分离到不同的目录中去了(arch目录),基础的总线和外设的驱动也独立实现(driver目录),并在编译的时候集成在内核中。此外,一些重要的基础能力包括文件系统的支持、网络连接的支持,也是要在编译的时候和内核集成在一起的(ext目录)。

(v)[zhangpei@yunzhu:~/Documents/code/zephyr]$ ls
CMakeLists.txt   README.rst       dts              scripts
CODEOWNERS       VERSION          ext              subsys
CONTRIBUTING.rst arch             include          tests
Kconfig          boards           kernel           version.h.in
Kconfig.zephyr   cmake            lib              zephyr-env.cmd
LICENSE          doc              misc             zephyr-env.sh
Makefile         drivers          samples          zephyr.log

Zephyr的编译工作也采用Kconfig配置的方式。在进行一个具体的开发板适配的时候,内核配置和裁剪是很重要的工作,它决定了编译出来的内核size可以小到什么程度。比如下面是一个实现了USB HID功能的示例项目,它的基本配置只有聊聊几项内容:

CONFIG_USB=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_HID=y
CONFIG_USB_DEVICE_PRODUCT="Zephyr HID sample"

CONFIG_SYS_LOG=y
CONFIG_SYS_LOG_USB_DRIVER_LEVEL=1
CONFIG_SYS_LOG_USB_DEVICE_LEVEL=1

此外,内核配置中可以包含资源配置。包括CPU、RAM等的信息。这避免了系统起来之后进行动态检索的过程,适合嵌入式平台的精简模式。

平台支持

对于一个嵌入式RTOS系统来说,当前的Zephyr的平台支持是很广泛的,特别是它支持的开发板的类型,多达150种,并且提供了100多种典型的开发示例,可以覆盖各种简单的传感器设备,到一些专用外设或IoT等(如鼠键、摄像头、网关等)。

它所支持的平台包括:arm、x86、RISC-v、ARC。同时,它还支持Linux的POSIX接口,就是它可以通过POSIX接口来模拟一个软件的硬件平台作为CPU、RAM来执行,从而可以把完整的Zephyr项目作为一个POSIX应用运行在Unix/Linux系统上。这对于开发和验证很友好。

但要说明的是,对于嵌入式系统使用很广的arm平台它的支持并不好。目前只支持面向嵌入式和实时应用的R系列、M系列。对于所用的A系列芯片,它不支持。对于新的arm 64平台,当然也不支持。

除了有较多的平台支持外,Zephyr更大的能力体现在驱动栈的成熟。它对于嵌入式常用的总线如I2C、I2S、GPIO、CAN甚至x86平台上的PCI等全都支持,支持fat32、nffs这两个轻量文件系统,有完整的USB驱动栈,完整的网络驱动栈,对包括WIFI、Zigbee、蓝牙等在内的无线连接也全部支持,它对于audio和显示也有一定的支持。这使得嵌入式系统可以通过它进行快速的开发。

同时,它还有一个名为JerryScript的轻量的JavaScript引擎,使得用户可以基于JS这种简单的脚本语言在Zephyr上快速地开发轻量应用,甚至是web应用。

image-20191016105342412.png

用户应用

先看三个Zephyr的系统特性:

  1. Zephyr有内存保护,但不支持虚拟内存,亦即只做到MPU的支持,没有做到MMU的支持;
  2. 支持多线程,不同的线程可以使用独有的内存区域;
  3. 用户程序的入口地址是全局唯一的main函数。

从上述这3个基本事实出发,同时结合它的众多的sample示例,我们知道Zephyr是一个单应用的操作系统。全局唯一的main函数是用户应用的入口地址,这从设计上就不允许两个独立应用同时存在。但这个应用内部可以创建多个线程。

应用通过ymal文件进行配置,通过它来指定应用的描述信息,配置依赖信息。如果要支持多应用,可以通过一些简单的改造来快速实现。主要的思路是:

  1. 通过一个通用的init任务对用户空间进行初始化,内核完成初始任务后,将执行权交给init;
  2. 实现一种用户交互的方式,比如串口方式的terminal shell,以支持用户操作;
  3. 或者不实现2,而通过静态的用户配置文件,由init进程启动指定的用户进程。

结论

Zephyr是一个更适用于MCU/MPU平台的嵌入式RTOS系统,采用宏内核的开发模式,支持单个应用在上层执行。它本身的价值在于:虽然功能单一,但能力全面,可以在很小的系统上运行。

由于微内核现在很热,很多既有的RTOS在尝试把自己改造成微内核的架构。这样,不仅可以支持多应用的运行模式,也可以让内核更加地安全(驱动移出内核),面向的应用领域也可以更广泛。通过一些手段,Zephyr也可以被改造成微内核的架构。需要做的主要工作包括:

  1. 建立用户驱动模型,把当前的内核驱动按需移到独立进程中;
  2. 实现虚拟内存的管理功能,当然必须是在有MMU支持的平台上;
  3. 根据需要,对内核的基础功能进行一定的拓展,包括系统IPC的实现,如果要支持多应用,则最好有进程或Job的支持。

但考虑到一旦改造之后,可能导致它原有的架构大大变化,反而令其不能很好地适用于MCU/MPU平台,使得它的既有价值削弱。所以并不建议。

162 total views, 2 views today

发表评论

电子邮件地址不会被公开。