mirror of
https://github.com/espressif/esp-idf.git
synced 2026-10-03 03:31:41 +03:00
docs: Sync CN and EN docs without translation label
This commit is contained in:
@@ -345,16 +345,9 @@ To satisfy the high quality audio requirement, following advanced APIs are provi
|
||||
The typical usage steps are:
|
||||
|
||||
1. Create and initialize an I2S TX channel.
|
||||
2. Call :cpp:func:`i2s_channel_config_tx_fifo_sync` to configure :cpp:type:`i2s_tx_fifo_sync_config_t`. ``ideal_cnt``
|
||||
is the expected number of transmitted data units at each ETM synchronization check. This step can be performed while the TX channel is running, but TX FIFO synchronization must be disabled before reconfiguration. ``auto_suppl_thresh`` is
|
||||
the automatic hardware supplement threshold and must be smaller than ``manual_suppl_thresh``.
|
||||
``manual_suppl_thresh`` is the threshold for triggering the callback for manual handling. If the difference
|
||||
exceeds the automatic supplement threshold but has not reached the manual supplement threshold, hardware
|
||||
automatically supplements or deletes the corresponding amount of data to synchronize with ``ideal_cnt``.
|
||||
2. Call :cpp:func:`i2s_channel_config_tx_fifo_sync` to configure :cpp:type:`i2s_tx_fifo_sync_config_t`. ``ideal_cnt`` is the expected number of transmitted data units at each ETM synchronization check. This step can be performed while the TX channel is running, but TX FIFO synchronization must be disabled before reconfiguration. ``auto_suppl_thresh`` is the automatic hardware supplement threshold and must be smaller than ``manual_suppl_thresh``. ``manual_suppl_thresh`` is the threshold for triggering the callback for manual handling. If the difference exceeds the automatic supplement threshold but has not reached the manual supplement threshold, hardware automatically supplements or deletes the corresponding amount of data to synchronize with ``ideal_cnt``.
|
||||
3. To handle severe out-of-sync conditions, call :cpp:func:`i2s_channel_register_event_callback` to register a callback.
|
||||
4. Call :cpp:func:`i2s_channel_enable_tx_fifo_sync` with ``enable`` set to ``true`` to activate both automatic
|
||||
hardware supplementation and manual interrupt simultaneously. This call resets the TX FIFO/BCLK synchronization
|
||||
counters, so the first ETM synchronization check uses a new count window.
|
||||
4. Call :cpp:func:`i2s_channel_enable_tx_fifo_sync` with ``enable`` set to ``true`` to activate both automatic hardware supplementation and manual interrupt simultaneously. This call resets the TX FIFO/BCLK synchronization counters, so the first ETM synchronization check uses a new count window.
|
||||
5. Call :cpp:func:`i2s_new_etm_task` to create the ``I2S_ETM_TASK_SYNC_FIFO`` task, and connect an external ETM event to this task.
|
||||
6. Enable the ETM channel and I2S TX channel, so that ETM events periodically trigger synchronization checks.
|
||||
|
||||
|
||||
@@ -66,7 +66,6 @@ Overview
|
||||
|
||||
Pins used by Slot 0 (``HS1_*``) are also used to connect the SPI flash chip in ESP32-WROOM and ESP32-WROVER modules. These pins cannot be concurrently shared between an SD card and an SPI flash. If you need to use Slot 0, establish an alternative connection for the SPI flash using different pins and configure the necessary eFuses accordingly.
|
||||
|
||||
|
||||
.. only:: esp32s3
|
||||
|
||||
Both slots :c:macro:`SDMMC_HOST_SLOT_0` and :c:macro:`SDMMC_HOST_SLOT_1` support 1-, 4- and 8-line SD interfaces. The slots are connected to {IDF_TARGET_NAME} GPIOs using the GPIO matrix. This means that any GPIO may be used for each of the SD card signals.
|
||||
@@ -215,7 +214,5 @@ API Reference
|
||||
-------------
|
||||
|
||||
.. include-build-file:: inc/sdmmc_host.inc
|
||||
|
||||
.. include-build-file:: inc/sd_pwr_ctrl.inc
|
||||
|
||||
.. include-build-file:: inc/sd_pwr_ctrl_by_on_chip_ldo.inc
|
||||
|
||||
@@ -86,6 +86,7 @@ See :ref:`iram-safe-interrupt-handlers` for information on how to prevent an int
|
||||
|
||||
When the cache is disabled, all CPUs should execute code and access data only from internal RAM. For differences between internal RAM (e.g., IRAM, DRAM) and flash cache, please refer to the :ref:`application memory layout <memory-layout>` documentation.
|
||||
|
||||
|
||||
.. _iram-safe-interrupt-handlers:
|
||||
|
||||
IRAM-Safe Interrupt Handlers
|
||||
|
||||
@@ -12,7 +12,7 @@ For the full list of error codes defined in ESP-IDF, see :doc:`Error Codes Refer
|
||||
.. _registering-error-codes:
|
||||
|
||||
Registering Error Codes
|
||||
------------------------
|
||||
-----------------------
|
||||
|
||||
ESP-IDF uses a composable error code registration system that automatically collects error code definitions from all components at build time. This allows :cpp:func:`esp_err_to_name` and :cpp:func:`esp_err_to_name_r` to look up error codes defined across the entire project without requiring manual maintenance of a central registry.
|
||||
|
||||
@@ -77,7 +77,7 @@ After building your project, calls to ``esp_err_to_name(ESP_ERR_MY_COMPONENT_INI
|
||||
|
||||
.. note::
|
||||
|
||||
Most ESP-IDF components already have their error codes registered. You only need to add ``idf_define_esp_err_codes()`` for your own custom components or when adding new error codes to existing components.
|
||||
Most ESP-IDF components already have their error codes registered. You only need to add ``idf_define_esp_err_codes()`` for your own custom components or for new error codes added to existing components.
|
||||
|
||||
.. _esp-check-api-ref:
|
||||
|
||||
|
||||
@@ -63,6 +63,7 @@ Dynamic frequency scaling (DFS) and automatic Light-sleep can be enabled in an a
|
||||
|
||||
Power Management Locks
|
||||
----------------------
|
||||
|
||||
{IDF_TARGET_MAX_CPU_FREQ: default="Not updated yet", esp32="80 MHz, 160 MHz, or 240 MHz", esp32s2="80 MHz, 160 MHz, or 240 MHz", esp32s3="80 MHz, 160 MHz, or 240 MHz", esp32c2="80 MHz or 120 MHz", esp32c3="80 MHz or 160 MHz", esp32c6="80 MHz or 160 MHz", esp32p4="360 MHz", esp32c5="80 MHz, 160 MHz or 240 MHz", esp32c61="80 MHz or 160 MHz"}
|
||||
|
||||
Applications have the ability to acquire/release locks in order to control the power management algorithm. When an application acquires a lock, the power management algorithm operation is restricted in a way described below. When the lock is released, such restrictions are removed.
|
||||
|
||||
Reference in New Issue
Block a user