zephyr 是一个用于物联网的轻量级开源操作系统，目标是为资源有限的设备建立一个小型、可切割的实时操作系统(RTOS)，它提供了一个低占用空间、高性能、多线程的执行环境。关于类型的划分，2017年1月推出的V1.6.0核版本用统一的核代替了原来分离的超微核和微核。根据使用场景配置，zephyr内核既适用于内存有限(低至低) 2 KB！）或者有简单的多线程要求(如一组中断处理程序和单个后台任务)的应用程序，例如嵌入式传感器集线器、环境传感器、简单 LED 可穿戴设备和商店库存标签，也适合开发需要更多的内存(50) 到 900 KB）、多通信设备(如 Wi-Fi 应用程序，蓝牙功耗低)和复杂的多线程，例如健身可穿戴设备、智能手表和物联网无线网关。
从zephyr可以看到架构图，zephyr将架构分为操作系统部分（内核 操作系统服务)和用户的特定部分(应用程序服务)。操作系统本身包含底层的驱动程序和特定的平台 I/O API、通用实现文件系统、内核特定函数和加密库。
Kernel/HAL：Kernel service(例如thread，同步、数据传输、中断管理、时间管理、内存管理等。内核调度、电源管理、平台专用驱动等Radios，传感器，加密硬件，Flash等；
OS服务：底层驱动接口、设备管理、网络层和传输层的协议(TCP/IP)，socket接口；
应用服务：网络应用协议和高层接口，如HTTP，coap，mqtt，tls，dtls提供基于智能对象的智能对象，如lwm2m的IPSO；
项目在zephyr在使用过程中提供梳理基础功能表，目前待新增驱动开发方法；
zephyr硬件抽象可以划分为6层，此处只做概念上的描述，具体案例参考编写设备树及配置系统Kconfig部分。
架构(Architecutre)：指令架构体系，例如ARM，RISC-V，x86等；
CPU内核(CPU core)：架构中特定的CPU，例如ARM中有Cortex-M0,M3,M4,M7等；
芯片族(Soc family)：具有相似特性的SoC，例如Cortex-M7中有STMicro STM32，NXP i.MX；
芯片系列(SoC series)：一小部分紧密关联的SoC，例如i.MX中有i.MX RT 系列，i.MX 8系列等；
芯片(SoC)：电路板上的SoC，例如i.MX RT系列中有RT1050,RT1060等芯片；
板级(Board)：PCB上特定的SoC和一些外设相连构成有特定功能的电路板。例如Zephyr支援的mimxrt1050_evk，mm_swiftio开发板使用了rt1052芯片；
芯片与开发板关系举例：
STM32 SoC Family有STM32F4、STM32G4等SoC Series；
STM32F4 SoC Series 有STM32F401、STM32F429等SoC；
STM32F429 SoC有野火STM32F429挑战者开发板、正点原子stm32f429阿波罗开发板等；
ARCv2（EM和HS）和ARCv3（HS6X）
ARMv6-M、ARMv7-M和ARMv8-M (Cortex-M)
ARMv7-A和ARMv8-A（Cortex-A，32 位和 64 位）
ARMv7-R、ARMv8-R（Cortex-R、32位和64位）
英特尔x86（32位和64位）
MIPS（MIPS32第1版规范）
NIOS II第2代
RISC-V（32位和64位）
SPARC V8
Tensilica Xtensa
开源：基于 Apache 2.0 许可，完全开源，代码托管在github；
模块化：针对受限制的物联网设备而设计，可以通过 Kconfig 裁剪功能选项，从而实现用户自定义的最佳配置；
编程语言：主要用C语言编写，代码风格、框架与Linux十分相似；
开发环境：支持多种开发环境（Windows、Linux、MacOS）；
联网能力：系统中提供了多种针对低功耗、内存受限设备的连接协议，支持低功耗蓝牙(BLE)、wifi、802.15.4以及其他标准，包括6lowpan、coap、ipv4和ipv6 ；
安全性：项目在开发过程中将安全因素考虑在内，该项目中提供了安全验证、模糊和渗透测试、代码审查、静态代码分析、威胁建模和审查等多种检测方法，用来防止代码中存在后门和漏洞。以上工作由专门的安全小组及维护人员进行监督和维护。
zephyr 内核有很多独特的优秀特性(zephyr基础功能特性表详述)：
1、单地址空间操作系统。将应用程序相关的代码与内核结合在一起，创建一个在硬件上加载、运行的单一镜像。应用程序代码和内核代码运行在同一个共享地址空间。
2、高度可配置。允许应用程序只包含它们需要的功能，例如对于多级中断是否支持、是否使线程在user mode模式运行等，均可以通过CONFIG_进行配置；
3、编译时定义资源。所有系统资源都在编译时定义，以减小代码量、增强代码性能。
4、最小错误检查。提供最小化的运行时错误检查，以减小代码量、增强代码性能。提供一个可选的错误检查基础，以协助应用程序的开发和调试。
5、广泛的服务。提供了许多耳熟能详的服务：
多线程服务：为基于优先级的、非抢占式的 fiber 和基于优先级的、抢占式的 task 提供可选时间片。
中断服务：在编译时、运行时均可注册中断处理函数。
线程间同步服务：包括二元信号量、计数信号量和互斥信号量。
线程间数据传递服务：包括基本消息队列、增强型消息队列和字节流。
内存分配服务：动态地分配固定尺寸、可变尺寸的内存块。
电源管理服务：包括无滴答 CPU 空转和高级 CPU 空转。
zephyr 源码树的顶层目录如下所述，每个顶层目录都包括一级或多级子目录。
arch架构相关的超微内核代码和支持的各种架构的平台代码：
支持的每个架构都有一个子目录，且这些子目录还包括下面子目录：
架构相关的超微内核源文件。
架构相关的超微内核的私有 API 的头文件。
平台相关的代码。
boards 板级相关的代码和配置文件，boards下一层级目录结构与arch很相似，依据不同的处理器架构划分，每个目录内是包括dts、Kconfig等设备树配置文件。对应zephyr硬件支持架构board模块。doc zephyr系统相关的材料和工具，描述系统内模块使用什么样子的工具完成什么样子的模块功能。drivers 设备驱动代码。对应zephyr系统架构OS services中I2C、SPI等驱动模块。include 所有（不包括 lib 目录）公有 API 的头文件，例如定时器、USB等。kernel 架构无关的微内核代码。对应zephyr系统架构kernel services。lib 库代码，包括最小的 C 库、posix等。misc 暂时无法按照统一标准进行归类的杂项代码。net 网络相关的代码，包括蓝牙协议栈和网络协议栈。对应zephyr系统架构OS services中BLE、TCP/IP模块；samples 微内核、蓝牙协议栈和网络协议栈的应用程序举例。tests 内核各个特性的测试代码。scripts 用于编译、测试 zephyr 应用程序的程序和文件，例如搭建zephyr工程过程中安装python依赖选项命令：
modules 提供特定芯片系列的一些外设配置选项。
官方说明：https://docs.zephyrproject.org/latest/develop/modules.html?highlight=west
CMakeLists.txt CMake 构建系统的顶层文件，包含构建 Zephyr 所需的大量逻辑。
Kconfig 顶层 Kconfig 文件，它引用 Kconfig.zephyr 文件。也可以在顶级目录中找到。
west.yml west清单，列出由 West 命令行工具管理的外部存储库。
dts devicetrree 源文件，用于描述特定板子的设备细节，如外设寄存器数量及寄存器地址。
soc SoC 相关代码和配置文件，如 nRF9160 soc。
7.1 west介绍
west是zephyr项目提供的一款命令行工具，类似于 Google 的 Repo 工具，多库管理，支持自定义编写扩展命令，使用python调用脚本来完成系统构建，zephyr使用west来构建、烧写和调试应用程序。west运行需要用到常用选项、需要要运行的子命令，以及该子命令的选项和参数：
7.2 west安装
执行west -V可以验证安装是否成功
7.3初始化west工作区
获取zephyr源码及update获取其他的依赖仓库
west init默认使用https://github.com/zephyrproject-rtos/zephy 作为zephyr代码仓库地址。完整的zephyr 项目实际包含了30多个子仓库，并且每个子仓库都要求版本号(分支)，例如驱动的SDK代码或者HAL层，为各大半导体商所定义，均是单独管理的。west init只获取了关于zephyr部分的代码，而 west update 命令就是获取这些相关联的子仓库代码并放到指定的目录下。zephyr团队写了个脚本用来关联这些子仓库，这个脚本叫 west.yml，放在 zephyr 的源代码仓库下。west update 会读取 zephyr\west.yml 文件，将其中列举的仓库依次下载下来，放到指定目录下，若找不到 west.yml 文件就会报错。每次新版本发布，可以通过git checkout来切换分支，获取新的west.yml脚本，以此更新整个仓库。
west.yml的部分内容如下所示：从 Zephyr Project · GitHub 获取仓库代码，将 canopennode、civetweb、cmsis 等仓库的对应分支代码下载放至 modules/lib/canopennode、 modules/lib/civetweb、modules/hal/cmsis 等的目录下，直至所有子仓库代码获取完毕。
在上图可以看到mainfest，manifest指明要下载各代码仓库的名称，路径，版本。manifest包含四项: default, remotes, projects, self。其中remotes和projects是强制必须要的，remote指定远端地址, projects指定仓库地址和版本，以图中标记的chre为例：
west下载时会以remotes的url-base+projects chre的name结合为https://github.com/zephyrproject
-rtos/chre下载版本为0edfe2c2ec656afb910cfab8ed59a5ffd59b87c8的代码到modules/lib/chre下，manifest可以在remotes里面指定多个url-base, 在projects中被不同的project引用，此处不再详述；
7.4 west build编译
基于具体的板子进行编译
正在上传…重新上传取消
west build -p ...，-p可以清除老的生成文件，west build核心工作内容为：
正在上传…重新上传取消
west命令执行过程中会转换成cmake命令，具体转换方法为west在运行的时候会根据路径去寻找.west文件夹，该文件夹下的config文件记录了zephyr文件夹的路径，然后去读取zephyr目录下的west.yml文件，在west.yml中指向了west的扩展命令路径：scripts/west-commands.yml。
正在上传…重新上传取消
展开west-commands.yml如下所示，当执行west build时，会执行scripts/west-commands/build.py，将执行命令引导到python脚本，经过build.py脚本处理生成cmake执行命令。
正在上传…重新上传取消
west flash与west build总体相似，所不同的是，在执行flash.py时会调用run_common.py，而该脚本会读取runners.yaml文件，runners.yaml记录了下载和调试工具信息，不同的板子依据不同的board.cmake会生成不同的runners.yaml，具体编译过程如下：
zephyr\cmake\app\boilerplate.cmake
zephyr\CMakeLists.txt
zephyr\cmake\flash\CMakeLists.txt
在最后一步会根据board.cmake生成runners.yaml。
7.5 CMakeLists.txt文件编译过程
前面讲述了west命令经多次文件调用最终转成cmake命令，cmake命令执行就是依赖CMakeLists.txt文件完成的。以~/zephyrproject/zephyr/samples/hello_world为例，CMakeLists.txt展开如下：
正在上传…重新上传取消
第3行设置cmake要求最低版本，第6行设置工程，第8行设置源代码文件，重点关注第5行，find_package是cmake系统函数，表示在ZEPHYR_BASE目录下找名为Zephyr的模块(ZEPHYR_BASE宏定义在scripts/west-commands/zephyr _ext _common.py中)，根据find_package工作原理可知，最终要找的是<PackageName>Config.cmake，即zephyr\share\zephyr- package\cmake\ZephyrConfig.cmake，ZephyrConfig.cmake调用zephyr\cmake\app\boilerplate.cmake，它将处理Device tree和Kconfig等配置信息，最终生成必要的头文件，它还会关联其他的相关文件及Zephyr下的CMakeLists.txt文件，这个 CMakeLists.txt又会关联其他的配置文件以及zephyr\cmake\flash\CMakeLists.txt，最终完成整个编译的过程。编译完成后，会在生成的 <build> 文件夹下生成一个名为 CMakeCache.txt 的文件，这个文件记录了编译过程中保存的一些变量值和文件，还有相关的文件路径，这些信息用来烧录与调试。
7.6 west调用menuconfig
west build -t menuconfig
正在上传…重新上传取消
7.7 west调用GUI 界面
west build -t guiconfig
正在上传…重新上传取消
其他west命令汇总：
烧写/调试
west flash 等同 make flashwest debug 等同 make debug west debugserver 等同 make debugserver
ram/rom信息查看
west build -t rom_report 等同 make rom_reportwest build -t ram_report 等同 make ram_report
west自定义扩展(官网查看)：Extensions — Zephyr Project Documentation
west：Zephyr RTOS -- West 命令及编译过程简介_搬砖-工人的博客-CSDN博客_west命令
Zephyr west简介 | Half Coder
清风徐来——Zephyr实战篇(2)之西 - 「MCU加油站」 - 恩智浦技术社区
7.8 zephyr配置系统裁剪介绍
zephyr作为一个针对资源受限设备的小型、可裁剪的实时操作系统，本身支持多种架构类型处理器及开发板，此处分享配置最小系统，其实就是在zephyr os上新增支持soc、开发板，以CPU_CORTEX_M7为例，新增board、soc、dts相应配置文件夹，最终配置出一套名为xp_cortex_m7的新板子，新增文件夹结构如下：
board：xp_cortex_m7 soc:xp_m7 dts:xp
正在上传…重新上传取消
针对board、soc、dts新增配置文件详解具体配置内容：
board：zephyrproject/zephyr/boards/arm/xp_cortex_m7
正在上传…重新上传取消
如上图所示，board.cmake、Kconfig.board、Kconfig.defconfig、xp_cortex_m7.dts、xp_cortex_m7.yaml、xp_cortex_m7_defconfig
六份新增文件，其中（1）xp_cortex_m7.dts为设备树格式的硬件描述，声明 SoC、连接器和其他硬件组件，例如 LED、按钮、传感器或通信外围设备；（2）Kconfig.board、Kconfig.defconfig、xp_cortex_m7_defconfig是配置系统格式(Kconfig)的软件配置，提供了软件功能和外围驱动程序的默认设置；（3）board.cmake用于支持烧写和调试；（4）xp_cortex_m7.yaml为支持测试用到的各种元数据的YAML文件。
- 重要
设备树是描述硬件的分层数据结构，有两种类型的设备树输入文件：设备树源和 设备树绑定。源包含设备树本身，绑定描述了它的内容以及数据类型，构建系统使用设备树源和绑定来生成 C 头文件，过程如下：
正在上传…重新上传取消
设备树语法和结构：
正在上传…重新上传取消
/dts-v1/;表示当前设备树遵循DTS语法规范版本1(目前设备树规范有4个版本)；
设备树有3个节点：
- 根节点：/
- 根节点的子节点a-node
- 子节点a-node的子节点a-sub-node
- 可以为节点分配节点标签，上图中subnode_nodelable为a-sub-node的节点标签，可在设备树中被引用，一个节点可以有零个、一个或多个节点标签，设备树节点内会有属性，属性分属性名与属性值，属性值可以是任何字节序列，上图中节点a-sub-nod的属性foo，值为3，属性label，值为字符串“SUBNODE”。
在实际应用中，devicetree节点通常对应一些硬件，节点层次反映了硬件的物理布局，例如具有三个 I2C 外设的板，这些外设连接到 SoC 上的 I2C 总线控制器，示意图及DTS文件分别如下：
正在上传…重新上传取消
下面以xp_cortex_m7.dts为例看一下本次zephyr最小系统设备树内容，如下面四图所示：
正在上传…重新上传取消
图1 图2
正在上传…重新上传取消
图3 图4
设备树文件有*.dts、*.dtsi两种，其中，图3、图4是图1的xp_cortex_m7.dts引用头文件xpm7.dtsi内容，*.dts文件是一种ASCII文本对Device Tree的描述，一个*.dts文件对应一个ARM的machine，由于一个SOC可能有多个不同的电路板，而每个电路板拥有一个 *.dts。这些dts势必会存在许多共同部分，为了减少代码的冗余，设备树将这些共同部分提炼保存在*.dtsi文件中，供不同的dts共同使用。*.dtsi的使用方法，类似于C语言的头文件，在dts文件中需要进行include *.dtsi文件。当然，dtsi本身也支持include 另一个dtsi文件。
在xpm7.dtsi中可以看到类似于sram0：memory@40000000{}这样的子节点，其中40000000是一种新的设备树概念即单元地址，使用@符号将子节点与单元地址衔接。
下面了解一下设备树节点中的各种属性，设备树常用属性有以下几种：
compatible：代表的硬件设备的名称，推荐的格式是"vendor,device"，“vendor”部分是供应商名字，可以在 dts/bindings/vendor-prefixes.txt查询，“device”部分为模块对应驱动的名字，构建系统使用 compatible 属性为节点找到 正确的绑定，作为驱动和设备（设备节点）的匹配依据，以图4为例，compatible = “arm,pl011”;参数为arm公司的pl011 驱动，而根目录下compatible = "ti,lm3s6965evb-qemu", "ti,lm3s6965";会发现没有ti这样的公司，也没有lm3s6965这样 的驱动，实际上这里的"ti,lm3s6965"为zephyrproject/zephyr/dts/arm目录下ti文件夹的lm3s6965.dtsi，而lm3s6965.dtsi 内完成了类似图4这样的驱动设备匹配工作。
label：标签属性与节点标签不是一个内容，标签属性依据设备驱动模型而来，例如UART、I2C等，设置label为I2C_0，则会 调用device_get_binding("I2C_0")并返回一个指向设备结构的指针，该结构可以传递给I2C API函数， 如 i2c_transfer()， 生成的 C 头文件将包含该字符串的宏。
reg：用于描述设备地址空间资源信息，一般都是某个外设的寄存器地址范围信息，常见设置模式为(address, length)。
status：描述设备的状态信息，okay代表设备正常运行，disable代表该设备尚未运行，fail代表表明设备不可操作，fail-sss代 表含义和“fail”相同，后面的 sss 部分是检测到的错误内容。
model：描述板子的型号或者芯片型号，仅仅是给人看的，无其他特殊用途。
#address-cells：决定了子节点 reg 属性中地址信息所占用的字长(u32)。
#size-cells：决定了子节点 reg 属性中长度信息所占用的字长(u32)。
name：用于记录节点名字，已废弃，不建议使用。
ranges：格式 <local地址， parent地址， size>， 表示将local地址向parent地址的转换，比如对于#address-cells和#size-cells 都为1的话，以<0x0 0x10 0x20>为例，表示将local的从0x0~(0x0 + 0x20)的地址空间映射到parent的0x10~(0x10 + 0x20)，其中，local地址的个数取决于当前含有ranges属性的节点的#address-cells属性的值，size取决于当前含有ranges 属性的节点的#size-cells属性的值。而parent地址的个数取决于当前含有ranges属性的节点的parent节点的 #address-cells的值。对于含有ranges属性的节点的子节点来说，子节点reg都是基于local地址的，ranges属性值为空 的话，表示1:1映射。
- 重要
zephyr 内核和功能子系统可以在构建时进行配置，以适应特定的应用和平台需求。配置通过 Kconfig 处理，这是 Linux 内核使用的相同配置系统。目标是无需更改任何源代码下支持各种配置。
Kconfig、Makefile、.config联系：Makefile是编译源文件的方法，最大的特点就是方便，把需要编译的文件都写Makefile里面，Kconfig是搭配Makefile文件一起使用，Makefile里面编译的模块是从Kconfig中选取出来的，.config文件就是控制和选择那些文件编译或者不编译的。
9.1设置Kconfig配置