Merge branch 'docs/sync_cn_and_en_docs' into 'master'

docs: Sync CN and EN docs missing the translation label

Closes DOC-14472

See merge request espressif/esp-idf!48241

docs/en/api-guides/ble/ble-audio.rst

@@ -302,7 +302,7 @@ PBP depends entirely on BAP for the underlying broadcast transport; it does not
 
 
 Profile and Service Dependency Reference
------------------------------------------
+----------------------------------------
 
 The following tables summarize the dependencies between profiles and services in the ESP-IDF LE Audio implementation.
 

docs/en/api-guides/external-ram.rst

@@ -253,6 +253,7 @@ By default, failure to initialize external RAM will cause the ESP-IDF startup to
 
         On {IDF_TARGET_NAME}, PSRAM encryption can use an independent encryption key. If the PSRAM encryption key is not programmed, the flash encryption key will be used as the PSRAM encryption key.
 
+
 .. only:: esp32
 
     .. include:: inc/external-ram-esp32-notes.rst

docs/en/api-guides/tools/idf-tools.rst

@@ -60,7 +60,9 @@ To use Espressif's download server, set the environment variable ``IDF_GITHUB_AS
 
 Any mirror server can be used provided the URL matches the ``github.com`` download URL format. For any GitHub asset URL that the install process downloads, it will replace ``https://github.com`` with ``https://${IDF_GITHUB_ASSETS}``.
 
-.. note:: The Espressif download server currently does not mirror everything from GitHub, but only files attached as Assets to some releases, as well as source archives for some releases.
+.. note::
+
+    The Espressif download server currently does not mirror everything from GitHub, but only files attached as Assets to some releases, as well as source archives for some releases.
 
 .. _idf-tools-py:
 

docs/en/api-reference/bluetooth/index.rst

@@ -90,7 +90,7 @@ For additional details and API reference from the upstream documentation, refer
 ----
 
 Examples and Tutorials
----------------------------
+----------------------
 
 Explore examples and tutorials in the ESP-IDF examples directory:
 

docs/en/api-reference/system/console.rst

@@ -187,7 +187,7 @@ To establish a basic REPL environment, ``console`` component provides several us
 
 In a typical application, you only need to call :cpp:func:`esp_console_new_repl_stdio` to initialize the REPL environment, including driver install, basic console configuration, spawning a thread to do REPL task and register several useful commands (e.g., `help`).
 
-After that, you can register your own commands with :cpp:func:`esp_console_cmd_register`. The REPL environment keeps in init state until you call :cpp:func:`esp_console_start_repl`.
+After that, you can register your own commands with :cpp:func:`esp_console_cmd_register`. The REPL environment keeps in initialized state until you call :cpp:func:`esp_console_start_repl`.
 
 
 Application Examples

docs/en/api-reference/system/efuse.rst

@@ -573,9 +573,9 @@ To get a dump for all eFuse registers.
 Deferred WR_DIS Burning
 -----------------------
 
-``WR_DIS`` (Write Disable) is a special eFuse field that implements permanent write-protection. Each bit in ``WR_DIS`` disables further programming of one (or more) associated eFuse fields. Once burned, the affected fields can no longer be modified.
+``WR_DIS`` (Write Disable) is a special eFuse field that implements permanent write-protection. Each bit in ``WR_DIS`` disables further programming of one (or more) associated eFuse fields. Once a ``WR_DIS`` bit is burned, its associated fields can no longer be modified.
 
-When burning staged data in BLOCK0, ``WR_DIS`` bits are burned separately after all other BLOCK0 data to ensure the retry mechanism of the burn function can recover from coding errors. This approach guarantees that write-protection is applied only after other BLOCK0 data is successfully burned.
+When burning staged data in BLOCK0, the ``WR_DIS`` bits are burned separately after all other BLOCK0 data to ensure the burn function can recover from coding errors via its retry mechanism. This approach guarantees that write-protection is applied only after other BLOCK0 data is successfully burned.
 
 Application Examples
 --------------------

docs/en/api-reference/system/freertos_idf.rst

@@ -434,8 +434,8 @@ Misc
 
 .. only:: SOC_CPU_HAS_PIE
 
-    PIE / AI Coprocessor Usage
-    ^^^^^^^^^^^^^^^^^^^^^^^^^^
+    PIE/AI Coprocessor Usage
+    ^^^^^^^^^^^^^^^^^^^^^^^^
 
     Like the Floating Point Unit (FPU), IDF FreeRTOS implements **Lazy Context Switching** for the PIE coprocessor. On a context switch, PIE registers remain untouched until a task executes a PIE instruction. Once a task uses the PIE coprocessor, it is **pinned to the current core**.
 
@@ -444,6 +444,7 @@ Misc
         .. note::
 
             On ESP32-S31, the PIE coprocessor is available **only on Core 1**. If a task executes a PIE instruction while running on Core 0, IDF FreeRTOS migrates the task to Core 1 and pins it there. This migration **overrides** any existing core affinity.
+
             Because of this migration, tasks must **not** use the PIE coprocessor within a critical section or ISR, as doing so will cause a runtime abort.
 
 

docs/en/api-reference/system/mem_alloc.rst

@@ -41,7 +41,7 @@ All DRAM memory is single-byte accessible, thus all DRAM heaps possess the ``MAL
 
     .. note::
 
-        This option is available only on single-core ESP32 configuration (``CONFIG_FREERTOS_UNICORE=y``). The ``CONFIG_ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY`` option has a significant disadvantage compared to regular memory: every byte, half-word, and arbitrary unaligned access to ``MALLOC_CAP_IRAM_8BIT`` memory triggers a ``LoadStore`` or ``Alignment`` exception. Although these exceptions are handled in software to ensure correct values are read or written, each access incurs approximately 167 CPU cycles of overhead and can cause significant performance degradation if accessed frequently. Therefore, it should be avoided in performance-critical sections of code such as ISRs or tight loops. Consider to refactor the code to use 32-bit aligned (``uint32_t``) accesses.
+        This option is available only on single-core ESP32 configuration (``CONFIG_FREERTOS_UNICORE=y``). The ``CONFIG_ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY`` option has a significant disadvantage compared to regular memory: every byte, half-word, and arbitrary unaligned access to ``MALLOC_CAP_IRAM_8BIT`` memory triggers a ``LoadStore`` or ``Alignment`` exception. Although these exceptions are handled in software to ensure correct values are read or written, each access incurs approximately 167 CPU cycles of overhead and can cause significant performance degradation if accessed frequently. Therefore, it should be avoided in performance-critical sections of code such as ISRs or tight loops. Consider refactoring the code to use 32-bit aligned (``uint32_t``) accesses.
 
 When calling ``malloc()``, the ESP-IDF ``malloc()`` internally calls ``heap_caps_malloc_default(size)``. This will allocate memory with the capability ``MALLOC_CAP_DEFAULT``, which is byte-addressable.
 

docs/en/security/flash-encryption.rst

@@ -1276,6 +1276,7 @@ The command ``idf.py decrypt-flash-data`` can be used with the same options (and
 
     On {IDF_TARGET_NAME}, PSRAM encryption can use an independent encryption key. If the PSRAM encryption key is not programmed, the flash encryption key will be used as the PSRAM encryption key.
 
+
 Technical Details
 -----------------
 

docs/zh_CN/api-guides/ble/ble-audio.rst

@@ -306,7 +306,6 @@ PBP 完全依赖 BAP 提供底层广播传输，不定义新的 GATT 服务。
 
 以下表格汇总了 ESP-IDF LE Audio 实现中规范与服务之间的依赖关系。
 
-
 规范对服务的依赖
 ^^^^^^^^^^^^^^^^
 

docs/zh_CN/api-guides/external-ram.rst

@@ -239,7 +239,7 @@ ESP-IDF 启动过程中，片外 RAM 被映射到数据虚拟地址空间，该
 .. only:: not esp32
 
     加密
-    ==========
+    ====
 
     可以为存储在外部 RAM 中的数据启用自动加密功能。启用该功能后，通过缓存读写的任何数据将被外部存储器加密硬件自动加密、解密。
 

docs/zh_CN/api-guides/tools/idf-tools.rst

@@ -45,6 +45,8 @@
 - ``python_env`` —  与工具无关；虚拟 Python 环境安装在其子目录中。注意，设置 ``IDF_PYTHON_ENV_PATH`` 环境变量可以将 Python 环境目录放置到其他位置。
 
   - ``idf_version.txt`` — 位于 ``python_env`` 目录下每个特定 Python 环境的子目录中，记录了该 Python 环境所对应的 ESP-IDF 版本。版本信息的存储格式如 ``5.3`` ，表示 ESP-IDF 版本 ``v5.3``。
+
+- ``root_managed_components`` — 由 ``idf-component-manager`` 管理的目录，用于存放全局安装的组件。
 - ``espidf.constraints.*.txt`` — 每个 ESP-IDF 版本都有的约束文件，包含 Python 包版本要求。
 
 GitHub 资源镜像
@@ -58,7 +60,9 @@ GitHub 资源镜像
 
 只要 URL 与 ``github.com`` 的下载 URL 格式匹配，任何镜像服务器均可使用，安装过程中下载的 GitHub 资源 URL 将把 ``https://github.com`` 替换为 ``https://${IDF_GITHUB_ASSETS}``。
 
-.. note:: 目前，乐鑫下载服务器不会镜像 GitHub 上的所有内容，只镜像部分发布版本的附件资源文件及源文件。
+.. note::
+
+    目前，乐鑫下载服务器不会镜像 GitHub 上的所有内容，只镜像部分发布版本的附件资源文件及源文件。
 
 .. _idf-tools-py:
 

docs/zh_CN/api-reference/bluetooth/index.rst

@@ -90,12 +90,13 @@ ESP-IDF 默认的主机协议栈，支持经典蓝牙和低功耗蓝牙。
 ----
 
 示例与教程
-------------
+----------
 
 ESP-IDF 提供了丰富的示例代码和实践教程，路径见 examples 目录：
 
 - **Bluedroid**: :example:`bluetooth/bluedroid`
 - **NimBLE**: :example:`bluetooth/nimble`
+- **BLE UART 服务** （基于 NimBLE 或 Bluedroid 的即用型蓝牙串口透传外设，提供 BLE UART Service GATT 布局）：:example:`bluetooth/ble_uart_service`
 
 使用 Bluedroid 协议栈进行开发的分步示例教程：
 

docs/zh_CN/api-reference/system/console.rst

@@ -189,9 +189,6 @@ Linenoise 库不需要显式地初始化，但是在调用行编辑函数之前
 
 之后你可以使用 :cpp:func:`esp_console_cmd_register` 来注册其它命令。REPL 环境在初始化后需要再调用 :cpp:func:`esp_console_start_repl` 函数才能开始运行。
 
-.. only:: SOC_USB_SERIAL_JTAG_SUPPORTED
-
-    同样，如果 REPL 环境是构建在 USB_SERIAL_JTAG 设备基础上，你只需要先调用 :cpp:func:`esp_console_new_repl_usb_serial_jtag` 函数进行初始化，然后再照常调用其它函数。
 
 应用示例
 ------------

docs/zh_CN/api-reference/system/efuse.rst

@@ -570,6 +570,13 @@ esptool 中包含一个用于读取/写入 {IDF_TARGET_NAME} eFuse 位的有用
 
 .. include:: inc/espefuse_summary_{IDF_TARGET_NAME}_dump.rst
 
+延迟烧写 WR_DIS
+---------------
+
+``WR_DIS`` （写禁用）是一个特殊的 eFuse 字段，用于实现永久写保护。``WR_DIS`` 中的每个位用于禁止进一步烧写一个（或多个）关联的 eFuse 字段。一旦完成烧写，将无法再修改受影响的 eFuse 字段。
+
+烧写 BLOCK0 中的暂存数据时，``WR_DIS`` 的各个位会在所有其他 BLOCK0 数据烧写完成后单独烧写，以确保在出现编码错误时，烧写函数能够通过重试机制进行恢复。这种方式保证了仅在其他 BLOCK0 数据成功烧写后，才对其施加写保护。
+
 应用示例
 -----------------
 

docs/zh_CN/api-reference/system/freertos_idf.rst

@@ -412,7 +412,7 @@ IDF FreeRTOS 中，特定核进入和退出临界区的过程如下：
     - 核寄存器的当前状态保存到要切出的任务栈中
     - 核寄存器的先前保存状态从要切入的任务栈中加载
 
-    然而，IDF FreeRTOS 为核的浮点运算单元 (FPU) 寄存器实现了延迟上下文切换。换句话说，当在特定核上（如核 0）发生上下文切换时，核的 FPU 寄存器状态不会立即保存到要被切出的任务的堆栈中（如任务 A）。FPU 的寄存器在发生以下情况前将保持不变：
+    然而，IDF FreeRTOS 为核的浮点运算单元 (FPU) 寄存器实现了惰性上下文切换。换句话说，当在特定核上（如核 0）发生上下文切换时，核的 FPU 寄存器状态不会立即保存到要被切出的任务的堆栈中（如任务 A）。FPU 的寄存器在发生以下情况前将保持不变：
 
     - 另一个任务（如任务 B）在同一核上运行并使用 FPU，这将触发异常，将 FPU 寄存器保存到任务 A 的堆栈中。
     - 任务 A 重新调度到同一核并继续执行。在这种情况下，不需要保存和恢复 FPU 的寄存器。
@@ -429,7 +429,42 @@ IDF FreeRTOS 中，特定核进入和退出临界区的过程如下：
 
     .. note::
 
-        具有 FPU 的 ESP 芯片不支持双精度浮点运算 ``double`` 的硬件加速。``double`` 通过软件实现，因此比起 ``float`` 类型，``double`` 操作可能消耗更多 CPU 时间。
+        包含 FPU 的乐鑫芯片不支持双精度浮点运算 ``double`` 的硬件加速。``double`` 通过软件实现，因此针对 ``float`` 类型的行为限制不适用于 ``double``。请注意，由于缺少硬件加速，``double`` 运算与 ``float`` 相比可能会消耗更多的 CPU 时间。
+
+
+.. only:: SOC_CPU_HAS_PIE
+
+    使用 PIE/AI 协处理器
+    ^^^^^^^^^^^^^^^^^^^^
+
+    与浮点运算单元 (FPU) 类似，IDF FreeRTOS 在 PIE 协处理器上也采用了 **惰性上下文切换** 策略。在上下文切换时，PIE 寄存器保持不变，直到某个任务执行 PIE 指令时才进行处理。一旦有任务使用了 PIE 协处理器，该任务将被 **固定到当前核心**。
+
+    .. only:: esp32s31
+
+        .. note::
+
+            在 ESP32-S31 上，PIE 协处理器 **仅在核心 1 上可用**。如果任务在核心 0 上运行时执行了 PIE 指令，IDF FreeRTOS 会将该任务迁移至核心 1 并将其固定。此迁移会 **覆盖** 任何现有的核心亲和性设置。
+
+            由于存在这种迁移机制，任务 **不得** 在临界区或 ISR 例程中使用 PIE 协处理器，否则将导致运行时中止。
+
+
+.. only:: SOC_CPU_HAS_HWLOOP
+
+    使用硬件循环 (HWLP)
+    ^^^^^^^^^^^^^^^^^^^
+
+    在 IDF FreeRTOS 中，硬件循环 (HWLP) 单元的处理方式与其他协处理器不同：它 **不** 使用惰性上下文切换。
+
+    当使用 HWLP 的任务发生上下文切换时，HWLP 寄存器会在中断入口路径中立即保存。之后，如果同一任务被切换回来，所有 HWLP 寄存器会立即恢复。
+
+    在实践中，这意味着任何曾经使用过 HWLP 的任务，在每次上下文切出和切入时都会产生额外的开销。
+
+.. only:: SOC_CPU_HAS_DSP
+
+    使用 DSP 协处理器
+    ^^^^^^^^^^^^^^^^^
+
+    在包含 DSP 协处理器的目标芯片上，上下文切换遵循与 FPU 相同的延迟方案：只有在同一核心上的另一个任务使用了该协处理器，或者该任务被切换到另一个核心时，协处理器的状态才会被保存。当任务使用 DSP 协处理器时，IDF FreeRTOS 会自动 **将该任务固定至其当前运行的核心**。DSP 协处理器不得在中断上下文中使用。
 
 
 .. -------------------------------------------------- Single Core  -----------------------------------------------------

docs/zh_CN/api-reference/system/mem_alloc.rst

@@ -39,6 +39,9 @@ ESP-IDF 应用程序使用常见的计算机架构模式：由程序控制流动
 
     如果占用了所有的 ``MALLOC_CAP_8BIT`` 堆空间，则可以用 ``MALLOC_CAP_IRAM_8BIT`` 代替。此时，若只以 32 位对齐的方式访问 IRAM 内存，或者启用了 ``CONFIG_ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY``，则仍然可以将 IRAM 用作内部内存的“储备池”。
 
+    .. note::
+
+        此选项仅在单核 ESP32 配置（``CONFIG_FREERTOS_UNICORE=y``）下可用。与普通内存相比，``CONFIG_ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY`` 选项有一个显著的缺点：对 ``MALLOC_CAP_IRAM_8BIT`` 内存的每次字节、半字或任意非对齐访问都会触发 ``LoadStore`` 或 ``Alignment`` 异常。虽然这些异常会通过软件处理以确保读写值的正确性，但每次访问都会产生约 167 个 CPU 周期的开销，如果频繁访问，可能导致严重的性能下降。因此，应避免在注重性能的代码段（如 ISR 例程或紧凑循环）中使用此类内存。建议重构代码，改用 32 位对齐（``uint32_t``）的访问方式。
 
 调用 ``malloc()`` 时，ESP-IDF ``malloc()`` 内部调用 ``heap_caps_malloc_default(size)``，使用属性 ``MALLOC_CAP_DEFAULT`` 分配内存。该属性可实现字节寻址功能，即存储空间的最小编址单位为字节。
 

docs/zh_CN/security/flash-encryption.rst

@@ -1278,7 +1278,7 @@ JTAG 调试
 
 
 技术细节
------------
+--------
 
 以下章节将提供 flash 加密操作的相关信息。