diff --git a/README_zh-cn.md b/README_zh-cn.md index bf6e205c..58172732 100644 --- a/README_zh-cn.md +++ b/README_zh-cn.md @@ -43,13 +43,13 @@ openvela 支持各种不同的架构（ARM32、ARM64、RISC-V、Xtensa、MIPS、 | 子仓库链接 | 描述 | | :----------------------------------------------------------- | :----------------------------------------------------------- | -| [frameworks](https://github.com/open-vela/frameworks) | openvela 服务框架：主要包含蓝牙、电话、图形、多媒体、应用框架、安全、系统服务框架（KVDB、OTA、healthd、binder、charger 等）。| -| [vendor](https://github.com/open-vela/vendor) | 芯片原厂的驱动和框架。 | -| [nuttx](https://github.com/open-vela/nuttx) | 基于开源实时操作系统 NuttX 打造的内核，提供基础的内核功能，包括任务调度、跨进程通信、文件系统、TCP/IP 协议栈、设备驱动和电源管理等，同时对上提供标准的 POSIX 接口。如果您想要对 NuttX 操作系统有更深入了解，可以在 [Apache NuttX](https://nuttx.apache.org/) 官网查看更多信息。 | -| [apps](https://github.com/open-vela/nuttx-apps) | `apps` 是开源实时操作系统（NuttX）的应用程序库，包含了一系列为 NuttX RTOS 设计的应用程序和实用工具。这些应用程序和工具包括 shell 命令行工具、文件系统工具、网络工具等，它们可以帮助开发者更方便地开发和调试基于 NuttX RTOS 的嵌入式系统。 | -| [external](https://github.com/open-vela/external) | openvela 引入的三方库。 | -| [tests]([../../../../open-vela/tests](https://github.com/open-vela/tests)) | 该仓库包含接口测试，具体包括多媒体、文件系统、内存管理和 socket 通信等核心 API 的测试。 | -| [docs](https://github.com/open-vela/docs) | openvela 对应的开发者文档。 | +| [frameworks](../../../../open-vela/frameworks) | openvela 服务框架：主要包含蓝牙、电话、图形、多媒体、应用框架、安全、系统服务框架（KVDB、OTA、healthd、binder、charger 等）。| +| [vendor](../../../../open-vela/vendor) | 芯片原厂的驱动和框架。 | +| [nuttx](../../../../open-vela/nuttx) | 基于开源实时操作系统 NuttX 打造的内核，提供基础的内核功能，包括任务调度、跨进程通信、文件系统、TCP/IP 协议栈、设备驱动和电源管理等，同时对上提供标准的 POSIX 接口。如果您想要对 NuttX 操作系统有更深入了解，可以在 [Apache NuttX](https://nuttx.apache.org/) 官网查看更多信息。 | +| [apps](../../../../open-vela/apps) | `apps` 是开源实时操作系统（NuttX）的应用程序库，包含了一系列为 NuttX RTOS 设计的应用程序和实用工具。这些应用程序和工具包括 shell 命令行工具、文件系统工具、网络工具等，它们可以帮助开发者更方便地开发和调试基于 NuttX RTOS 的嵌入式系统。 | +| [external](../../../../open-vela/external) | openvela 引入的三方库。 | +| [tests](../../../../open-vela/tests) | 该仓库包含接口测试，具体包括多媒体、文件系统、内存管理和 socket 通信等核心 API 的测试。 | +| [docs](../../../../open-vela/docs) | openvela 对应的开发者文档。 | ## 示例 diff --git a/en/device_dev_guide/build/build_system.md b/en/device_dev_guide/build/build_system.md index f029a40f..2458873b 100644 --- a/en/device_dev_guide/build/build_system.md +++ b/en/device_dev_guide/build/build_system.md @@ -1,6 +1,6 @@ # Build System -## 1. Overview +## I. Overview In the current version, **openvela** uses `Makefile` to organize the build process. The main entry point for the build process is located in the `nuttx/Makefile` file. Depending on the host platform, different core build files are executed: @@ -13,11 +13,11 @@ The `nuttx/tools/` directory contains the necessary scripts and C programs requi In addition to the core build files, the following key files and configurations are required to build **openvela**: -1. **Board-level macros and build options file:** +1. **Board-level macros and build options file.** - **Location:** `nuttx/Make.defs`. - **Source:** Copied from the template file located at `nuttx/board/${arch}/${chip}/${board}/${config}/scripts/Make.defs`. -2. **Conditional build configuration file:** +2. **Conditional build configuration file.** - **Location:** `configs/defconfig` in the root directory. - **Function:** - Copied as `.config` and serves as the base configuration file for **openvela**, supporting highly customizable and modular configurations. @@ -26,10 +26,10 @@ In addition to the core build files, the following key files and configurations ### 2. Key Points in the Build Process -1. **Configuring the Host Build Environment:** +1. **Configuring the Host Build Environment.** Use the `nuttx/tools/configure.sh` script to select the appropriate configuration for the build host. -2. **Key File Inclusions:** +2. **Key File Inclusions.** In the `Make.defs` file, the following two critical files are included and passed to different stages of the `Makefile` process: - `nuttx/.config`: The build configuration file. @@ -37,16 +37,16 @@ In addition to the core build files, the following key files and configurations 3. **File Generation and Invocation:** - 1. **File Generation:** + 1. **File Generation.** - At various stages of the `Makefile` execution, the `Makefile`, `Make.defs`, and `Make.dep` files in the `nuttx/` and `apps/` directories and their subdirectories are either generated or invoked. - **`Make.dep`:** Generated using the `tools/mkdep` tool during the build process. Internally, it utilizes the `gcc -M` command to create dependency statements in a format compliant with `Makefile` build targets. - 2. **File Invocation:** + 2. **File Invocation.** - `Makefile` files in subdirectories include the board-level macros configuration file `nuttx/Make.defs` at the top. By organizing the build system in this way, **openvela** achieves a flexible build process that supports multi-platform builds and highly modular configurations. -## 2. Build Dependency Tree +## II. Build Dependency Tree The following section summarizes the build target dependency tree based on the **FlatMode sim:nsh** board configuration. @@ -398,7 +398,7 @@ endif sort > $(TOPDIR)/System.map ``` -### Key Points: +### Key Points - Intermediate File Generation: Produces the `nuttx.rel` file as an intermediate result of the link process. - Symbol Table Processing: Uses `OBJCOPY` and `sed` to modify the symbol table, ensuring symbol names conform to requirements. @@ -474,7 +474,7 @@ endif $(call POSTBUILD, $(TOPDIR)) ``` -### Key Points: +### Key Points - Multi-format support: Generate `.hex`, `.srec`, `.bin`, and `uImage` files based on configuration options. - U-Boot image generation: Use the `mkimage` tool to create the `uImage` file, with support for automatically copying it to the TFTP directory. diff --git a/zh-cn/contribute/process/doc_dev_process.md b/zh-cn/contribute/process/doc_dev_process.md index e15aff7e..5327ba83 100644 --- a/zh-cn/contribute/process/doc_dev_process.md +++ b/zh-cn/contribute/process/doc_dev_process.md @@ -10,7 +10,7 @@ 如果你负责开发某一特性，你需要与文档团队一起配合，确保在版本发布之前完成该特性所配套文档的开发。否则，未提供配套文档的特性在发布时可能被移除。 -1. 联系[文档团队资料作者](https://github.com/open-vela/docs/blob/dev/zh-cn/contribute/process/doc_reviewer.md)，讨论文档设计。 +1. 联系[文档团队资料作者](./doc_reviewer.md)，讨论文档设计。 2. 参考[文档写作模板](https://github.com/open-vela/docs/tree/dev/zh-cn/contribute/template)进行配套文档的写作。 3. 为功能特性撰写详细的文档初稿，提交 PR 并在描述中提供对应的需求 `Issue` 链接。 diff --git a/zh-cn/demo/Music_Player_Example_zh-cn.md b/zh-cn/demo/Music_Player_Example_zh-cn.md index 5a25e34e..d2e4fdc8 100644 --- a/zh-cn/demo/Music_Player_Example_zh-cn.md +++ b/zh-cn/demo/Music_Player_Example_zh-cn.md @@ -1,4 +1,4 @@ -# 音乐播放器 Demo +# 音乐播放器 \[ [English](./../../en/demo/Music_Player_Example.md) | 简体中文 \] @@ -179,4 +179,4 @@ music_player & 2. 退出模拟器。 -3. 重新执行 [步骤三](#步骤三-启动模拟器并推送资源) 和 [步骤四](#步骤四-启动音乐播放器)。 +3. 重新执行[步骤三](#步骤三-启动模拟器并推送资源)和[步骤四](#步骤四-启动音乐播放器)。 diff --git a/zh-cn/demo/Smart_Band_Example_zh-cn.md b/zh-cn/demo/Smart_Band_Example_zh-cn.md index a03d8711..96650895 100644 --- a/zh-cn/demo/Smart_Band_Example_zh-cn.md +++ b/zh-cn/demo/Smart_Band_Example_zh-cn.md @@ -1,4 +1,4 @@ -# 手环 Bandx Demo +# 手环 Bandx \[ [English](../../en/demo/Smart_Band_Example.md) | 简体中文 \] @@ -152,4 +152,4 @@ sudo apt install android-tools-adb #### 解决方案 -请按 [步骤三](#步骤三-启动模拟器并推送资源) 进行资源推送。 +请按[步骤三](#步骤三-启动模拟器并推送资源)进行资源推送。 diff --git a/zh-cn/demo/X_Track_zh-cn.md b/zh-cn/demo/X_Track_zh-cn.md index 94e8b2fd..631f9d4e 100644 --- a/zh-cn/demo/X_Track_zh-cn.md +++ b/zh-cn/demo/X_Track_zh-cn.md @@ -1,4 +1,4 @@ -# 自行车码表示例 +# 自行车码表 \[ [English](../../en/demo/X_Track.md) | 简体中文 \] @@ -157,7 +157,7 @@ sudo apt install android-tools-adb #### 解决方案 -请按 [步骤三](#步骤三-启动模拟器并推送资源) 进行资源推送。 +请按[步骤三](#步骤三-启动模拟器并推送资源)进行资源推送。 ### 3. 为什么没有地图显示功能 diff --git a/zh-cn/demo/hello_world/Hello_World.md b/zh-cn/demo/hello_world/Hello_World.md index 5dfea6e5..c4878d37 100644 --- a/zh-cn/demo/hello_world/Hello_World.md +++ b/zh-cn/demo/hello_world/Hello_World.md @@ -1,4 +1,4 @@ -# 添加 Hello World 示例 +# 添加 Hello World ## 一、概述 diff --git a/zh-cn/device_dev_guide/build/build_system.md b/zh-cn/device_dev_guide/build/build_system.md index f744c73d..69362066 100644 --- a/zh-cn/device_dev_guide/build/build_system.md +++ b/zh-cn/device_dev_guide/build/build_system.md @@ -13,12 +13,12 @@ 除了核心编译文件外，编译 openvela 时还需要以下关键文件和配置： -1. 板级构建宏定义与构建选项文件： +1. 板级构建宏定义与构建选项文件。 - 文件位置：`nuttx/Make.defs`。 - 来源：从模板文件 `nuttx/board/${arch}/${chip}/${board}/${config}/scripts/Make.defs` 拷贝而来。 -2. 条件编译配置文件： +2. 条件编译配置文件。 - 文件位置：根目录的 `configs/defconfig`。 - 功能：被拷贝为 `.config` 文件，作为 openvela 的基础配置文件，支持高度裁剪和模块化配置。 @@ -26,20 +26,21 @@ ### 2、编译流程关键点 -1. 配置编译主机： +1. 配置编译主机。 使用 `nuttx/tools/configure.sh` 脚本选择编译主机的配置。 -2. 关键文件包含： +2. 关键文件包含。 在 `Make.defs` 文件中，包含以下两个关键文件，这些文件会被传递给各阶段的 Makefile： - `nuttx/.config`：构建配置文件。 - `nuttx/tools/Config.mk`：通用宏定义文件。 -3. 文件生成与调用： +3. 文件生成与调用。 1. 文件生成 + - 在 `nuttx/` 和 `apps/` 的各级子目录中，`Makefile`、`Make.defs` 和 `Make.dep` 文件会在 `Makefile` 执行的各阶段中被调用或生成。 - `Make.dep`：由工具 `tools/mkdep` 在编译过程中生成，其内部使用 `gcc -M` 命令生成符合 `Makefile` 构建目标格式的依赖语句。 diff --git a/zh-cn/device_dev_guide/driver/driver_development.md b/zh-cn/device_dev_guide/driver/driver_development.md index 6bd46f33..59907805 100644 --- a/zh-cn/device_dev_guide/driver/driver_development.md +++ b/zh-cn/device_dev_guide/driver/driver_development.md @@ -18,7 +18,7 @@ openvela 的驱动框架相对简单，并未提供像 Linux 系统中那样复 在 openvela 中，应用层通过系统调用访问驱动，其调用流程如下： -**系统调用 -> VFS（Virtual File System）-> 驱动**。 +系统调用 -> VFS（Virtual File System）-> 驱动。 为了理解驱动如何注册到文件系统中，需要先了解相关的数据结构。这些数据结构的定义位于 `include/nuttx/fs/fs.h` 文件中。 @@ -180,7 +180,7 @@ int register_driver(FAR const char *path, FAR const struct file_operations *fops - 将 `priv` 数据存储到 `inode` 的私有字段中。 - 该字段通常用于存放驱动的私有数据，例如硬件相关的上下文信息。 -## 二 驱动内部结构 +## 二、驱动内部结构 ### 1、驱动类型与层次结构 diff --git a/zh-cn/device_dev_guide/file_system/file_system.md b/zh-cn/device_dev_guide/file_system/file_system.md index 214108e3..1b7a8aa4 100644 --- a/zh-cn/device_dev_guide/file_system/file_system.md +++ b/zh-cn/device_dev_guide/file_system/file_system.md @@ -592,13 +592,12 @@ int nx_mount(FAR const char *source, FAR const char *target, 文件系统挂载操作主要完成如下关键步骤： -1. （可选）查找文件系统操作函数集和块设备驱动（若需要）。 +1. （可选）查找文件系统操作函数集和块设备驱动。 - 调用 `mount_findfs()` 函数，根据传入的参数 `filesystemtype` 查找对应的文件系统操作函数集 `mops`。 - 如果文件系统需要块设备支持，则调用 `find_blockdriver()` 函数，根据传入的参数 `source` 查找对应的块设备驱动。 - 目的： - 确定文件系统的操作方式，并关联相应的块设备驱动（如果需要），为后续的挂载操作做准备。 + 目的：确定文件系统的操作方式，并关联相应的块设备驱动（如果需要），为后续的挂载操作做准备。 > 注意 > @@ -611,13 +610,11 @@ int nx_mount(FAR const char *source, FAR const char *target, - 如果找到对应的 `inode`，检查其是否为有效的目录节点。 - 如果未找到对应的 `inode`，调用 `inode_reserve()` 函数创建一个新的 `mountpt_inode` 节点。 - 目的： - - 确定挂载点在文件系统中的位置，确保后续可以将文件系统挂载到指定路径。 + 目的：确定挂载点在文件系统中的位置，确保后续可以将文件系统挂载到指定路径。 > 注意 - - > 挂载点必须是有效的目录节点，不能是特殊节点（如设备节点）。 - - > 如果 `inode_reserve()` 失败，可能是因为路径无效、节点已存在或内存不足。 + > - 挂载点必须是有效的目录节点，不能是特殊节点（如设备节点）。 + > - 如果 `inode_reserve()` 失败，可能是因为路径无效、节点已存在或内存不足。 3. （可选）绑定文件系统与块设备驱动。 @@ -626,9 +623,7 @@ int nx_mount(FAR const char *source, FAR const char *target, - 对于不需要块设备支持的文件系统，`bind()` 函数可能无需特殊处理。 - 对于需要块设备支持的文件系统，`bind()` 函数会将文件系统的整体状态保存在`fshandle` 中。 - 目的： - - 实现文件系统与块设备驱动的关联（如果需要），使文件系统能够通过块设备进行数据读写操作。 + 目的：实现文件系统与块设备驱动的关联（如果需要），使文件系统能够通过块设备进行数据读写操作。 > 注意 > @@ -641,10 +636,8 @@ int nx_mount(FAR const char *source, FAR const char *target, - 设置操作函数集 `mops`。 - 将文件系统的整体状态（`fshandle`）存储到 `mountpt_inode` 的 `i_private` 字段中。 - 目的： - - 完成挂载点的最终设置，使文件系统成功挂载到指定路径。 + 目的：完成挂载点的最终设置，使文件系统成功挂载到指定路径。 > 说明 - - > 挂载完成后，用户可以通过挂载点访问文件系统中的文件和目录。 - - > 当打开挂载点 `mountpt_inode` 时，系统会根据 `i_private` 字段取出对应的文件系统信息。 + > - 挂载完成后，用户可以通过挂载点访问文件系统中的文件和目录。 + > - 当打开挂载点 `mountpt_inode` 时，系统会根据 `i_private` 字段取出对应的文件系统信息。 diff --git a/zh-cn/device_dev_guide/kernal/KernelDev.md b/zh-cn/device_dev_guide/kernal/KernelDev.md index 5a0bcdb8..9a2bf21c 100644 --- a/zh-cn/device_dev_guide/kernal/KernelDev.md +++ b/zh-cn/device_dev_guide/kernal/KernelDev.md @@ -8,7 +8,7 @@ openvela 内核基于当前实时嵌入式操作系统中对 POSIX 标准支持 - 文件系统与网络支持：兼容多种文件系统和网络连接协议。 - 驱动接口兼容性：兼容 Linux/xBSD 驱动访问接口，为上层通用 Linux 用户程序、模块组件复用和互联通信奠定基础。 -这些特性使得 Openvela 能够在嵌入式设备中提供高效、可靠的实时操作能力。 +这些特性使得 openvela 能够在嵌入式设备中提供高效、可靠的实时操作能力。 ## 二、支持的处理器架构 @@ -43,7 +43,7 @@ openvela 同时支持以下多处理器模式： 1. SMP（Symmetric Multiprocessing）：多个处理器共享同一内存和总线，提升并发响应效率。 2. AMP（Asymmetric Multiprocessing）：每个处理器拥有独立的内存和总线，并通过通信机制实现协作。 -这些特性使得 Openvela 能够在多个芯片和子系统上同时部署，确保系统的可靠性和实时性能。 +这些特性使得 openvela 能够在多个芯片和子系统上同时部署，确保系统的可靠性和实时性能。 ## 三、相关仓 diff --git a/zh-cn/device_dev_guide/kernal/boot_process.md b/zh-cn/device_dev_guide/kernal/boot_process.md index 9dcf0ea9..be5da8d7 100644 --- a/zh-cn/device_dev_guide/kernal/boot_process.md +++ b/zh-cn/device_dev_guide/kernal/boot_process.md @@ -16,21 +16,22 @@ nx_start-> rcS-> ``` -- `nx_start`：openvela OS 入口。 -- `board_early_initialize`：用于板级早期初始化，依赖于 CONFIG_BOARD_EARLY_INITIALIZE，执行上下文是 idle task，不能等待任何事件，不能调用任何可能阻塞的函数（比如sem_wait，因为 OS 的基础组件还没有进行初始化）。 -- `board_late_initialize`：相对于 board_early_initialize 较晚执行，OS 基础组件已经就绪，是板级大部分驱动的初始化入口，依赖于 CONFIG_BOARD_LATE_INITIALIZE，执行上下文是内核临时的 AppBringup thread 中，可以等待事件。芯片大部分驱动初始化在此过程中。 -- `board_app_initialize`：用于应用初始化，通过 boardctl（BOARDIOC_INIT）被调用，执行上下文是 nsh task。注意这个阶段不能访问文件系统。 -- `rc.sysinit`：openela 的启动脚本分为两个阶段，目前为第一阶段脚本，主要用于文件系统挂载和核心启动服务初始化，执行时机是 nsh 可输入前。 -- `board_app_finalinitialize`：用于板级最终的初始化，通过 boardctl（BOARDIOC_FINALINIT）被调用，执行上下文是 nsh task。有对文件访问需求的驱动初始化（TP、Charger、Audio PA 、BMI、PPG 和 GPS）需要挪到这个里面，可直接操作文件，不需要使用 delay work 的方式推后执行。 -- `rcS`：第二阶段脚本，主要用于启动其他的应用程序，包含 miwear、algo_service、gpsd 和 healthd 等，执行时机是 nsh 可输入前。 +1. `nx_start`：openvela OS 入口。 +2. `board_early_initialize`：用于板级早期初始化，依赖于 CONFIG_BOARD_EARLY_INITIALIZE，执行上下文是 idle task，不能等待任何事件，不能调用任何可能阻塞的函数（比如sem_wait，因为 OS 的基础组件还没有进行初始化）。 +3. `board_late_initialize`：相对于 board_early_initialize 较晚执行，OS 基础组件已经就绪，是板级大部分驱动的初始化入口，依赖于 CONFIG_BOARD_LATE_INITIALIZE，执行上下文是内核临时的 AppBringup thread 中，可以等待事件。芯片大部分驱动初始化在此过程中。 +4. `board_app_initialize`：用于应用初始化，通过 boardctl（BOARDIOC_INIT）被调用，执行上下文是 nsh task。注意这个阶段不能访问文件系统。 +5. `rc.sysinit`：openela 的启动脚本分为两个阶段，目前为第一阶段脚本，主要用于文件系统挂载和核心启动服务初始化，执行时机是 nsh 可输入前。 +6. `board_app_finalinitialize`：用于板级最终的初始化，通过 boardctl（BOARDIOC_FINALINIT）被调用，执行上下文是 nsh task。有对文件访问需求的驱动初始化（TP、Charger、Audio PA 、BMI、PPG 和 GPS）需要挪到这个里面，可直接操作文件，不需要使用 delay work 的方式推后执行。 +7. `rcS`：第二阶段脚本，主要用于启动其他的应用程序，包含 miwear、algo_service、gpsd 和 healthd 等，执行时机是 nsh 可输入前。 ## 二、启动脚本 -openvela 的启动脚本 rcS 和 rc.sysinit，是由 nsh task 通过 nshlib 进行加载和解析的，启动脚本的位置由 config 指定： -1. CONFIG_ETC_ROMFSMOUNTPT/CONFIG_NSH_SYSINITSCRIPT -2. CONFIG_ETC_ROMFSMOUNTPT/CONFIG_NSH_INITSCRIPT +openvela 的启动脚本 `rcS` 和 `rc.sysinit`，是由 `nsh task` 通过 `nshlib` 进行加载和解析的，启动脚本的位置由 `config` 指定： -通常启动脚本被放置在 `/etc` 下，`etc` 目录内容以 romfs 的形式与 openvela binary 编译链接在一起，启动之后会自动被内核进行 mount，相关配置如下： +1. `CONFIG_ETC_ROMFSMOUNTPT/CONFIG_NSH_SYSINITSCRIPT` +2. `CONFIG_ETC_ROMFSMOUNTPT/CONFIG_NSH_INITSCRIPT` + +通常启动脚本被放置在 `/etc` 下，`etc` 目录内容以 `romfs` 的形式与 openvela binary 编译链接在一起，启动之后会自动被内核进行 mount，相关配置如下： ```Makefile CONFIG_FS_ROMFS=y @@ -40,14 +41,14 @@ CONFIG_NSH_SYSINITSCRIPT="init.d/rc.sysinit" CONFIG_NSH_INITSCRIPT="init.d/rcS" ``` -openvela etc 由不同的 board 来生成，可以用 genromfs 和 xxd 工具生成 etc_romfs.c，编译到内核。 +openvela etc 由不同的 board 来生成，可以用 `genromfs` 和 `xxd` 工具生成 `etc_romfs.c`，编译到内核。 -例如：boards/arm/at32/at32f437-mini/src/etc_romfs.c，由脚本 boards/arm/at32/at32f437-mini/tool/mkromfs.sh 生成。 +例如：`boards/arm/at32/at32f437-mini/src/etc_romfs.c`，由脚本 `boards/arm/at32/at32f437-mini/tool/mkromfs.sh` 生成。 -更常用的方式是，etc 内容由对应 board/arch/board/board/src/etc 目录下的内容生成。 -例如：boards/sim/sim/sim/src/etc。 +更常用的方式是，`etc` 内容由对应 `board/arch/board/board/src/etc` 目录下的内容生成。 +例如：`boards/sim/sim/sim/src/etc`。 -`etc` 下所有的内容受 `etc/` 前一级目录的 Makefile 控制，RCSRCS 用于指定启动脚本，RCRAWS 用于指定加入 etc 目录下的其他文件和目录。 +`etc` 下所有的内容受 `etc/` 前一级目录的 Makefile 控制，`RCSRCS` 用于指定启动脚本，`RCRAWS` 用于指定加入 etc 目录下的其他文件和目录。 ```Makefile ifeq ($(CONFIG_ETC_ROMFS),y) diff --git a/zh-cn/device_dev_guide/kernal/inter_processor_communication/Rpmsg/Introduction_to_RPMsg.md b/zh-cn/device_dev_guide/kernal/inter_processor_communication/Rpmsg/Introduction_to_RPMsg.md index 5af5a3e1..b6acc94e 100644 --- a/zh-cn/device_dev_guide/kernal/inter_processor_communication/Rpmsg/Introduction_to_RPMsg.md +++ b/zh-cn/device_dev_guide/kernal/inter_processor_communication/Rpmsg/Introduction_to_RPMsg.md @@ -10,7 +10,7 @@ openvela 基于 OpenAMP 实现了自己的 RPMsg 框架，但由于原有的 Ope ## 二、框架 -### 1、Rpmsg 架构图 +### 1、RPMsg 架构图 ![img](./figures/011.svg) diff --git a/zh-cn/device_dev_guide/kernal/inter_processor_communication/Rpmsg/RPMsg_Clock.md b/zh-cn/device_dev_guide/kernal/inter_processor_communication/Rpmsg/RPMsg_Clock.md index 0e2eef92..c1511615 100644 --- a/zh-cn/device_dev_guide/kernal/inter_processor_communication/Rpmsg/RPMsg_Clock.md +++ b/zh-cn/device_dev_guide/kernal/inter_processor_communication/Rpmsg/RPMsg_Clock.md @@ -66,11 +66,11 @@ const struct clk_ops_s g_clk_rpmsg_ops = 操作流程 - Client 端请求转发： `g_clk_rpmsg_ops` 中的函数实现会将请求转发给 Server 端。转发的目标由时钟源名称中的 `cpuname` 字符串确定。 -- Server 端处理请求： Server 端 完成实际的函数调用，并将结果返回给 Client 端。 +- Server 端处理请求： Server 端完成实际的函数调用，并将结果返回给 Client 端。 ### 2、启用时钟的处理流程 -例如 `clk_rpmsg_enable` 函数会向 Server 端 发送 `CLK_RPMSG_ENABLE` 请求。以下是 `clk_rpmsg_enable` 函数的实现，它负责将启用时钟的请求从 Client 端 转发到 Server 端： +例如 `clk_rpmsg_enable` 函数会向 Server 端发送 `CLK_RPMSG_ENABLE` 请求。以下是 `clk_rpmsg_enable` 函数的实现，它负责将启用时钟的请求从 Client 端转发到 Server 端： ```C static int clk_rpmsg_enable(FAR struct clk_s *clk) @@ -105,10 +105,10 @@ static int clk_rpmsg_enable(FAR struct clk_s *clk) } ``` -**处理逻辑说明** +#### 处理逻辑说明 1. 获取通信端点： - - 函数通过 `clk_rpmsg_get_ept` 获取与目标 Server 端 的通信端点。如果通信端点不存在，则返回错误代码 `-ENODEV`。 + - 函数通过 `clk_rpmsg_get_ept` 获取与目标 Server 端的通信端点。如果通信端点不存在，则返回错误代码 `-ENODEV`。 2. 构造消息： - 函数通过 `rpmsg_get_tx_payload_buffer` 分配消息缓冲区，并将时钟名称复制到消息中。 3. 发送请求并接收响应： @@ -116,7 +116,7 @@ static int clk_rpmsg_enable(FAR struct clk_s *clk) ### 3、Server 端的请求处理 -当 Server 端 接收到 `CLK_RPMSG_ENABLE` 请求时，会调用对应的处理函数 `clk_rpmsg_enable_handler`。 +当 Server 端接收到 `CLK_RPMSG_ENABLE` 请求时，会调用对应的处理函数 `clk_rpmsg_enable_handler`。 以下是消息处理函数的注册表： @@ -161,7 +161,7 @@ static int clk_rpmsg_enable_handler(FAR struct rpmsg_endpoint *ept, } ``` -处理逻辑说明： +#### 处理逻辑说明： 1. 获取时钟实例： - 函数通过 `clk_rpmsg_get_clk` 获取指定名称的时钟实例。 diff --git a/zh-cn/device_dev_guide/kernal/logging/logging_system.md b/zh-cn/device_dev_guide/kernal/logging/logging_system.md index eb991d4d..e1a6d9e9 100644 --- a/zh-cn/device_dev_guide/kernal/logging/logging_system.md +++ b/zh-cn/device_dev_guide/kernal/logging/logging_system.md @@ -167,10 +167,6 @@ CONFIG_SYSLOG_TIMESTAMP_FORMATTED=y # 格式化时间戳输出 ##### 颜色打印 -> 注意 -> -> 请不要在自定义日志（LOG）中直接添加颜色字符。 - ```Makefile CONFIG_SYSLOG_COLOR_OUTPUT=y ``` diff --git a/zh-cn/device_dev_guide/kernal/memory_management/memory_mgt.md b/zh-cn/device_dev_guide/kernal/memory_management/memory_mgt.md index 74f0a846..79777224 100644 --- a/zh-cn/device_dev_guide/kernal/memory_management/memory_mgt.md +++ b/zh-cn/device_dev_guide/kernal/memory_management/memory_mgt.md @@ -454,9 +454,7 @@ struct gran_s `gran_alloc()` 函数通过调用 `gran_search()` 和 `gran_set()` 完成内存分配，具体流程如下： -1. 计算所需颗粒数。 - - - 根据申请的内存大小（`size`），计算需要分配的颗粒数量（`ngran`）。 +1. 计算所需颗粒数：根据申请的内存大小（`size`），计算需要分配的颗粒数量（`ngran`）。 2. 查询颗粒分配表，在颗粒分配表中查找 `ngran` 个连续的空闲颗粒区域： diff --git a/zh-cn/device_dev_guide/kernal/resource_sync/atomic_operation.md b/zh-cn/device_dev_guide/kernal/resource_sync/atomic_operation.md index 330bb028..f1b6e193 100644 --- a/zh-cn/device_dev_guide/kernal/resource_sync/atomic_operation.md +++ b/zh-cn/device_dev_guide/kernal/resource_sync/atomic_operation.md @@ -133,7 +133,7 @@ bool atomic_compare_exchange_strong(atomic_type *object, int *expected, int desi 以下是位操作相关的原子操作接口及其功能说明： ```C -//按位亦或操作，将指定值与原子变量的值进行按位异或运算，并返回执行xor操作前的旧值 +//按位异或操作，将指定值与原子变量的值进行按位异或运算，并返回执行xor操作前的旧值 atomic_type atomic_fetch_xor(atomic_type *object, atomic_type desired); //按位或操作，将指定值与原子变量进行按位或运算，并返回执行or操作前的旧值 diff --git a/zh-cn/device_dev_guide/kernal/resource_sync/figures/003.png b/zh-cn/device_dev_guide/kernal/resource_sync/figures/003.png index c6e686ea..7c1e4af9 100644 Binary files a/zh-cn/device_dev_guide/kernal/resource_sync/figures/003.png and b/zh-cn/device_dev_guide/kernal/resource_sync/figures/003.png differ diff --git a/zh-cn/device_dev_guide/kernal/resource_sync/semaphore_mechanism.md b/zh-cn/device_dev_guide/kernal/resource_sync/semaphore_mechanism.md index d5be30af..c888b2f9 100644 --- a/zh-cn/device_dev_guide/kernal/resource_sync/semaphore_mechanism.md +++ b/zh-cn/device_dev_guide/kernal/resource_sync/semaphore_mechanism.md @@ -14,17 +14,17 @@ ### 2、优先级反转 -正确使用信号量可以避免 `sched_lock()` 带来的问题，但在某些情况下，仍可能出现 优先级反转 的问题。优先级反转是指高优先级任务因低优先级任务持有的资源而被阻塞，导致系统性能下降的现象。 +正确使用信号量可以避免 `sched_lock()` 带来的问题，但在某些情况下，仍可能出现优先级反转的问题。优先级反转是指高优先级任务因低优先级任务持有的资源而被阻塞，导致系统性能下降的现象。 以下是一个典型的优先级反转场景： 1. 低优先级任务 `Task C` 获取信号量，从而独占对受保护资源的访问。 -2. `Task C` 被挂起，操作系统切换到 高优先级任务 `Task A`。 +2. `Task C` 被挂起，操作系统切换到高优先级任务 `Task A`。 3. `Task A` 试图获取信号量，但由于信号量被 `Task C` 持有，`Task A` 被阻塞。 -4. 操作系统允许 `Task C` 再次运行，但此时 中等优先级任务 `Task B` 抢占了 `Task C` 的运行时间。 +4. 操作系统允许 `Task C` 再次运行，但此时中等优先级任务 `Task B` 抢占了 `Task C` 的运行时间。 5. 在 `Task B`（以及可能其他中等优先级任务）完成之前，`Task C` 无法释放信号量，导致高优先级任务 `Task A` 无法执行。 -这种现象表现为：高优先级任务 `Task A` 的执行被中等优先级任务 `Task B` 阻塞，看起来 `Task A` 的优先级比 `Task B` 更低。这就是 优先级反转。 +这种现象表现为：高优先级任务 `Task A` 的执行被中等优先级任务 `Task B` 阻塞，看起来 `Task A` 的优先级比 `Task B` 更低。这就是优先级反转。 #### 解决优先级反转 @@ -118,7 +118,7 @@ #### 概述 -在 openvela 中，优先级继承功能基于 POSIX 信号量 实现。这是因为信号量是 openvela 中最基础的等待机制，大多数其他等待方式（如互斥锁）都依赖于信号量。因此，为 POSIX 信号量实现优先级继承功能，也意味着大多数等待机制都具备了优先级继承的能力。 +在 openvela 中，优先级继承功能基于 POSIX 信号量实现。这是因为信号量是 openvela 中最基础的等待机制，大多数其他等待方式（如互斥锁）都依赖于信号量。因此，为 POSIX 信号量实现优先级继承功能，也意味着大多数等待机制都具备了优先级继承的能力。 通过配置项 `CONFIG_PRIORITY_INHERITANCE`，可以启用信号量的优先级继承功能。相比优先级保护，优先级继承的实现稍显复杂，因为信号量可能同时被多个任务持有。为了实现优先级继承，系统需要分配内部数据结构来管理信号量与任务之间的关系。 @@ -247,11 +247,11 @@ #### Locking 信号量 -Locking 信号量 的典型用途是用于对共享资源的独占访问，也就是对临界区的保护。 +Locking 信号量的典型用途是用于对共享资源的独占访问，也就是对临界区的保护。 当需要独占访问临界区时，线程通过信号量来获取资源的访问权限，完成操作后释放信号量的计数。 -在这种场景下，优先级继承 是适用的，因为它可以解决优先级反转问题，确保高优先级任务不会因低优先级任务持有信号量而被阻塞。 +在这种场景下，优先级继承是适用的，因为它可以解决优先级反转问题，确保高优先级任务不会因低优先级任务持有信号量而被阻塞。 特点： @@ -298,43 +298,36 @@ Signaling 信号量的用途是用于线程之间的通信和同步。 功能：销毁未命名信号量 `sem`。 - 注意事项： + 注意： - 仅能销毁通过 `sem_init()` 创建的信号量。 + - 仅能销毁通过 `sem_init()` 创建的信号量。 - 销毁命名信号量的行为未定义。 + - 销毁命名信号量的行为未定义。 - 在调用 `sem_destroy()` 后尝试使用信号量的行为未定义。 + - 在调用 `sem_destroy()` 后尝试使用信号量的行为未定义。 3. `sem_t *sem_open(const char *name, int oflag, ...)` 功能：在任务（Task）和命名信号量之间建立连接。 - 说明： - - 通过信号量名称调用 `sem_open()` 后，关联的任务可以使用该函数返回的地址引用对应的信号量。 + 说明：通过信号量名称调用 `sem_open()` 后，关联的任务可以使用该函数返回的地址引用对应的信号量。 4. `int sem_close(sem_t *sem)` 功能：关闭命名信号量。 说明： - - 释放系统为该命名信号量分配的资源。 - 如果未使用 `sem_unlink()` 删除信号量，`sem_close()` 对信号量无影响。 - 当信号量被完全解除链接（调用 `sem_unlink()` 后），信号量将在最后一个任务关闭它时消失。 - 注意事项： - - 必须小心避免删除其他任务正在锁定的信号量。 + 注意事项：必须小心避免删除其他任务正在锁定的信号量。 5. `int sem_unlink(const char *name)` 功能：删除命名信号量。 - 说明： - - 如果有一个或多个任务正在使用信号量，销毁操作会被延迟，直到所有引用都通过 `sem_close()` 被释放。 + 说明：如果有一个或多个任务正在使用信号量，销毁操作会被延迟，直到所有引用都通过 `sem_close()` 被释放。 6. `int sem_wait(sem_t *sem)` @@ -364,7 +357,7 @@ Signaling 信号量的用途是用于线程之间的通信和同步。 - 如果信号量值为正数，不会阻塞等待信号量的任务，信号量值递增。 - 如果信号量值为 0，则唤醒阻塞的任务，使其从 `sem_wait()` 调用中成功返回。 - 注意事项：可以从中断处理程序中调用此函数。 + 注意：可以从中断处理程序中调用此函数。 10. `int sem_getvalue(sem_t *sem, int *sval)` @@ -407,7 +400,7 @@ Signaling 信号量的用途是用于线程之间的通信和同步。 信号量整体的框架如上图所示，与之相关的结构如下： -1. `struct semaphore` +1. `struct sem_s` - 描述：信号量的核心数据结构。 - 主要字段： @@ -424,7 +417,7 @@ Signaling 信号量的用途是用于线程之间的通信和同步。 - 当任务需要等待信号量时，从全局队列中分配一个持有者结构。 - 当信号量被释放时，将持有者结构返回到全局队列。 -3. `sem->waitlist` +3. `waitlist` - 描述：有序任务等待队列。 - 功能： @@ -800,7 +793,7 @@ static int nxsem_post_slow(FAR sem_t *sem) - 超时机制。 - 定时器设置：函数在调用时会根据指定的超时时间创建一个看门狗计时器。 - - 超时处理：如果超时时间到达且仍未获取信号量，会触发回调函数 `nxse``m_timeout``()`，取消任务的等待状态并重新调度。 + - 超时处理：如果超时时间到达且仍未获取信号量，会触发回调函数 `nxsem_timeout()`，取消任务的等待状态并重新调度。 - 信号量获取。 - 尝试立即获取信号量，若成功直接返回。 - 若信号量不可用，则进入阻塞状态，等待信号量释放或超时。 diff --git a/zh-cn/device_dev_guide/kernal/scheduling_interrupts/interrupt_system.md b/zh-cn/device_dev_guide/kernal/scheduling_interrupts/interrupt_system.md index e5d52f03..45ec8b22 100644 --- a/zh-cn/device_dev_guide/kernal/scheduling_interrupts/interrupt_system.md +++ b/zh-cn/device_dev_guide/kernal/scheduling_interrupts/interrupt_system.md @@ -1,6 +1,6 @@ # 中断系统 -## 实现芯片中断调试 +## 一、实现芯片中断调试 在调试芯片中断子系统（`bringup`）时，厂商需要实现一系列与架构相关的函数（`arch` 函数），以完成以下任务： @@ -10,11 +10,11 @@ 以下内容提供了具体的要求和实现示例。 -### 需要实现的中断相关函数 +### 1、需要实现的中断相关函数 -以下是厂商（ Vendor）需要实现的中断相关函数及其功能说明。 +以下是厂商（Vendor）需要实现的中断相关函数及其功能说明。 -#### 1 初始化中断系统 +#### 1.1 初始化中断系统 ```C void up_irqinitialize(void) @@ -29,7 +29,7 @@ void up_irqinitialize(void) 此函数用于初始化中断系统，包括禁用所有中断、配置向量表位置、设置默认优先级以及启用中断。 -#### 2 启用指定中断 +#### 1.2 启用指定中断 ```C void up_enable_irq(int irq) @@ -40,7 +40,7 @@ void up_enable_irq(int irq) 此函数用于启用指定的中断号。 -#### 3 禁用指定中断 +#### 1.3 禁用指定中断 ```C void up_disable_irq(int irq) @@ -51,7 +51,7 @@ void up_disable_irq(int irq) 此函数用于禁用指定的中断号。 -#### 4 （可选）设置中断优先级 +#### 1.4 （可选）设置中断优先级 如果启用了 `CONFIG_ARCH_IRQPRIO` 配置，则需要实现以下函数： @@ -66,7 +66,7 @@ int up_prioritize_irq(int irq, int priority) 此函数用于设置指定中断的优先级。 -#### 5 中断状态管理 +#### 1.5 中断状态管理 以下函数用于管理中断状态： @@ -114,7 +114,7 @@ int up_prioritize_irq(int irq, int priority) } ``` -#### 6 核间中断 +#### 1.6 核间中断 以下函数用于处理核间中断： @@ -123,9 +123,9 @@ int up_prioritize_irq(int irq, int priority) void up_trigger_irq(int irq, cpu_set_t cpuset) ``` -#### 7 中断安全属性 +#### 1.7 中断安全属性 -以下函数用于设置中断的安全属性。 +以下函数用于设置中断的安全属性： - 设置指定中断的安全属性。 @@ -141,25 +141,25 @@ void up_trigger_irq(int irq, cpu_set_t cpuset) void up_secure_irq_all(bool secure) ``` -### 需要定义的中断相关宏 +### 2、需要定义的中断相关宏 除上面的函数实现，厂商还需定义一系列中断相关的宏，用于描述 NVIC 的配置，这些宏需定义在`chips/chip_name/include/irq.h` 文件中。可参考实现：[RTL8720C 示例](https://github.com/open-vela/nuttx/blob/trunk/arch/arm/src/rtl8720c/include/irq.h)。 以下是必须实现的宏及其功能说明： -#### 1 第一个中断向量号 +#### 2.1 第一个中断向量号 ```C #define NVIC_IRQ_FIRST (16) /* Vector number of the first interrupt */ ``` -#### 2 中断数量 +#### 2.2 中断数量 ```C #define NR_IRQS (64) ``` -#### 3 NVIC 优先级级别 +#### 2.3 NVIC 优先级级别 - 最低优先级 @@ -191,11 +191,11 @@ void up_trigger_irq(int irq, cpu_set_t cpuset) #define NVIC_SYSH_PRIORITY_SUBSTEP 0x20 /* Three bits priority used, bit[5] as sub */ ``` -## 中断绑定处理函数 +## 二、中断绑定处理函数 在中断处理过程中，可以通过以下三种方式绑定处理函数。每种方式适用于不同场景，具有各自的优缺点。 -### 方式一 使用`irq_attach` +### 1、 使用`irq_attach` ```C int irq_attach(int irq, xcpt_t isr, FAR void *arg) @@ -221,7 +221,7 @@ int irq_attach(int irq, xcpt_t isr, FAR void *arg) - 优点：处理效率高。 - 缺点：中断处理期间屏蔽所有中断，影响系统实时性。 -### 方式二 使用`irq_attach_thread` +### 2、使用`irq_attach_thread` ```C int irq_attach_thread(int irq, xcpt_t isr, xcpt_t isrthread, FAR void *arg, int priority, int stack_size) @@ -253,7 +253,7 @@ int irq_attach_thread(int irq, xcpt_t isr, xcpt_t isrthread, FAR void *arg, int irq_detach_thread(irq) ``` -### 方式三 使用`irq_attach_wqueue` +### 3、使用`irq_attach_wqueue` ```C int irq_attach_wqueue(int irq, xcpt_t isr, xcpt_t isrwork, FAR void *arg, int priority) @@ -285,7 +285,7 @@ int irq_attach_wqueue(int irq, xcpt_t isr, xcpt_t isrwork, FAR void *arg, int pr irq_detach_wqueue(irq) ``` -### 总结对比 +### 4、总结对比 | 绑定方式 | 优点 | 缺点 | 使用场景 | | :---------------- | :------------------------------- | :------------------------------------------------- | :----------------------------------- | @@ -293,11 +293,11 @@ int irq_attach_wqueue(int irq, xcpt_t isr, xcpt_t isrwork, FAR void *arg, int pr | irq_attach_thread | 提升实时性，支持优先级调度。 | 消耗更多内存，增加上下文切换，处理完成有一定延迟。 | 实时性要求高的场景。 | | irq_attach_wqueue | 节省内存，支持工作队列复用。 | 单一中断场景效率低，多核场景灵活性不足。 | 中断数量多、内存资源有限的场景。 | -## 中断线程/工作队列的实现示例 +## 三、中断线程/工作队列的实现示例 以下是绑定中断并实现中断线程或工作队列的示例代码。 -### 绑定中断 +### 1、绑定中断 使用 `irq_attach_work` 函数绑定中断处理程序： @@ -310,7 +310,7 @@ irq_attach_work(IRQ, isrhandle, isrwork, arg, 253) - `arg`：传递给处理函数的参数。 - `253`：优先级设置。 -### 中断处理函数示例 +### 2、中断处理函数示例 在 `isrhandle` 中返回 `IRQ_WAKE_THREAD`，以唤醒中断线程或工作队列。如果返回 `OK`，则不会唤醒中断线程。 @@ -324,7 +324,7 @@ static int isrhandle(int irq, void *regs, void *arg) } ``` -### 中断线程/工作队列处理函数示例 +### 3、中断线程/工作队列处理函数示例 `isrwork` 用于处理中断任务，并在完成后清除中断状态。 @@ -340,11 +340,11 @@ static int isrwork(int irq, void *regs, void *arg) } ``` -### 特殊情况：One-shot 中断 +### 4、特殊情况：One-shot 中断 对于一些 one-shot 中断，可以将 `isrhandle` 设置为 `NULL`，直接使用 `isrwork` 处理中断任务。 -## 中断结构体优化 +## 四、中断结构体优化 在中断使用时，系统通常会定义一个全局中断结构体数组： @@ -357,11 +357,11 @@ struct irq_info_s g_irqvector[NR_IRQS]; - 内存浪费：即使只使用少量中断，也需要为所有可能的中断号分配内存，存储 `NR_IRQS` 个结构体。 - 低效资源利用：大部分中断号对应的结构体未被使用，造成资源浪费。 -### 优化策略与实现原理 +### 1、优化策略与实现原理 为了解决上述问题，可以通过如下动态映射的方式优化中断结构体的存储。 -#### 1 映射关系数组 +#### 1.1 映射关系数组 定义一个映射关系数组，用于动态建立中断号与中断结构体的映射： @@ -372,7 +372,7 @@ irq_mapped_t g_irqmap[NR_IRQS] - 该数组仅占用 `NR_IRQS` 字节的额外内存。 - 在中断使用时，动态建立映射关系。 -#### 2 精简中断结构体数组 +#### 1.2 精简中断结构体数组 将 `g_irqvector` 定义为： @@ -383,11 +383,11 @@ struct irq_info_s g_irqvector[CONFIG_ARCH_NUSER_INTERRUPTS]; - `CONFIG_ARCH_NUSER_INTERRUPTS` 表示系统中可能使用的最大中断数量加 1 。 - 通过限制数组大小，仅为实际可能使用的中断分配内存。 -#### 3 中断使用统计 +#### 1.3 中断使用统计 使用 `g_irqmap_count` 统计当前已使用的中断数量，便于监控和调试。 -### 配置示例 +### 2、配置示例 通过以下宏配置启用优化： @@ -401,12 +401,12 @@ CONFIG_ARCH_NUSER_INTERRUPTS=24 - `CONFIG_ARCH_MINIMAL_VECTORTABLE`：启用精简中断向量表。 - `CONFIG_ARCH_NUSER_INTERRUPTS`：设置最大可能使用的中断数量。 -### 优化效果 +### 3、优化效果 - 内存节省：仅为实际使用的中断分配存储空间，避免为未使用的中断号浪费内存。 - 灵活性提升：通过动态映射关系，支持离散分布的中断号。 - 可扩展性：通过配置宏灵活调整中断数量限制。 -## 相关仓 +## 五、相关仓 - [nuttx](https://github.com/open-vela/nuttx) \ No newline at end of file diff --git a/zh-cn/device_dev_guide/kernal/time_system.md b/zh-cn/device_dev_guide/kernal/time_system.md index 3f5f8780..5ec48c90 100644 --- a/zh-cn/device_dev_guide/kernal/time_system.md +++ b/zh-cn/device_dev_guide/kernal/time_system.md @@ -56,28 +56,28 @@ std offset[dst[offset][,start[/time],end[/time]]] 参数说明 -1. **std** +1. std 表示时区缩写，由三个或三个以上的字符组成。例如： - CST：中国标准时间。 - EST：东部标准时间。 -2. **offset** +2. offset - 当前时区与 UTC 的偏移量。 - 格式为 `±hh:mm:ss`，例如 `+8:00:00` 表示东八区（UTC+8）。 -3. **dst**（可选） +3. dst（可选） 表示夏令时时区缩写。 -4. **offset**（可选） +4. offset（可选） - 夏令时相对于 UTC 的偏移量。 - 如果省略，默认比标准时间提前 1 小时。 -5. **start[/time]，end[/time]**（可选） +5. start[/time]，end[/time]（可选） 表示夏令时开始和结束规则： @@ -98,8 +98,7 @@ std offset[dst[offset][,start[/time],end[/time]]] - `/Asia/Shanghai`：绝对路径，表示直接指定时区文件的完整路径。 - `:Asia/Shanghai`：同时支持绝对路径和系统时区目录下的相对路径。 -2. 解析规则。 - 找到时区文件后，会根据 `tzfile` 格式解析文件内容，加载对应的时区信息。 +2. 解析规则：找到时区文件后，会根据 `tzfile` 格式解析文件内容，加载对应的时区信息。 ### 2、`zoneinfo` 制作与挂载说明 @@ -107,7 +106,7 @@ std offset[dst[offset][,start[/time],end[/time]]] 1. `tzfile` 格式 - - `zoneinfo` 使用 `tzfile` 格式存储时区信息，具体格式请参考 [tzfile文档](https://man7.org/linux/man-pages/man5/tzfile.5.html)。 + `zoneinfo` 使用 `tzfile` 格式存储时区信息，具体格式请参考 [tzfile文档](https://man7.org/linux/man-pages/man5/tzfile.5.html)。 2. 数据库下载。 @@ -359,71 +358,72 @@ timedatectl set-timezone Asia/Tokyo ### 2、时间转换 API -`time_t timegm(FAR struct tm *tmp)` +1. `time_t timegm(FAR struct tm *tmp)` -- 描述：将 `struct tm` 转换为从 `1970-01-01 00:00:00` 至今的秒数（UTC 时间）。 + 描述：将 `struct tm` 转换为从 `1970-01-01 00:00:00` 至今的秒数（UTC 时间）。 -`FAR struct tm *gmtime(FAR const time_t *timep)` +2. `FAR struct tm *gmtime(FAR const time_t *timep)` -- 描述：将从 `1970-01-01 00:00:00` 至今的秒数转换为 `struct tm` 格式的时间，并用 UTC 时间表示。 -- 说明：`gmtime_r` 是线程安全版本。 + - 描述：将从 `1970-01-01 00:00:00` 至今的秒数转换为 `struct tm` 格式的时间，并用 UTC 时间表示。 -`time_t mktime(FAR struct tm *tp)` + - 说明：`gmtime_r` 是线程安全版本。 -描述：将 `struct tm` 转换为依据本地时区的秒数。 +3. `time_t mktime(FAR struct tm *tp)` -`FAR struct tm *localtime(FAR const time_t *timep)` + 描述：将 `struct tm` 转换为依据本地时区的秒数。 -- 描述：将从 `1970-01-01 00:00:00` 至今的秒数转换为 `struct tm` 格式的时间，并用本地时区表示。 -- 说明：`localtime_r` 是线程安全版本。 +4. `FAR struct tm *localtime(FAR const time_t *timep)` -`FAR char *asctime(FAR const struct tm *tp)` + - 描述：将从 `1970-01-01 00:00:00` 至今的秒数转换为 `struct tm` 格式的时间，并用本地时区表示。 + - 说明：`localtime_r` 是线程安全版本。 -- 描述：将日期和时间格式化为字符串并返回。 -- 说明：`asctime_r` 是线程安全版本。 +5. `FAR char *asctime(FAR const struct tm *tp)` -`size_t strftime(FAR char *s, size_t max, FAR const char *format, FAR const struct tm *tm)` + - 描述：将日期和时间格式化为字符串并返回。 + - 说明：`asctime_r` 是线程安全版本。 -- 描述：将 `struct tm` 中的数据按照 `format` 的格式填充到字符串 `s` 中，长度最长为 `max`。 +6. `size_t strftime(FAR char *s, size_t max, FAR const char *format, FAR const struct tm *tm)` -`FAR char *strptime(FAR const char *s, FAR const char *format, FAR struct tm *tm)` + 描述：将 `struct tm` 中的数据按照 `format` 的格式填充到字符串 `s` 中，长度最长为 `max`。 -- 描述：将字符串 `s` 按照 `format` 的格式解析，并初始化 `struct tm` 结构体。 +7. `FAR char *strptime(FAR const char *s, FAR const char *format, FAR struct tm *tm)` -`FAR char *ctime(FAR const time_t *timep)` + 描述：将字符串 `s` 按照 `format` 的格式解析，并初始化 `struct tm` 结构体。 -- 描述：返回一个表示当地时间（`localtime`）的字符串。 -- 说明：`ctime_r` 是线程安全版本。 +8. `FAR char *ctime(FAR const time_t *timep)` -`double difftime(time_t time2, time_t time1)` + - 描述：返回一个表示当地时间（`localtime`）的字符串。 + - 说明：`ctime_r` 是线程安全版本。 -- 描述：返回两次时间的差值，单位为秒。 +9. `double difftime(time_t time2, time_t time1)` + + 描述：返回两次时间的差值，单位为秒。 ### 3、高精度时间 API -`int gettimeofday(FAR struct timeval *tv, FAR struct timezone *tz)` +1. `int gettimeofday(FAR struct timeval *tv, FAR struct timezone *tz)` -- 描述：返回当前时间，包含自 `1970-01-01 00:00:00` 起的秒数和微秒数。 + - 描述：返回当前时间，包含自 `1970-01-01 00:00:00` 起的秒数和微秒数。 -- 参数 - - `tv`：指向 `struct timeval` 的指针，用于存储秒数和微秒数。 - - `tz`：时区信息，通常传入 `NULL`。 + - 参数 + - `tv`：指向 `struct timeval` 的指针，用于存储秒数和微秒数。 + - `tz`：时区信息，通常传入 `NULL`。 -- 示例： + - 示例： - ```C - struct timeval tv; - gettimeofday(&tv, NULL); - printf("Seconds: %ld, Microseconds: %ld\n", tv.tv_sec, tv.tv_usec); - ``` + ```C + struct timeval tv; + gettimeofday(&tv, NULL); + printf("Seconds: %ld, Microseconds: %ld\n", tv.tv_sec, tv.tv_usec); + ``` -`int settimeofday(FAR const struct timeval *tv, FAR struct timezone *tz)` +2. `int settimeofday(FAR const struct timeval *tv, FAR struct timezone *tz)` -- 描述：设置系统时间（UTC）。 + 描述：设置系统时间（UTC）。 -`int clock_systime_timespec(FAR struct timespec *ts)` +3. `int clock_systime_timespec(FAR struct timespec *ts)` -- 描述：获取系统的运行时间（内核版 API）。 + 描述：获取系统的运行时间（内核版 API）。 ## 八、命令说明 @@ -448,7 +448,7 @@ ap> date -s "May 11 11:11:21 2022" ### 4、查看本地时间 -（默认显示 localtime，无时区时显示 UTC） +默认显示 localtime，无时区时显示 UTC。 ```Bash ap> date diff --git a/zh-cn/device_dev_guide/kernal/trace_system.md b/zh-cn/device_dev_guide/kernal/trace_system.md index 4425241a..58253705 100644 --- a/zh-cn/device_dev_guide/kernal/trace_system.md +++ b/zh-cn/device_dev_guide/kernal/trace_system.md @@ -11,14 +11,14 @@ Trace 是一种用于跟踪和记录系统活动的工具，能够详细捕获 Trace 以微秒为单位记录事件，并按时间顺序排列，提供精确的系统运行日志。 -### 1 核心原理 +### 1、核心原理 Trace 系统通过在系统运行的关键点插桩来收集事件数据。例如： - 在任务启动时调用 `sched_note_start`。 - 在中断函数中调用 `sched_note_irqhandle`。 -### 2 支持的事件类型 +### 2、支持的事件类型 Trace 工具支持以下事件的跟踪和记录： @@ -33,7 +33,7 @@ Trace 工具支持以下事件的跟踪和记录： 在系统编译时，可以通过 `/drivers/note/Kconfig` 配置需要记录或跟踪的 `Kernel Events` 和可选的 `Channel`。 -### 1 配置 Kernel Events +### 1、配置 Kernel Events 以下是可选择配置的 `Kernel Events`，用于记录和跟踪系统中的关键事件： @@ -57,7 +57,7 @@ SCHED_INSTRUMENTATION_SPINLOCKS SCHED_INSTRUMENTATION_SYSCALL ``` -### 2 使用 API 添加自定义 Trace 的配置 +### 2、使用 API 添加自定义 Trace 的配置 如果仅使用 API 添加自定义 Trace，请启用以下配置项： @@ -155,36 +155,36 @@ CONFIG_DRIVERS_NOTERAM_SECTION=".bss.xxx" 系统打点工具通过 `perf_gettime` API 获取时钟源，可配置为以下三种时钟源，推荐使用第一种方案： -- 方案一：使用硬件 PMU 作为时钟源。 +### 方案一 （推荐）使用硬件 PMU 作为时钟源 - 硬件 PMU 提供高精度（纳秒级）的时间精度，并支持处理时间回滚问题。 +硬件 PMU 提供高精度（纳秒级）的时间精度，并支持处理时间回滚问题。 - ```Bash - # 使能硬件 PMU 时钟源 - CONFIG_ARCH_PERF_EVENTS=y - # 处理 perf 时钟溢出，关闭后时间可能发生回滚 - CONFIG_PERF_OVERFLOW_CORRECTION=y - ``` +```Bash +# 使能硬件 PMU 时钟源 +CONFIG_ARCH_PERF_EVENTS=y +# 处理 perf 时钟溢出，关闭后时间可能发生回滚 +CONFIG_PERF_OVERFLOW_CORRECTION=y +``` -- 方案二：使用硬件定时器作为时钟源。 +### 方案二 使用硬件定时器作为时钟源 - 使用硬件定时器作为时钟源，时钟精度和 `oneshot timer` 一致，并支持处理时间回滚问题。 +使用硬件定时器作为时钟源，时钟精度和 `oneshot timer` 一致，并支持处理时间回滚问题。 - ```Bash - # 关闭硬件 PMU 时钟源，使用定时器作为 perf 时钟源 - CONFIG_ARCH_PERF_EVENTS=n - ``` +```Bash +# 关闭硬件 PMU 时钟源，使用定时器作为 perf 时钟源 +CONFIG_ARCH_PERF_EVENTS=n +``` -- 方案三：使用系统滴答时钟作为时钟源。 +### 方案三 使用系统滴答时钟作为时钟源 - 关闭下面配置，将默认使用系统 systick 作为时钟源， 时钟精度与 `CONFIG_USEC_PER_TICK` 配置一致，默认 10ms 。 +关闭下面配置，将默认使用系统 systick 作为时钟源， 时钟精度与 `CONFIG_USEC_PER_TICK` 配置一致，默认 10ms 。 - ```Bash - # 所有配置均关闭后，自动使用系统时间作为时钟源 - CONFIG_ALARM_ARCH=n - CONFIG_TIMER_ARCH=n - CONFIG_ARCH_PERF_EVENTS=n - ``` +```Bash +# 所有配置均关闭后，自动使用系统时间作为时钟源 +CONFIG_ALARM_ARCH=n +CONFIG_TIMER_ARCH=n +CONFIG_ARCH_PERF_EVENTS=n +``` ## 四、Trace 系统原理 @@ -195,7 +195,7 @@ Trace 系统的核心原理是在系统运行的关键点进行插桩，以收 ![img](./figures/005.png) -### 数据收集与分发 +### 1、数据收集与分发 Trace 系统通过插桩 API 收集系统运行数据，并将数据分发到不同的 Channel。每个 Channel 可输出到不同的后端。目前支持的后端包括： @@ -207,7 +207,7 @@ Trace 系统通过插桩 API 收集系统运行数据，并将数据分发到不 ## 五、API 使用说明 -### 1 内核打点函数/宏 +### 1、内核打点函数/宏 以下 API 用于在内核代码中添加固定插桩代码。 @@ -283,7 +283,7 @@ Trace 系统通过插桩 API 收集系统运行数据，并将数据分发到不 void sched_note_syscall_leave(int nr, uintptr_t result); ``` -### 2 自定义打点 API +### 2、自定义打点 API `sched_note` 的扩展部分可用于在应用代码中添加打点功能。通过配置宏 `CONFIG_SCHED_INSTRUMENTATION_DUMP` 可启用该功能。 @@ -386,7 +386,7 @@ enum note_tag_e - `Event`：支持自定义事件 ID，可结合上述枚举值使用，以便更精确地标识和分类事件。 -### 3 自定义 Trace Buffer +### 3、自定义 Trace Buffer 如果内核模块需要自定义一个 buffer 来存放私有事件，可通过以下方法注册一个 `noteram` 驱动，并指定需要关注的事件类型。 @@ -449,7 +449,7 @@ void note_rpmsg_initialize(void) } ``` -### 4 使用示例 +### 4、使用示例 #### 功能说明 @@ -528,11 +528,11 @@ int main(int argc, FAR char *argv[]) ## 六、ATRACE 使用 -### 1 功能概述 +### 1、功能概述 ATRACE 是一种用于性能分析和调试的工具，提供了一系列宏，用于记录不同类型的事件和上下文信息。例如，ATRACE 可以用于跟踪函数执行时间、异步事件、瞬时事件以及整数计数器的变化。 -### 2 ATRACE 宏说明 +### 2、ATRACE 宏说明 以下是 ATRACE 提供的主要宏及其功能描述： @@ -644,7 +644,7 @@ private: }; ``` -### 3 ATrace TAG +### 3、ATrace TAG ```C #define ATRACE_TAG_NEVER 0 // This tag is never enabled. @@ -679,7 +679,7 @@ private: #define ATRACE_TAG_LAST ATRACE_TAG_THERMAL ``` -### 4 使用示例 +### 4、使用示例 1. 在代码中插桩。 @@ -749,7 +749,7 @@ private: ## 七、函数自动插桩 -#### 原理介绍 +#### 1、原理介绍 通过 `__cyg_profile_func_enter` 和 `__cyg_profile_func_exit` 函数，自动记录函数的开始和结束信息。结合编译选项，用户可以为指定模块启用自动插桩功能，同时排除特定文件或函数。以下是插桩函数的实现代码： @@ -775,7 +775,7 @@ __cyg_profile_func_exit(void *this_fn, void *call_site) } ``` -#### 使用方法 +#### 2、使用方法 1. 启用功能选项。 在 `menuconfig` 中启用以下配置项： diff --git a/zh-cn/device_dev_guide/security/security_configuration.md b/zh-cn/device_dev_guide/security/security_configuration.md index 8ca1c148..723590a9 100644 --- a/zh-cn/device_dev_guide/security/security_configuration.md +++ b/zh-cn/device_dev_guide/security/security_configuration.md @@ -61,7 +61,7 @@ 在 QEMU (Quick Emulator) / SIM 模拟平台上，无需使用独立的 TEE 核来提供安全环境。可以通过模拟运行，将 TEE 核的功能整合为一个独立的 AP 服务进程。为实现此目标，需要完成以下调整： -1. 通信方式调整：将跨核通信方式从 PRMSG 修改为 LOCAL SOCKET 通信，以简化通信逻辑并适配模拟平台。 +1. 通信方式调整：将跨核通信方式从 RPMsg 修改为 LOCAL SOCKET 通信，以简化通信逻辑并适配模拟平台。 2. 配置迁移：将所有 TEE 核的相关配置迁移至 AP 核，集中实现系统的功能逻辑。 | 序号 | 配置项 | 是否必选 | 默认值 | 功能描述 | diff --git a/zh-cn/overview/glossary.md b/zh-cn/overview/glossary.md index 7cd7d202..03100844 100644 --- a/zh-cn/overview/glossary.md +++ b/zh-cn/overview/glossary.md @@ -12,7 +12,7 @@ - Bssid（Basic Service Set Identifier） - 通常指无线接入点（AP，Access Point）的MAC地址。 + 通常指无线接入点（AP，Access Point）的 MAC 地址。 ## C diff --git a/zh-cn/quickstart/Set_up_the_development_environment_zh-cn.md b/zh-cn/quickstart/Set_up_the_development_environment_zh-cn.md index 34562079..e0d4efd4 100644 --- a/zh-cn/quickstart/Set_up_the_development_environment_zh-cn.md +++ b/zh-cn/quickstart/Set_up_the_development_environment_zh-cn.md @@ -12,7 +12,7 @@ ## 二、操作系统需求 -开发工作站需运行 64 位 Linux 发行版。 +开发工作站需**运行 64 位 Linux 发行版**。 ## 三、安装必备的软件包