alex/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2025-08-15 22:44:19 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: update for esp32c6

Browse Source
This commit is contained in:
liuning
2023-05-23 20:20:54 +08:00
committed by xuxiao
parent 5a9cff0d34
commit 6cd76ba321
5 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/en/api-guides/coexist.rst
View File

@@ -10,7 +10,7 @@ Overview
Supported Coexistence Scenario for {IDF_TARGET_NAME}
---------------------------------------------------------------------
.. only:: esp32c3 or esp32s3 or esp32
.. only:: esp32c3 or esp32s3 or esp32 or esp32c6
.. table:: Supported Features of Wi-Fi and BLE Coexistence
@@ -122,7 +122,7 @@ Coexistence Period and Time Slice
Wi-Fi, BT, and BLE have their fixed time slice to use the RF. A coexistence period is divided into 3 time slices in the order of Wi-Fi, BT, and BLE. In the Wi-Fi slice, Wi-Fi's request to the coexistence arbitration module will have higher priority. Similarly, BT/BLE can enjoy higher priority at their own time slices. The duration of the coexistence period and the proportion of each time slice are divided into four categories according to the Wi-Fi status:
.. only:: esp32c3 or esp32s3
.. only:: esp32c3 or esp32s3 or esp32c6
Wi-Fi and BLE have their fixed time slice to use the RF. In the Wi-Fi time slice, Wi-Fi will send a higher priority request to the coexistence arbitration module. Similarly, BLE can enjoy higher priority at their own time slice. The duration of the coexistence period and the proportion of each time slice are divided into four categories according to the Wi-Fi status:
@@ -130,7 +130,7 @@ Coexistence Period and Time Slice
.. list::
:esp32: 1) IDLE status: the coexistence of BT and BLE is controlled by Bluetooth module.
:esp32c3 or esp32s3: 1) IDLE status: RF module is controlled by Bluetooth module.
:esp32c3 or esp32s3 or esp32c6: 1) IDLE status: RF module is controlled by Bluetooth module.
#) CONNECTED status: the coexistence period starts at the Target Beacon Transmission Time (TBTT) and is more than 100 ms.
#) SCAN status: Wi-Fi slice and coexistence period are longer than in the CONNECTED status. To ensure Bluetooth performance, the Bluetooth time slice will also be adjusted accordingly.
#) CONNECTING status: Wi-Fi slice is longer than in the CONNECTED status. To ensure Bluetooth performance, the Bluetooth time slice will also be adjusted accordingly.

6
docs/en/api-guides/wifi.rst
View File

@@ -1450,7 +1450,7 @@ Currently, the ESP-IDF supports the following protocol modes:
LR Compatibility
*************************
Since LR is Espressif-unique Wi-Fi mode, only ESP32 series chips devices (except esp32c2) can transmit and receive the LR data. In other words, the ESP32 series chips devices (except esp32c2) should NOT transmit the data in LR data rate if the connected device does not support LR. The application can achieve this by configuring suitable Wi-Fi mode. If the negotiated mode supports LR, the ESP32 series chips devices (except esp32c2) may transmit data in LR rate. Otherwise, ESP32 series chips devices (except esp32c2) will transmit all data in traditional Wi-Fi data rate.
Since LR is Espressif-unique Wi-Fi mode, only ESP32 chip series devices (except ESP32-C2) can transmit and receive the LR data. In other words, the ESP32 chip series devices (except ESP32-C2) should NOT transmit the data in LR data rate if the connected device does not support LR. The application can achieve this by configuring a suitable Wi-Fi mode. If the negotiated mode supports LR, the ESP32 chip series devices (except ESP32-C2) may transmit data in LR rate. Otherwise, ESP32 chip series devices (except ESP32-C2) will transmit all data in the traditional Wi-Fi data rate.
The following table depicts the Wi-Fi mode negotiation:
@@ -1504,7 +1504,7 @@ Currently, the ESP-IDF supports the following protocol modes:
- For LR-enabled AP of {IDF_TARGET_NAME}, it is incompatible with traditional 802.11 mode, because the beacon is sent in LR mode.
- For LR-enabled station of {IDF_TARGET_NAME} whose mode is NOT LR-only mode, it is compatible with traditional 802.11 mode.
- If both station and AP are ESP32 series chips devices (except esp32c2) and both of them have enabled LR mode, the negotiated mode supports LR.
- If both station and AP are ESP32 series chips devices (except ESP32-C2) and both of them have enabled LR mode, the negotiated mode supports LR.
If the negotiated Wi-Fi mode supports both traditional 802.11 mode and LR mode, it is the Wi-Fi driver's responsibility to automatically select the best data rate in different Wi-Fi modes and the application can ignore it.
@@ -1710,7 +1710,7 @@ Refer ESP-IDF example :idf_file:`examples/wifi/roaming/README.md` to set up and
- {IDF_TARGET_NAME} as FTM Initiator in station mode.
- {IDF_TARGET_NAME} as FTM Responder in AP mode.
Distance measurement using RTT is not accurate, and factors such as RF interference, multi-path travel, antenna orientation, and lack of calibration increase these inaccuracies. For better results, it is suggested to perform FTM between two ESP32 series chips devices (except esp32c2) as station and AP.
Distance measurement using RTT is not accurate, and factors such as RF interference, multi-path travel, antenna orientation, and lack of calibration increase these inaccuracies. For better results, it is suggested to perform FTM between two ESP32 chip series devices (except ESP32-C2) as station and AP.
Refer to ESP-IDF example :idf_file:`examples/wifi/ftm/README.md` for steps on how to set up and perform FTM.