forked from espressif/esp-idf
Merge branch 'docs/add_sphinx_lint' into 'master'
docs(sphinx-lint): Add sphinx-lint to pre-commit See merge request espressif/esp-idf!28578
This commit is contained in:
Kirill Chalov
@@ -225,3 +225,9 @@ repos:
|
||||
hooks:
|
||||
- id: validate-sbom-manifest
|
||||
stages: [post-commit]
|
||||
- repo: https://github.com/sphinx-contrib/sphinx-lint
|
||||
rev: v0.9.1
|
||||
hooks:
|
||||
- id: 'sphinx-lint'
|
||||
name: Lint rST files in docs folder using Sphinx Lint
|
||||
files: ^(docs/en|docs/zh_CN)/.*\.(rst|inc)$
|
||||
|
||||
@@ -26,7 +26,7 @@ Most applications use the following workflow when working with ``esp_vfs_fat_``
|
||||
|
||||
#. Call :cpp:func:`ff_diskio_register` to register the disk I/O driver for the drive number used in Step 1.
|
||||
|
||||
#. To mount the filesystem using the same drive number which was passed to :cpp:func:`esp_vfs_fat_register`, call the FatFs function :cpp:func:`f_mount`. If the filesystem is not present on the target logical drive, :cpp:func:`f_mount` will fail with the ``FR_NO_FILESYSTEM`` error. In such case, call :cpp:func:`f_mkfs` to create a fresh FatFS structure on the drive first, and then call:cpp:func:`f_mount` again. Note that SD cards need to be partitioned with :cpp:func:`f_fdisk` prior to previously described steps. For more information, see `FatFs documentation <http://elm-chan.org/fsw/ff/doc/mount.html>`_.
|
||||
#. To mount the filesystem using the same drive number which was passed to :cpp:func:`esp_vfs_fat_register`, call the FatFs function :cpp:func:`f_mount`. If the filesystem is not present on the target logical drive, :cpp:func:`f_mount` will fail with the ``FR_NO_FILESYSTEM`` error. In such case, call :cpp:func:`f_mkfs` to create a fresh FatFS structure on the drive first, and then call :cpp:func:`f_mount` again. Note that SD cards need to be partitioned with :cpp:func:`f_fdisk` prior to previously described steps. For more information, see `FatFs documentation <http://elm-chan.org/fsw/ff/doc/mount.html>`_.
|
||||
|
||||
#. Call the C standard library and POSIX API functions to perform such actions on files as open, read, write, erase, copy, etc. Use paths starting with the path prefix passed to :cpp:func:`esp_vfs_register` (for example, ``"/sdcard/hello.txt"``). The filesystem uses `8.3 filenames <https://en.wikipedia.org/wiki/8.3_filename>`_ format (SFN) by default. If you need to use long filenames (LFN), enable the :ref:`CONFIG_FATFS_LONG_FILENAMES` option. Please refer to `FatFs filenames <http://elm-chan.org/fsw/ff/doc/filename.html>`_ for more details.
|
||||
|
||||
|
||||
@@ -322,4 +322,3 @@ Debugging OTA Failure
|
||||
:figclass: align-center
|
||||
|
||||
How to Debug When OTA Fails (click to enlarge)
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ Peripherals
|
||||
Drivers
|
||||
-------
|
||||
|
||||
In order to control the dependence of other components on drivers at a smaller granularity, the original peripheral drivers under the `driver`` component were split into separate components:
|
||||
In order to control the dependence of other components on drivers at a smaller granularity, the original peripheral drivers under the ``driver`` component were split into separate components:
|
||||
|
||||
- `esp_driver_gptimer` - Driver for general purpose timers
|
||||
- `esp_driver_pcnt` - Driver for pulse counter
|
||||
@@ -28,7 +28,7 @@ In order to control the dependence of other components on drivers at a smaller g
|
||||
- `esp_driver_parlio` - Driver for Parallel IO
|
||||
- `esp_driver_usb_serial_jtag` - Driver for USB_SERIAL_JTAG
|
||||
|
||||
For compatibility, the original `driver`` component is still treated as an all-in-one component by registering these `esp_driver_xyz`` components as its public dependencies. In other words, you do not need to modify the CMake file of an existing project, but you now have a way to specify the specific peripheral driver that your project depends on.
|
||||
For compatibility, the original ``driver`` component is still treated as an all-in-one component by registering these `esp_driver_xyz` components as its public dependencies. In other words, you do not need to modify the CMake file of an existing project, but you now have a way to specify the specific peripheral driver that your project depends on.
|
||||
|
||||
Originally, you may have used **linker.lf** to specify the link location of some driver functions in memory space, but now, because the location of the driver files have been moved, you need to make changes your **linker.lf** file accordingly. For example, a linker.lf file with the following entries:
|
||||
|
||||
|
||||
@@ -607,5 +607,3 @@ Secure Boot V2 Guidelines
|
||||
.. only:: SOC_EFUSE_REVOKE_BOOT_KEY_DIGESTS
|
||||
|
||||
* It is recommended to use all the available digest slots to reduce dependency on a single private key.
|
||||
|
||||
|
||||
|
||||
@@ -694,7 +694,7 @@ project_include.cmake
|
||||
|
||||
``project_include.cmake`` 文件在 ESP-IDF 内部使用，以定义项目范围内的构建功能，比如 ``esptool.py`` 的命令行参数和 ``bootloader`` 这个特殊的应用程序。
|
||||
|
||||
与组件 ``CMakeLists.txt`` 文件有所不同，在导入``project_include.cmake`` 文件的时候，当前源文件目录（即 ``CMAKE_CURRENT_SOURCE_DIR``和工作目录）为项目目录。如果想获得当前组件的绝对路径，可以使用 ``COMPONENT_PATH`` 变量。
|
||||
与组件 ``CMakeLists.txt`` 文件有所不同，在导入 ``project_include.cmake`` 文件的时候，当前源文件目录（即 ``CMAKE_CURRENT_SOURCE_DIR`` 和工作目录）为项目目录。如果想获得当前组件的绝对路径，可以使用 ``COMPONENT_PATH`` 变量。
|
||||
|
||||
请注意，``project_include.cmake`` 对于大多数常见的组件并不是必需的。例如给项目添加 include 搜索目录，给最终的链接步骤添加 ``LDFLAGS`` 选项等等都可以通过 ``CMakeLists.txt`` 文件来自定义。详细信息请参考 :ref:`optional_project_variable`。
|
||||
|
||||
@@ -1311,7 +1311,7 @@ ESP-IDF 构建属性
|
||||
- DEPENDENCIES_LOCK - 组件管理器使用的依赖关系锁定文件的路径。默认值为项目路径下的 `dependencies.lock`。
|
||||
- EXECUTABLE_NAME - 不含扩展名的项目可执行文件的名称；通过调用 ``idf_build_executable`` 设置。
|
||||
- EXECUTABLE_DIR - 输出的可执行文件的路径
|
||||
- IDF_COMPONENT_MANAGER - 默认启用组件管理器，但如果设置这个属性为`0``，则会被 IDF_COMPONENT_MANAGER 环境变量禁用。
|
||||
- IDF_COMPONENT_MANAGER - 默认启用组件管理器，但如果设置这个属性为 ``0``，则会被 IDF_COMPONENT_MANAGER 环境变量禁用。
|
||||
- IDF_PATH - ESP-IDF 路径；由 IDF_PATH 环境变量设置，或者从 ``idf.cmake`` 的位置推断。
|
||||
- IDF_TARGET - 构建的目标芯片；由 ``idf_build_process`` 的目标参数设置。
|
||||
- IDF_VER - ESP-IDF 版本；由版本文件或 IDF_PATH 仓库的 Git 版本设置。
|
||||
@@ -1414,7 +1414,7 @@ ESP-IDF 组件属性
|
||||
- KCONFIG - 组件 Kconfig 文件；由 ``idf_build_component`` 设置。
|
||||
- KCONFIG_PROJBUILD - 组件 Kconfig.projbuild；由 ``idf_build_component`` 设置。
|
||||
- LDFRAGMENTS - 组件链接器片段文件列表；由 ``idf_component_register`` LDFRAGMENTS 参数设置。
|
||||
- MANAGED_PRIV_REQUIRES - IDF 组件管理器从``idf_component.yml``清单文件中的依赖关系中添加的私有组件依赖关系列表。
|
||||
- MANAGED_PRIV_REQUIRES - IDF 组件管理器从 ``idf_component.yml`` 清单文件中的依赖关系中添加的私有组件依赖关系列表。
|
||||
- MANAGED_REQUIRES - IDF 组件管理器从 ``idf_component.yml`` 清单文件的依赖关系中添加的公共组件依赖关系列表。
|
||||
- PRIV_INCLUDE_DIRS - 组件私有 include 目录列表；在 LIBRARY 类型的组件 ``idf_component_register`` PRIV_INCLUDE_DIRS 参数中设置。
|
||||
- PRIV_REQUIRES - 私有组件依赖关系列表；根据 ``idf_component_register`` PRIV_REQUIRES 参数的值以及 ``idf_component.yml`` 清单文件中的依赖关系设置。
|
||||
@@ -1500,7 +1500,7 @@ ESP-IDF 构建系统的列表文件位于 :idf:`/tools/cmake` 中。实现构建
|
||||
除了这些文件，还有两个重要的 CMake 脚本在 :idf:`/tools/cmake` 中：
|
||||
|
||||
- idf.cmake - 设置构建参数并导入上面列出的核心模块。之所以包括在 CMake 项目中，是为了方便访问 ESP-IDF 构建系统功能。
|
||||
- project.cmake - 导入 ``idf.cmake``，并提供了一个自定义的``project()``命令，该命令负责处理建立可执行文件时所有的繁重工作。包含在标准 ESP-IDF 项目的顶层 CMakeLists.txt 中。
|
||||
- project.cmake - 导入 ``idf.cmake``，并提供了一个自定义的 ``project()`` 命令，该命令负责处理建立可执行文件时所有的繁重工作。包含在标准 ESP-IDF 项目的顶层 CMakeLists.txt 中。
|
||||
|
||||
:idf:`/tools/cmake` 中的其它文件都是构建过程中的支持性文件或第三方脚本。
|
||||
|
||||
@@ -1535,9 +1535,9 @@ ESP-IDF 构建系统的列表文件位于 :idf:`/tools/cmake` 中。实现构建
|
||||
- 设置全局构建参数，即编译选项、编译定义、包括所有组件的 include 目录。
|
||||
- 将 :idf:`components` 中的组件添加到构建中。
|
||||
- 自定义 ``project()`` 命令的初始部分执行以下步骤：
|
||||
- 在环境变量或 CMake 缓存中设置 ``IDF_TARGET`` 以及设置相应要使用的``CMAKE_TOOLCHAIN_FILE``。
|
||||
- 在环境变量或 CMake 缓存中设置 ``IDF_TARGET`` 以及设置相应要使用的 ``CMAKE_TOOLCHAIN_FILE``。
|
||||
- 添加 ``EXTRA_COMPONENT_DIRS`` 中的组件至构建中
|
||||
- 从 ``COMPONENTS``/``EXCLUDE_COMPONENTS``、``SDKCONFIG``、``SDKCONFIG_DEFAULTS`` 等变量中为调用命令 ``idf_build_process()`` 准备参数。
|
||||
- 从 ``COMPONENTS``/ ``EXCLUDE_COMPONENTS``、``SDKCONFIG``、``SDKCONFIG_DEFAULTS`` 等变量中为调用命令 ``idf_build_process()`` 准备参数。
|
||||
|
||||
调用 ``idf_build_process()`` 命令标志着这个阶段的结束。
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ USB 连接
|
||||
Udev 规则（仅限 Linux）
|
||||
--------------------------------
|
||||
|
||||
Udev 是 Linux 内核的设备管理器，允许用户在没有 ``sudo`` 的情况下运行 ``dfu-util``（和 ``idf.py dfu-flash``）从而访问芯片。
|
||||
Udev 是 Linux 内核的设备管理器，允许用户在没有 ``sudo`` 的情况下运行 ``dfu-util`` （和 ``idf.py dfu-flash``）从而访问芯片。
|
||||
|
||||
创建文件 ``/etc/udev/rules.d/40-dfuse.rules``，并在文件中添加如下内容::
|
||||
|
||||
|
||||
@@ -204,7 +204,7 @@ ESP-BLE-MESH 架构主要由以下 5 大部分组成：
|
||||
|
||||
``API /事件`` 与 ESP-BLE-MESH 协议栈的交互
|
||||
|
||||
- 用户使用的 API 主要调用``Mesh Networking``、``Mesh Provisioning`` 和 ``Mesh Models`` 提供的函数。
|
||||
- 用户使用的 API 主要调用 ``Mesh Networking``、 ``Mesh Provisioning`` 和 ``Mesh Models`` 提供的函数。
|
||||
|
||||
- ``API /事件`` 和协议栈的交互不会跨越协议栈的层级进行操作。比如 API 不会调用 ``Network Layer`` 相关的函数。
|
||||
|
||||
|
||||
@@ -533,7 +533,7 @@ FreeRTOS 堆栈检查
|
||||
- 移位基数或指数错误（如移位超过 32 位）
|
||||
- 整数转换错误
|
||||
|
||||
请参考 `GCC 文档 <https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html>`_ 中的``-fsanitize=undefined`` 选项，查看支持检查的完整列表。
|
||||
请参考 `GCC 文档 <https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html>`_ 中的 ``-fsanitize=undefined`` 选项，查看支持检查的完整列表。
|
||||
|
||||
使能 UBSAN
|
||||
""""""""""""""
|
||||
|
||||
@@ -145,7 +145,7 @@
|
||||
else:
|
||||
* (default)
|
||||
|
||||
来看一种更复杂的情况。假设``CONFIG_PERFORMANCE_LEVEL == 1`` 时，只有 ``object1.o`` 存放到 RAM 中；``CONFIG_PERFORMANCE_LEVEL == 2`` 时，``object1.o`` 和 ``object2.o`` 会存放到 RAM 中；``CONFIG_PERFORMANCE_LEVEL == 3`` 时，库中的所有目标文件都会存放到 RAM 中。以上三个条件为假时，整个库会存放到 RTC 存储器中。虽然这种使用场景很罕见，不过，还是可以通过以下方式实现：
|
||||
来看一种更复杂的情况。假设 ``CONFIG_PERFORMANCE_LEVEL == 1`` 时，只有 ``object1.o`` 存放到 RAM 中； ``CONFIG_PERFORMANCE_LEVEL == 2`` 时，``object1.o`` 和 ``object2.o`` 会存放到 RAM 中； ``CONFIG_PERFORMANCE_LEVEL == 3`` 时，库中的所有目标文件都会存放到 RAM 中。以上三个条件为假时，整个库会存放到 RTC 存储器中。虽然这种使用场景很罕见，不过，还是可以通过以下方式实现：
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
||||
@@ -162,7 +162,7 @@ ESP-IDF 应用程序的入口是 :idf_file:`components/esp_system/port/cpu_start
|
||||
|
||||
主任务的内核亲和性也是可以配置的，请参考 :ref:`CONFIG_ESP_MAIN_TASK_AFFINITY`。
|
||||
|
||||
与普通的 FreeRTOS 任务（或嵌入式 C 的 ``main`` 函数）不同，``app_main`` 任务可以返回。如果``app_main`` 函数返回，那么主任务将会被删除。系统将继续运行其他的 RTOS 任务。因此可以将 ``app_main`` 实现为一个创建其他应用任务然后返回的函数，或主应用任务本身。
|
||||
与普通的 FreeRTOS 任务（或嵌入式 C 的 ``main`` 函数）不同，``app_main`` 任务可以返回。如果 ``app_main`` 函数返回，那么主任务将会被删除。系统将继续运行其他的 RTOS 任务。因此可以将 ``app_main`` 实现为一个创建其他应用任务然后返回的函数，或主应用任务本身。
|
||||
|
||||
.. only:: SOC_HP_CPU_HAS_MULTIPLE_CORES
|
||||
|
||||
|
||||
@@ -229,7 +229,7 @@ DUT2 (slave) 终端::
|
||||
- 方括号中的模块名字，运行指定模块所有的测试用例。
|
||||
- 星号，运行所有测试用例。
|
||||
|
||||
``[multi_device]`` 和 ``[multi_stage]``标签告诉测试运行者该用例是多设备测试还是多阶段测试。这些标签由 ``TEST_CASE_MULTIPLE_STAGES`` 和 ``TEST_CASE_MULTIPLE_DEVICES`` 宏自动生成。
|
||||
``[multi_device]`` 和 ``[multi_stage]`` 标签告诉测试运行者该用例是多设备测试还是多阶段测试。这些标签由 ``TEST_CASE_MULTIPLE_STAGES`` 和 ``TEST_CASE_MULTIPLE_DEVICES`` 宏自动生成。
|
||||
|
||||
一旦选择了多设备测试用例，它会打印一个子菜单::
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ SPI 传输事务
|
||||
使用驱动程序
|
||||
------------
|
||||
|
||||
- 调用函数 cpp:func:`spi_slave_initialize`，将 SPI 外设初始化为从机设备。请确保在 `bus_config` 中设置正确的 I/O 管脚，并将未使用的信号设置为 ``-1``。
|
||||
- 调用函数 :cpp:func:`spi_slave_initialize`，将 SPI 外设初始化为从机设备。请确保在 `bus_config` 中设置正确的 I/O 管脚，并将未使用的信号设置为 ``-1``。
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ SPIFFS 是一个用于 SPI NOR flash 设备的嵌入式文件系统，支持磨
|
||||
- SPIFFS 并非实时栈，每次写操作耗时不等；
|
||||
- 目前，SPIFFS 尚不支持检测或处理已损坏的块。
|
||||
- SPIFFS 只能稳定地使用约 75% 的指定分区容量。
|
||||
- 当文件系统空间不足时，垃圾收集器会尝试多次扫描文件系统来寻找可用空间。根据所需空间的不同，写操作会被调用多次，每次函数调用将花费几秒。同一操作可能会花费不同时长的问题缘于 SPIFFS 的设计，且已在官方的 `SPIFFS github 仓库 <https://github.com/pellepl/spiffs/issues/>`_ 或是 <https://github.com/espressif/esp-idf/issues/1737>`_ 中被多次报告。这个问题可以通过 `SPIFFS 配置 <https://github.com/pellepl/spiffs/wiki/Configure-spiffs>`_ 部分缓解。
|
||||
- 当文件系统空间不足时，垃圾收集器会尝试多次扫描文件系统来寻找可用空间。根据所需空间的不同，写操作会被调用多次，每次函数调用将花费几秒。同一操作可能会花费不同时长的问题缘于 SPIFFS 的设计，且已在官方的 `SPIFFS github 仓库 <https://github.com/pellepl/spiffs/issues/>`_ 或是 `<https://github.com/espressif/esp-idf/issues/1737>`_ 中被多次报告。这个问题可以通过 `SPIFFS 配置 <https://github.com/pellepl/spiffs/wiki/Configure-spiffs>`_ 部分缓解。
|
||||
- 被删除文件通常不会被完全清除，会在文件系统中遗留下无法使用的部分。
|
||||
- 如果 {IDF_TARGET_NAME} 在文件系统操作期间断电，可能会导致 SPIFFS 损坏。但是仍可通过 ``esp_spiffs_check`` 函数恢复文件系统。详情请参阅官方 SPIFFS `FAQ <https://github.com/pellepl/spiffs/wiki/FAQ>`_。
|
||||
|
||||
@@ -25,7 +25,7 @@ SPIFFS 是一个用于 SPI NOR flash 设备的嵌入式文件系统，支持磨
|
||||
``spiffsgen.py``
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
:component_file:`spiffsgen.py<spiffs/spiffsgen.py>`（只写）是 SPIFFS 的一种 Python 实现，可用于从主机文件夹内容生成文件系统镜像。打开终端并运行以下命令即可使用 ``spiffsgen.py``::
|
||||
:component_file:`spiffsgen.py<spiffs/spiffsgen.py>` （只写）是 SPIFFS 的一种 Python 实现，可用于从主机文件夹内容生成文件系统镜像。打开终端并运行以下命令即可使用 ``spiffsgen.py``::
|
||||
|
||||
python spiffsgen.py <image_size> <base_dir> <output_file>
|
||||
|
||||
|
||||
@@ -1,2 +1 @@
|
||||
.. include:: ../../../en/api-reference/system/inc/espefuse_summary_ESP32-C2.rst
|
||||
|
||||
@@ -55,7 +55,7 @@
|
||||
|
||||
.. note::
|
||||
|
||||
在关键部分中断被禁用，因此只能使用 ``ESP_DRAM_LOGx``（首选）或 ``ESP_EARLY_LOGx`` 宏。尽管这样可以输出日志，但最好可以调整程序使其不用输出日志。
|
||||
在关键部分中断被禁用，因此只能使用 ``ESP_DRAM_LOGx`` （首选）或 ``ESP_EARLY_LOGx`` 宏。尽管这样可以输出日志，但最好可以调整程序使其不用输出日志。
|
||||
|
||||
如需在文件或组件范围内覆盖默认的日志级别，请定义 ``LOG_LOCAL_LEVEL`` 宏。
|
||||
|
||||
|
||||
@@ -56,7 +56,7 @@ OTA 数据分区的容量是 2 个 flash 扇区的大小（0x2000 字节），
|
||||
则仅会选取一次。在引导加载程序中，状态立即变为
|
||||
``ESP_OTA_IMG_PENDING_VERIFY``。
|
||||
ESP_OTA_IMG_PENDING_VERIFY 如使能 :ref:`CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE`，
|
||||
则不会选取，状态变为``ESP_OTA_IMG_ABORTED``。
|
||||
则不会选取，状态变为 ``ESP_OTA_IMG_ABORTED``。
|
||||
============================= ========================================================
|
||||
|
||||
如果 :ref:`CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE` 没有使能（默认情况），则 :cpp:func:`esp_ota_mark_app_valid_cancel_rollback` 和 :cpp:func:`esp_ota_mark_app_invalid_rollback_and_reboot` 为可选功能，``ESP_OTA_IMG_NEW`` 和 ``ESP_OTA_IMG_PENDING_VERIFY`` 不会使用。
|
||||
@@ -322,4 +322,3 @@ OTA 升级失败排查
|
||||
:figclass: align-center
|
||||
|
||||
OTA 升级失败时如何排查（点击放大）
|
||||
|
||||
|
||||
@@ -393,4 +393,3 @@ ESP32-S2-Kaluga-1 Kit v1.2
|
||||
有关本开发板的更多设计文档，请联系我们的商务部门 sales@espressif.com。
|
||||
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ Trax API（即以 ``trax_`` 为前缀的函数、类型或宏）已更新为私
|
||||
ROM
|
||||
---
|
||||
|
||||
``components/esp32/rom/`` 路径下存放的已弃用的 ROM 相关头文件已移除（原包含路径为 ``rom/*.h``）。请使用新的特定目标的路径 ``components/esp_rom/include/{IDF_TARGET_NAME}/``（新的包含路径为 ``{IDF_TARGET_NAME}/rom/*.h``）。
|
||||
``components/esp32/rom/`` 路径下存放的已弃用的 ROM 相关头文件已移除（原包含路径为 ``rom/*.h``）。请使用新的特定目标的路径 ``components/esp_rom/include/{IDF_TARGET_NAME}/`` （新的包含路径为 ``{IDF_TARGET_NAME}/rom/*.h``）。
|
||||
|
||||
``esp_hw_support``
|
||||
---------------------
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
驱动程序
|
||||
---------------
|
||||
|
||||
为了细粒度地控制其他组件对外设驱动的依赖，原先位于 `driver` 组件下的驱动程序被拆分到了各自独立的组件中。这些组件包括：
|
||||
为了细粒度地控制其他组件对外设驱动的依赖，原先位于 ``driver`` 组件下的驱动程序被拆分到了各自独立的组件中。这些组件包括：
|
||||
|
||||
- `esp_driver_gptimer` - 通用定时器驱动
|
||||
- `esp_driver_pcnt` - 脉冲计数器驱动
|
||||
@@ -28,7 +28,7 @@
|
||||
- `esp_driver_parlio` - 并行 IO 驱动
|
||||
- `esp_driver_usb_serial_jtag` - USB_SERIAL_JTAG 驱动
|
||||
|
||||
为了兼容性，原来的 `driver` 组件仍然存在，并作为一个 “all-in-one" 的组件，将以上这些 `esp_driver_xyz` 组件注册成自己的公共依赖。换句话说，你无需修改既有项目的 CMake 文件，但是你现在多了一个途径去指定你项目依赖的具体的外设驱动。
|
||||
为了兼容性，原来的 ``driver`` 组件仍然存在，并作为一个 “all-in-one" 的组件，将以上这些 `esp_driver_xyz` 组件注册成自己的公共依赖。换句话说，你无需修改既有项目的 CMake 文件，但是你现在多了一个途径去指定你项目依赖的具体的外设驱动。
|
||||
|
||||
原来你可能使用 **linker.lf** 指定了一些驱动函数在内存空间的链接位置，但是现在，因为驱动文件的位置发生了挪动，就需要你对 **linker.lf** 文件做出相应的改动的。假如，你的 linker.lf 文件里面有以下的条目：
|
||||
|
||||
|
||||
Reference in New Issue
Block a user