forked from espressif/esp-idf
Merge branch 'docs/update_pthread_cn' into 'master'
docs: Update the CN translation for pthread.rst/ota .rst Closes DOC-8536 and DOC-9081 See merge request espressif/esp-idf!32531
This commit is contained in:
morris
@@ -167,7 +167,7 @@ By applying the macro ``EXT_RAM_NOINIT_ATTR``, data could be moved from the inte
|
||||
|
||||
The benefits of XiP from PSRAM is:
|
||||
|
||||
- PSRAM access speed may be faster than Flash access, so the overall application performance may be better. For example, if the PSRAM is an Octal mode (8-line-PSRAM) and is configured to 80 MHz, then it is faster than a Quad flash (4-line-flash) which is configured to 80 MHz.
|
||||
- PSRAM access speed may be faster than flash access, so the overall application performance may be better. For example, if the PSRAM is an Octal mode (8-line PSRAM) and is configured to 80 MHz, then it is faster than a Quad flash (4-line flash) which is configured to 80 MHz.
|
||||
|
||||
- The cache will not be disabled during an SPI1 flash operation, thus optimizing the code execution performance during SPI1 flash operations. For ISRs, ISR callbacks and data which might be accessed during this period, you do not need to place them in internal RAM, thus internal RAM usage can be optimized. This feature is useful for high throughput peripheral involved applications to improve the performance during SPI1 flash operations.
|
||||
|
||||
@@ -186,11 +186,11 @@ By applying the macro ``EXT_RAM_NOINIT_ATTR``, data could be moved from the inte
|
||||
|
||||
.. only:: SOC_MMU_PER_EXT_MEM_TARGET
|
||||
|
||||
Because {IDF_TARGET_NAME} flash and PSRAM are using two separate SPI buses, moving flash content to PSRAM will actually increase the load of the PSRAM MSPI bus, so the exact impact on performance will be dependent on your app usage of PSRAM.
|
||||
Since the flash and PSRAM in {IDF_TARGET_NAME} use two separate SPI buses, moving flash content to PSRAM will actually increase the load on the PSRAM MSPI bus. Therefore, the exact impact on performance will be dependent on your app usage of PSRAM.
|
||||
|
||||
For example, as the PSRAM bus speed could be faster than flash bus speed (e.g., if the PSRAM is a HEX (16-line-PSRAM on ESP32P4) and is configured to 200 Mhz, then it is much faster than a Quad flash (4-line-flash) which is configured to 80 MHz.).
|
||||
The PSRAM bus can operate at a higher speed than the flash bus. For example, if the PSRAM is a HEX (16-line PSRAM on ESP32P4) running at 200 MHz, it is significantly faster than a Quad flash (4-line flash) running at 80 MHz.
|
||||
|
||||
If the instructions and data that are used to be in flash are not accessed very frequently, you should get better performance with this option enabled. We suggest doing performance profiling to determine how enabling this option will impact your system.
|
||||
If the instructions and data previously stored in flash are not accessed frequently, then enabling this option could improve performance. It is recommended to conduct performance profiling to evaluate how this option will affect your system.
|
||||
|
||||
Restrictions
|
||||
============
|
||||
|
||||
@@ -114,7 +114,7 @@ Then, in the component ``CMakeLists.txt``, add this name as an unresolved symbol
|
||||
|
||||
This will ensure the linker to always includes the file defining ``ld_include_my_isr_file``, so that the ISR is always linked.
|
||||
|
||||
- High-priority interrupts can be routed and handled using :cpp:func:`esp_intr_alloc` and associated functions. The handler and handler arguments to :cpp:func:`esp_intr_alloc` must be NULL, however.
|
||||
- High-priority interrupts can be routed and handled using :cpp:func:`esp_intr_alloc` and associated functions. However, the handler and handler arguments to :cpp:func:`esp_intr_alloc` must be NULL.
|
||||
|
||||
- In theory, medium priority interrupts could also be handled in this way. ESP-IDF does not support this yet.
|
||||
|
||||
|
||||
@@ -344,7 +344,7 @@ See Also
|
||||
Application Examples
|
||||
--------------------
|
||||
|
||||
- :example:`system/ota/native_ota_example` demonstrates how to use the `app_update` component's APIs for native Over-the-Air (OTA) updates on {IDF_TARGET_NAME}. For the applicable SoCs, please refer to :example_file:`system/ota/native_ota_example/README.md`.
|
||||
- :example:`system/ota/native_ota_example` demonstrates how to use the `app_update` component's APIs for native over-the-air (OTA) updates on {IDF_TARGET_NAME}. For applicable SoCs, please refer to :example_file:`system/ota/native_ota_example/README.md`.
|
||||
|
||||
- :example:`system/ota/otatool` demonstrates how to use the OTA tool to perform operations such as reading, writing, and erasing OTA partitions, switching boot partitions, and switching to factory partition. For more information, please refer to :example_file:`system/ota/otatool/README.md`.
|
||||
|
||||
|
||||
@@ -183,6 +183,7 @@ Message Queues
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
The message queue implementation is based on the `FreeRTOS-Plus-POSIX <https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_POSIX/index.html>`_ project. Message queues are not made available in any filesystem on ESP-IDF. Message priorities are not supported.
|
||||
|
||||
The following API functions of the POSIX message queue specification are implemented:
|
||||
|
||||
* `mq_open() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_open.html>`_
|
||||
@@ -191,7 +192,7 @@ The following API functions of the POSIX message queue specification are impleme
|
||||
- It has to begin with a leading slash.
|
||||
- It has to be no more than 255 + 2 characters long (including the leading slash, excluding the terminating null byte). However, memory for ``name`` is dynamically allocated internally, so the shorter it is, the fewer memory it will consume.
|
||||
- The ``mode`` argument is not implemented and is ignored.
|
||||
- Supported ``oflags``: ``O_RDWR``, ``O_CREAT``, ``O_EXCL``, and ``O_NONBLOCK``
|
||||
- Supported ``oflags``: ``O_RDWR``, ``O_CREAT``, ``O_EXCL``, and ``O_NONBLOCK``.
|
||||
|
||||
* `mq_close() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_close.html>`_
|
||||
* `mq_unlink() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_unlink.html>`_
|
||||
@@ -218,7 +219,7 @@ The following API functions of the POSIX message queue specification are impleme
|
||||
Building
|
||||
........
|
||||
|
||||
To use the POSIX message queue API, please add ``rt`` as a requirement in your component's ``CMakeLists.txt``
|
||||
To use the POSIX message queue API, please add ``rt`` as a requirement in your component's ``CMakeLists.txt``.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
@@ -193,12 +193,3 @@ ESP-IDF 支持 ``iostream`` 功能，但应注意：
|
||||
-------------
|
||||
|
||||
请勿在 C++ 中使用 ``setjmp``/``longjmp``。``longjmp`` 会在不调用任何析构函数的情况下盲目跳出堆栈，容易引起未定义的行为和内存泄漏。请改用 C++ 异常处理，这类程序可以确保正确调用析构函数。如果无法使用 C++ 异常处理，请使用其他替代方案（ ``setjmp``/``longjmp`` 除外），如简单的返回码。
|
||||
|
||||
应用示例
|
||||
--------------------
|
||||
|
||||
- :example:`cxx/pthread`
|
||||
|
||||
- :example:`cxx/exceptions` 演示了如何在 {IDF_TARGET_NAME} 中启用和使用 C++ 异常。该示例声明了一个类，当提供的参数等于 0 时，这个类会在构造函数中抛出异常。
|
||||
|
||||
- :example:`cxx/rtti`
|
||||
|
||||
@@ -167,7 +167,7 @@ ESP-IDF 启动过程中，片外 RAM 被映射到数据虚拟地址空间，该
|
||||
|
||||
在 PSRAM 中直接执行代码的好处包括：
|
||||
|
||||
- PSRAM 访问速度可能快于 flash，因此性能更好。例如，如果使用的 PSRAM 是八线的，且被配置为 80 MHz，而 flash 是4线的，且被配置为 80 Mhz，那么 PSRAM 的访问速度是快于 flash 的。
|
||||
- PSRAM 的访问速度可能快于 flash，因此性能更好。例如，如果使用的 PSRAM 是八线的，且被配置为 80 MHz，而 flash 是四线的，且被配置为 80 Mhz，那么 PSRAM 的访问速度将快于 flash。
|
||||
|
||||
- 在进行 SPI1 flash 操作期间，cache 仍然保持启用状态，这样可以优化代码执行性能。由于无需把中断服务程序 (ISR)、ISR 回调和在此期间可能被访问的数据放置在片上 RAM 中，片上 RAM 可用于其他用途，从而提高了使用效率。这个特性适用于需要处理大量数据的高吞吐量外设应用，能显著提高 SPI1 flash 操作期间的性能。
|
||||
|
||||
@@ -188,7 +188,9 @@ ESP-IDF 启动过程中，片外 RAM 被映射到数据虚拟地址空间，该
|
||||
|
||||
由于 {IDF_TARGET_NAME} flash 和 PSRAM 使用两个独立的 SPI 总线，将 flash 内容移动到 PSRAM 实际上增加了 PSRAM MSPI 总线的负载，
|
||||
|
||||
例如，PSRAM 的访问速度可能快于 flash (比如在 ESP32-P4 上，选择的 PSRAM 是十六线的并将其配置为 200 MHz， 此时 PSRAM 的访问速度是远快于一颗被配置为 80 MHz 的四线 flash 芯片)，如果这些之前在 flash 中被就地执行的指令和数据不是十分频繁地被访问，则使能这个选项会增加系统的性能。建议先进行性能分析以确定启用此选项是否会显著影响应用程序性能。
|
||||
PSRAM 的访问速度可能快于 flash。比如在 ESP32-P4 上，选择十六线 PSRAM 并将其配置为 200 MHz，此时 PSRAM 的访问速度远快于被配置为 80 MHz 的四线 flash 芯片。
|
||||
|
||||
如果这些之前在 flash 中被就地执行的指令和数据不会被频繁访问，则使能该选项可能会提高系统的性能。建议先进行性能分析，评估启用此选项是否会显著影响应用程序的性能。
|
||||
|
||||
片外 RAM 使用限制
|
||||
===================
|
||||
|
||||
@@ -119,3 +119,5 @@ Xtensa 架构支持 32 个中断处理程序，这些中断分为从 1 到 7 的
|
||||
- 中等优先级的中断理论上也可以通过上述方式处理，但 ESP-IDF 尚不支持此功能。
|
||||
|
||||
- 要检查 Xtensa 指令集架构 (ISA)，请参阅 `Xtensa ISA 摘要 <https://www.cadence.com/content/dam/cadence-www/global/en_US/documents/tools/ip/tensilica-ip/isa-summary.pdf>`_。
|
||||
|
||||
:example:`system/nmi_isr` 提供了一个示例，可以在基于 Xtensa 架构的目标平台上实现自定义 NMI 处理程序。
|
||||
|
||||
@@ -14,14 +14,13 @@ Wi-Fi 场景下低功耗模式介绍
|
||||
|
||||
在介绍具体内容前先给出 Wi-Fi 场景下低功耗模式总结表，以方便用户根据需求快速选择想要了解的内容，选择合适的低功耗模式。
|
||||
|
||||
|
||||
.. include:: ../sleep-current/{IDF_TARGET_PATH_NAME}_summary.inc
|
||||
|
||||
.. note::
|
||||
|
||||
上表中所有电流均为平均电流，所测数据均在屏蔽箱中测试得出。表中术语在下文均有介绍，用户可根据需求进行查看。
|
||||
|
||||
.. _Wi-Fi 省电的基本原理:
|
||||
.. _Basic Principles of Wi-Fi Power Saving:
|
||||
|
||||
Wi-Fi 省电的基本原理
|
||||
---------------------
|
||||
@@ -90,9 +89,9 @@ Wi-Fi 省电的基本原理
|
||||
|
||||
可以看出影响功耗表现的主要有三点：interval、period 和 base current。
|
||||
|
||||
- **interval** 是 station Wi-Fi 相关模块工作的间隔，既可以由低功耗模式自定义，也可根据 Wi-Fi 协议省电机制（详细内容请见 :ref:`Wi-Fi 省电的基本原理`），由 DTIM 周期决定。可以看出在同等情下，interval 越大，功耗表现会更好，但是响应会更慢，影响通信的及时性。
|
||||
- **interval** 是 station Wi-Fi 相关模块工作的间隔，既可以由低功耗模式自定义，也可根据 Wi-Fi 协议省电机制（详细内容请见 :ref:`Basic Principles of Wi-Fi Power Saving`），由 DTIM 周期决定。可以看出在同等情下，interval 越大，功耗表现会更好，但是响应会更慢，影响通信的及时性。
|
||||
|
||||
- **period** 可以看作每次 station Wi-Fi 工作的时间，这段时间的长度也会影响功耗的表现。period 不是一个固定的时长（详细内容请见 :ref:`Wi-Fi 省电的基本原理`），在保证 Wi-Fi 通信正常的情况下，period 持续时间越短，功耗表现越好。但是减少 period 时间，必然会影响通信的可靠性。
|
||||
- **period** 可以看作每次 station Wi-Fi 工作的时间，这段时间的长度也会影响功耗的表现。period 不是一个固定的时长（详细内容请见 :ref:`Basic Principles of Wi-Fi Power Saving`），在保证 Wi-Fi 通信正常的情况下，period 持续时间越短，功耗表现越好。但是减少 period 时间，必然会影响通信的可靠性。
|
||||
|
||||
- **base current** 是 Wi-Fi 相关模块不工作时芯片的电流，影响其大小的因素很多，不同的功耗模式下休眠策略不同。所以，在满足功能的情况下，优化配置降低该电流大小可以提高功耗表现，但同时关闭其余模块会影响相关功能和芯片的唤醒时间。
|
||||
|
||||
@@ -106,7 +105,7 @@ Modem-sleep 模式主要工作原理基于 DTIM 机制，周期性的醒来处
|
||||
|
||||
Modem-sleep 模式会在 Wi-Fi 任务结束后自动进入休眠无需调用 API，休眠时仅会关闭 Wi-Fi 相关模块 (PHY)，其余模块均处在正常上电状态。
|
||||
|
||||
Modem-sleep 模式默认会根据 DTIM 周期或 listen interval（于 :ref:`Modem-sleep 模式配置` 中介绍）醒来，相当于系统自动设置了一个 Wi-Fi 唤醒源，因此用户无需再配置唤醒源，同时系统主动发包时也可以唤醒。
|
||||
Modem-sleep 模式默认会根据 DTIM 周期或 listen interval（于 :ref:`Modem-sleep Mode Configuration` 中介绍）醒来，相当于系统自动设置了一个 Wi-Fi 唤醒源，因此用户无需再配置唤醒源，同时系统主动发包时也可以唤醒。
|
||||
|
||||
Modem-sleep 模式是一个开关型的模式，调用 API 开启后一直自动运行，其工作流程十分简单，具体如下图。
|
||||
|
||||
@@ -121,7 +120,7 @@ Modem-sleep 模式是一个开关型的模式，调用 API 开启后一直自动
|
||||
|
||||
Modem-sleep 模式工作流程图
|
||||
|
||||
根据上文的基本电流图，结合 Modem-sleep 模式的工作原理，以 Min Modem 模式（于 :ref:`Modem-sleep 模式配置` 中介绍）为例可得理想情况下电流变化图。
|
||||
根据上文的基本电流图，结合 Modem-sleep 模式的工作原理，以 Min Modem 模式（于 :ref:`Modem-sleep Mode Configuration` 中介绍）为例可得理想情况下电流变化图。
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
@@ -294,7 +293,7 @@ Deep-sleep 模式在 Wi-Fi 场景下与纯系统下基本相同，详情可以
|
||||
- 丢失 beacon 时睡眠优化 (:ref:`CONFIG_ESP_WIFI_SLP_BEACON_LOST_OPT`)
|
||||
|
||||
|
||||
.. _Modem-sleep 模式配置:
|
||||
.. _Modem-sleep Mode Configuration:
|
||||
|
||||
Modem-sleep 模式配置
|
||||
+++++++++++++++++++++++
|
||||
|
||||
@@ -16,7 +16,7 @@ ESP x509 证书包 API 提供了一种简便的方法，帮助你安装自定义
|
||||
|
||||
生成证书包时，你需选择：
|
||||
|
||||
* 来自 Mozilla 的完整根证书包，包含超过 130 份证书。目前提供的证书包更新于 2024 年 3 月 11 日，星期一，15:25:27 (GMT)。
|
||||
* 来自 Mozilla 的完整根证书包，包含超过 130 份证书。目前提供的证书包更新于 2024 年 9 月 24 日，星期二，03:12:04 (GMT)。
|
||||
* 一组预先筛选的常用根证书。其中仅包含约 41 份证书，但根据 SSL 证书颁发机构统计数据，其绝对使用率约达到 90%，市场覆盖率约达 99%。
|
||||
|
||||
此外，还可指定证书文件的路径或包含证书的目录，将其他证书添加到生成的证书包中。
|
||||
|
||||
@@ -141,6 +141,7 @@ FatFs 分区生成器
|
||||
|
||||
相关示例请查看 :example:`storage/fatfsgen`。
|
||||
|
||||
|
||||
.. _fatfs-partition-analyzer:
|
||||
|
||||
FatFs 分区分析器
|
||||
|
||||
@@ -344,7 +344,9 @@ Python API
|
||||
应用示例
|
||||
------------
|
||||
|
||||
- :example:`system/ota/otatool` 演示了如何使用 OTA 工具执行读取、写入和擦除 OTA 分区、切换启动分区以及切换到出厂分区等操作。有关更多信息，请参考 :example_file:`system/ota/otatool/README.md`。
|
||||
- :example:`system/ota/native_ota_example` 演示了如何在 {IDF_TARGET_NAME} 上使用 `app_update` 组件的 API 进行原生空中升级 (OTA)。适用的 SoC 请参阅 :example_file:`system/ota/native_ota_example/README.md`。
|
||||
|
||||
- :example:`system/ota/otatool` 演示了如何使用 OTA 工具执行读取、写入和擦除 OTA 分区、切换启动分区以及切换到工厂分区等操作。详情请参阅 :example_file:`system/ota/otatool/README.md`。
|
||||
|
||||
API 参考
|
||||
--------
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
POSIX Thread
|
||||
============
|
||||
POSIX 支持（包括 POSIX 线程支持）
|
||||
=================================
|
||||
|
||||
:link_to_translation:`en:[English]`
|
||||
|
||||
@@ -12,7 +12,11 @@ ESP-IDF 基于 FreeRTOS，但提供了一系列与 POSIX 兼容的 API，以便
|
||||
|
||||
添加标准 ``pthread.h`` 头文件后可以在 ESP-IDF 中使用 pthread，该头文件已包含在工具链 libc 中。还有另一个专用于 ESP-IDF 的头文件 ``esp_pthread.h``，其中提供了一些额外的非 POSIX API，以便通过 pthread 使用一些 ESP-IDF 功能。
|
||||
|
||||
C++ 标准库中的 ``std::thread``、``std::mutex``、``std::condition_variable`` 等功能也是通过 pthread（利用 GCC libstdc++）实现的。因此，本文档提到的限制条件也同样适用于 C++ 标准库中等效功能。
|
||||
除了 POSIX 线程，ESP-IDF 还支持 :ref:`POSIX 消息队列 <posix_message_queues>`。
|
||||
|
||||
C++ 标准库中的 ``std::thread``、``std::mutex``、``std::condition_variable`` 等功能也是通过 pthread 和其他 POSIX API（利用 GCC libstdc++）实现的。因此，本文档提到的限制条件也同样适用于 C++ 标准库中的等效功能。
|
||||
|
||||
如果希望 ESP-IDF 支持某个尚未实现的 API，请 `在 GitHub 上发起功能请求 <https://github.com/espressif/esp-idf/issues>`_ 并提供详细信息。
|
||||
|
||||
RTOS 集成
|
||||
----------------
|
||||
@@ -23,6 +27,10 @@ RTOS 集成
|
||||
|
||||
如果调用 C 标准库或 C++ sleep 函数，例如在 ``unistd.h`` 中定义的 ``usleep``，那么只有当睡眠时间超过 :ref:`一个 FreeRTOS 滴答周期 <CONFIG_FREERTOS_HZ>` 时，任务才会阻塞并让出内核。如果时间较短，线程将处于忙等待状态，不会让步给另一个 RTOS 任务。
|
||||
|
||||
.. note::
|
||||
|
||||
POSIX 的 ``errno`` 由 ESP-IDF 中的 newlib 提供。因此，配置项 ``configUSE_POSIX_ERRNO`` 并未被使用，应该保持禁用状态。
|
||||
|
||||
默认情况下，所有 pthread 具有相同的 RTOS 优先级，但可以通过调用 :ref:`ESP-IDF 提供的扩展 API <esp-pthread>` 对此优先级进行更改。
|
||||
|
||||
标准功能
|
||||
@@ -169,15 +177,65 @@ ESP-IDF 中实现了 POSIX 读写锁规范的以下 API 函数：
|
||||
|
||||
ESP-IDF 中还有其他的线程本地存储选项，包括性能更高的选项。参见 :doc:`/api-guides/thread-local-storage`。
|
||||
|
||||
.. _posix_message_queues:
|
||||
|
||||
消息队列
|
||||
^^^^^^^^
|
||||
|
||||
消息队列的实现基于 `FreeRTOS-Plus-POSIX <https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_POSIX/index.html>`_ 项目，ESP-IDF 的文件系统不提供消息队列，不支持消息优先级。
|
||||
|
||||
以下 POSIX 消息队列规范中的 API 函数已被实现：
|
||||
|
||||
* `mq_open() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_open.html>`_
|
||||
|
||||
- 除了要符合 POSIX 规范，``name`` 参数还有以下额外限制：
|
||||
- 必须以斜杠开头。
|
||||
- 长度不得超过 255 + 2 个字符（包括开头的斜杠，除去终止的空字符）。但 ``name`` 的内存是在内部动态分配的，所以名称越短，消耗的内存越少。
|
||||
- ``mode`` 参数未实现且被忽略。
|
||||
- 支持的 ``oflags``：``O_RDWR``、``O_CREAT``、``O_EXCL`` 和 ``O_NONBLOCK``。
|
||||
|
||||
* `mq_close() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_close.html>`_
|
||||
* `mq_unlink() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_unlink.html>`_
|
||||
* `mq_receive() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_receive.html>`_
|
||||
|
||||
- 不支持消息优先级，因此 ``msg_prio`` 未被使用。
|
||||
|
||||
* `mq_timedreceive() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_receive.html>`_
|
||||
|
||||
- 不支持消息优先级，因此 ``msg_prio`` 未被使用。
|
||||
|
||||
* `mq_send() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_send.html>`_
|
||||
|
||||
- 不支持消息优先级，因此 ``msg_prio`` 无效。
|
||||
|
||||
* `mq_timedsend() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_send.html>`_
|
||||
|
||||
- 不支持消息优先级，因此 ``msg_prio`` 无效。
|
||||
|
||||
* `mq_getattr() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_getattr.html>`_
|
||||
|
||||
尚未实现 `mq_notify() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_notify.html>`_ 和 `mq_setattr() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_setattr.html>`_。
|
||||
|
||||
构建
|
||||
....
|
||||
|
||||
要使用 POSIX 消息队列 API，请在组件的 ``CMakeLists.txt`` 文件中添加 ``rt`` 作为依赖项。
|
||||
|
||||
.. note::
|
||||
|
||||
请注意，如果曾在其他 FreeRTOS 项目中使用过 `FreeRTOS-Plus-POSIX <https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_POSIX/index.html>`_，则 IDF 中的包含路径是 POSIX 风格的。因此，应用程序应直接包含 ``mqueue.h``，而不是使用子目录来包含 ``FreeRTOS_POSIX/mqueue.h``。
|
||||
|
||||
未实现 API
|
||||
---------------
|
||||
|
||||
``pthread.h`` 头文件是一个标准头文件，包含了在 ESP-IDF 中未实现的额外 API 和功能，包括：
|
||||
|
||||
* 如果调用 ``pthread_cancel()``，返回 ``ENOSYS``。
|
||||
* ``pthread_condattr_init()`` 如果被调用，返回 ``ENOSYS``。
|
||||
* 若调用 ``pthread_cancel()``，则返回 ``ENOSYS``。
|
||||
* 若调用 ``pthread_condattr_init()``，则返回 ``ENOSYS``。
|
||||
* 若调用 `mq_notify() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_notify.html>`_，则返回 ``ENOSYS``。
|
||||
* 若调用 `mq_setattr() <https://pubs.opengroup.org/onlinepubs/9699919799/functions/mq_setattr.html>`_，则返回 ``ENOSYS``。
|
||||
|
||||
其他未列出的 pthread 函数未在 ESP-IDF 中实现，如果从 ESP-IDF 应用程序中直接引用，将产生编译器错误或链接器错误。如果希望 ESP-IDF 支持某个尚未实现的 API，请 `在 GitHub 上发起功能请求 <https://github.com/espressif/esp-idf/issues>`_ 并提供详细信息。
|
||||
其他未列出的 pthread 函数未在 ESP-IDF 中实现，如果从 ESP-IDF 应用程序中直接引用，将产生编译器错误或链接器错误。
|
||||
|
||||
.. _esp-pthread:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user