bartoszek/zephyr
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: Rename BLE to Bluetooth (LE) where applicable

Browse Source 
The BLE acronym is not an official description of Bluetooth
LE, and the Bluetooth SIG only ever refers to it as Bluetooth
Low Energy or Bluetooth LE, so Zephyr should as well.

This commit does not change any board or vendor specific
documentation, and the term BLE may still be used in those.
It will be up to the vendors to update it if they want,
since many of them are using the term BLE in their
products.

Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This commit is contained in:
Emil Gydesen 2025-02-10 08:44:26 +01:00 committed by Benjamin Cabé
parent e6c5f4d6aa
commit bf95ad47be
12 changed files with 52 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/connectivity/bluetooth/api/hci.txt
View File

@ -805,7 +805,7 @@ event shall be generated.
Zephyr Write Tx Power Level (per Role/Connection) Command
=========================================================
This command dynamically modifies BLE Tx power level given a handle and a
This command dynamically modifies Bluetooth Tx power level given a handle and a
handle type (advertiser, scanner, connection).
+--------------------------+-------+--------------------+--------------------+
@ -818,8 +818,8 @@ handle type (advertiser, scanner, connection).
| | | | Selected_Tx_Power |
+--------------------------+-------+--------------------+--------------------+
The Tx power of the BLE radio interface is modified for any low-level link by
the controller with a high degree of flexibility. The BLE link whose power is
The Tx power of the Bluetooth radio interface is modified for any low-level link by
the controller with a high degree of flexibility. The Bluetooth link whose power is
set is identified based on a handle type (advertiser, scanner, connection) and
handle pair.
@ -927,10 +927,10 @@ event shall be generated.
Zephyr Read Tx Power Level (per Role/Connection) Command
========================================================
This command reads the BLE Tx power level. In contrast to the standardized HCI
This command reads the Bluetooth Tx power level. In contrast to the standardized HCI
command, i.e. Read_Transmit_Power_Level, which returns the transmitted power
level only for a specified connection handle, this command operates for both
connected and unconnected states. It gets the BLE Tx power level for any given
connected and unconnected states. It gets the Bluetooth Tx power level for any given
handle type (advertiser, scanner, connection) and handle.
+--------------------------+-------+--------------------+--------------------+
@ -943,7 +943,7 @@ handle type (advertiser, scanner, connection) and handle.
| | | | Tx_Power_Level |
+--------------------------+-------+--------------------+--------------------+
The Tx power of the BLE radio interface used for a low-level link identified
The Tx power of the Bluetooth radio interface used for a low-level link identified
by a pair of Handle_Type and Handle is retrieved from the controller.
The role/state defining input parameter is the Handle_Type, whereas its

39
doc/connectivity/bluetooth/bluetooth-arch.rst
View File

@ -10,15 +10,14 @@ This page describes the software architecture of Zephyr's Bluetooth protocol
stack.
.. note::
Zephyr supports mainly Bluetooth Low Energy (BLE), the low-power
Zephyr supports mainly Bluetooth Low Energy (LE), the low-power
version of the Bluetooth specification. Zephyr also has limited support
for portions of the BR/EDR Host. Throughout this architecture document we
use BLE interchangeably for Bluetooth except when noted.
for portions of the BR/EDR Host.
.. _bluetooth-layers:
BLE Layers
==========
Bluetooth LE Layers
===================
There are 3 main layers that together constitute a full Bluetooth Low Energy
protocol stack:
@ -62,7 +61,7 @@ following configurations are commonly used:
* **Single-chip configuration**: In this configuration, a single microcontroller
implements all three layers and the application itself. This can also be called a
system-on-chip (SoC) implementation. In this case the BLE Host and the BLE
system-on-chip (SoC) implementation. In this case the Bluetooth Host and the Bluetooth
Controller communicate directly through function calls and queues in RAM. The
Bluetooth specification does not specify how HCI is implemented in this
single-chip configuration and so how HCI commands, events, and data flows between
@ -75,11 +74,11 @@ following configurations are commonly used:
configuration. This configuration allows for a wider variety of combinations of
Hosts when using the Zephyr OS as a Controller. Since HCI ensures
interoperability among Host and Controller implementations, including of course
Zephyr's very own BLE Host and Controller, users of the Zephyr Controller can
Zephyr's very own Bluetooth Host and Controller, users of the Zephyr Controller can
choose to use whatever Host running on any platform they prefer. For example,
the host can be the Linux BLE Host stack (BlueZ) running on any processor
the host can be the Linux Bluetooth Host stack (BlueZ) running on any processor
capable of supporting Linux. The Host processor may of course also run Zephyr
and the Zephyr OS BLE Host. Conversely, combining an IC running the Zephyr
and the Zephyr OS Bluetooth Host. Conversely, combining an IC running the Zephyr
Host with an external Controller that does not run Zephyr is also supported.
.. _bluetooth-build-types:
@ -88,12 +87,12 @@ Build Types
===========
The Zephyr software stack as an RTOS is highly configurable, and in particular,
the BLE subsystem can be configured in multiple ways during the build process to
the Bluetooth subsystem can be configured in multiple ways during the build process to
include only the features and layers that are required to reduce RAM and ROM
footprint as well as power consumption. Here's a short list of the different
BLE-enabled builds that can be produced from the Zephyr project codebase:
Bluetooth-enabled builds that can be produced from the Zephyr project codebase:
* **Controller-only build**: When built as a BLE Controller, Zephyr includes
* **Controller-only build**: When built as a Bluetooth Controller, Zephyr includes
the Link Layer and a special application. This application is different
depending on the physical transport chosen for HCI:
@ -114,7 +113,7 @@ BLE-enabled builds that can be produced from the Zephyr project codebase:
corresponding device tree node is enabled.
* **Host-only build**: A Zephyr OS Host build will contain the Application and
the BLE Host, along with an HCI driver (UART or SPI) to interface with an
the Bluetooth Host, along with an HCI driver (UART or SPI) to interface with an
external Controller chip.
A build of this type sets the following Kconfig option values:
@ -143,12 +142,12 @@ BLE-enabled builds that can be produced from the Zephyr project codebase:
used for Controller-only builds can be built as Combined
The picture below shows the SoC or single-chip configuration when using a Zephyr
combined build (a build that includes both a BLE Host and a Controller in the
combined build (a build that includes both a Bluetooth Host and a Controller in the
same firmware image that is programmed onto the chip):
.. figure:: img/ble_cfg_single.png
:align: center
:alt: BLE Combined build on a single chip
:alt: Bluetooth Combined build on a single chip
A Combined build on a Single-Chip configuration
@ -157,25 +156,25 @@ combinations are possible, some of which are depicted below:
.. figure:: img/ble_cfg_dual.png
:align: center
:alt: BLE dual-chip configuration builds
:alt: Bluetooth dual-chip configuration builds
Host-only and Controller-only builds on dual-chip configurations
When using a Zephyr Host (left side of image), two instances of Zephyr OS
must be built with different configurations, yielding two separate images that
must be programmed into each of the chips respectively. The Host build image
contains the application, the BLE Host and the selected HCI driver (UART or
contains the application, the Bluetooth Host and the selected HCI driver (UART or
SPI), while the Controller build runs either the
:zephyr:code-sample:`bluetooth_hci_uart`, or the
:zephyr:code-sample:`bluetooth_hci_spi` app to provide an interface to
the BLE Controller.
the Bluetooth Controller.
This configuration is not limited to using a Zephyr OS Host, as the right side
of the image shows. One can indeed take one of the many existing GNU/Linux
distributions, most of which include Linux's own BLE Host (BlueZ), to connect it
distributions, most of which include Linux's own Bluetooth Host (BlueZ), to connect it
via UART or USB to one or more instances of the Zephyr OS Controller build.
BlueZ as a Host supports multiple Controllers simultaneously for applications
that require more than one BLE radio operating at the same time but sharing the
that require more than one Bluetooth radio operating at the same time but sharing the
same Host stack.
Source tree layout

2
doc/connectivity/bluetooth/bluetooth-dev.rst
View File

@ -139,7 +139,7 @@ Simulated nRF5x with BabbleSim
The :ref:`nrf52_bsim <nrf52_bsim>` and :ref:`nrf5340bsim <nrf5340bsim>` boards,
are simulated target boards
which emulate the necessary peripherals of a nRF52/53 SOC to be able to develop
and test BLE applications.
and test Bluetooth LE applications.
These boards, use:
* `BabbleSim`_ to simulate the nRF5x modem and the radio environment.

8
doc/connectivity/bluetooth/bluetooth-le-host.rst
View File

@ -21,7 +21,7 @@ host, and vice-versa.
Perhaps the most important block above the HCI handling is the Generic
Access Profile (GAP). GAP simplifies Bluetooth LE access by defining
four distinct roles of BLE usage:
four distinct roles of Bluetooth usage:
* Connection-oriented roles
@ -31,9 +31,9 @@ four distinct roles of BLE usage:
* Connection-less roles
* Broadcaster (sending out BLE advertisements, e.g. a smart beacon)
* Broadcaster (sending out Bluetooth LE advertisements, e.g. a smart beacon)
* Observer (scanning for BLE advertisements)
* Observer (scanning for Bluetooth LE advertisements)
Each role comes with its own build-time configuration option:
:kconfig:option:`CONFIG_BT_PERIPHERAL`, :kconfig:option:`CONFIG_BT_CENTRAL`,
@ -49,7 +49,7 @@ section.
Peripheral role
===============
Most Zephyr-based BLE devices will most likely be peripheral-role
Most Zephyr-based Bluetooth LE devices will most likely be peripheral-role
devices. This means that they perform connectable advertising and expose
one or more GATT services. After registering services using the
:c:func:`bt_gatt_service_register` API the application will typically

12
doc/connectivity/bluetooth/bluetooth-tools.rst
View File

@ -40,7 +40,7 @@ Using BlueZ with Zephyr
***********************
The Linux Bluetooth Protocol Stack, BlueZ, comes with a very useful set of
tools that can be used to debug and interact with Zephyr's BLE Host and
tools that can be used to debug and interact with Zephyr's Bluetooth Host and
Controller. In order to benefit from these tools you will need to make sure
that you are running a recent version of the Linux Kernel and BlueZ:
@ -62,7 +62,7 @@ You can then find :file:`btattach`, :file:`btmgt` and :file:`btproxy` in the
:file:`tools/` folder and :file:`btmon` in the :file:`monitor/` folder.
You'll need to enable BlueZ's experimental features so you can access its
most recent BLE functionality. Do this by editing the file
most recent Bluetooth functionality. Do this by editing the file
:file:`/lib/systemd/system/bluetooth.service`
and making sure to include the :literal:`-E` option in the daemon's execution
start line:
@ -160,11 +160,11 @@ building and running a sample:
$ sudo ./build/zephyr/zephyr.exe --bt-dev=hci0
Using a Zephyr-based BLE Controller
===================================
Using a Zephyr-based Bluetooth Controller
=========================================
Depending on which hardware you have available, you can choose between two
transports when building a single-mode, Zephyr-based BLE Controller:
transports when building a single-mode, Zephyr-based Bluetooth Controller:
* UART: Use the :zephyr:code-sample:`bluetooth_hci_uart` sample and follow
the instructions in :ref:`bluetooth-hci-uart-qemu-posix`.
@ -309,7 +309,7 @@ peripheral samples such as :zephyr:code-sample:`ble_peripheral_hr` or
Using Zephyr-based Controllers with BlueZ
*****************************************
If you want to test a Zephyr-powered BLE Controller using BlueZ's Bluetooth
If you want to test a Zephyr-powered Bluetooth Controller using BlueZ's Bluetooth
Host, you will need a few tools described in the :ref:`bluetooth_bluez` section.
Once you have installed the tools you can then use them to interact with your
Zephyr-based controller:

6
doc/connectivity/bluetooth/features.rst
View File

@ -8,10 +8,10 @@ Supported features
:depth: 2
Since its inception, Zephyr has had a strong focus on Bluetooth and, in
particular, on Bluetooth Low Energy (BLE). Through the contributions of
particular, on Bluetooth Low Energy (LE). Through the contributions of
several companies and individuals involved in existing open source
implementations of the Bluetooth specification (Linux's BlueZ) as well as the
design and development of BLE radio hardware, the protocol stack in Zephyr has
design and development of Bluetooth LE radio hardware, the protocol stack in Zephyr has
grown to be mature and feature-rich, as can be seen in the section below.
* Bluetooth v5.3 compliant
@ -41,7 +41,7 @@ grown to be mature and feature-rich, as can be seen in the section below.
* All v5.3 specification features supported (except a few minor items)
* Concurrent multi-protocol support ready
* Intelligent scheduling of roles to minimize overlap
* Portable design to any open BLE radio, currently supports Nordic
* Portable design to any open Bluetooth LE radio, currently supports Nordic
Semiconductor nRF52x and nRF53x SoC Series, as well as proprietary radios
* Supports little and big endian architectures, and abstracts the hard
real-time specifics so that they can be encapsulated in a hardware-specific

4
doc/develop/test/bsim.rst
View File

@ -7,11 +7,11 @@ BabbleSim and Zephyr
********************
In the Zephyr project we use the `Babblesim`_ simulator to test some of the Zephyr radio protocols,
including the BLE stack, 802.15.4, and some of the networking stack.
including the Bluetooth LE stack, 802.15.4, and some of the networking stack.
BabbleSim_ is a physical layer simulator, which in combination with the Zephyr
:ref:`bsim boards<bsim boards>`
can be used to simulate a network of BLE and 15.4 devices.
can be used to simulate a network of Bluetooth LE and 15.4 devices.
When we build Zephyr targeting a :ref:`bsim board<bsim boards>` we produce a Linux
executable, which includes the application, Zephyr OS, and models of the HW.

2
doc/hardware/porting/board_porting.rst
View File

@ -281,7 +281,7 @@ The mandatory files are:
#. :file:`plank_<qualifiers>.dts`: a hardware description
in :ref:`devicetree <dt-guide>` format. This declares your SoC, connectors,
and any other hardware components such as LEDs, buttons, sensors, or
communication peripherals (USB, BLE controller, etc).
communication peripherals (USB, Bluetooth controller, etc).
#. :file:`Kconfig.plank`: the base software configuration for selecting SoC and
other board and SoC related settings. Kconfig settings outside of the board

8
doc/security/vulnerabilities.rst
View File

@ -1599,8 +1599,8 @@ This has been fixed in main for v3.6.0
:cve:`2024-3077`
----------------
Bluetooth: Integer underflow in gatt_find_info_rsp. A malicious BLE
device can crash BLE victim device by sending malformed gatt packet.
Bluetooth: Integer underflow in gatt_find_info_rsp. A malicious Bluetooth LE
device can crash Bluetooth LE victim device by sending malformed gatt packet.
- `Zephyr project bug tracker GHSA-gmfv-4vfh-2mh8
<https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-gmfv-4vfh-2mh8>`_
@ -1615,8 +1615,8 @@ This has been fixed in main for v3.7.0
Bluetooth: DoS caused by null pointer dereference.
A malicious BLE device can send a specific order of packet
sequence to cause a DoS attack on the victim BLE device.
A malicious Bluetooth LE device can send a specific order of packet
sequence to cause a DoS attack on the victim Bluetooth LE device.
- `Zephyr project bug tracker GHSA-jmr9-xw2v-5vf4
<https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-jmr9-xw2v-5vf4>`_

4
doc/services/device_mgmt/mcumgr.rst
View File

@ -19,7 +19,7 @@ The following management operations are available:
over the following transports:
* BLE (Bluetooth Low Energy)
* Bluetooth Low Energy (LE)
* Serial (UART)
* UDP over IP
@ -32,7 +32,7 @@ The management subsystem is located in :zephyr_file:`subsys/mgmt/` inside of
the Zephyr tree.
Additionally, there is a :zephyr:code-sample:`sample <smp-svr>` server that provides
management functionality over BLE and serial.
management functionality over Bluetooth LE and serial.
.. _mcumgr_tools_libraries:

2
doc/services/device_mgmt/ota.rst
View File

@ -62,7 +62,7 @@ SMP Server
==========
A Simple Management Protocol (SMP) server can be used to update firmware via
Bluetooth Low Energy (BLE) or UDP. :ref:`mcu_mgr` is used to send a signed
Bluetooth Low Energy (LE) or UDP. :ref:`mcu_mgr` is used to send a signed
firmware binary to the remote device where it is verified by MCUboot before the
upgrade occurs.

6
doc/services/device_mgmt/smp_transport.rst
View File

@ -8,10 +8,10 @@ side SMP transports.
.. _mcumgr_smp_transport_ble:
BLE (Bluetooth Low Energy)
**************************
Bluetooth Low Energy (LE)
*************************
MCUmgr Clients need to use following BLE Characteristics, when implementing
MCUmgr Clients need to use following Bluetooth Characteristics, when implementing
SMP client:
- **Service UUID**: ``8D53DC1D-1DB7-4CD3-868B-8A527460AA84``