docs: update format issues for EN and CN files under api-reference/bluetooth folder

This commit is contained in:
caixinying-git 2023-07-12 16:48:16 +08:00
parent a416c12e9d
commit db241482a6
28 changed files with 80 additions and 81 deletions

View File

@ -1,9 +1,9 @@
BT COMMON
=========
Bluetooth® Common
=================
.. toctree::
:caption: Bluetooth Common Defines and APIs
Bluetooth DEFINE <esp_bt_defs>
Bluetooth MAIN <esp_bt_main>
Bluetooth DEVICE <esp_bt_device>
Bluetooth Define <esp_bt_defs>
Bluetooth Main <esp_bt_main>
Bluetooth Device <esp_bt_device>

View File

@ -1,11 +1,11 @@
BT LE
=========
Bluetooth® Low Energy (Bluetooth LE)
====================================
.. toctree::
:caption: Bluetooth LE
:caption: Bluetooth Low Energy
BLE GAP <esp_gap_ble>
BLE GATT DEFINE <esp_gatt_defs>
BLE GATT SERVER <esp_gatts>
BLE GATT CLIENT <esp_gattc>
:SOC_BLUFI_SUPPORTED: BLE BLUFI <esp_blufi>
Bluetooth Low Energy GAP <esp_gap_ble>
Bluetooth Low Energy GATT Define <esp_gatt_defs>
Bluetooth Low Energy GATT Server <esp_gatts>
Bluetooth Low Energy GATT Client <esp_gattc>
:SOC_BLUFI_SUPPORTED: Bluetooth Low Energy BluFi <esp_blufi>

View File

@ -1,17 +1,17 @@
CLASSIC BT
==========
Classic Bluetooth®
==================
.. toctree::
:caption: Classic BT
:caption: Classic Bluetooth
BT GAP <esp_gap_bt>
BT A2DP <esp_a2dp>
BT AVRC <esp_avrc>
BT SPP <esp_spp>
BT HFP Define <esp_hf_defs>
BT HFP Client <esp_hf_client>
BT HFP AG <esp_hf_ag>
BT HID DEVICE <esp_hidd>
BT HID HOST <esp_hidh>
BT L2CAP <esp_l2cap_bt>
BT SDP <esp_sdp>
Bluetooth GAP <esp_gap_bt>
Bluetooth A2DP <esp_a2dp>
Bluetooth AVRC <esp_avrc>
Bluetooth SPP <esp_spp>
Bluetooth HFP Define <esp_hf_defs>
Bluetooth HFP Client <esp_hf_client>
Bluetooth HFP AG <esp_hf_ag>
Bluetooth HID Device <esp_hidd>
Bluetooth HID Host <esp_hidh>
Bluetooth L2CAP <esp_l2cap_bt>
Bluetooth SDP <esp_sdp>

View File

@ -6,7 +6,7 @@ Application Example
Check :example:`bluetooth/hci` folder in ESP-IDF examples, which contains the following application:
* This is a BLE advertising demo with virtual HCI interface. Send Reset/ADV_PARAM/ADV_DATA/ADV_ENABLE HCI command for BLE advertising - :example:`bluetooth/hci/controller_vhci_ble_adv`.
* This is a Bluetooth® Low Energy (Bluetooth LE) advertising demo with virtual HCI interface. Send Reset/ADV_PARAM/ADV_DATA/ADV_ENABLE HCI command for Bluetooth Low Energy advertising - :example:`bluetooth/hci/controller_vhci_ble_adv`.
API Reference
-------------

View File

@ -1,20 +1,15 @@
ESP-BLE-MESH
============
With various features of ESP-BLE-MESH, users can create a managed flooding mesh network for several
scenarios, such as lighting, sensor and etc.
With various features of ESP-BLE-MESH, users can create a managed flooding mesh network for several scenarios, such as lighting, sensor and etc.
For an ESP32 to join and work on a ESP-BLE-MESH network, it must be provisioned firstly. By provisioning,
the ESP32, as an unprovisioned device, will join the ESP-BLE-MESH network and become a ESP-BLE-MESH node,
communicating with other nodes within or beyond the radio range.
For an ESP32 to join and work on a ESP-BLE-MESH network, it must be provisioned firstly. By provisioning, the ESP32, as an unprovisioned device, will join the ESP-BLE-MESH network and become a ESP-BLE-MESH node, communicating with other nodes within or beyond the radio range.
Apart from ESP-BLE-MESH nodes, inside ESP-BLE-MESH network, there is also ESP32 that works as ESP-BLE-MESH
Provisioner, which could provision unprovisioned devices into ESP-BLE-MESH nodes and configure the nodes
with various features.
Apart from ESP-BLE-MESH nodes, inside ESP-BLE-MESH network, there is also ESP32 that works as ESP-BLE-MESH provisioner, which could provision unprovisioned devices into ESP-BLE-MESH nodes and configure the nodes with various features.
For information how to start using ESP32 and ESP-BLE-MESH, please see the Section :ref:`getting-started-with-ble-mesh`. If you are interested in information on ESP-BLE-MESH architecture, including some details of software implementation, please see Section :doc:`../../api-guides/esp-ble-mesh/ble-mesh-architecture`.
Application Examples and Demos
------------------------------
@ -48,8 +43,7 @@ This section contains only one header file, which lists the following items of E
ESP-BLE-MESH Core API Reference
-------------------------------
This section contains ESP-BLE-MESH Core related APIs, which can be used to initialize ESP-BLE-MESH
stack, provision, send/publish messages, etc.
This section contains ESP-BLE-MESH Core related APIs, which can be used to initialize ESP-BLE-MESH stack, provision, send/publish messages, etc.
This API reference covers six components:
@ -79,7 +73,7 @@ Low Power Operation (Updating)
.. include-build-file:: inc/esp_ble_mesh_low_power_api.inc
Send/Publish Messages, add Local AppKey, etc.
Send/Publish Messages, Add Local AppKey, Etc.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. include-build-file:: inc/esp_ble_mesh_networking_api.inc

View File

@ -1,5 +1,5 @@
Bluetooth A2DP API
==================
Bluetooth® A2DP API
===================
Application Example
-------------------

View File

@ -1,5 +1,5 @@
BT AVRCP APIs
=============
Bluetooth® AVRCP APIs
=====================
Overview
--------

View File

@ -1,9 +1,11 @@
BLUFI API
BluFi API
=========
Overview
--------
BLUFI is a profile based GATT to config ESP32 WIFI to connect/disconnect AP or setup a softap and etc.
BluFi is a profile based GATT to config ESP32 Wi-Fi to connect/disconnect AP or setup a softap and etc.
Use should concern these things:
1. The event sent from profile. Then you need to do something as the event indicate.
@ -14,7 +16,7 @@ Application Example
Check :example:`bluetooth` folder in ESP-IDF examples, which contains the following application:
* This is the BLUFI demo. This demo can set ESP32's wifi to softap/station/softap&station mode and config wifi connections - :example:`bluetooth/blufi`
* This is the BluFi demo. This demo can set ESP32's Wi-Fi to softap/station/softap&station mode and config Wi-Fi connections - :example:`bluetooth/blufi`
API Reference
-------------

View File

@ -1,5 +1,5 @@
BT GENERIC DEFINES
==================
Bluetooth® Generic Defines
==========================
API Reference
-------------

View File

@ -1,5 +1,5 @@
BT DEVICE APIs
===============
Bluetooth® Device APIs
======================
Overview
--------

View File

@ -1,5 +1,5 @@
BT MAIN API
===========
Bluetooth® Main API
===================
API Reference
-------------

View File

@ -1,5 +1,6 @@
GAP API
=======
:link_to_translation:`zh_CN:[中文]`
Application Example

View File

@ -1,5 +1,5 @@
CLASSIC BLUETOOTH GAP API
=========================
Classic Bluetooth® GAP API
==========================
API Reference
-------------

View File

@ -1,4 +1,4 @@
GATT DEFINES
GATT Defines
============
API Reference

View File

@ -1,4 +1,4 @@
GATT CLIENT API
GATT Client API
===============
Application Example
@ -16,7 +16,7 @@ Check :example:`bluetooth/bluedroid/ble` folder in ESP-IDF examples, which conta
- :example:`bluetooth/bluedroid/ble/gattc_multi_connect`
- :example_file:`GATT Client Multi-connection Example Walkthrough <bluetooth/bluedroid/ble/gattc_multi_connect/tutorial/Gatt_Client_Multi_Connection_Example_Walkthrough.md>`
* This is a BLE SPP-Like demo. This demo, which acts as a GATT client, can receive data from UART and then send the data to the peer device automatically.
* This is a demo similar to Bluetooth® Low Energy (Bluetooth LE) SPP. This demo, which acts as a GATT client, can receive data from UART and then send the data to the peer device automatically.
- :example:`bluetooth/bluedroid/ble/ble_spp_client`

View File

@ -18,7 +18,7 @@ Check :example:`bluetooth/bluedroid/ble` folder in ESP-IDF examples, which conta
- :example:`bluetooth/bluedroid/ble/gatt_server`
- :example_file:`GATT Server Example Walkthrough <bluetooth/bluedroid/ble/gatt_server/tutorial/Gatt_Server_Example_Walkthrough.md>`
* This is a demo similar to Bluetooth SPP. In this demo, GATT server can receive data from UART and then send the data to the peer device automatically.
* This is a demo similar to Bluetooth® Low Energy (Bluetooth LE) SPP. In this demo, GATT server can receive data from UART and then send the data to the peer device automatically.
- :example:`bluetooth/bluedroid/ble/ble_spp_server`

View File

@ -1,4 +1,4 @@
HFP CLIENT API
HFP Client API
==============
API Reference

View File

@ -1,4 +1,4 @@
HFP DEFINES
HFP Defines
===========
API Reference

View File

@ -1,5 +1,5 @@
Bluetooth HID Device API
========================
Bluetooth® HID Device API
=========================
Overview
--------

View File

@ -1,4 +1,4 @@
Bluetooth HID Host API
Bluetooth® HID Host API
========================
Overview

View File

@ -1,4 +1,4 @@
Classic Bluetooth L2CAP API
Classic Bluetooth® L2CAP API
============================
Application Example

View File

@ -1,5 +1,5 @@
BT SDP APIs
=============
Bluetooth® SDP APIs
===================
Overview
--------

View File

@ -1,5 +1,5 @@
SPP API
===============
=======
Application Example
-------------------

View File

@ -1,5 +1,5 @@
Bluetooth API
*************
Bluetooth® API
**************
:link_to_translation:`zh_CN:[中文]`
@ -13,10 +13,10 @@ Bluetooth API
:SOC_BLE_MESH_SUPPORTED: esp-ble-mesh
nimble/index
ESP-IDF currently supports two host stacks. The Bluedroid based stack (default) supports classic Bluetooth as well as BLE. On the other hand, Apache NimBLE based stack is BLE only. For users to make a choice:
ESP-IDF currently supports two host stacks. The Bluedroid based stack (default) supports classic Bluetooth as well as Bluetooth Low Energy (Bluetooth LE). On the other hand, Apache NimBLE based stack is Bluetooth Low Energy only. For users to make a choice:
* For usecases involving classic Bluetooth as well as BLE, Bluedroid should be used.
* For BLE-only usecases, using NimBLE is recommended. It is less demanding in terms of code footprint and runtime memory, making it suitable for such scenarios.
* For usecases involving classic Bluetooth as well as Bluetooth Low Energy, Bluedroid should be used.
* For Bluetooth Low Energy-only usecases, using NimBLE is recommended. It is less demanding in terms of code footprint and runtime memory, making it suitable for such scenarios.
.. only:: esp32

View File

@ -1,9 +1,10 @@
NimBLE-based host APIs
NimBLE-based Host APIs
**********************
Overview
========
Apache MyNewt NimBLE is a highly configurable and BT SIG qualifiable BLE stack providing both host and controller functionalities. ESP-IDF supports NimBLE host stack which is specifically ported for ESP32 platform and FreeRTOS. The underlying controller is still the same (as in case of Bluedroid) providing VHCI interface. Refer to `NimBLE user guide <https://mynewt.apache.org/latest/network/index.html>`_ for a complete list of features and additional information on NimBLE stack. Most features of NimBLE including BLE Mesh are supported by ESP-IDF. The porting layer is kept cleaner by maintaining all the existing APIs of NimBLE along with a single ESP-NimBLE API for initialization, making it simpler for the application developers.
Apache MyNewt NimBLE is a highly configurable and Bluetooth® SIG qualifiable Bluetooth Low Energy (Bluetooth LE) stack providing both host and controller functionalities. ESP-IDF supports NimBLE host stack which is specifically ported for ESP32 platform and FreeRTOS. The underlying controller is still the same (as in case of Bluedroid) providing VHCI interface. Refer to `NimBLE user guide <https://mynewt.apache.org/latest/network/index.html>`_ for a complete list of features and additional information on NimBLE stack. Most features of NimBLE including Bluetooth Low Energy Mesh are supported by ESP-IDF. The porting layer is kept cleaner by maintaining all the existing APIs of NimBLE along with a single ESP-NimBLE API for initialization, making it simpler for the application developers.
Architecture
============
@ -21,7 +22,7 @@ Currently, NimBLE host and controller support different transports such as UART
Threading Model
===============
The NimBLE host can run inside the application thread or can have its own independent thread. This flexibility is inherently provided by NimBLE design. By default, a thread is spawned by the porting function ``nimble_port_freertos_init``. This behavior can be changed by overriding the same function. For BLE Mesh, additional thread (advertising thread) is used which keeps on feeding advertisement events to the main thread.
The NimBLE host can run inside the application thread or can have its own independent thread. This flexibility is inherently provided by NimBLE design. By default, a thread is spawned by the porting function ``nimble_port_freertos_init``. This behavior can be changed by overriding the same function. For Bluetooth Low Energy Mesh, additional thread (advertising thread) is used which keeps on feeding advertisement events to the main thread.
Programming Sequence
====================

View File

@ -1,8 +1,9 @@
GAP API
=======
:link_to_translation:`en:[English]`
应用
应用
-------------------
以下示例及其教程存放在 ESP-IDF 项目示例的 :example:`bluetooth/bluedroid/ble` 目录下。

View File

@ -18,7 +18,7 @@ GATT 服务器 API
- :example:`bluetooth/bluedroid/ble/gatt_server`
- :example_file:`GATT 服务器示例 <bluetooth/bluedroid/ble/gatt_server/tutorial/Gatt_Server_Example_Walkthrough.md>`
* 以下示例与 Bluetooth SPP 类似。在该示例中GATT 服务器可以接收来自 UART 的数据,并将数据自动发送到对端设备。
* 以下示例与低功耗蓝牙 (Bluetooth® LE) SPP 类似。在该示例中GATT 服务器可以接收来自 UART 的数据,并将数据自动发送到对端设备。
- :example:`bluetooth/bluedroid/ble/ble_spp_server`

View File

@ -13,10 +13,10 @@
:SOC_BLE_MESH_SUPPORTED: esp-ble-mesh
nimble/index
ESP-IDF 目前支持两个主机堆栈。基于 Bluedroid 的堆栈(默认)支持传统蓝牙和 BLE而基于 Apache NimBLE 的堆栈仅支持 BLE。用户可参考如下信息进行选择:
ESP-IDF 目前支持两个主机堆栈。基于 Bluedroid 的堆栈(默认)支持传统蓝牙和低功耗蓝牙 (Bluetooth® LE),而基于 Apache NimBLE 的堆栈仅支持低功耗蓝牙。用户可参考如下信息进行选择:
* 对于同时涉及传统蓝牙和 BLE 的用例,应该选用 Bluedroid。
* 对于仅涉及 BLE 的用例,建议选用 NimBLE。在代码占用和运行时NimBLE 对内存的要求较低,因此适用于此类场景。
* 对于同时涉及传统蓝牙和低功耗蓝牙的用例,应该选用 Bluedroid。
* 对于仅涉及低功耗蓝牙的用例,建议选用 NimBLE。在代码占用和运行时NimBLE 对内存的要求较低,因此适用于此类场景。
.. only:: esp32