Browse Source

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

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>
pull/78407/head
Benjamin Cabé 10 months ago committed by Mahesh Mahadevan
parent
commit
df294e34e1
  1. 4
      boards/adafruit/feather_nrf52840/doc/index.rst
  2. 2
      boards/adafruit/kb2040/doc/index.rst
  3. 2
      boards/adafruit/qt_py_rp2040/doc/index.rst
  4. 2
      boards/ambiq/apollo3_evb/doc/index.rst
  5. 2
      boards/ambiq/apollo3p_evb/doc/index.rst
  6. 2
      boards/ambiq/apollo4p_blue_kxr_evb/doc/index.rst
  7. 2
      boards/ambiq/apollo4p_evb/doc/index.rst
  8. 2
      boards/arduino/nano_33_ble/doc/index.rst
  9. 2
      boards/arm/fvp_base_revc_2xaemv8a/doc/index.rst
  10. 2
      boards/circuitdojo/feather/doc/index.rst
  11. 4
      boards/ct/ctcc/doc/index.rst
  12. 2
      boards/enjoydigital/litex_vexriscv/doc/index.rst
  13. 2
      boards/intel/rpl/doc/index.rst
  14. 2
      boards/intel/socfpga/agilex5_socdk/doc/index.rst
  15. 2
      boards/m5stack/m5stack_core2/doc/index.rst
  16. 8
      boards/native/doc/arch_soc.rst
  17. 24
      boards/native/doc/bsim_boards_design.rst
  18. 4
      boards/nxp/lpcxpresso54114/doc/index.rst
  19. 2
      boards/nxp/lpcxpresso55s69/doc/index.rst
  20. 2
      boards/nxp/mimxrt1040_evk/doc/index.rst
  21. 6
      boards/nxp/mimxrt1170_evk/doc/index.rst
  22. 2
      boards/nxp/rd_rw612_bga/doc/index.rst
  23. 2
      boards/nxp/s32z2xxdc2/doc/index.rst
  24. 8
      boards/phytec/phyboard_electra/doc/index.rst
  25. 11
      boards/phytec/phyboard_lyra/doc/phyboard_lyra_am62xx_m4.rst
  26. 2
      boards/rak/rak11720/doc/index.rst
  27. 11
      boards/raspberrypi/rpi_5/doc/index.rst
  28. 25
      boards/raspberrypi/rpi_pico/doc/index.rst
  29. 4
      boards/renesas/rzt2m_starterkit/doc/index.rst
  30. 6
      boards/seeed/xiao_ble/doc/index.rst
  31. 2
      boards/seeed/xiao_esp32c3/doc/index.rst
  32. 2
      boards/shields/mikroe_mcp2518fd_click/doc/index.rst
  33. 11
      boards/shields/rpi_pico_uno_flexypin/doc/index.rst
  34. 2
      boards/silabs/dev_kits/sltb010a/doc/index.rst
  35. 6
      boards/silabs/dev_kits/xg27_dk2602a/doc/index.rst
  36. 3
      boards/sparkfun/micromod/doc/index.rst
  37. 4
      boards/sparkfun/pro_micro_rp2040/doc/index.rst
  38. 2
      boards/sparkfun/thing_plus/doc/index.rst
  39. 4
      boards/st/b_u585i_iot02a/doc/index.rst
  40. 6
      boards/st/nucleo_l552ze_q/doc/nucleol552ze_q.rst
  41. 4
      boards/st/stm32l562e_dk/doc/index.rst
  42. 4
      boards/st/stm32wb5mm_dk/doc/stm32wb5mm_dk.rst
  43. 4
      boards/st/stm32wb5mmg/doc/stm32wb5mmg.rst
  44. 2
      boards/telink/tlsr9518adk80d/doc/index.rst
  45. 10
      boards/ti/sk_am62/doc/index.rst
  46. 24
      boards/wiznet/w5500_evb_pico/doc/index.rst
  47. 24
      doc/connectivity/bluetooth/api/audio/bluetooth-le-audio-arch.rst
  48. 2
      doc/connectivity/bluetooth/bluetooth-shell.rst
  49. 8
      doc/connectivity/networking/api/coap_client.rst
  50. 2
      doc/connectivity/networking/api/tls_credentials_shell.rst
  51. 11
      doc/connectivity/networking/api/wifi.rst
  52. 2
      doc/connectivity/usb/device_next/usb_device.rst
  53. 2
      doc/contribute/index.rst
  54. 2
      doc/develop/debug/index.rst
  55. 4
      doc/develop/manifest/index.rst
  56. 6
      doc/develop/modules.rst
  57. 2
      doc/develop/test/pytest.rst
  58. 20
      doc/develop/test/twister.rst
  59. 2
      doc/develop/test/ztest.rst
  60. 2
      doc/develop/tools/vscode.rst
  61. 2
      doc/develop/west/sign.rst
  62. 2
      doc/glossary.rst
  63. 6
      doc/hardware/arch/risc-v.rst
  64. 2
      doc/hardware/emulator/bus_emulators.rst
  65. 6
      doc/hardware/peripherals/uart.rst
  66. 2
      doc/kernel/object_cores/index.rst
  67. 8
      doc/kernel/services/interrupts.rst
  68. 2
      doc/project/release_process.rst
  69. 2
      doc/releases/index.rst
  70. 10
      doc/releases/migration-guide-4.0.rst
  71. 4
      doc/releases/release-notes-4.0.rst
  72. 2
      doc/security/standards/etsi-303645.rst
  73. 8
      doc/services/device_mgmt/ec_host_cmd.rst
  74. 2
      doc/services/device_mgmt/smp_groups/smp_group_0.rst
  75. 4
      doc/services/device_mgmt/smp_transport.rst
  76. 2
      doc/services/input/gpio-kbd.rst
  77. 8
      doc/services/llext/build.rst
  78. 2
      doc/services/llext/config.rst
  79. 2
      doc/services/logging/index.rst
  80. 4
      doc/services/mem_mgmt/index.rst
  81. 2
      doc/services/pm/device_runtime.rst
  82. 4
      doc/services/portability/posix/conformance/index.rst
  83. 2
      doc/services/storage/flash_map/flash_map.rst
  84. 2
      doc/services/tracing/index.rst
  85. 7
      doc/services/zbus/index.rst
  86. 10
      samples/bluetooth/bap_broadcast_sink/README.rst
  87. 4
      samples/bluetooth/bap_broadcast_source/README.rst
  88. 4
      samples/bluetooth/bap_unicast_client/README.rst
  89. 4
      samples/bluetooth/bap_unicast_server/README.rst
  90. 4
      samples/bluetooth/broadcaster_multiple/README.rst
  91. 2
      samples/bluetooth/cap_acceptor/README.rst
  92. 2
      samples/bluetooth/cap_initiator/README.rst
  93. 2
      samples/bluetooth/encrypted_advertising/README.rst
  94. 2
      samples/bluetooth/extended_adv/README.rst
  95. 4
      samples/bluetooth/hci_uart/README.rst
  96. 4
      samples/bluetooth/hci_uart_3wire/README.rst
  97. 4
      samples/bluetooth/hci_uart_async/README.rst
  98. 2
      samples/bluetooth/iso_broadcast/README.rst
  99. 2
      samples/bluetooth/iso_receive/README.rst
  100. 2
      samples/bluetooth/observer/README.rst
  101. Some files were not shown because too many files have changed in this diff Show More

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

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

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

@ -117,7 +117,7 @@ Using UF2
Since it doesn't expose the SWD pins, you must flash the Adafruit KB2040 with 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 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 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. UF2 file should be drag-and-dropped to the device, which will flash the KB2040.

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

@ -116,7 +116,7 @@ Using UF2
Since it doesn't expose the SWD pins, you must flash the Adafruit QT Py RP2040 with 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 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 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. 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

@ -69,7 +69,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash :goals: flash
.. note:: .. 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. to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings: Open a serial terminal (minicom, putty, etc.) with the following settings:

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

@ -69,7 +69,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash :goals: flash
.. note:: .. 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. to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings: Open a serial terminal (minicom, putty, etc.) with the following settings:

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

@ -77,7 +77,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash :goals: flash
.. note:: .. 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. to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings: Open a serial terminal (minicom, putty, etc.) with the following settings:

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

@ -72,7 +72,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash :goals: flash
.. note:: .. 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. to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings: Open a serial terminal (minicom, putty, etc.) with the following settings:

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

@ -160,7 +160,7 @@ That license ties to Arduino Nano 33 BLE hardware serial number,
it also works with the ZephyrRTOS. it also works with the ZephyrRTOS.
Follow the instruction of the tutorial for Arduino 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. to install the TRACE32.
After installing the TRACE32, You should set the environmental variable ``T32_DIR``. After installing the TRACE32, You should set the environmental variable ``T32_DIR``.

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

@ -99,7 +99,7 @@ Checkout and Build the TF-A:
cd trusted-firmware-a/ cd trusted-firmware-a/
make PLAT=fvp PRELOADED_BL33_BASE="0x88000000" all fip 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 .. code-block:: console

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

@ -100,7 +100,7 @@ or Nordic based examples.
Trusted Firmware-M (TF-M) and building the ``ns`` target is not supported for this board. 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 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 Flashing
======== ========

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

@ -172,7 +172,7 @@ As an example we'll use the :zephyr:code-sample:`usb-cdc-acm-console` sample.
.. note:: .. 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. directory. Providing certificate in build args produces signed binary automatically.
Do not use this certificate in your production firmware! 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. and plug such adapter to USB port.
You should see ``NordicSemiconductor MCUBOOT`` or ``NordicSemiconductor Zephyr DFU sample`` 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. 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 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

@ -184,7 +184,7 @@ Use `ecpprog <https://github.com/gregdavill/ecpprog>`_ to upload the bitstream t
ecpprog -S antmicro_sdi_mipi_video_converter.bit 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 .. code-block:: bash

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

@ -23,7 +23,7 @@ please refer to `RPL`_.
Raptor Lake Customer Reference Board (RPL CRB) is an example implementation of a 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 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 These board configurations enable kernel support for the supported Raptor Lake
boards. boards.

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

@ -45,7 +45,7 @@ hardware features:
NOTE: TODO, more details on dev kit will be updated as and when available. NOTE: TODO, more details on dev kit will be updated as and when available.
The default configuration can be found in the defconfig file: 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 Programming and Debugging
************************* *************************

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

@ -79,7 +79,7 @@ of the M5Stack Core2 board.
| MPU6886 | combines a 3-axis gyroscope and a 3-axis accelerometer. | | | MPU6886 | combines a 3-axis gyroscope and a 3-axis accelerometer. | |
| | For details please refer to :ref:`m5stack_core2_ext` | | | | 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 | | Built-in | The `SPM-1423`_ I2S driven microphone. | todo |
| microphone | | | | microphone | | |

8
boards/native/doc/arch_soc.rst

@ -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`, * Stack checks: :kconfig:option:`CONFIG_HW_STACK_PROTECTION`,
:kconfig:option:`CONFIG_STACK_CANARIES`, and :kconfig:option:`CONFIG_STACK_CANARIES`, and
:kconfig:option:`CONFIG_THREAD_ANALYZER`. :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 in other architectures. Check
:ref:`the architecture section's architecture layer paragraph <posix_arch_design_archl>` :ref:`the architecture section's architecture layer paragraph <posix_arch_design_archl>`
for more information. 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). executing the boot of the embedded code (including the POSIX arch code).
During this MCU boot process, the Zephyr kernel will be initialized and 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. just like in the embedded target.
As the embedded SW execution progresses, more Zephyr threads may be spawned, As the embedded SW execution progresses, more Zephyr threads may be spawned,
and for each the POSIX architecture will create a dedicated pthread. 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. 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 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 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 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 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 non-maskable phony interrupt which does not have a corresponding interrupt
handler but will resume the busy_wait SW execution. handler but will resume the busy_wait SW execution.
Note that other interrupts may arrive while the busy wait is in progress, 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 Interrupts may be locked out or masked during this time, but the special
fake-timer non-maskable interrupt will wake the CPU nonetheless. fake-timer non-maskable interrupt will wake the CPU nonetheless.

24
boards/native/doc/bsim_boards_design.rst

@ -16,7 +16,7 @@ Bsim boards
This page covers the design, architecture and rationale, of the This page covers the design, architecture and rationale, of the
nrf5x_bsim boards and other similar bsim boards. 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. (shortened bsim), to simulate the radio environment.
These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build
and execute the embedded code natively on Linux. 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. simulation specific ones.
- The architecture (arch) is the Zephyr :ref:`POSIX architecture<Posix arch>` - The architecture (arch) is the Zephyr :ref:`POSIX architecture<Posix arch>`
layer. 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 specific device we are simulating.
- The POSIX architecture provides an adaptation from the Zephyr arch API - The POSIX architecture provides an adaptation from the Zephyr arch API
(which handles mostly the thread context switching) to the native simulator (which handles mostly the thread context switching) to the native simulator
CPU thread emulation. CPU thread emulation.
See :ref:`POSIX arch architecture<posix_arch_architecture>` 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 and the handling of control between the "CPU simulation" (Zephyr threads) and the
HW models thread ( See `Threading`_ ). HW models thread ( See `Threading`_ ).
- The board layer provides all SOC/ IC specific content, including - 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. 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 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 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 The board layer provides other test specific
functionality like bs_tests hooks, trace control, etc, and 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 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 program, command line argument handling, and the overall time scheduling of
the simulated device. 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 the board. This includes the busy wait API, a basic tracing API, the interrupt
controller and interrupt handling APIs, :c:func:`posix_exit`, 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`). 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 All native and bsim boards share the same set of
:ref:`important limitations which<posix_arch_limitations>` :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 Similarly, they inherit the POSIX architecture
:ref:`unsupported features set <posix_arch_unsupported>`. :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 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. 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``, 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 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 and Zephyr OS, a hook to process possible command line arguments, and, a hook
that can be used to sniff or capture interrupts. 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, :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 that is, if the main app is a version for simulation which calls
:c:func:`bst_main` when running in the bsim board. :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, 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 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 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, to build quite complex test tasks which can wait for a given amount of time,
for conditions to be fulfilled, etc. 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 bs tests will probably be built with the same application, and that therefore
the tests should not be registering initialization or callback functions using the tests should not be registering initialization or callback functions using
NATIVE_TASKS or Zephyr's PRE/POST kernel driver initialization APIs as this NATIVE_TASKS or Zephyr's PRE/POST kernel driver initialization APIs as this
will execute even if the test is not selected. 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 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. for each MCU separatedly with the command line options.
Command line argument parsing Command line argument parsing

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

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

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

@ -299,7 +299,7 @@ board.
----------------------------------------- -----------------------------------------
1. Install the :ref:`linkserver-debug-host-tools` and make sure they are in your search path. 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` :ref:`opensda-daplink-onboard-debug-probe`
------------------------------------------ ------------------------------------------

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

@ -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. 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 WiFi Module
----------- -----------

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

@ -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 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 Zephyr, to better enable the entire RT11xx family. NXP prioritizes enabling
this board with new support for Zephyr features. Note that this table this board with new support for Zephyr features. Note that this table
covers two boards: the RT1170 EVK (`mimxrt1170_evk//cm7/cm4`), and covers two boards: the RT1170 EVK (``mimxrt1170_evk//cm7/cm4``), and
RT1170 EVKB (`mimxrt1170_evk@B//cm7/cm4`) RT1170 EVKB (``mimxrt1170_evk@B//cm7/cm4``)
+-----------+------------+-------------------------------------+-----------------+-----------------+ +-----------+------------+-------------------------------------+-----------------+-----------------+
| Interface | Controller | Driver/Component | RT1170 EVK | RT1170 EVKB | | 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. 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 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

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

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

@ -118,7 +118,7 @@ Serial Port
=========== ===========
The SoC has 12 LINFlexD instances that can be used in UART mode. The console can 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 Watchdog
======== ========

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

@ -84,7 +84,7 @@ GPIO
---- ----
The phyCORE-AM64x has a heartbeat LED connected to gpio6. It's configured 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 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 :zephyr-app: samples/hello_world
:goals: build :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 .. code-block:: console

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

@ -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 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. 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 .. code-block:: console
# From the root of the Zephyr repository # From the root of the Zephyr repository
west build -p -b phyboard_lyra/am6234/m4 samples/hello_world 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 .. code-block:: console
@ -134,7 +136,8 @@ port.
Debugging 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:: .. zephyr-app-commands::
:app: <my_app> :app: <my_app>

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

@ -92,7 +92,7 @@ Build the Zephyr kernel and application, then flash it to the device:
:goals: flash :goals: flash
.. note:: .. 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. to be installed on you host computer.
Open a serial terminal (minicom, putty, etc.) with the following settings: Open a serial terminal (minicom, putty, etc.) with the following settings:

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

@ -69,7 +69,7 @@ In brief,
* `bcm2712-rpi-5.dtb`_ * `bcm2712-rpi-5.dtb`_
3. Insert the Micro SD card and power on the Raspberry Pi 5. 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 config.txt
---------- ----------
@ -83,14 +83,15 @@ config.txt
zephyr.bin zephyr.bin
---------- ----------
Build an app `samples/basic/blinky` Build an app, for example :zephyr:code-sample:`blinky`
.. zephyr-app-commands:: .. zephyr-app-commands::
:zephyr-app: samples/basic/blinky :zephyr-app: samples/basic/blinky
:board: rpi_5 :board: rpi_5
:goals: build :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. 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 zephyr.bin
---------- ----------
Build an app `samples/hello_world` Build an app, for example :ref:`hello_world`:
.. zephyr-app-commands:: .. zephyr-app-commands::
:zephyr-app: samples/hello_world :zephyr-app: samples/hello_world
:board: rpi_5 :board: rpi_5
:goals: build :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. Insert the Micro SD card into your Raspberry Pi 5.

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

@ -137,11 +137,11 @@ Programmable I/O (PIO)
The RP2040 SoC comes with two PIO periherals. These are two simple The RP2040 SoC comes with two PIO periherals. These are two simple
co-processors that are designed for I/O operations. The PIOs run co-processors that are designed for I/O operations. The PIOs run
a custom instruction set, generated from a custom assembly language. 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 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 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 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" 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 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. 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 :goals: build flash
:gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=cmsis-dap :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` Set the environment variables **OPENOCD** to :file:`/usr/local/bin/openocd`
and **OPENOCD_DEFAULT_PATH** to `/usr/local/share/openocd/scripts`. This should work and **OPENOCD_DEFAULT_PATH** to :file:`/usr/local/share/openocd/scripts`. This should work
with the OpenOCD that was installed with the default configuration. 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. 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. **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. If **RPI_PICO_DEBUG_ADAPTER** was not assigned, ``cmsis-dap`` is used by default.
The other supported adapters are `raspberrypi-swd`, `jlink` and `blackmagicprobe`. 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`_. 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. 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 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. 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 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 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 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 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. 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 :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** 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. You can also debug with OpenOCD and gdb launching from command-line.
Run the following command: Run the following command:

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

@ -67,7 +67,7 @@ By default, the board is configured for use with:
* UART0 connected to the USB serial port (pins K18, K19), * UART0 connected to the USB serial port (pins K18, K19),
* UART3 connected to the PMOD Header (J25, pins H16, G20), * 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. The Zephyr console uses UART0.
@ -78,7 +78,7 @@ Debugging
========= =========
Connect to the board using the J-Link On-board USB connector. 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 .. code-block:: console

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

@ -92,9 +92,9 @@ UF2 Flashing
To enter the bootloader, connect the USB port of the XIAO BLE to your host, and 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 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 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 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 of the ``XIAO BLE`` mass storage device. The XIAO BLE will automatically reset
and launch the newly flashed application. and launch the newly flashed application.
External Debugger External Debugger

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

@ -172,7 +172,7 @@ For the :code:`Hello, world!` application, follow the instructions below.
:board: xiao_esp32c3 :board: xiao_esp32c3
:goals: build flash :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. the espressif monitor to view.
.. code-block:: console .. code-block:: console

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

@ -16,7 +16,7 @@ Requirements
************ ************
The shield uses a mikroBUS interface. The target board must define 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 (see :ref:`shields` for more details). The target board must also
support level triggered interrupts. support level triggered interrupts.

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

@ -6,12 +6,13 @@ RaspberryPi Pico to UNO FlexyPin Adapter
Overview Overview
******** ********
Raspberry Pi Pico to Uno `FlexyPin Adapter` is a converter-PCB to Arduino UNO form-factor The Raspberry Pi Pico to Uno FlexyPin Adapter is an open-source hardware converter PCB that adapts
from Raspberry Pi Pico that is released in Open Source Hardware. the Raspberry Pi Pico to the Arduino UNO form factor
This board design to use with `FlexyPin`. This board is designed to be use with FlexyPin connector pins.
The FlexyPin holds Pico and contacts to castellated through-hole. 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 .. image:: img/rpi_pico_uno_flexypin.png
:align: center :align: center

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

@ -149,7 +149,7 @@ BRD4184B:
:goals: flash :goals: flash
.. note:: .. 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. computer.
Open a serial terminal (minicom, putty, etc.) with the following settings: Open a serial terminal (minicom, putty, etc.) with the following settings:

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

@ -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. Commander in unattended mode and passes all the necessary arguments to it.
- If Simplicity Commander is installed in the system and the directory in - 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: variable:
.. code-block:: console .. code-block:: console
west flash 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 .. code-block:: console
@ -114,7 +114,7 @@ Build the Zephyr kernel and application:
:goals: build :goals: build
Connect your device to your host computer using the USB port and you 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: Open a serial terminal (minicom, putty, etc.) with the following settings:

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

@ -139,7 +139,7 @@ applications as usual (see :ref:`build_an_application` and
:ref:`application_run` for more details). :ref:`application_run` for more details).
The flashing tool will depend on the carrier used along with the board. 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. the SWD interface along with a J-Link.
Here is an example for the :ref:`hello_world` application. Here is an example for the :ref:`hello_world` application.
@ -199,6 +199,7 @@ References
.. target-notes:: .. target-notes::
.. _Micromod specification website: https://www.sparkfun.com/micromod .. _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 .. _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 .. _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 .. _nRF52840 Product Specification: http://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.0.pdf

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

@ -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 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. debugger. You can also flash the SparkFun ProMicro RP2040 with a UF2 file.
By default, building an app for this board will generate a 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 :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 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 device. The UF2 file should be copied to the device, which will
flash the Pro Micro RP2040. flash the Pro Micro RP2040.

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

@ -92,7 +92,7 @@ In most cases you'll want to use the ``ns`` target with any of the Zephyr
or Nordic based examples. or Nordic based examples.
Some of the examples do not use secure mode, so they do not required the ``ns`` suffix. 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 Flashing
======== ========

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

@ -220,7 +220,7 @@ The BOARD options are summarized below:
+-------------------------------+-------------------------------------------+ +-------------------------------+-------------------------------------------+
Here are the instructions to build Zephyr with a non-secure configuration, 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:: bash
@ -236,7 +236,7 @@ option bit TZEN will be set).
$ west flash $ west flash
Please note that, after having run a TFM sample on the board, you will need to 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 options and get back the platform back to a "normal" state and be able to run
usual, non-TFM, binaries. usual, non-TFM, binaries.
Also note that, even then, TZEN will remain set, and you will need to use 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

@ -197,9 +197,9 @@ The BOARD options are summarized below:
+--------------------------------+-------------------------------------------+ +--------------------------------+-------------------------------------------+
Here are the instructions to build Zephyr with a non-secure configuration, 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/ $ 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 $ west flash
Please note that, after having run a TFM sample on the board, you will need to 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 options and get back the platform back to a "normal" state and be able to run
usual, non-TFM, binaries. usual, non-TFM, binaries.
Also note that, even then, TZEN will remain set, and you will need to use Also note that, even then, TZEN will remain set, and you will need to use

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

@ -223,7 +223,7 @@ The BOARD options are summarized below:
+------------------------------+-------------------------------------------+ +------------------------------+-------------------------------------------+
Here are the instructions to build Zephyr with a non-secure configuration, 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:: bash
@ -239,7 +239,7 @@ option bit TZEN will be set).
$ west flash $ west flash
Please note that, after having run a TFM sample on the board, you will need to 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 options and get back the platform back to a "normal" state and be able to run
usual, non-TFM, binaries. usual, non-TFM, binaries.
Also note that, even then, TZEN will remain set, and you will need to use Also note that, even then, TZEN will remain set, and you will need to use

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

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

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

@ -248,8 +248,8 @@ the ``--runner`` (or ``-r``) option:
$ west flash --runner openocd $ 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 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 the SW4 (MCU SWD) in OFF mode and SW5 (SWD BLE) in ON mode. Then build

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

@ -235,7 +235,7 @@ It is also possible to use the west flash command, but additional steps are requ
Debugging 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: it in a simple way, like:
.. code-block:: console .. code-block:: console

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

@ -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. 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 .. code-block:: console
# From the root of the Zephyr repository # From the root of the Zephyr repository
west build -p -b sk_am62/am6234/m4 samples/hello_world 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 .. code-block:: console
@ -122,7 +124,7 @@ The binary will run and print Hello world to the MCU_UART0 port.
Debugging 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:: .. zephyr-app-commands::
:app: <my_app> :app: <my_app>

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

@ -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" 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 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 interface that can be used to program and debug the on board RP2040. This
@ -189,26 +189,26 @@ application.
:goals: build flash :goals: build flash
:gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=picoprobe :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 Set the environment variables **OPENOCD** to :file:`/usr/local/bin/openocd` and
**OPENOCD_DEFAULT_PATH** to `/usr/local/share/openocd/scripts`. This should **OPENOCD_DEFAULT_PATH** to :file:`/usr/local/share/openocd/scripts`. This should
work with the OpenOCD that was installed with the default configuration. This work with the OpenOCD that was installed with the default configuration. This
configuration also works with an environment that is set up by the configuration also works with an environment that is set up by the
`pico_setup.sh`_ script. `pico_setup.sh`_ script.
**RPI_PICO_DEBUG_ADAPTER** specifies what debug adapter is used for debugging. **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. If **RPI_PICO_DEBUG_ADAPTER** was not assigned, ``picoprobe`` is used by default.
The other supported adapters are `raspberrypi-swd`, `jlink` and The other supported adapters are ``raspberrypi-swd``, ``jlink`` and
`blackmagicprobe`. How to connect `picoprobe` and `raspberrypi-swd` is ``blackmagicprobe``. How to connect ``picoprobe`` and ``raspberrypi-swd`` is
described in `Getting Started with Raspberry Pi Pico`_. Any other SWD debug described in `Getting Started with Raspberry Pi Pico`_. Any other SWD debug
adapter maybe also work with this configuration. adapter maybe also work with this configuration.
The value of **RPI_PICO_DEBUG_ADAPTER** is cached, so it can be omitted from 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 flash`` and ``west debug`` if it was previously set while running
`west build`. ``west build``.
**RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as **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 **RPI_PICO_DEBUG_ADAPTER** needs to be assigned the file name of the debug
adapter. adapter.
@ -224,7 +224,7 @@ Using UF2
If you don't have an SWD adapter, you can flash the Raspberry Pi Pico with 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 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 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. 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 :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 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 **RPI_PICO_DEBUG_ADAPTER** at ``west build`` time. No needs to specify it at
`west debug` time. ``west debug`` time.
You can also debug with OpenOCD and gdb launching from command-line. You can also debug with OpenOCD and gdb launching from command-line.
Run the following command: Run the following command:

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

@ -22,14 +22,14 @@ The overall design of the LE Audio stack is that the implementation follows the
as closely as possible, as closely as possible,
both in terms of structure but also naming. both in terms of structure but also naming.
Most API functions are prefixed by the specification acronym 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)). (e.g. ``bt_bap`` for the Basic Audio Profile (BAP) and ``bt_vcp`` for the Volume Control Profile
The functions are then further prefixed with the specific role from each profile where applicable (VCP)). The functions are then further prefixed with the specific role from each profile where
(e.g. :c:func:`bt_bap_unicast_client_discover` and :c:func:`bt_vcp_vol_rend_set_vol`). 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, 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. and additional helper or meta functions that do not correspond to procedures.
The structure of the files generally also follow this, 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. If the file is specific for a profile role, the role is also embedded in the file name.
Generic Audio Framework (GAF) 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. 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 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. 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, 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. 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. 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 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. 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`, 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`, 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, indicating that the application not only controls a lot of the Unicast Server data,
but can also reject the requests. but can also reject the requests.
The choice of what the return type of the callbacks often depend on the specifications, 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. use other profiles and services that do not require such security.
We guard all access to services using a custom security check implemented in 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 :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 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. 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 Find it here at https://discordapp.com/channels/720317445772017664/1207326649591271434 or simply
search for `ble-audio` from within Discord. search for "ble-audio" from within Discord.
Since the `ble-audio` channel is open for all, Since the ``#ble-audio`` channel is open for all,
we cannot discuss any specifications that are in development in that channel. 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. Discord channel found at https://discordapp.com/channels/720317445772017664/869172014018097162.
Zephyr weekly meetings Zephyr weekly meetings

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

@ -218,7 +218,7 @@ Extended Advertising
==================== ====================
Let's now have a look at some extended advertising features. To enable extended advertising, use the 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 .. code-block:: console

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

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

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

@ -206,7 +206,7 @@ After the list is printed, a final summary of the found credentials will be prin
<N> credentials found. <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: .. _tls_credentials_shell_cred_types:

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

@ -18,7 +18,8 @@ Only personal mode security is supported with below types:
* WPA3-PSK-256 * WPA3-PSK-256
* WPA3-SAE * 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: Currently, two types of Wi-Fi drivers are supported:
* Networking or socket offloaded drivers * 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 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 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. module.
.. code-block:: bash .. 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 uart:~$ wifi connect -s <SSID> -k 5 -a anon -K whatever
Server certificate is also provided in the same directory for testing purposes. 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:: .. 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:: .. note::
The certificates are for testing purposes only and should not be used in production. 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 API Reference
************* *************

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

@ -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, 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 while others use a general Zephyr RTOS driver API, such as MSC and CDC class
implementations. The *Identification string* identifies a class or function 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 | | Class or function | User API (if any) | Identification string |

2
doc/contribute/index.rst

@ -27,7 +27,7 @@ General Guidelines
merged. merged.
:ref:`contributor-expectations` :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. contributors to the project.
:ref:`coding_guidelines` :ref:`coding_guidelines`

2
doc/develop/debug/index.rst

@ -291,7 +291,7 @@ Debugging I2C communication
There is a possibility to log all or some of the I2C transactions done by the application. 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 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. :kconfig:option:`CONFIG_I2C_LOG_LEVEL_DBG` option must also be enabled.
The sample output of the dump looks like this:: The sample output of the dump looks like this::

4
doc/develop/manifest/index.rst

@ -12,7 +12,7 @@ Active Projects/Modules
+++++++++++++++++++++++ +++++++++++++++++++++++
The projects below are enabled by default and will be downloaded when you 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 essential for building generic Zephyr application and include among others
hardware support for many of the platforms available in Zephyr. 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 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 and use them to write application code and extend your workspace with the added
functionality. functionality.

6
doc/develop/modules.rst

@ -52,7 +52,7 @@ In summary:
Modules are repositories that contain a :file:`zephyr/module.yml` file, so that 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. 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. section in the :file:`west.yml` manifest file.
West projects are often also modules, but not always. There are west projects 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 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. use.
Here is an example :file:`module.yml` file referring to 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: the module:
.. code-block:: yaml .. code-block:: yaml
@ -592,7 +592,7 @@ be monitored for your module. The supported formats are:
- <an-other-module-related-cpe> - <an-other-module-related-cpe>
- <module-related-purl> - <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 .. code-block:: yaml

2
doc/develop/test/pytest.rst

@ -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/>`_). 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 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. 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 and twister, allowing Zephyr’s community to utilize pytest functionality with keeping twister as
the main framework. the main framework.

20
doc/develop/test/twister.rst

@ -261,11 +261,11 @@ test application and has to follow basic rules:
two sections: two sections:
* Ztest tests: The individual test cases in the ztest testsuite will be * 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. generating unique identifiers for every test case in the suite.
* Standalone tests and samples: This type of test should at least have 3 * 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. ``testcase.yaml`` (or ``sample.yaml``) file.
The last section of the name shall signify the test case itself. 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; * ``-l/--all``: all available platforms;
* ``-G/--integration``: all platforms from an ``integration_platforms`` list in * ``-G/--integration``: all platforms from an ``integration_platforms`` list in
a given test configuration file. If a test has no ``integration_platforms`` a given test configuration file. If a test has no ``integration_platforms``
`"scope presumption"` will happen; *"scope presumption"* will happen;
* No scope argument: `"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 list. If nothing is left after the filtration, the ``platform_allow`` list
is used as the initial scope. is used as the initial scope.
@ -1338,7 +1338,7 @@ locally. As of now, those options are available:
CI) CI)
- Option to specify your own list of default platforms overriding what - Option to specify your own list of default platforms overriding what
upstream defines. 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 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. platforms you specify in the configuration file or on the command line.
- Ignore some logic in twister to expand platform coverage in cases where - 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: 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 and instead use the list of platforms provided in the
configuration file as the list of default platforms. This option is set to configuration file as the list of default platforms. This option is set to
False by default. 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 disabled, twister will not increase platform coverage automatically and will
only build and run tests on the specified platforms. 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 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: And example platforms configuration:

2
doc/develop/test/ztest.rst

@ -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 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 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 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: Static configuration of ZTEST_SHUFFLE contains:

2
doc/develop/tools/vscode.rst

@ -17,7 +17,7 @@ Get VS Code
`Download VS Code`_ and install it. `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. Search for the `C/C++ Extension Pack`_ and install it.
Initialize a new workspace Initialize a new workspace

2
doc/develop/west/sign.rst

@ -116,7 +116,7 @@ for all images, for example:
west build -b <board> <application> -DSIGNING_SCRIPT=<file> west build -b <board> <application> -DSIGNING_SCRIPT=<file>
The zephyr property method is achieved by adjusting the ``SIGNING_SCRIPT`` property 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 .. code-block:: cmake

2
doc/glossary.rst

@ -60,7 +60,7 @@ Glossary of Terms
See :ref:`board_terminology` for additional details. See :ref:`board_terminology` for additional details.
board qualifiers 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 follow the :term:`board name` (and optionally :term:`board revision`) to
form the :term:`board target`. The currently accepted qualifiers are form the :term:`board target`. The currently accepted qualifiers are
:term:`SoC`, :term:`CPU cluster` and :term:`variant`. :term:`SoC`, :term:`CPU cluster` and :term:`variant`.

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

@ -23,7 +23,7 @@ ISA extensions
************** **************
It's possible to set in Zephyr which ISA extensions (RV32/64I(E)MAFD(G)QC) 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. kconfig. Look at :file:`arch/riscv/Kconfig.isa` for more information.
Note that Zephyr SDK toolchain support may not be defined for all 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 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 order to test the SMP support, one can use ``qemu_riscv32_smp`` or
`qemu_riscv64_smp` boards. ``qemu_riscv64_smp`` boards.

2
doc/hardware/emulator/bus_emulators.rst

@ -73,7 +73,7 @@ an emulator instance using one of the :c:func:`EMUL_DT_DEFINE()` or
:c:func:`EMUL_DT_INST_DEFINE()` APIs. :c:func:`EMUL_DT_INST_DEFINE()` APIs.
Emulators for peripheral devices reuse the same devicetree node as the real 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. same ``compat`` value from the real driver.
.. code-block:: C .. code-block:: C

6
doc/hardware/peripherals/uart.rst

@ -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` 3. :ref:`uart_async_api` using :ref:`dma_api`
Polling is the most basic method to access the UART peripheral. The reading 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 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, 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 :c:func:`uart_poll_out`, is a blocking function and the thread waits until the given
character is sent. character is sent.
With the Interrupt-driven API, possibly slow communication can happen in the With the Interrupt-driven API, possibly slow communication can happen in the

2
doc/kernel/object_cores/index.rst

@ -13,7 +13,7 @@ perform operations on registered objects.
Object Core Concepts 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 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 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 respective object type. Each object type contains a singly linked list

8
doc/kernel/services/interrupts.rst

@ -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. :kconfig:option:`ISR_TABLES_LOCAL_DECLARATION_SUPPORTED` is set.
See details of this option for the information about currently supported configurations. 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 Any invocation of :c:macro:`IRQ_CONNECT` or :c:macro:`IRQ_DIRECT_CONNECT` will declare an instance
_isr_list_sname which is placde in a special .intList section: of ``struct _isr_list_sname`` which is placed in a special .intList section:
.. code-block:: c .. 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. 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. structure name length.
The whole entry is used by the script during the build of the application The whole entry is used by the script during the build of the application
and has all the information needed for proper interrupt placement. 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 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, 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 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 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 :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 length of the bit masks and shift to apply when generating interrupt values, when checking the

2
doc/project/release_process.rst

@ -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 release from happening. All blocker bugs shall be resolved before a release is
created. 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. the release all the way until the final release date.
Bugs of moderate severity and higher that have impact on all users are typically Bugs of moderate severity and higher that have impact on all users are typically

2
doc/releases/index.rst

@ -73,7 +73,7 @@ Release Notes
Release notes contain a list of changes that have been made to the different 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. 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 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. needs to be changed are to be detailed in the release's migration guide.
.. toctree:: .. toctree::

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

@ -30,14 +30,14 @@ Boards
to define default flash and ram partitioning based on TF-M. 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 * 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 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 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 Modules
******* *******
@ -69,10 +69,10 @@ zcbor
Migration guide at https://github.com/NordicSemiconductor/zcbor/blob/0.9.0/MIGRATION_GUIDE.md Migration guide at https://github.com/NordicSemiconductor/zcbor/blob/0.9.0/MIGRATION_GUIDE.md
Migration guide copied here: 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. 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. 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. If a removed variant is strictly needed, add your own forward declaration in your code.
* Code generation naming: * Code generation naming:

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

@ -68,8 +68,8 @@ Architectures
has an additional field ``csf`` that points to the callee-saved-registers upon an fatal error, 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``. 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 * 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. include the ``csf`` member, otherwise the build would fail.
* Xtensa * Xtensa

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

@ -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 of Things: Baseline Requirements," is a standard developed by the
European Telecommunications Standards Institute (ETSI). European Telecommunications Standards Institute (ETSI).

8
doc/services/device_mgmt/ec_host_cmd.rst

@ -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``. For the SPI, it is required to set the backend chosen node ``zephyr,host-cmd-spi-backend``.
The supported backend and peripheral drivers: 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 The host command has an embedded logging system of the ongoing communication. The are a few logging
levels: 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 same command are not logged
* `LOG_DBG` logs every command, even repeats * :c:macro:`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` + :kconfig:option:`CONFIG_EC_HOST_CMD_LOG_DBG_BUFFERS` logs every command and responses
with the data buffers with the data buffers
API Reference API Reference

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

@ -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 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 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 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 System reset request
==================== ====================

4
doc/services/device_mgmt/smp_transport.rst

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

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

@ -171,7 +171,7 @@ Actual key mask configuration
***************************** *****************************
If the key matrix is not complete, a map of the keys that are actually 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 the matrix state to be filtered to remove keys that are not present before
ghosting detection, potentially allowing key combinations that would otherwise ghosting detection, potentially allowing key combinations that would otherwise
be blocked by it. be blocked by it.

8
doc/services/llext/build.rst

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

2
doc/services/llext/config.rst

@ -104,7 +104,7 @@ significant as the number of exported symbols increases.
Perform an extra processing step on the Zephyr binary and on all Perform an extra processing step on the Zephyr binary and on all
extensions being built, converting every string in the symbol tables to 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. stored in the binary.
This speeds up the symbol lookup process by allowing usage of This speeds up the symbol lookup process by allowing usage of

2
doc/services/logging/index.rst

@ -500,7 +500,7 @@ backends.
In some cases, logs need to be redirected at the macro level. For these cases, 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 :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) Frontend using ARM Coresight STM (System Trace Macrocell)
--------------------------------------------------------- ---------------------------------------------------------

4
doc/services/mem_mgmt/index.rst

@ -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 A test for the ``mem-attr`` library and its usage is provided in
``tests/subsys/mem_mgmt/mem_attr/``. ``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 When the ``zephyr,memory-attr`` property was introduced, the
``zephyr,memory-region-mpu`` property was removed and deprecated. ``zephyr,memory-region-mpu`` property was removed and deprecated.

2
doc/services/pm/device_runtime.rst

@ -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. calls on the child device.
For the previous to automatically control the power domain state, device runtime PM must be enabled 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`). or :c:func:`pm_device_runtime_enable`).
.. graphviz:: .. graphviz::

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

@ -3,7 +3,9 @@
POSIX Conformance 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: .. _posix_system_interfaces:

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

@ -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 characterizing the flash area they will be working on. There are two possible
methods to obtain such a pointer: 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 * 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 a valid :c:struct:`device` object pointer with offset and size of the area

2
doc/services/tracing/index.rst

@ -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 it to *y*. For example, this can be added to the
:zephyr:code-sample:`synchronization` sample to visualize fast switching between threads. :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 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 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:: latest data from the internal RAM buffer can be loaded into SystemView::

7
doc/services/zbus/index.rst

@ -380,7 +380,8 @@ Limitations
Based on the fact that developers can use zbus to solve many different problems, some challenges 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 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 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 Delivery guarantees
------------------- -------------------
@ -524,12 +525,12 @@ sequence of the static observers.
notified. 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 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 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 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 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 only messages with ``move`` equal to 0, -1, and 1 are valid. Publish function will discard all other
values to ``move``. values to ``move``.

10
samples/bluetooth/bap_broadcast_sink/README.rst

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

4
samples/bluetooth/bap_broadcast_source/README.rst

@ -29,7 +29,7 @@ Building and Running
******************** ********************
When building targeting an nrf52 series board with the Zephyr Bluetooth Controller, 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. feature support.
Building for an nrf5340dk Building for an nrf5340dk
@ -66,7 +66,7 @@ Similarly to how you would for real HW, you can do:
:goals: build :goals: build
:west-args: --sysbuild :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>`. For more information, check :ref:`this board documentation <nrf5340bsim>`.
Building for a simulated nrf52_bsim Building for a simulated nrf52_bsim

4
samples/bluetooth/bap_unicast_client/README.rst

@ -25,7 +25,7 @@ Building and Running
******************** ********************
When building targeting an nrf52 series board with the Zephyr Bluetooth Controller, 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. feature support.
Building for an nrf52840dk Building for an nrf52840dk
@ -71,7 +71,7 @@ Similarly to how you would for real HW, you can do:
:goals: build :goals: build
:gen-args: -DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf :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>`. For more information, check :ref:`this board documentation <nrf52_bsim>`.
Building for a simulated nrf5340bsim Building for a simulated nrf5340bsim

4
samples/bluetooth/bap_unicast_server/README.rst

@ -25,7 +25,7 @@ Building and Running
******************** ********************
When building targeting an nrf52 series board with the Zephyr Bluetooth Controller, 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. feature support.
Building for an nrf52840dk Building for an nrf52840dk
@ -71,7 +71,7 @@ Similarly to how you would for real HW, you can do:
:goals: build :goals: build
:gen-args: -DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf :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>`. For more information, check :ref:`this board documentation <nrf52_bsim>`.
Building for a simulated nrf5340bsim Building for a simulated nrf5340bsim

4
samples/bluetooth/broadcaster_multiple/README.rst

@ -12,11 +12,11 @@ uses multiple advertising sets functionality.
This sample advertises two non-connectable non-scannable advertising sets with This sample advertises two non-connectable non-scannable advertising sets with
two different SID. Number of advertising sets can be increased by updating the 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 When building this sample combined with a Bluetooth LE Controller, the
advertising data length can be increased from the default 31 bytes by updating 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. manufacturer data is calculated to maximize the use of supported AD data length.
Requirements Requirements

2
samples/bluetooth/cap_acceptor/README.rst

@ -61,7 +61,7 @@ Similarly to how you would for real HW, you can do:
:goals: build :goals: build
:west-args: --sysbuild :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>`. For more information, check :ref:`this board documentation <nrf5340bsim>`.
Building for a simulated nrf52_bsim Building for a simulated nrf52_bsim

2
samples/bluetooth/cap_initiator/README.rst

@ -62,7 +62,7 @@ Similarly to how you would for real HW, you can do:
:goals: build :goals: build
:west-args: --sysbuild :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>`. For more information, check :ref:`this board documentation <nrf5340bsim>`.
Building for a simulated nrf52_bsim Building for a simulated nrf52_bsim

2
samples/bluetooth/encrypted_advertising/README.rst

@ -15,7 +15,7 @@ This sample demonstrates the use of the encrypted advertising feature, such as:
- the decryption of those advertising payloads, - the decryption of those advertising payloads,
- and the update of the Randomizer field whenever the RPA is changed. - 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`. the Kconfig symbol :kconfig:option:`CONFIG_BT_EAD`.
While this sample uses extended advertising, it is **not** mandatory when using While this sample uses extended advertising, it is **not** mandatory when using

2
samples/bluetooth/extended_adv/README.rst

@ -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 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 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 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 Requirements
************ ************

4
samples/bluetooth/hci_uart/README.rst

@ -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 This describes how to hook up a board running this sample to a board running
an application that uses the Zephyr host. 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 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 keep the console logs, we can keep console on uart0 and the HCI on uart1 like
so: so:
@ -180,7 +180,7 @@ driver instead of the built-in controller:
CONFIG_BT_HCI=y CONFIG_BT_HCI=y
CONFIG_BT_CTLR=n 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: The UART needs to have as its child node a HCI UART node:
.. code-block:: dts .. code-block:: dts

4
samples/bluetooth/hci_uart_3wire/README.rst

@ -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 This describes how to hook up a board running this sample to a board running
an application that uses the Zephyr host. 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 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 keep the console logs, we can keep console on uart0 and the HCI on uart1 like
so: so:
@ -180,7 +180,7 @@ driver instead of the built-in controller:
CONFIG_BT_HCI=y CONFIG_BT_HCI=y
CONFIG_BT_CTLR=n 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: The UART needs to have as its child node a HCI UART node:
.. code-block:: dts .. code-block:: dts

4
samples/bluetooth/hci_uart_async/README.rst

@ -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 This describes how to hook up a board running this sample to a board running
an application that uses the Zephyr host. 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 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 keep the console logs, we can keep console on uart0 and the HCI on uart1 like
so: so:
@ -148,7 +148,7 @@ driver instead of the built-in controller:
CONFIG_BT_HCI=y CONFIG_BT_HCI=y
CONFIG_BT_CTLR=n 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: The UART needs to have as its child node a HCI UART node:
.. code-block:: dts .. code-block:: dts

2
samples/bluetooth/iso_broadcast/README.rst

@ -22,7 +22,7 @@ Building and Running
******************** ********************
This sample can be found under :zephyr_file:`samples/bluetooth/iso_broadcast` in 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. required ISO feature support in Zephyr Bluetooth Controller on supported boards.
Use the sample found under :zephyr_file:`samples/bluetooth/iso_receive` in the Use the sample found under :zephyr_file:`samples/bluetooth/iso_receive` in the

2
samples/bluetooth/iso_receive/README.rst

@ -22,7 +22,7 @@ Building and Running
******************** ********************
This sample can be found under :zephyr_file:`samples/bluetooth/iso_receive` in 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. required ISO feature support in Zephyr Bluetooth Controller on supported boards.
Use the sample found under :zephyr_file:`samples/bluetooth/iso_broadcast` on Use the sample found under :zephyr_file:`samples/bluetooth/iso_broadcast` on

2
samples/bluetooth/observer/README.rst

@ -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. type, and the Advertising data length to the console.
If the used Bluetooth Low Energy Controller supports Extended Scanning, you may 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. project configuration file for further details.
Requirements Requirements

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

Loading…
Cancel
Save