mirror of
https://github.com/espressif/esp-idf.git
synced 2026-10-02 03:00:34 +03:00
Merge branch 'docs/sync_cn_and_en' into 'master'
docs: Sync the CN transation and EN source Closes DOC-13807 See merge request espressif/esp-idf!45861
This commit is contained in:
@@ -193,7 +193,7 @@ The following options will reduce IRAM usage of some ESP-IDF features:
|
||||
:esp32c2: - Enable :ref:`CONFIG_BT_RELEASE_IRAM`. Release BT text section and merge BT data, bss & text into a large free heap region when ``esp_bt_mem_release`` is called. This makes Bluetooth unavailable until the next restart, but saving ~22 KB or more of IRAM.
|
||||
- Disable :ref:`CONFIG_LIBC_LOCKS_PLACE_IN_IRAM` if no ISRs that run while cache is disabled (i.e. IRAM ISRs) use libc lock APIs.
|
||||
:CONFIG_ESP_ROM_HAS_SUBOPTIMAL_NEWLIB_ON_MISALIGNED_MEMORY: - Disable :ref:`CONFIG_LIBC_OPTIMIZED_MISALIGNED_ACCESS` to save approximately 1000 bytes of IRAM, at the cost of reduced performance.
|
||||
:SOC_SPIRAM_SUPPORTED: - Enable :ref:`CONFIG_ESP_EVENT_LOOP_IN_EXT_RAM` to force esp_event to place event loop related allocations in external RAM instead of internal RAM.
|
||||
:SOC_SPIRAM_SUPPORTED: - Enable :ref:`CONFIG_ESP_EVENT_LOOP_IN_EXT_RAM` to force ``esp_event`` to place event loop related allocations in external RAM instead of internal RAM.
|
||||
|
||||
.. only:: esp32
|
||||
|
||||
|
||||
@@ -134,7 +134,6 @@ The ECDSA peripheral in Mbed TLS stack is integrated by overriding the ECDSA sig
|
||||
|
||||
For a particular TLS context, additional APIs have been supplied to populate certain fields (e.g., private key ctx) to differentiate routing to hardware. ESP-TLS layer integrates these APIs internally and hence no additional work is required at the application layer. However, for custom use-cases please refer to API details below.
|
||||
|
||||
|
||||
API Reference
|
||||
-------------
|
||||
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
====================
|
||||
I3C master interface
|
||||
====================
|
||||
|
||||
@@ -501,10 +502,12 @@ Thread Safety
|
||||
The following functions of the I3C driver are thread-safe and can be called from different RTOS tasks without additional lock protection:
|
||||
|
||||
Factory functions:
|
||||
|
||||
- :cpp:func:`i3c_new_master_bus`
|
||||
- :cpp:func:`i3c_del_master_bus`
|
||||
|
||||
I3C master operation functions (thread safety guaranteed through bus operation signals):
|
||||
|
||||
- :cpp:func:`i3c_master_bus_add_i3c_static_device`
|
||||
- :cpp:func:`i3c_master_bus_rm_i3c_device`
|
||||
- :cpp:func:`i3c_master_i3c_device_transmit`
|
||||
|
||||
@@ -216,7 +216,7 @@ The general procedure to create, start, stop, and delete a timer is as follows:
|
||||
3. Stop the timer
|
||||
|
||||
- To stop the running timer, call the function :cpp:func:`esp_timer_stop`. But it does not guarantee that after this call, the callback will not be running one or more times. To check if the callback is not running after stopping the timer, you can use :cpp:func:`esp_timer_is_active`. Another approach is to use a blocking stop API.
|
||||
- Blocking the timer stop operation until any in-flight callback completes can be done using :cpp:func:`esp_timer_stop_blocking`.
|
||||
- To block the timer stop operation until any in-flight callback completes, use :cpp:func:`esp_timer_stop_blocking`.
|
||||
|
||||
4. Delete the timer
|
||||
|
||||
|
||||
@@ -449,22 +449,20 @@ Dependency-driven build rules are defined in per-folder manifest files (``.build
|
||||
- esp_eth
|
||||
- esp_netif
|
||||
|
||||
|
||||
We also have a set of common components (defined as ``common_components`` in :idf_file:`.idf_build_apps.toml`). ``common_components`` is a list of baseline (core) components that are used by many apps. In general, if one of these components changes, you usually want to rebuild and retest the apps that depend on it.
|
||||
|
||||
The app maintainer should decide which components are important for their app. If the app should depend on a ``common_components``, add it to ``depends_components``. If not, specify only the important components.
|
||||
|
||||
If ``depends_components`` is not specified, we use the calculated components (``project_description.json``) and check whether the app is affected by the changed components.
|
||||
|
||||
Deprecated (prefer using ``depends_components`` / ``common_components`` instead):
|
||||
``deactivate_dependency_driven_build_by_components`` disables the dependency-driven checks if certain components change.
|
||||
Deprecated (prefer using ``depends_components`` and ``common_components`` instead): ``deactivate_dependency_driven_build_by_components`` disables the dependency-driven checks if certain components change.
|
||||
|
||||
Target Test Jobs
|
||||
----------------
|
||||
|
||||
In CI, all generated target test jobs are named according to the pattern "<targets> - <env_markers>". For example, single-dut test job ``esp32 - generic``, or multi-dut test job ``esp32,esp32 - multi_dut_generic``.
|
||||
|
||||
The binaries in the target test jobs are downloaded from our internal MinIO servers. For most of the test cases, only the files that are required by flash (like .bin files, flash_args files, etc) would be downloaded. For some test cases, like jtag test cases, .elf files are also downloaded.
|
||||
The binaries in the target test jobs are downloaded from our internal MinIO servers. For most of the test cases, only the files that are required by flash (like .bin files, flash_args files, etc) would be downloaded. For some test cases, like JTAG test cases, .elf files are also downloaded.
|
||||
|
||||
.. _run_the_tests_locally:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user