michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: sphinx-lint: fix bad usage of "default role"

Browse source 
Fixes bad usage of single backticks in lieu of double backticks for
rendering inline literals, or simple '*' for italics.

When appropriate, a better construct than double backticks has been
selected (ex. :file:, :kconfig:option:, :c:func:, ...), or proper :ref:
have been used if the original intention was to have a link.

Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
This commit is contained in:
Benjamin Cabé 2024-09-10 19:51:57 +02:00 • committed by Mahesh Mahadevan
commit df294e34e1
127 changed files with 304 additions and 285 deletions
Download patch file Download diff file Expand all files Collapse all files

4
boards/adafruit/feather_nrf52840/doc/index.rst
View file

@ -181,8 +181,8 @@ but does not support debugging the device.
#. If using UF2, connect the board to your host computer using USB.
#. Tap the reset button twice quickly to enter bootloader mode.
A mass storage device named `FTHR840BOOT` for (Express) or
`FTHRSNSBOOT` (Sense) should appear on the host. Ensure this is
A mass storage device named ``FTHR840BOOT`` for (Express) or
``FTHRSNSBOOT`` (Sense) should appear on the host. Ensure this is
mounted.
#. Flash the image.

2
boards/adafruit/kb2040/doc/index.rst
View file

@ -117,7 +117,7 @@ Using UF2
Since it doesn't expose the SWD pins, you must flash the Adafruit KB2040 with
a UF2 file. By default, building an app for this board will generate a
`build/zephyr/zephyr.uf2` file. If the KB2040 is powered on with the `BOOTSEL`
:file:`build/zephyr/zephyr.uf2` file. If the KB2040 is powered on with the ``BOOTSEL``
button pressed, it will appear on the host as a mass storage device. The
UF2 file should be drag-and-dropped to the device, which will flash the KB2040.

2
boards/adafruit/qt_py_rp2040/doc/index.rst
View file

@ -116,7 +116,7 @@ Using UF2
Since it doesn't expose the SWD pins, you must flash the Adafruit QT Py RP2040 with
a UF2 file. By default, building an app for this board will generate a
`build/zephyr/zephyr.uf2` file. If the QT Py RP2040 is powered on with the `BOOTSEL`
:file:`build/zephyr/zephyr.uf2` file. If the QT Py RP2040 is powered on with the ``BOOTSEL``
button pressed, it will appear on the host as a mass storage device. The
UF2 file should be drag-and-dropped to the device, which will flash the QT Py RP2040.

2
boards/ambiq/apollo3_evb/doc/index.rst
View file

@ -69,7 +69,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash
.. note::
`west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings:

2
boards/ambiq/apollo3p_evb/doc/index.rst
View file

@ -69,7 +69,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash
.. note::
`west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings:

2
boards/ambiq/apollo4p_blue_kxr_evb/doc/index.rst
View file

@ -77,7 +77,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash
.. note::
`west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings:

2
boards/ambiq/apollo4p_evb/doc/index.rst
View file

@ -72,7 +72,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash
.. note::
`west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings:

2
boards/arduino/nano_33_ble/doc/index.rst
View file

@ -160,7 +160,7 @@ That license ties to Arduino Nano 33 BLE hardware serial number,
it also works with the ZephyrRTOS.
Follow the instruction of the tutorial for Arduino
`Lauterbach TRACE32 GDB Front-End Debugger for Nano 33 BLE`
`Lauterbach TRACE32 GDB Front-End Debugger for Nano 33 BLE`_
to install the TRACE32.
After installing the TRACE32, You should set the environmental variable ``T32_DIR``.

2
boards/arm/fvp_base_revc_2xaemv8a/doc/index.rst
View file

@ -99,7 +99,7 @@ Checkout and Build the TF-A:
cd trusted-firmware-a/
make PLAT=fvp PRELOADED_BL33_BASE="0x88000000" all fip
then export the ``ARMFVP_BL1_FILE` and ``ARMFVP_FIP_FILE`` environment variables:
then export the :envvar:`ARMFVP_BL1_FILE` and :envvar:`ARMFVP_FIP_FILE` environment variables:
.. code-block:: console

2
boards/circuitdojo/feather/doc/index.rst
View file

@ -100,7 +100,7 @@ or Nordic based examples.
Trusted Firmware-M (TF-M) and building the ``ns`` target is not supported for this board.
Some of the examples do not use secure mode, so they do not require the
``ns`` suffix. A great example of this is the `hello_world` below.
``ns`` suffix. A great example of this is the ``hello_world`` below.
Flashing
========

4
boards/ct/ctcc/doc/index.rst
View file

@ -172,7 +172,7 @@ As an example we'll use the :zephyr:code-sample:`usb-cdc-acm-console` sample.
.. note::
In all examples it is assumed to use default `root-rsa-2048.pem` file from ``mcuboot/boot``
In all examples it is assumed to use default :file:`root-rsa-2048.pem` file from ``mcuboot/boot``
directory. Providing certificate in build args produces signed binary automatically.
Do not use this certificate in your production firmware!
@ -180,7 +180,7 @@ As an example we'll use the :zephyr:code-sample:`usb-cdc-acm-console` sample.
and plug such adapter to USB port.
You should see ``NordicSemiconductor MCUBOOT`` or ``NordicSemiconductor Zephyr DFU sample``
(if you flashed `dfu` sample to slot0) device once plugging it into host
(if you flashed ``dfu`` sample to slot0) device once plugging it into host
USB port. You can check that on Linux system by entering ``lsusb`` command.
To check if DFU device is visible you can enter ``sudo dfu-util -l`` command. Once the

2
boards/enjoydigital/litex_vexriscv/doc/index.rst
View file

@ -184,7 +184,7 @@ Use `ecpprog <https://github.com/gregdavill/ecpprog>`_ to upload the bitstream t
ecpprog -S antmicro_sdi_mipi_video_converter.bit
You can boot from a serial port using litex_term (replace `ttyUSBX` with your device) , e.g.:
You can boot from a serial port using litex_term (replace ``ttyUSBX`` with your device) , e.g.:
.. code-block:: bash

2
boards/intel/rpl/doc/index.rst
View file

@ -23,7 +23,7 @@ please refer to `RPL`_.
Raptor Lake Customer Reference Board (RPL CRB) is an example implementation of a
compact single board computer with high performance for IoT edge devices. The
supported boards are `intel_rpl_s_crb` and `intel_rpl_p_crb`.
supported boards are ``intel_rpl_s_crb`` and ``intel_rpl_p_crb``.
These board configurations enable kernel support for the supported Raptor Lake
boards.

2
boards/intel/socfpga/agilex5_socdk/doc/index.rst
View file

@ -45,7 +45,7 @@ hardware features:
NOTE: TODO, more details on dev kit will be updated as and when available.
The default configuration can be found in the defconfig file:
`boards/intel/socfpga/agilex5_socdk/intel_socfpga_agilex5_socdk_defconfig`
:zephyr_file:`boards/intel/socfpga/agilex5_socdk/intel_socfpga_agilex5_socdk_defconfig`.
Programming and Debugging
*************************

2
boards/m5stack/m5stack_core2/doc/index.rst
View file

@ -79,7 +79,7 @@ of the M5Stack Core2 board.
| MPU6886 | combines a 3-axis gyroscope and a 3-axis accelerometer. | |
| | For details please refer to :ref:`m5stack_core2_ext` | |
+------------------+--------------------------------------------------------------------------+-----------+
| Grove port | Note: Grove port requires 5V to be enabled via `bus_5v` regulator | supported |
| Grove port | Note: Grove port requires 5V to be enabled via ``bus_5v`` regulator | supported |
+------------------+--------------------------------------------------------------------------+-----------+
| Built-in | The `SPM-1423`_ I2S driven microphone. | todo |
| microphone | | |

8
boards/native/doc/arch_soc.rst
View file

@ -183,7 +183,7 @@ Currently, these are the most significant features which are not supported in th
* Stack checks: :kconfig:option:`CONFIG_HW_STACK_PROTECTION`,
:kconfig:option:`CONFIG_STACK_CANARIES`, and
:kconfig:option:`CONFIG_THREAD_ANALYZER`.
This is due to how Zephyr allocated threads' stacks are not `actually` being used like they are
This is due to how Zephyr allocated threads' stacks are not *actually* being used like they are
in other architectures. Check
:ref:`the architecture section's architecture layer paragraph <posix_arch_design_archl>`
for more information.
@ -355,7 +355,7 @@ while this newly created thread will be the first "SW" thread and start
executing the boot of the embedded code (including the POSIX arch code).
During this MCU boot process, the Zephyr kernel will be initialized and
eventually this will call into the embedded application `main()`,
eventually this will call into the embedded application ``main()``,
just like in the embedded target.
As the embedded SW execution progresses, more Zephyr threads may be spawned,
and for each the POSIX architecture will create a dedicated pthread.
@ -413,7 +413,7 @@ Busy waits
Busy waits work thanks to provided board functionality.
This does not need to be the same for all boards, but both native_sim and the
nrf52_bsim board work similarly thru the combination of a board specific
`arch_busy_wait()` and a special fake HW timer (provided by the board).
:c:func:`arch_busy_wait()` and a special fake HW timer (provided by the board).
When a SW thread wants to busy wait, this fake timer will be programmed in
the future time corresponding to the end of the busy wait and the CPU will
@ -422,7 +422,7 @@ When this fake HW timer expires the CPU will be waken with a special
non-maskable phony interrupt which does not have a corresponding interrupt
handler but will resume the busy_wait SW execution.
Note that other interrupts may arrive while the busy wait is in progress,
which may delay the `k_busy_wait()` return just like in real life.
which may delay the :c:func:`k_busy_wait()` return just like in real life.
Interrupts may be locked out or masked during this time, but the special
fake-timer non-maskable interrupt will wake the CPU nonetheless.

24
boards/native/doc/bsim_boards_design.rst
View file

@ -16,7 +16,7 @@ Bsim boards
This page covers the design, architecture and rationale, of the
nrf5x_bsim boards and other similar bsim boards.
These boards are postfixed with `_bsim` as they use BabbleSim_
These boards are postfixed with ``_bsim`` as they use BabbleSim_
(shortened bsim), to simulate the radio environment.
These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build
and execute the embedded code natively on Linux.
@ -135,13 +135,13 @@ The basic architecture layering of these boards is as follows:
simulation specific ones.
- The architecture (arch) is the Zephyr :ref:`POSIX architecture<Posix arch>`
layer.
The SOC layer is `inf_clock`. And the board layer is dependent on
The SOC layer is ``inf_clock``. And the board layer is dependent on
the specific device we are simulating.
- The POSIX architecture provides an adaptation from the Zephyr arch API
(which handles mostly the thread context switching) to the native simulator
CPU thread emulation.
See :ref:`POSIX arch architecture<posix_arch_architecture>`
- The SOC `inf_clock` layer provides an adaptation to the native simulator CPU "simulation"
- The SOC ``inf_clock`` layer provides an adaptation to the native simulator CPU "simulation"
and the handling of control between the "CPU simulation" (Zephyr threads) and the
HW models thread ( See `Threading`_ ).
- The board layer provides all SOC/ IC specific content, including
@ -149,13 +149,13 @@ The basic architecture layering of these boards is as follows:
busy wait API (see :ref:`posix_busy_wait<posix_busy_wait>`), and Zephyr's printk backend.
Note that in a normal Zephyr target interrupt handling and a custom busy wait
would be provided by the SOC layer, but abusing Zephyr's layering, and for the
`inf_clock` layer to be generic, these were delegated to the board.
``inf_clock`` layer to be generic, these were delegated to the board.
The board layer provides other test specific
functionality like bs_tests hooks, trace control, etc, and
by means of the native simulator, provides the :c:func:`main` entry point for the Linux
program, command line argument handling, and the overall time scheduling of
the simulated device.
Note that the POSIX arch and `inf_clock` soc expect a set of APIs being provided by
Note that the POSIX arch and ``inf_clock`` soc expect a set of APIs being provided by
the board. This includes the busy wait API, a basic tracing API, the interrupt
controller and interrupt handling APIs, :c:func:`posix_exit`,
and :c:func:`posix_get_hw_cycle` (see :file:`posix_board_if.h` and :file:`posix_soc_if.h`).
@ -173,7 +173,7 @@ Important limitations and unsupported features
All native and bsim boards share the same set of
:ref:`important limitations which<posix_arch_limitations>`
are inherited from the POSIX arch and `inf_clock` design.
are inherited from the POSIX arch and ``inf_clock`` design.
Similarly, they inherit the POSIX architecture
:ref:`unsupported features set <posix_arch_unsupported>`.
@ -261,7 +261,7 @@ posix_print and nsi_print backends
==================================
The bsim board provides a backend for the ``posix_print`` API which is expected by the posix
ARCH and `inf_clock` code, and for the ``nsi_print`` API expected by the native simulator.
ARCH and ``inf_clock`` code, and for the ``nsi_print`` API expected by the native simulator.
These simply route this API calls into the ``bs_trace`` bsim API.
Any message printed to these APIs, and by extension by default to Zephyr's ``printk``,
@ -287,12 +287,12 @@ callbacks are assigned to the respective hooks.
There is a set of one time hooks at different levels of initialization of the HW
and Zephyr OS, a hook to process possible command line arguments, and, a hook
that can be used to sniff or capture interrupts.
`bs_tests` also provides a hook which will be called from the embedded application
``bs_tests`` also provides a hook which will be called from the embedded application
:c:func:`main`, but this will only work if the main application supports it,
that is, if the main app is a version for simulation which calls
:c:func:`bst_main` when running in the bsim board.
Apart from these hooks, the `bs_tests` system provides facilities to build a
Apart from these hooks, the ``bs_tests`` system provides facilities to build a
dedicated test "task". This will be executed in the HW models thread context,
but will have access to all SW variables. This task will be driven with a
special timer which can be configured to produce either periodic or one time
@ -302,15 +302,15 @@ at specific points in time. This can be combined with Babblesim's tb_defs macros
to build quite complex test tasks which can wait for a given amount of time,
for conditions to be fulfilled, etc.
Note when writing the tests with `bs_tests` one needs to be aware that other
Note when writing the tests with ``bs_tests`` one needs to be aware that other
bs tests will probably be built with the same application, and that therefore
the tests should not be registering initialization or callback functions using
NATIVE_TASKS or Zephyr's PRE/POST kernel driver initialization APIs as this
will execute even if the test is not selected.
Instead the equivalent `bs_tests` provided hooks should be used.
Instead the equivalent ``bs_tests`` provided hooks should be used.
Note also that, for AMP targets like the :ref:`nrf5340bsim <nrf5340bsim>`, each embedded MCU has
its own separate `bs_tests` built with that MCU. You can select if and what test is used
its own separate ``bs_tests`` built with that MCU. You can select if and what test is used
for each MCU separatedly with the command line options.
Command line argument parsing

4
boards/nxp/lpcxpresso54114/doc/index.rst
View file

@ -74,8 +74,8 @@ features:
The default configuration for each core can be found in the defconfig files:
`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m4_defconfig`
`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m0_defconfig`
- :zephyr_file:`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m4_defconfig`
- :zephyr_file:`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m0_defconfig`
Other hardware features are not currently supported by the port.

2
boards/nxp/lpcxpresso55s69/doc/index.rst
View file

@ -299,7 +299,7 @@ board.
-----------------------------------------
1. Install the :ref:`linkserver-debug-host-tools` and make sure they are in your search path.
2. To update the debug firmware, please follow the instructions on `LPCXPRESSO55S69 Debug Firmware`
2. To update the debug firmware, please follow the instructions on `LPCXPRESSO55S69 Debug Firmware`_
:ref:`opensda-daplink-onboard-debug-probe`
------------------------------------------

2
boards/nxp/mimxrt1040_evk/doc/index.rst
View file

@ -335,7 +335,7 @@ Remove resistors from R497, R498, R456 and R457.
And due to pin conflict issue, the PCM interface of Bluetooth module cannot be supported.
For the debugger fails to connect with the following error, please refer to section `WiFi Module`.
For the debugger fails to connect with the following error, please refer to the next section.
WiFi Module
-----------

6
boards/nxp/mimxrt1170_evk/doc/index.rst
View file

@ -111,8 +111,8 @@ NXP considers the MIMXRT1170-EVK as the superset board for the i.MX RT11xx
family of MCUs. This board is a focus for NXP's Full Platform Support for
Zephyr, to better enable the entire RT11xx family. NXP prioritizes enabling
this board with new support for Zephyr features. Note that this table
covers two boards: the RT1170 EVK (`mimxrt1170_evk//cm7/cm4`), and
RT1170 EVKB (`mimxrt1170_evk@B//cm7/cm4`)
covers two boards: the RT1170 EVK (``mimxrt1170_evk//cm7/cm4``), and
RT1170 EVKB (``mimxrt1170_evk@B//cm7/cm4``)
+-----------+------------+-------------------------------------+-----------------+-----------------+
| Interface | Controller | Driver/Component | RT1170 EVK | RT1170 EVKB |
@ -478,4 +478,4 @@ ENET1G Driver
Current default of ethernet driver is to use 100M Ethernet instance ENET.
To use the 1G Ethernet instance ENET1G, include the overlay to west build with
the option `-DEXTRA_DTC_OVERLAY_FILE=nxp,enet1g.overlay` instead.
the option ``-DEXTRA_DTC_OVERLAY_FILE=nxp,enet1g.overlay`` instead.

2
boards/nxp/rd_rw612_bga/doc/index.rst
View file

@ -196,7 +196,7 @@ Remove resistors:
- R508
- R505
Then, build for the board target `rd_rw612_bga//ethernet`.
Then, build for the board target ``rd_rw612_bga//ethernet``.
Resources
*********

2
boards/nxp/s32z2xxdc2/doc/index.rst
View file

@ -118,7 +118,7 @@ Serial Port
===========
The SoC has 12 LINFlexD instances that can be used in UART mode. The console can
be accessed by default on the USB micro-B connector `J119`.
be accessed by default on the USB micro-B connector J119.
Watchdog
========

8
boards/phytec/phyboard_electra/doc/index.rst
View file

@ -84,7 +84,7 @@ GPIO
----
The phyCORE-AM64x has a heartbeat LED connected to gpio6. It's configured
to build and run the `basic/blinky` sample.
to build and run the :zephyr:code-sample:`blinky` sample.
SD Card
*******
@ -111,9 +111,11 @@ To test the M4F core, we build the :ref:`hello_world` sample with the following
:zephyr-app: samples/hello_world
:goals: build
This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`.
This builds the program and the binary is present in the :file:`build/zephyr` directory as
:file:`zephyr.elf`.
We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am64-mcu-m4f0_0-fw`.
We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as
:file:`am64-mcu-m4f0_0-fw`.
.. code-block:: console

11
boards/phytec/phyboard_lyra/doc/phyboard_lyra_am62xx_m4.rst
View file

@ -96,16 +96,18 @@ The Linux running on the A53 uses the remoteproc framework to manage the M4F co-
Therefore, the testing requires the binary to be copied to the SD card to allow the A53 cores to
load it while booting using remoteproc.
To test the M4F core, we build the `hello_world` sample with the following command.
To test the M4F core, we build the :ref:`hello_world` sample with the following command.
.. code-block:: console
# From the root of the Zephyr repository
west build -p -b phyboard_lyra/am6234/m4 samples/hello_world
This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`.
This builds the program and the binary is present in the :file:`build/zephyr` directory as
:file:`zephyr.elf`.
We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am62-mcu-m4f0_0-fw`.
We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as
:file:`am62-mcu-m4f0_0-fw`.
.. code-block:: console
@ -134,7 +136,8 @@ port.
Debugging
*********
The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the `debug` build target:
The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the ``debug`` build
target:
.. zephyr-app-commands::
:app: <my_app>

2
boards/rak/rak11720/doc/index.rst
View file

@ -92,7 +92,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash
.. note::
`west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings:

11
boards/raspberrypi/rpi_5/doc/index.rst
View file

@ -69,7 +69,7 @@ In brief,
* `bcm2712-rpi-5.dtb`_
3. Insert the Micro SD card and power on the Raspberry Pi 5.
then, You will see the Raspberry Pi 5 running the `zephyr.bin`.
then, You will see the Raspberry Pi 5 running the :file:`zephyr.bin`.
config.txt
----------
@ -83,14 +83,15 @@ config.txt
zephyr.bin
----------
Build an app `samples/basic/blinky`
Build an app, for example :zephyr:code-sample:`blinky`
.. zephyr-app-commands::
:zephyr-app: samples/basic/blinky
:board: rpi_5
:goals: build
Copy `zephyr.bin` from `build/zephyr` directory to the root directory of the Micro SD card.
Copy :file:`zephyr.bin` from :file:`build/zephyr` directory to the root directory of the Micro SD
card.
Insert the Micro SD card and power on the Raspberry Pi 5. And then, the STAT LED will start to blink.
@ -125,14 +126,14 @@ config.txt
zephyr.bin
----------
Build an app `samples/hello_world`
Build an app, for example :ref:`hello_world`:
.. zephyr-app-commands::
:zephyr-app: samples/hello_world
:board: rpi_5
:goals: build
Copy `zephyr.bin` from `build/zephyr` directory to the root directory of the Micro SD card.
Copy :file:`zephyr.bin` from :file:`build/zephyr` directory to the root directory of the Micro SD card.
Insert the Micro SD card into your Raspberry Pi 5.

25
boards/raspberrypi/rpi_pico/doc/index.rst
View file

@ -137,11 +137,11 @@ Programmable I/O (PIO)
The RP2040 SoC comes with two PIO periherals. These are two simple
co-processors that are designed for I/O operations. The PIOs run
a custom instruction set, generated from a custom assembly language.
PIO programs are assembled using `pioasm`, a tool provided by Raspberry Pi.
PIO programs are assembled using :command:`pioasm`, a tool provided by Raspberry Pi.
Zephyr does not (currently) assemble PIO programs. Rather, they should be
manually assembled and embedded in source code. An example of how this is done
can be found at `drivers/serial/uart_rpi_pico_pio.c`.
can be found at :zephyr_file:`drivers/serial/uart_rpi_pico_pio.c`.
Sample: SPI via PIO
====================
@ -187,7 +187,7 @@ Create a file in /etc/udev.rules.d with any name, and write the line below.
ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess"
This example is valid for the case that the user joins to `plugdev` groups.
This example is valid for the case that the user joins to ``plugdev`` groups.
The Raspberry Pi Pico has an SWD interface that can be used to program
and debug the on board RP2040. This interface can be utilized by OpenOCD.
@ -208,22 +208,23 @@ Here is an example of building and flashing the :zephyr:code-sample:`blinky` app
:goals: build flash
:gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=cmsis-dap
Set the environment variables **OPENOCD** to `/usr/local/bin/openocd`
and **OPENOCD_DEFAULT_PATH** to `/usr/local/share/openocd/scripts`. This should work
Set the environment variables **OPENOCD** to :file:`/usr/local/bin/openocd`
and **OPENOCD_DEFAULT_PATH** to :file:`/usr/local/share/openocd/scripts`. This should work
with the OpenOCD that was installed with the default configuration.
This configuration also works with an environment that is set up by the `pico_setup.sh`_ script.
**RPI_PICO_DEBUG_ADAPTER** specifies what debug adapter is used for debugging.
If **RPI_PICO_DEBUG_ADAPTER** was not assigned, `cmsis-dap` is used by default.
The other supported adapters are `raspberrypi-swd`, `jlink` and `blackmagicprobe`.
How to connect `cmsis-dap` and `raspberrypi-swd` is described in `Getting Started with Raspberry Pi Pico`_.
If **RPI_PICO_DEBUG_ADAPTER** was not assigned, ``cmsis-dap`` is used by default.
The other supported adapters are ``raspberrypi-swd``, ``jlink`` and ``blackmagicprobe``.
How to connect ``cmsis-dap`` and ``raspberrypi-swd`` is described in `Getting Started with Raspberry Pi Pico`_.
Any other SWD debug adapter maybe also work with this configuration.
The value of **RPI_PICO_DEBUG_ADAPTER** is cached, so it can be omitted from
`west flash` and `west debug` if it was previously set while running `west build`.
``west flash`` and ``west debug`` if it was previously set while running
``west build``.
**RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as `"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"`.
**RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as ``"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"``.
Thus, **RPI_PICO_DEBUG_ADAPTER** needs to be assigned the file name of the debug adapter.
You can also flash the board with the following
@ -238,7 +239,7 @@ Using UF2
If you don't have an SWD adapter, you can flash the Raspberry Pi Pico with
a UF2 file. By default, building an app for this board will generate a
`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the `BOOTSEL`
:file:`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the ``BOOTSEL``
button pressed, it will appear on the host as a mass storage device. The
UF2 file should be drag-and-dropped to the device, which will flash the Pico.
@ -270,7 +271,7 @@ Here is an example for debugging the :zephyr:code-sample:`blinky` application.
:gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=raspberrypi-swd
As with flashing, you can specify the debug adapter by specifying **RPI_PICO_DEBUG_ADAPTER**
at `west build` time. No needs to specify it at `west debug` time.
at ``west build`` time. No needs to specify it at ``west debug`` time.
You can also debug with OpenOCD and gdb launching from command-line.
Run the following command:

4
boards/renesas/rzt2m_starterkit/doc/index.rst
View file

@ -67,7 +67,7 @@ By default, the board is configured for use with:
* UART0 connected to the USB serial port (pins K18, K19),
* UART3 connected to the PMOD Header (J25, pins H16, G20),
* LEDs defined as `led0`, `led1`, `led2` and `led3`,
* LEDs defined as ``led0``, ``led1``, ``led2`` and ``led3``,
The Zephyr console uses UART0.
@ -78,7 +78,7 @@ Debugging
=========
Connect to the board using the J-Link On-board USB connector.
Use `west` to start the debug server:
Use ``west`` to start the debug server:
.. code-block:: console

6
boards/seeed/xiao_ble/doc/index.rst
View file

@ -92,9 +92,9 @@ UF2 Flashing
To enter the bootloader, connect the USB port of the XIAO BLE to your host, and
double tap the reset botton to the left of the USB connector. A mass storage
device named `XIAO BLE` should appear on the host. Using the command line, or
your file manager copy the `zephyr/zephyr.uf2` file from your build to the base
of the `XIAO BLE` mass storage device. The XIAO BLE will automatically reset
device named ``XIAO BLE`` should appear on the host. Using the command line, or
your file manager copy the :file:`zephyr/zephyr.uf2` file from your build to the base
of the ``XIAO BLE`` mass storage device. The XIAO BLE will automatically reset
and launch the newly flashed application.
External Debugger

2
boards/seeed/xiao_esp32c3/doc/index.rst
View file

@ -172,7 +172,7 @@ For the :code:`Hello, world!` application, follow the instructions below.
:board: xiao_esp32c3
:goals: build flash
Since the Zephyr console is by default on the `usb_serial` device, we use
Since the Zephyr console is by default on the ``usb_serial`` device, we use
the espressif monitor to view.
.. code-block:: console

2
boards/shields/mikroe_mcp2518fd_click/doc/index.rst
View file

@ -16,7 +16,7 @@ Requirements
************
The shield uses a mikroBUS interface. The target board must define
a `mikrobus_spi` and `mikrobus_header` node labels
a ``mikrobus_spi`` and ``mikrobus_header`` node labels
(see :ref:`shields` for more details). The target board must also
support level triggered interrupts.

11
boards/shields/rpi_pico_uno_flexypin/doc/index.rst
View file

@ -6,12 +6,13 @@ RaspberryPi Pico to UNO FlexyPin Adapter
Overview
********
Raspberry Pi Pico to Uno `FlexyPin Adapter` is a converter-PCB to Arduino UNO form-factor
from Raspberry Pi Pico that is released in Open Source Hardware.
This board design to use with `FlexyPin`.
The Raspberry Pi Pico to Uno FlexyPin Adapter is an open-source hardware converter PCB that adapts
the Raspberry Pi Pico to the Arduino UNO form factor
This board is designed to be use with FlexyPin connector pins.
The FlexyPin holds Pico and contacts to castellated through-hole.
With simple soldering, it can also be used as a board to convert the RapsberryPi Pico
o the Arduino UNO form factor.
With simple soldering, it can also be used as a board to convert the Rapsberry Pi Pico
to the Arduino UNO form factor.
.. image:: img/rpi_pico_uno_flexypin.png
:align: center

2
boards/silabs/dev_kits/sltb010a/doc/index.rst
View file

@ -149,7 +149,7 @@ BRD4184B:
:goals: flash
.. note::
`west flash` requires `SEGGER J-Link software`_ to be installed on you host
``west flash`` requires `SEGGER J-Link software`_ to be installed on you host
computer.
Open a serial terminal (minicom, putty, etc.) with the following settings:

6
boards/silabs/dev_kits/xg27_dk2602a/doc/index.rst
View file

@ -82,14 +82,14 @@ The simplest way to flash the board is by using West, which runs Simplicity
Commander in unattended mode and passes all the necessary arguments to it.
- If Simplicity Commander is installed in the system and the directory in
which `commander` executable is located is present in the `PATH` environment
which ``commander`` executable is located is present in the :envvar:`PATH` environment
variable:
.. code-block:: console
west flash
- Otherwise, one should specify full path to the `commander` executable:
- Otherwise, one should specify full path to the ``commander`` executable:
.. code-block:: console
@ -114,7 +114,7 @@ Build the Zephyr kernel and application:
:goals: build
Connect your device to your host computer using the USB port and you
should see a USB connection. Use `west`'s flash command
should see a USB connection. Use ``west``'s flash command
Open a serial terminal (minicom, putty, etc.) with the following settings:

3
boards/sparkfun/micromod/doc/index.rst
View file

@ -139,7 +139,7 @@ applications as usual (see :ref:`build_an_application` and
:ref:`application_run` for more details).
The flashing tool will depend on the carrier used along with the board.
In the case of `Sparkfun asset tracking carrier`, it is possible to use
In the case of `Sparkfun asset tracking carrier`_, it is possible to use
the SWD interface along with a J-Link.
Here is an example for the :ref:`hello_world` application.
@ -199,6 +199,7 @@ References
.. target-notes::
.. _Micromod specification website: https://www.sparkfun.com/micromod
.. _Sparkfun asset tracking carrier: https://www.sparkfun.com/products/17272
.. _Micromod nRF52840 guide: https://learn.sparkfun.com/tutorials/micromod-nrf52840-processor-hookup-guide
.. _J-Link Software and documentation pack: https://www.segger.com/jlink-software.html
.. _nRF52840 Product Specification: http://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.0.pdf

4
boards/sparkfun/pro_micro_rp2040/doc/index.rst
View file

@ -119,8 +119,8 @@ The Pro Micro board does make the SWD pins available on pads on the
underside of the board. You can solder to these pins, and use a JTag
debugger. You can also flash the SparkFun ProMicro RP2040 with a UF2 file.
By default, building an app for this board will generate a
`build/zephyr/zephyr.uf2` file. If the Pro Micro RP2040 is powered on with
the `BOOTSEL` button pressed, it will appear on the host as a mass storage
:file:`build/zephyr/zephyr.uf2` file. If the Pro Micro RP2040 is powered on with
the ``BOOTSEL`` button pressed, it will appear on the host as a mass storage
device. The UF2 file should be copied to the device, which will
flash the Pro Micro RP2040.

2
boards/sparkfun/thing_plus/doc/index.rst
View file

@ -92,7 +92,7 @@ In most cases you'll want to use the ``ns`` target with any of the Zephyr
or Nordic based examples.
Some of the examples do not use secure mode, so they do not required the ``ns`` suffix.
A great example of this is the `hello_world` below.
A great example of this is the :ref:`hello_world` below.
Flashing
========

4
boards/st/b_u585i_iot02a/doc/index.rst
View file

@ -220,7 +220,7 @@ The BOARD options are summarized below:
+-------------------------------+-------------------------------------------+
Here are the instructions to build Zephyr with a non-secure configuration,
using `tfm_ipc_` sample:
using :ref:`tfm_ipc` sample:
.. code-block:: bash
@ -236,7 +236,7 @@ option bit TZEN will be set).
$ west flash
Please note that, after having run a TFM sample on the board, you will need to
run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure
run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure
options and get back the platform back to a "normal" state and be able to run
usual, non-TFM, binaries.
Also note that, even then, TZEN will remain set, and you will need to use

6
boards/st/nucleo_l552ze_q/doc/nucleol552ze_q.rst
View file

@ -197,9 +197,9 @@ The BOARD options are summarized below:
+--------------------------------+-------------------------------------------+
Here are the instructions to build Zephyr with a non-secure configuration,
using `tfm_ipc_` sample:
using :ref:`tfm_ipc` sample:
.. code-block:: bash
.. code-block:: console
$ west build -b nucleo_l552ze_q/stm32l552xx/ns samples/tfm_integration/tfm_ipc/
@ -213,7 +213,7 @@ option bit TZEN will be set).
$ west flash
Please note that, after having run a TFM sample on the board, you will need to
run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure
run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure
options and get back the platform back to a "normal" state and be able to run
usual, non-TFM, binaries.
Also note that, even then, TZEN will remain set, and you will need to use

4
boards/st/stm32l562e_dk/doc/index.rst
View file

@ -223,7 +223,7 @@ The BOARD options are summarized below:
+------------------------------+-------------------------------------------+
Here are the instructions to build Zephyr with a non-secure configuration,
using `tfm_ipc_` sample:
using :ref:`tfm_ipc` sample:
.. code-block:: bash
@ -239,7 +239,7 @@ option bit TZEN will be set).
$ west flash
Please note that, after having run a TFM sample on the board, you will need to
run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure
run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure
options and get back the platform back to a "normal" state and be able to run
usual, non-TFM, binaries.
Also note that, even then, TZEN will remain set, and you will need to use

4
boards/st/stm32wb5mm_dk/doc/stm32wb5mm_dk.rst
View file

@ -142,8 +142,8 @@ For compatibility information with the various versions of these binaries,
please check `modules/hal/stm32/lib/stm32wb/hci/README`_
in the ``hal_stm32`` repo.
Note that since STM32WB Cube package V1.13.2, `"full stack"` binaries are not
compatible anymore for a use in Zephyr and only `"HCI Only"` versions should be
Note that since STM32WB Cube package V1.13.2, "full stack" binaries are not
compatible anymore for a use in Zephyr and only "HCI Only" versions should be
used on the M0 side.
Connections and IOs

4
boards/st/stm32wb5mmg/doc/stm32wb5mmg.rst
View file

@ -248,8 +248,8 @@ the ``--runner`` (or ``-r``) option:
$ west flash --runner openocd
Flashing `hci_uart` application to STM32WB5MMG
----------------------------------------------
Flashing ``hci_uart`` application to STM32WB5MMG
------------------------------------------------
Connect the B-U585I-IOT02A to your host computer using the USB port. Put
the SW4 (MCU SWD) in OFF mode and SW5 (SWD BLE) in ON mode. Then build

2
boards/telink/tlsr9518adk80d/doc/index.rst
View file

@ -235,7 +235,7 @@ It is also possible to use the west flash command, but additional steps are requ
Debugging
=========
This port supports UART debug and OpenOCD+GDB. The `west debug` command also supported. You may run
This port supports UART debug and OpenOCD+GDB. The ``west debug`` command also supported. You may run
it in a simple way, like:
.. code-block:: console

10
boards/ti/sk_am62/doc/index.rst
View file

@ -94,16 +94,18 @@ The board can using remoteproc, and uses the OpenAMP resource table to accomplis
The testing requires the binary to be copied to the SD card to allow the A53 cores to load it while booting using remoteproc.
To test the M4F core, we build the `hello_world` sample with the following command.
To test the M4F core, we build the :ref:`hello_world` sample with the following command.
.. code-block:: console
# From the root of the Zephyr repository
west build -p -b sk_am62/am6234/m4 samples/hello_world
This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`.
This builds the program and the binary is present in the :file:`build/zephyr` directory as
:file:`zephyr.elf`.
We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am62-mcu-m4f0_0-fw`.
We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as
:file:`am62-mcu-m4f0_0-fw`.
.. code-block:: console
@ -122,7 +124,7 @@ The binary will run and print Hello world to the MCU_UART0 port.
Debugging
*********
The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the `debug` build target:
The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the ``debug`` build target:
.. zephyr-app-commands::
:app: <my_app>

24
boards/wiznet/w5500_evb_pico/doc/index.rst
View file

@ -165,7 +165,7 @@ Create a file in /etc/udev.rules.d with any name, and write the line below.
ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess"
This example is valid for the case that the user joins to `plugdev` groups.
This example is valid for the case that the user joins to ``plugdev`` groups.
The Raspberry Pi Pico, and thus the W55500 Evaluation Board, has an SWD
interface that can be used to program and debug the on board RP2040. This
@ -189,26 +189,26 @@ application.
:goals: build flash
:gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=picoprobe
Set the environment variables **OPENOCD** to `/usr/local/bin/openocd` and
**OPENOCD_DEFAULT_PATH** to `/usr/local/share/openocd/scripts`. This should
Set the environment variables **OPENOCD** to :file:`/usr/local/bin/openocd` and
**OPENOCD_DEFAULT_PATH** to :file:`/usr/local/share/openocd/scripts`. This should
work with the OpenOCD that was installed with the default configuration. This
configuration also works with an environment that is set up by the
`pico_setup.sh`_ script.
**RPI_PICO_DEBUG_ADAPTER** specifies what debug adapter is used for debugging.
If **RPI_PICO_DEBUG_ADAPTER** was not assigned, `picoprobe` is used by default.
The other supported adapters are `raspberrypi-swd`, `jlink` and
`blackmagicprobe`. How to connect `picoprobe` and `raspberrypi-swd` is
If **RPI_PICO_DEBUG_ADAPTER** was not assigned, ``picoprobe`` is used by default.
The other supported adapters are ``raspberrypi-swd``, ``jlink`` and
``blackmagicprobe``. How to connect ``picoprobe`` and ``raspberrypi-swd`` is
described in `Getting Started with Raspberry Pi Pico`_. Any other SWD debug
adapter maybe also work with this configuration.
The value of **RPI_PICO_DEBUG_ADAPTER** is cached, so it can be omitted from
`west flash` and `west debug` if it was previously set while running
`west build`.
``west flash`` and ``west debug`` if it was previously set while running
``west build``.
**RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as
`"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"`. Thus,
``"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"``. Thus,
**RPI_PICO_DEBUG_ADAPTER** needs to be assigned the file name of the debug
adapter.
@ -224,7 +224,7 @@ Using UF2
If you don't have an SWD adapter, you can flash the Raspberry Pi Pico with
a UF2 file. By default, building an app for this board will generate a
`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the `BOOTSEL`
:file:`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the ``BOOTSEL``
button pressed, it will appear on the host as a mass storage device. The
UF2 file should be drag-and-dropped to the device, which will flash the Pico.
@ -256,8 +256,8 @@ Here is an example for debugging the :zephyr:code-sample:`blinky` application.
:gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=raspberrypi-swd
As with flashing, you can specify the debug adapter by specifying
**RPI_PICO_DEBUG_ADAPTER** at `west build` time. No needs to specify it at
`west debug` time.
**RPI_PICO_DEBUG_ADAPTER** at ``west build`` time. No needs to specify it at
``west debug`` time.
You can also debug with OpenOCD and gdb launching from command-line.
Run the following command:

24
doc/connectivity/bluetooth/api/audio/bluetooth-le-audio-arch.rst
View file

@ -22,14 +22,14 @@ The overall design of the LE Audio stack is that the implementation follows the
as closely as possible,
both in terms of structure but also naming.
Most API functions are prefixed by the specification acronym
(e.g. `bt_bap` for the Basic Audio Profile (BAP) and `bt_vcp` for the Volume Control Profile (VCP)).
The functions are then further prefixed with the specific role from each profile where applicable
(e.g. :c:func:`bt_bap_unicast_client_discover` and :c:func:`bt_vcp_vol_rend_set_vol`).
(e.g. ``bt_bap`` for the Basic Audio Profile (BAP) and ``bt_vcp`` for the Volume Control Profile
(VCP)). The functions are then further prefixed with the specific role from each profile where
applicable (e.g. :c:func:`bt_bap_unicast_client_discover` and :c:func:`bt_vcp_vol_rend_set_vol`).
There are usually a function per procedure defined by the profile or service specifications,
and additional helper or meta functions that do not correspond to procedures.
The structure of the files generally also follow this,
where BAP related files are prefixed with `bap` and VCP related files are prefixed with `vcp`.
where BAP related files are prefixed with ``bap`` and VCP related files are prefixed with ``vcp``.
If the file is specific for a profile role, the role is also embedded in the file name.
Generic Audio Framework (GAF)
@ -1065,8 +1065,8 @@ but the GTBS instance will report 2 calls,
making it possible for a simple Call Control Client to control all calls from a single bearer.
Similarly the supported URIs for each bearer are also made into a union in GTBS, and when placing
a call using the GTBS the server will pick the most suited bearer depending on the URI.
For example calls with URI `tel` would go to the regular phone application,
and calls with the URI `skype` would go to the Teams application.
For example calls with URI ``tel`` would go to the regular phone application,
and calls with the URI ``skype`` would go to the Teams application.
In conclusion the GTBS implementation in Zephyr is a union of the non-generic telephone bearers.
@ -1175,8 +1175,8 @@ the data is kept in and controlled by the application.
As a rule of thumb, the return types of the callbacks for each profile implementation indicate
whether the data is controlled by the stack or the application.
For example all the callbacks for the VCP Volume Renderer have the return type of `void`,
but the return type of the BAP Unicast Server callbacks are `int`,
For example all the callbacks for the VCP Volume Renderer have the return type of ``void``,
but the return type of the BAP Unicast Server callbacks are ``int``,
indicating that the application not only controls a lot of the Unicast Server data,
but can also reject the requests.
The choice of what the return type of the callbacks often depend on the specifications,
@ -1202,7 +1202,7 @@ In Zephyr we do not force the device to always use these, as a device that uses
use other profiles and services that do not require such security.
We guard all access to services using a custom security check implemented in
:zephyr_file:`subsys/bluetooth/audio/audio.c`, where all LE Audio services must use the
internal `BT_AUDIO_CHRC` macro for proper security verification.
internal :c:macro:`BT_AUDIO_CHRC` macro for proper security verification.
Access to the LTK for encrypted SIRKs in CSIS
---------------------------------------------
@ -1235,10 +1235,10 @@ The LE audio channel on Discord
Zephyr has a specific Discord channel for LE Audio development, which is open to all.
Find it here at https://discordapp.com/channels/720317445772017664/1207326649591271434 or simply
search for `ble-audio` from within Discord.
Since the `ble-audio` channel is open for all,
search for "ble-audio" from within Discord.
Since the ``#ble-audio`` channel is open for all,
we cannot discuss any specifications that are in development in that channel.
For discussions that require a Bluetooth SIG membership we refer to the `bluetooth-sig`
For discussions that require a Bluetooth SIG membership we refer to the ``#bluetooth-sig``
Discord channel found at https://discordapp.com/channels/720317445772017664/869172014018097162.
Zephyr weekly meetings

2
doc/connectivity/bluetooth/bluetooth-shell.rst
View file

@ -218,7 +218,7 @@ Extended Advertising
====================
Let's now have a look at some extended advertising features. To enable extended advertising, use the
`ext-adv` parameter.
``ext-adv`` parameter.
.. code-block:: console

8
doc/connectivity/networking/api/coap_client.rst
View file

@ -52,10 +52,10 @@ The callback provided in the callback will be called in following cases:
- There is a response for the request
- The request failed for some reason
The callback contains a flag `last_block`, which indicates if there is more data to come in the
response and means that the current response is part of a blockwise transfer. When the `last_block`
is set to true, the response is finished and the client is ready for the next request after
returning from the callback.
The callback contains a flag ``last_block``, which indicates if there is more data to come in the
response and means that the current response is part of a blockwise transfer. When the
``last_block`` is set to true, the response is finished and the client is ready for the next request
after returning from the callback.
If the server responds to the request, the library provides the response to the
application through the response callback registered in the request structure.

2
doc/connectivity/networking/api/tls_credentials_shell.rst
View file

@ -206,7 +206,7 @@ After the list is printed, a final summary of the found credentials will be prin
<N> credentials found.
Where `<N>` is the number of credentials found, and is zero if none are found.
Where ``<N>`` is the number of credentials found, and is zero if none are found.
.. _tls_credentials_shell_cred_types:

11
doc/connectivity/networking/api/wifi.rst
View file

@ -18,7 +18,8 @@ Only personal mode security is supported with below types:
* WPA3-PSK-256
* WPA3-SAE
The Wi-Fi management API is implemented in the `wifi_mgmt` module as a part of the networking L2 stack.
The Wi-Fi management API is implemented in the ``wifi_mgmt`` module as a part of the networking L2
stack.
Currently, two types of Wi-Fi drivers are supported:
* Networking or socket offloaded drivers
@ -29,7 +30,7 @@ Wi-Fi Enterprise test: X.509 Certificate header generation
Wi-Fi enterprise security requires use of X.509 certificates, test certificates
in PEM format are committed to the repo at :zephyr_file:`samples/net/wifi/test_certs` and the during the
build process the certificates are converted to a `C` header file that is included by the Wi-Fi shell
build process the certificates are converted to a C header file that is included by the Wi-Fi shell
module.
.. code-block:: bash
@ -46,16 +47,16 @@ To initiate Wi-Fi connection, the following command can be used:
uart:~$ wifi connect -s <SSID> -k 5 -a anon -K whatever
Server certificate is also provided in the same directory for testing purposes.
Any `AAA` server can be used for testing purposes, for example, `FreeRADIUS` or `hostapd`.
Any AAA server can be used for testing purposes, for example, ``FreeRADIUS`` or ``hostapd``.
.. important::
The passphrase for the client-key.pem and the server-key.pem is `whatever`.
The passphrase for the :file:`client-key.pem`` and the :file:`server-key.pem` is ``whatever``.
.. note::
The certificates are for testing purposes only and should not be used in production.
The certificates are generated using `FreeRADIUS raddb <https://github.com/FreeRADIUS/freeradius-server/tree/master/raddb/certs> _` scripts.
They are generated using `FreeRADIUS raddb <https://github.com/FreeRADIUS/freeradius-server/tree/master/raddb/certs>`_ scripts.
API Reference
*************

2
doc/connectivity/usb/device_next/usb_device.rst
View file

@ -30,7 +30,7 @@ The USB device stack has built-in USB functions. Some can be used directly in
the user application through a special API, such as HID or Audio class devices,
while others use a general Zephyr RTOS driver API, such as MSC and CDC class
implementations. The *Identification string* identifies a class or function
instance (`n`) and is used as an argument to the :c:func:`usbd_register_class`.
instance (``n``) and is used as an argument to the :c:func:`usbd_register_class`.
+-----------------------------------+-------------------------+-------------------------+
| Class or function | User API (if any) | Identification string |

2
doc/contribute/index.rst
View file

@ -27,7 +27,7 @@ General Guidelines
merged.
:ref:`contributor-expectations`
This document is another mandatory read that describes the expected behavior of `all`
This document is another mandatory read that describes the expected behavior of *all*
contributors to the project.
:ref:`coding_guidelines`

2
doc/develop/debug/index.rst
View file

@ -291,7 +291,7 @@ Debugging I2C communication
There is a possibility to log all or some of the I2C transactions done by the application.
This feature is enabled by the Kconfig option :kconfig:option:`CONFIG_I2C_DUMP_MESSAGES`, but it
uses the ``LOG_DBG`` function to print the contents so the
uses the :c:macro:`LOG_DBG` function to print the contents so the
:kconfig:option:`CONFIG_I2C_LOG_LEVEL_DBG` option must also be enabled.
The sample output of the dump looks like this::

4
doc/develop/manifest/index.rst
View file

@ -12,7 +12,7 @@ Active Projects/Modules
+++++++++++++++++++++++
The projects below are enabled by default and will be downloaded when you
call `west update`. Many of the projects or modules listed below are
call :command:`west update`. Many of the projects or modules listed below are
essential for building generic Zephyr application and include among others
hardware support for many of the platforms available in Zephyr.
@ -30,7 +30,7 @@ Inactive and Optional Projects/Modules
The projects below are optional and will not be downloaded when you
call `west update`. You can add any of the projects or modules listed below
call :command:`west update`. You can add any of the projects or modules listed below
and use them to write application code and extend your workspace with the added
functionality.

6
doc/develop/modules.rst
View file

@ -52,7 +52,7 @@ In summary:
Modules are repositories that contain a :file:`zephyr/module.yml` file, so that
the Zephyr build system can pull in the source code from the repository.
:ref:`West projects <west-manifests-projects>` are entries in the `projects:`
:ref:`West projects <west-manifests-projects>` are entries in the ``projects:``
section in the :file:`west.yml` manifest file.
West projects are often also modules, but not always. There are west projects
that are not included in the final firmware image (eg. tools) and thus do not
@ -545,7 +545,7 @@ The ``sysbuild-cmake: <cmake-directory>`` part specifies that
use.
Here is an example :file:`module.yml` file referring to
:file:`CMakeLists.txt` and :file:`Kconfig` files in the `sysbuild` directory of
:file:`CMakeLists.txt` and :file:`Kconfig` files in the ``sysbuild`` directory of
the module:
.. code-block:: yaml
@ -592,7 +592,7 @@ be monitored for your module. The supported formats are:
- <an-other-module-related-cpe>
- <module-related-purl>
A real life example for `mbedTLS` module could look like this:
A real life example for ``mbedTLS`` module could look like this:
.. code-block:: yaml

2
doc/develop/test/pytest.rst
View file

@ -14,7 +14,7 @@ Pytest is a python framework that *“makes it easy to write small, readable tes
support complex functional testing for applications and libraries”* (`<https://docs.pytest.org/en/7.3.x/>`_).
Python is known for its free libraries and ease of using it for scripting. In addition, pytest
utilizes the concept of plugins and fixtures, increasing its expendability and reusability.
A pytest plugin `pytest-twister-harness` was introduced to provide an integration between pytest
A pytest plugin ``pytest-twister-harness`` was introduced to provide an integration between pytest
and twister, allowing Zephyr’s community to utilize pytest functionality with keeping twister as
the main framework.

20
doc/develop/test/twister.rst
View file

@ -261,11 +261,11 @@ test application and has to follow basic rules:
two sections:
* Ztest tests: The individual test cases in the ztest testsuite will be
concatenated by dot (`.`) to the identifier in the ``testcase.yaml`` file
concatenated by dot (``.``) to the identifier in the ``testcase.yaml`` file
generating unique identifiers for every test case in the suite.
* Standalone tests and samples: This type of test should at least have 3
sections concatnated by dot (`.`) in the test scenario identifier in the
sections concatnated by dot (``.``) in the test scenario identifier in the
``testcase.yaml`` (or ``sample.yaml``) file.
The last section of the name shall signify the test case itself.
@ -851,10 +851,10 @@ Command line arguments define the initial scope in the following way:
* ``-l/--all``: all available platforms;
* ``-G/--integration``: all platforms from an ``integration_platforms`` list in
a given test configuration file. If a test has no ``integration_platforms``
`"scope presumption"` will happen;
* No scope argument: `"scope presumption"` will happen.
*"scope presumption"* will happen;
* No scope argument: *"scope presumption"* will happen.
`"Scope presumption"`: A list of Twister's :ref:`default platforms <twister_default_testing_board>`
*"Scope presumption"*: A list of Twister's :ref:`default platforms <twister_default_testing_board>`
is used as the initial list. If nothing is left after the filtration, the ``platform_allow`` list
is used as the initial scope.
@ -1338,7 +1338,7 @@ locally. As of now, those options are available:
CI)
- Option to specify your own list of default platforms overriding what
upstream defines.
- Ability to override `build_on_all` options used in some test scenarios.
- Ability to override ``build_on_all`` options used in some test scenarios.
This will treat tests or sample as any other just build for default
platforms you specify in the configuration file or on the command line.
- Ignore some logic in twister to expand platform coverage in cases where
@ -1350,16 +1350,16 @@ Platform Configuration
The following options control platform filtering in twister:
- `override_default_platforms`: override default key a platform sets in board
- ``override_default_platforms``: override default key a platform sets in board
configuration and instead use the list of platforms provided in the
configuration file as the list of default platforms. This option is set to
False by default.
- `increased_platform_scope`: This option is set to True by default, when
- ``increased_platform_scope``: This option is set to True by default, when
disabled, twister will not increase platform coverage automatically and will
only build and run tests on the specified platforms.
- `default_platforms`: A list of additional default platforms to add. This list
- ``default_platforms``: A list of additional default platforms to add. This list
can either be used to replace the existing default platforms or can extend it
depending on the value of `override_default_platforms`.
depending on the value of ``override_default_platforms``.
And example platforms configuration:

2
doc/develop/test/ztest.rst
View file

@ -600,7 +600,7 @@ By default the tests are sorted and ran in alphanumerical order. Test cases may
be dependent on this sequence. Enable :kconfig:option:`CONFIG_ZTEST_SHUFFLE` to
randomize the order. The output from the test will display the seed for failed
tests. For native simulator builds you can provide the seed as an argument to
twister with `--seed`
twister with ``--seed``.
Static configuration of ZTEST_SHUFFLE contains:

2
doc/develop/tools/vscode.rst
View file

@ -17,7 +17,7 @@ Get VS Code
`Download VS Code`_ and install it.
Install the required extensions through the `Extensions` marketplace in the left panel.
Install the required extensions through the :guilabel:`Extensions` marketplace in the left panel.
Search for the `C/C++ Extension Pack`_ and install it.
Initialize a new workspace

2
doc/develop/west/sign.rst
View file

@ -116,7 +116,7 @@ for all images, for example:
west build -b <board> <application> -DSIGNING_SCRIPT=<file>
The zephyr property method is achieved by adjusting the ``SIGNING_SCRIPT`` property
on the `zephyr_property_target`, ideally from by a module by using:
on the ``zephyr_property_target``, ideally from by a module by using:
.. code-block:: cmake

2
doc/glossary.rst
View file

@ -60,7 +60,7 @@ Glossary of Terms
See :ref:`board_terminology` for additional details.
board qualifiers
The set of additional tokens, separated by a forward slash (`/`) that
The set of additional tokens, separated by a forward slash (``/``) that
follow the :term:`board name` (and optionally :term:`board revision`) to
form the :term:`board target`. The currently accepted qualifiers are
:term:`SoC`, :term:`CPU cluster` and :term:`variant`.

6
doc/hardware/arch/risc-v.rst
View file

@ -23,7 +23,7 @@ ISA extensions
**************
It's possible to set in Zephyr which ISA extensions (RV32/64I(E)MAFD(G)QC)
are available on a given platform, by setting the appropriate `RISCV_ISA_*`
are available on a given platform, by setting the appropriate ``CONFIG_RISCV_ISA_*``
kconfig. Look at :file:`arch/riscv/Kconfig.isa` for more information.
Note that Zephyr SDK toolchain support may not be defined for all
@ -33,5 +33,5 @@ SMP support
***********
SMP is supported on RISC-V, but currently only on Qemu platforms. In
order to test the SMP support, one can use `qemu_riscv32_smp` or
`qemu_riscv64_smp` boards.
order to test the SMP support, one can use ``qemu_riscv32_smp`` or
``qemu_riscv64_smp`` boards.

2
doc/hardware/emulator/bus_emulators.rst
View file

@ -73,7 +73,7 @@ an emulator instance using one of the :c:func:`EMUL_DT_DEFINE()` or
:c:func:`EMUL_DT_INST_DEFINE()` APIs.
Emulators for peripheral devices reuse the same devicetree node as the real
device driver. This means that your emulator defines `DT_DRV_COMPAT` using the
device driver. This means that your emulator defines ``DT_DRV_COMPAT`` using the
same ``compat`` value from the real driver.
.. code-block:: C

6
doc/hardware/peripherals/uart.rst
View file

@ -14,9 +14,9 @@ on the method, different API functions are used according to below sections:
3. :ref:`uart_async_api` using :ref:`dma_api`
Polling is the most basic method to access the UART peripheral. The reading
function, `uart_poll_in`, is a non-blocking function and returns a character
or `-1` when no valid data is available. The writing function,
`uart_poll_out`, is a blocking function and the thread waits until the given
function, :c:func:`uart_poll_in`, is a non-blocking function and returns a character
or ``-1`` when no valid data is available. The writing function,
:c:func:`uart_poll_out`, is a blocking function and the thread waits until the given
character is sent.
With the Interrupt-driven API, possibly slow communication can happen in the

2
doc/kernel/object_cores/index.rst
View file

@ -13,7 +13,7 @@ perform operations on registered objects.
Object Core Concepts
********************
Each instance of an object embeds an object core field named `obj_core`.
Each instance of an object embeds an object core field named ``obj_core``.
Objects of the same type are linked together via their respective object
cores to form a singly linked list. Each object core also links to the their
respective object type. Each object type contains a singly linked list

8
doc/kernel/services/interrupts.rst
View file

@ -604,8 +604,8 @@ If this configuration is supported by the used architecture and toolchaing the
:kconfig:option:`ISR_TABLES_LOCAL_DECLARATION_SUPPORTED` is set.
See details of this option for the information about currently supported configurations.
Any invocation of :c:macro:`IRQ_CONNECT` or `IRQ_DIRECT_CONNECT` will declare an instance of struct
_isr_list_sname which is placde in a special .intList section:
Any invocation of :c:macro:`IRQ_CONNECT` or :c:macro:`IRQ_DIRECT_CONNECT` will declare an instance
of ``struct _isr_list_sname`` which is placed in a special .intList section:
.. code-block:: c
@ -619,7 +619,7 @@ _isr_list_sname which is placde in a special .intList section:
};
Note that the section name is placed in flexible array member.
It means that the size of the initialized structure will warry depending on the
It means that the size of the initialized structure will vary depending on the
structure name length.
The whole entry is used by the script during the build of the application
and has all the information needed for proper interrupt placement.
@ -720,7 +720,7 @@ aggregator. In this case it may be desirable to override these defaults and use
number of bits per level. Regardless of how many bits used for each level, the sum of
the total bits used between all levels must sum to be less than or equal to 32-bits,
fitting into a single 32-bit integer. To modify the bit total per level, override the
default 8 in `Kconfig.multilevel` by setting :kconfig:option:`CONFIG_1ST_LEVEL_INTERRUPT_BITS`
default 8 in :file:`Kconfig.multilevel` by setting :kconfig:option:`CONFIG_1ST_LEVEL_INTERRUPT_BITS`
for the first level, :kconfig:option:`CONFIG_2ND_LEVEL_INTERRUPT_BITS` for the second level and
:kconfig:option:`CONFIG_3RD_LEVEL_INTERRUPT_BITS` for the third level. These masks control the
length of the bit masks and shift to apply when generating interrupt values, when checking the

2
doc/project/release_process.rst
View file

@ -127,7 +127,7 @@ feature freeze milestone. An issue labeled as a blocker practically blocks a
release from happening. All blocker bugs shall be resolved before a release is
created.
A fix for a bug that is granted `blocker` status can be merged to 'main' and included in
A fix for a bug that is granted ``blocker`` status can be merged to 'main' and included in
the release all the way until the final release date.
Bugs of moderate severity and higher that have impact on all users are typically

2
doc/releases/index.rst
View file

@ -73,7 +73,7 @@ Release Notes
Release notes contain a list of changes that have been made to the different
areas of the project during the development cycle of the release.
Changes that require the user to modify their own application to support the new
release may be mentioned in the release notes, but the details regarding `what`
release may be mentioned in the release notes, but the details regarding *what*
needs to be changed are to be detailed in the release's migration guide.
.. toctree::

10
doc/releases/migration-guide-4.0.rst
View file

@ -30,14 +30,14 @@ Boards
to define default flash and ram partitioning based on TF-M.
* STM32WBA: The command used for fetching blobs required to build ble applications is now
`west blobs fetch hal_stm32` instead of `west blobs fetch stm32`.
``west blobs fetch hal_stm32`` instead of ``west blobs fetch stm32``.
STM32
=====
* On all official STM32 boards, `west flash` selects STM32CubeProgrammer as the default west runner.
* On all official STM32 boards, ``west flash`` selects STM32CubeProgrammer as the default west runner.
If you want to enforce the selection of another runner like OpenOCD or pyOCD for flashing, you should
specify it using the west `--runner` or `-r` option. (:github:`75284`)
specify it using the west ``--runner`` or ``-r`` option. (:github:`75284`)
Modules
*******
@ -69,10 +69,10 @@ zcbor
Migration guide at https://github.com/NordicSemiconductor/zcbor/blob/0.9.0/MIGRATION_GUIDE.md
Migration guide copied here:
* `zcbor_simple_*()` functions have been removed to avoid confusion about their use.
* ``zcbor_simple_*()`` functions have been removed to avoid confusion about their use.
They are still in the C file because they are used by other functions.
Instead, use the specific functions for the currently supported simple values, i.e.
`zcbor_bool_*()`, `zcbor_nil_*()`, and `zcbor_undefined_*()`.
``zcbor_bool_*()``, ``zcbor_nil_*()``, and ``zcbor_undefined_*()``.
If a removed variant is strictly needed, add your own forward declaration in your code.
* Code generation naming:

4
doc/releases/release-notes-4.0.rst
View file

@ -68,8 +68,8 @@ Architectures
has an additional field ``csf`` that points to the callee-saved-registers upon an fatal error,
which can be accessed in :c:func:`k_sys_fatal_error_handler` by ``esf->csf``.
* For SoCs that select `RISCV_SOC_HAS_ISR_STACKING`, the `SOC_ISR_STACKING_ESF_DECLARE` has to
include the `csf` member, otherwise the build would fail.
* For SoCs that select ``RISCV_SOC_HAS_ISR_STACKING``, the ``SOC_ISR_STACKING_ESF_DECLARE`` has to
include the ``csf`` member, otherwise the build would fail.
* Xtensa

2
doc/security/standards/etsi-303645.rst
View file

@ -4,7 +4,7 @@ ETSI 303-645
############
`ETSI EN 303 645`, also known as "Cyber Security for Consumer Internet
**ETSI EN 303 645**, also known as "Cyber Security for Consumer Internet
of Things: Baseline Requirements," is a standard developed by the
European Telecommunications Standards Institute (ETSI).

8
doc/services/device_mgmt/ec_host_cmd.rst
View file

@ -76,7 +76,7 @@ SoCs, modify the compatible string as shown.
...
};
The chip that runs Zephyr is a SPI slave and the `cs-gpios` property is used to point our CS pin.
The chip that runs Zephyr is a SPI slave and the ``cs-gpios`` property is used to point our CS pin.
For the SPI, it is required to set the backend chosen node ``zephyr,host-cmd-spi-backend``.
The supported backend and peripheral drivers:
@ -120,10 +120,10 @@ Logging
The host command has an embedded logging system of the ongoing communication. The are a few logging
levels:
* `LOG_INF` is used to log a command id of a new command and not success responses. Repeats of the
* :c:macro:`LOG_INF` is used to log a command id of a new command and not success responses. Repeats of the
same command are not logged
* `LOG_DBG` logs every command, even repeats
* `LOG_DBG` + :kconfig:option:`CONFIG_EC_HOST_CMD_LOG_DBG_BUFFERS` logs every command and responses
* :c:macro:`LOG_DBG` logs every command, even repeats
* :c:macro:`LOG_DBG` + :kconfig:option:`CONFIG_EC_HOST_CMD_LOG_DBG_BUFFERS` logs every command and responses
with the data buffers
API Reference

2
doc/services/device_mgmt/smp_groups/smp_group_0.rst
View file

@ -546,7 +546,7 @@ the :kconfig:option:`CONFIG_MCUMGR_GRP_OS_RESET_HOOK` is enabled and an
application registers a callback, the callback will be called when this command
is issued and can be used to perform any necessary tidy operations prior to the
module rebooting, or to reject the reset request outright altogether with an
error response. For details on this functionality, see `ref:`mcumgr_callbacks`.
error response. For details on this functionality, see :ref:`mcumgr_callbacks`.
System reset request
====================

4
doc/services/device_mgmt/smp_transport.rst
View file

@ -14,8 +14,8 @@ BLE (Bluetooth Low Energy)
MCUmgr Clients need to use following BLE Characteristics, when implementing
SMP client:
- **Service UUID**: `8D53DC1D-1DB7-4CD3-868B-8A527460AA84`
- **Characteristic UUID**: `DA2E7828-FBCE-4E01-AE9E-261174997C48`
- **Service UUID**: ``8D53DC1D-1DB7-4CD3-868B-8A527460AA84``
- **Characteristic UUID**: ``DA2E7828-FBCE-4E01-AE9E-261174997C48``
All SMP communication utilizes a single GATT characteristic. An SMP request is
sent via a GATT Write Without Response command. An SMP response is sent in the form

2
doc/services/input/gpio-kbd.rst
View file

@ -171,7 +171,7 @@ Actual key mask configuration
*****************************
If the key matrix is not complete, a map of the keys that are actually
populated can be specified using the `actual-key-mask` property. This allows
populated can be specified using the ``actual-key-mask`` property. This allows
the matrix state to be filtered to remove keys that are not present before
ghosting detection, potentially allowing key combinations that would otherwise
be blocked by it.

8
doc/services/llext/build.rst
View file

@ -112,18 +112,18 @@ The different build steps are:
``PRE_BUILD``
Before the extension code is linked, if the architecture uses dynamic
libraries. This step can access `lib_target` and its own properties.
libraries. This step can access ``lib_target`` and its own properties.
``POST_BUILD``
After the extension code is built, but before packaging it in an ``.llext``
file. This step is expected to create a `pkg_input` file by reading the
contents of `lib_output`.
file. This step is expected to create a :file:`pkg_input` file by reading the
contents of :file:`lib_output`.
``POST_PKG``
After the extension output file has been created. The command can operate
on the final llext file `pkg_output`.
on the final llext file :file:`pkg_output`.
Anything else after ``COMMAND`` will be passed to ``add_custom_command()`` as-is
(including multiple commands and other options).

2
doc/services/llext/config.rst
View file

@ -104,7 +104,7 @@ significant as the number of exported symbols increases.
Perform an extra processing step on the Zephyr binary and on all
extensions being built, converting every string in the symbol tables to
a pointer-sized hash called `Symbol Link Identifier` (SLID), which is
a pointer-sized hash called Symbol Link Identifier (SLID), which is
stored in the binary.
This speeds up the symbol lookup process by allowing usage of

2
doc/services/logging/index.rst
View file

@ -500,7 +500,7 @@ backends.
In some cases, logs need to be redirected at the macro level. For these cases,
:kconfig:option:`CONFIG_LOG_CUSTOM_HEADER` can be used to inject an application provided
header named `zephyr_custom_log.h` at the end of :zephyr_file:`include/zephyr/logging/log.h`.
header named :file:`zephyr_custom_log.h` at the end of :zephyr_file:`include/zephyr/logging/log.h`.
Frontend using ARM Coresight STM (System Trace Macrocell)
---------------------------------------------------------

4
doc/services/mem_mgmt/index.rst
View file

@ -66,8 +66,8 @@ and act on regions and attributes (see next section for more details).
A test for the ``mem-attr`` library and its usage is provided in
``tests/subsys/mem_mgmt/mem_attr/``.
Migration guide from `zephyr,memory-region-mpu`
***********************************************
Migration guide from ``zephyr,memory-region-mpu``
*************************************************
When the ``zephyr,memory-attr`` property was introduced, the
``zephyr,memory-region-mpu`` property was removed and deprecated.

2
doc/services/pm/device_runtime.rst
View file

@ -32,7 +32,7 @@ in response to :c:func:`pm_device_runtime_get` and :c:func:`pm_device_runtime_pu
calls on the child device.
For the previous to automatically control the power domain state, device runtime PM must be enabled
on the power domain device (either through the `zephyr,pm-device-runtime-auto` devicetree property
on the power domain device (either through the ``zephyr,pm-device-runtime-auto`` devicetree property
or :c:func:`pm_device_runtime_enable`).
.. graphviz::

4
doc/services/portability/posix/conformance/index.rst
View file

@ -3,7 +3,9 @@
POSIX Conformance
#################
As per `IEEE 1003.1-2017`, this section details Zephyr's POSIX conformance.
As per `IEEE 1003.1-2017`_, this section details Zephyr's POSIX conformance.
.. _IEEE 1003.1-2017: https://standards.ieee.org/ieee/1003.1/7101/
.. _posix_system_interfaces:

2
doc/services/storage/flash_map/flash_map.rst
View file

@ -32,7 +32,7 @@ Most ``<zephyr/storage/flash_map.h>`` API functions require a :c:struct:`flash_a
characterizing the flash area they will be working on. There are two possible
methods to obtain such a pointer:
* obtain it using `flash_area_open`;
* obtain it using :c:func:`flash_area_open`;
* defining a :c:struct:`flash_area` type object, which requires providing
a valid :c:struct:`device` object pointer with offset and size of the area

2
doc/services/tracing/index.rst
View file

@ -365,7 +365,7 @@ To enable tracing support with `SEGGER SystemView`_ add the configuration option
it to *y*. For example, this can be added to the
:zephyr:code-sample:`synchronization` sample to visualize fast switching between threads.
SystemView can also be used for post-mortem tracing, which can be enabled with
`CONFIG_SEGGER_SYSVIEW_POST_MORTEM_MODE`. In this mode, a debugger can
:kconfig:option:`CONFIG_SEGGER_SYSVIEW_POST_MORTEM_MODE`. In this mode, a debugger can
be attached after the system has crashed using ``west attach`` after which the
latest data from the internal RAM buffer can be loaded into SystemView::

7
doc/services/zbus/index.rst
View file

@ -380,7 +380,8 @@ Limitations
Based on the fact that developers can use zbus to solve many different problems, some challenges
arise. ZBus will not solve every problem, so it is necessary to analyze the situation to be sure
zbus is applicable. For instance, based on the zbus benchmark, it would not be well suited to a
high-speed stream of bytes between threads. The `Pipe` kernel object solves this kind of need.
high-speed stream of bytes between threads. The :ref:`Pipe <pipes_v2>` kernel object solves this
kind of need.
Delivery guarantees
-------------------
@ -524,12 +525,12 @@ sequence of the static observers.
notified.
Channels can have a `validator function` that enables a channel to accept only valid messages.
Channels can have a *validator function* that enables a channel to accept only valid messages.
Publish attempts invalidated by hard channels will return immediately with an error code. This
allows original creators of a channel to exert some authority over other developers/publishers who
may want to piggy-back on their channels. The following code defines and initializes a :dfn:`hard
channel` and its dependencies. Only valid messages can be published to a :dfn:`hard channel`. It is
possible because a `validator function` was passed to the channel's definition. In this example,
possible because a *validator function* was passed to the channel's definition. In this example,
only messages with ``move`` equal to 0, -1, and 1 are valid. Publish function will discard all other
values to ``move``.

10
samples/bluetooth/bap_broadcast_sink/README.rst
View file

@ -16,9 +16,9 @@ This sample can be found under
Check the :ref:`bluetooth samples section <bluetooth-samples>` for general information.
Use `CONFIG_TARGET_BROADCAST_NAME` Kconfig to specify the name (CONFIG_BT_DEVICE_NAME)
of a broadcast source to listen to. With default value (empty string), sink
device will listen to all available broadcast sources.
Use :kconfig:option:`CONFIG_TARGET_BROADCAST_NAME` Kconfig to specify the name
(:kconfig:option:`CONFIG_BT_DEVICE_NAME`) of a broadcast source to listen to. With default value
(empty string), sink device will listen to all available broadcast sources.
Requirements
************
@ -30,7 +30,7 @@ Building and Running
********************
When building targeting an nrf52 series board with the Zephyr Bluetooth Controller,
use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO
use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO
feature support.
Building for an nrf5340dk
@ -67,7 +67,7 @@ Similarly to how you would for real HW, you can do:
:goals: build
:west-args: --sysbuild
Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
For more information, check :ref:`this board documentation <nrf5340bsim>`.
Building for a simulated nrf52_bsim

4
samples/bluetooth/bap_broadcast_source/README.rst
View file

@ -29,7 +29,7 @@ Building and Running
********************
When building targeting an nrf52 series board with the Zephyr Bluetooth Controller,
use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO
use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO
feature support.
Building for an nrf5340dk
@ -66,7 +66,7 @@ Similarly to how you would for real HW, you can do:
:goals: build
:west-args: --sysbuild
Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
For more information, check :ref:`this board documentation <nrf5340bsim>`.
Building for a simulated nrf52_bsim

4
samples/bluetooth/bap_unicast_client/README.rst
View file

@ -25,7 +25,7 @@ Building and Running
********************
When building targeting an nrf52 series board with the Zephyr Bluetooth Controller,
use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO
use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO
feature support.
Building for an nrf52840dk
@ -71,7 +71,7 @@ Similarly to how you would for real HW, you can do:
:goals: build
:gen-args: -DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf
Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
For more information, check :ref:`this board documentation <nrf52_bsim>`.
Building for a simulated nrf5340bsim

4
samples/bluetooth/bap_unicast_server/README.rst
View file

@ -25,7 +25,7 @@ Building and Running
********************
When building targeting an nrf52 series board with the Zephyr Bluetooth Controller,
use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO
use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO
feature support.
Building for an nrf52840dk
@ -71,7 +71,7 @@ Similarly to how you would for real HW, you can do:
:goals: build
:gen-args: -DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf
Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
For more information, check :ref:`this board documentation <nrf52_bsim>`.
Building for a simulated nrf5340bsim

4
samples/bluetooth/broadcaster_multiple/README.rst
View file

@ -12,11 +12,11 @@ uses multiple advertising sets functionality.
This sample advertises two non-connectable non-scannable advertising sets with
two different SID. Number of advertising sets can be increased by updating the
`CONFIG_BT_EXT_ADV_MAX_ADV_SET` value in the project configuration file.
:kconfig:option:`CONFIG_BT_EXT_ADV_MAX_ADV_SET` value in the project configuration file.
When building this sample combined with a Bluetooth LE Controller, the
advertising data length can be increased from the default 31 bytes by updating
the Controller's `CONFIG_BT_CTLR_ADV_DATA_LEN_MAX` value. The size of the
the Controller's :kconfig:option:`CONFIG_BT_CTLR_ADV_DATA_LEN_MAX` value. The size of the
manufacturer data is calculated to maximize the use of supported AD data length.
Requirements

2
samples/bluetooth/cap_acceptor/README.rst
View file

@ -61,7 +61,7 @@ Similarly to how you would for real HW, you can do:
:goals: build
:west-args: --sysbuild
Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
For more information, check :ref:`this board documentation <nrf5340bsim>`.
Building for a simulated nrf52_bsim

2
samples/bluetooth/cap_initiator/README.rst
View file

@ -62,7 +62,7 @@ Similarly to how you would for real HW, you can do:
:goals: build
:west-args: --sysbuild
Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
For more information, check :ref:`this board documentation <nrf5340bsim>`.
Building for a simulated nrf52_bsim

2
samples/bluetooth/encrypted_advertising/README.rst
View file

@ -15,7 +15,7 @@ This sample demonstrates the use of the encrypted advertising feature, such as:
- the decryption of those advertising payloads,
- and the update of the Randomizer field whenever the RPA is changed.
To use the `bt_ead_encrypt` and `bt_ead_decrypt` functions, you must enable
To use the :c:func:`bt_ead_encrypt` and :c:func:`bt_ead_decrypt` functions, you must enable
the Kconfig symbol :kconfig:option:`CONFIG_BT_EAD`.
While this sample uses extended advertising, it is **not** mandatory when using

2
samples/bluetooth/extended_adv/README.rst
View file

@ -21,7 +21,7 @@ while the scanner cools-down for 5 seconds to restart its process.
This sample handles all actions in a separate thread, to promote good design
practices. Even though it is not strictly required, scheduling from another context is
strongly recommended (e.g. using a work item), as re-starting an advertiser or
scanner from within the `recycled` callback exposes the application to deadlocking.
scanner from within the ``recycled`` callback exposes the application to deadlocking.
Requirements
************

4
samples/bluetooth/hci_uart/README.rst
View file

@ -157,7 +157,7 @@ Using the controller with the Zephyr host
This describes how to hook up a board running this sample to a board running
an application that uses the Zephyr host.
On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen`
On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen``
block) is used to select which uart device to use. For example if we want to
keep the console logs, we can keep console on uart0 and the HCI on uart1 like
so:
@ -180,7 +180,7 @@ driver instead of the built-in controller:
CONFIG_BT_HCI=y
CONFIG_BT_CTLR=n
Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use.
Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use.
The UART needs to have as its child node a HCI UART node:
.. code-block:: dts

4
samples/bluetooth/hci_uart_3wire/README.rst
View file

@ -157,7 +157,7 @@ Using the controller with the Zephyr host
This describes how to hook up a board running this sample to a board running
an application that uses the Zephyr host.
On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen`
On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen``
block) is used to select which uart device to use. For example if we want to
keep the console logs, we can keep console on uart0 and the HCI on uart1 like
so:
@ -180,7 +180,7 @@ driver instead of the built-in controller:
CONFIG_BT_HCI=y
CONFIG_BT_CTLR=n
Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use.
Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use.
The UART needs to have as its child node a HCI UART node:
.. code-block:: dts

4
samples/bluetooth/hci_uart_async/README.rst
View file

@ -125,7 +125,7 @@ Using the controller with the Zephyr host
This describes how to hook up a board running this sample to a board running
an application that uses the Zephyr host.
On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen`
On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen``
block) is used to select which uart device to use. For example if we want to
keep the console logs, we can keep console on uart0 and the HCI on uart1 like
so:
@ -148,7 +148,7 @@ driver instead of the built-in controller:
CONFIG_BT_HCI=y
CONFIG_BT_CTLR=n
Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use.
Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use.
The UART needs to have as its child node a HCI UART node:
.. code-block:: dts

2
samples/bluetooth/iso_broadcast/README.rst
View file

@ -22,7 +22,7 @@ Building and Running
********************
This sample can be found under :zephyr_file:`samples/bluetooth/iso_broadcast` in
the Zephyr tree. Use `-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf` to enable
the Zephyr tree. Use ``-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf`` to enable
required ISO feature support in Zephyr Bluetooth Controller on supported boards.
Use the sample found under :zephyr_file:`samples/bluetooth/iso_receive` in the

2
samples/bluetooth/iso_receive/README.rst
View file

@ -22,7 +22,7 @@ Building and Running
********************
This sample can be found under :zephyr_file:`samples/bluetooth/iso_receive` in
the Zephyr tree. Use `-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf` to enable
the Zephyr tree. Use ``-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf`` to enable
required ISO feature support in Zephyr Bluetooth Controller on supported boards.
Use the sample found under :zephyr_file:`samples/bluetooth/iso_broadcast` on

2
samples/bluetooth/observer/README.rst
View file

@ -13,7 +13,7 @@ If any found, prints the address of the device, the RSSI value, the Advertising
type, and the Advertising data length to the console.
If the used Bluetooth Low Energy Controller supports Extended Scanning, you may
enable `CONFIG_BT_EXT_ADV` in the project configuration file. Refer to the
enable :kconfig:option:`CONFIG_BT_EXT_ADV` in the project configuration file. Refer to the
project configuration file for further details.
Requirements

Some files were not shown because too many files have changed in this diff Show more