diff --git a/boards/adafruit/feather_nrf52840/doc/index.rst b/boards/adafruit/feather_nrf52840/doc/index.rst index e4e62c0556e..7ab630978d4 100644 --- a/boards/adafruit/feather_nrf52840/doc/index.rst +++ b/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. #. Tap the reset button twice quickly to enter bootloader mode. - A mass storage device named `FTHR840BOOT` for (Express) or - `FTHRSNSBOOT` (Sense) should appear on the host. Ensure this is + A mass storage device named ``FTHR840BOOT`` for (Express) or + ``FTHRSNSBOOT`` (Sense) should appear on the host. Ensure this is mounted. #. Flash the image. diff --git a/boards/adafruit/kb2040/doc/index.rst b/boards/adafruit/kb2040/doc/index.rst index 09d5bfb0960..58b53aec815 100644 --- a/boards/adafruit/kb2040/doc/index.rst +++ b/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 a UF2 file. By default, building an app for this board will generate a -`build/zephyr/zephyr.uf2` file. If the KB2040 is powered on with the `BOOTSEL` +:file:`build/zephyr/zephyr.uf2` file. If the KB2040 is powered on with the ``BOOTSEL`` button pressed, it will appear on the host as a mass storage device. The UF2 file should be drag-and-dropped to the device, which will flash the KB2040. diff --git a/boards/adafruit/qt_py_rp2040/doc/index.rst b/boards/adafruit/qt_py_rp2040/doc/index.rst index 19b5a832223..bf081c029b7 100644 --- a/boards/adafruit/qt_py_rp2040/doc/index.rst +++ b/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 a UF2 file. By default, building an app for this board will generate a -`build/zephyr/zephyr.uf2` file. If the QT Py RP2040 is powered on with the `BOOTSEL` +:file:`build/zephyr/zephyr.uf2` file. If the QT Py RP2040 is powered on with the ``BOOTSEL`` button pressed, it will appear on the host as a mass storage device. The UF2 file should be drag-and-dropped to the device, which will flash the QT Py RP2040. diff --git a/boards/ambiq/apollo3_evb/doc/index.rst b/boards/ambiq/apollo3_evb/doc/index.rst index 12990d0c9fe..1982236becf 100644 --- a/boards/ambiq/apollo3_evb/doc/index.rst +++ b/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 .. note:: - `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module + ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module to be installed on you host computer. Open a serial terminal (minicom, putty, etc.) with the following settings: diff --git a/boards/ambiq/apollo3p_evb/doc/index.rst b/boards/ambiq/apollo3p_evb/doc/index.rst index 9d56556d69c..58b354288d2 100644 --- a/boards/ambiq/apollo3p_evb/doc/index.rst +++ b/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 .. note:: - `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module + ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module to be installed on you host computer. Open a serial terminal (minicom, putty, etc.) with the following settings: diff --git a/boards/ambiq/apollo4p_blue_kxr_evb/doc/index.rst b/boards/ambiq/apollo4p_blue_kxr_evb/doc/index.rst index 214b5d4c2ef..33a68ce8875 100644 --- a/boards/ambiq/apollo4p_blue_kxr_evb/doc/index.rst +++ b/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 .. note:: - `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module + ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module to be installed on you host computer. Open a serial terminal (minicom, putty, etc.) with the following settings: diff --git a/boards/ambiq/apollo4p_evb/doc/index.rst b/boards/ambiq/apollo4p_evb/doc/index.rst index 7c5cd174cf6..662b6c41515 100644 --- a/boards/ambiq/apollo4p_evb/doc/index.rst +++ b/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 .. note:: - `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module + ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module to be installed on you host computer. Open a serial terminal (minicom, putty, etc.) with the following settings: diff --git a/boards/arduino/nano_33_ble/doc/index.rst b/boards/arduino/nano_33_ble/doc/index.rst index 05c0605b464..2b5ede0ea11 100644 --- a/boards/arduino/nano_33_ble/doc/index.rst +++ b/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. Follow the instruction of the tutorial for Arduino -`Lauterbach TRACE32 GDB Front-End Debugger for Nano 33 BLE` +`Lauterbach TRACE32 GDB Front-End Debugger for Nano 33 BLE`_ to install the TRACE32. After installing the TRACE32, You should set the environmental variable ``T32_DIR``. diff --git a/boards/arm/fvp_base_revc_2xaemv8a/doc/index.rst b/boards/arm/fvp_base_revc_2xaemv8a/doc/index.rst index 495b7ad11f4..81a098b3ae1 100644 --- a/boards/arm/fvp_base_revc_2xaemv8a/doc/index.rst +++ b/boards/arm/fvp_base_revc_2xaemv8a/doc/index.rst @@ -99,7 +99,7 @@ Checkout and Build the TF-A: cd trusted-firmware-a/ make PLAT=fvp PRELOADED_BL33_BASE="0x88000000" all fip -then export the ``ARMFVP_BL1_FILE` and ``ARMFVP_FIP_FILE`` environment variables: +then export the :envvar:`ARMFVP_BL1_FILE` and :envvar:`ARMFVP_FIP_FILE` environment variables: .. code-block:: console diff --git a/boards/circuitdojo/feather/doc/index.rst b/boards/circuitdojo/feather/doc/index.rst index 1988a00e98f..998cfbcfdac 100644 --- a/boards/circuitdojo/feather/doc/index.rst +++ b/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. 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 ======== diff --git a/boards/ct/ctcc/doc/index.rst b/boards/ct/ctcc/doc/index.rst index 38987822b6e..914df63b3aa 100644 --- a/boards/ct/ctcc/doc/index.rst +++ b/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:: - In all examples it is assumed to use default `root-rsa-2048.pem` file from ``mcuboot/boot`` + In all examples it is assumed to use default :file:`root-rsa-2048.pem` file from ``mcuboot/boot`` directory. Providing certificate in build args produces signed binary automatically. Do not use this certificate in your production firmware! @@ -180,7 +180,7 @@ As an example we'll use the :zephyr:code-sample:`usb-cdc-acm-console` sample. and plug such adapter to USB port. You should see ``NordicSemiconductor MCUBOOT`` or ``NordicSemiconductor Zephyr DFU sample`` - (if you flashed `dfu` sample to slot0) device once plugging it into host + (if you flashed ``dfu`` sample to slot0) device once plugging it into host USB port. You can check that on Linux system by entering ``lsusb`` command. To check if DFU device is visible you can enter ``sudo dfu-util -l`` command. Once the diff --git a/boards/enjoydigital/litex_vexriscv/doc/index.rst b/boards/enjoydigital/litex_vexriscv/doc/index.rst index 2946802be5e..f9764907eb4 100644 --- a/boards/enjoydigital/litex_vexriscv/doc/index.rst +++ b/boards/enjoydigital/litex_vexriscv/doc/index.rst @@ -184,7 +184,7 @@ Use `ecpprog `_ to upload the bitstream t ecpprog -S antmicro_sdi_mipi_video_converter.bit -You can boot from a serial port using litex_term (replace `ttyUSBX` with your device) , e.g.: +You can boot from a serial port using litex_term (replace ``ttyUSBX`` with your device) , e.g.: .. code-block:: bash diff --git a/boards/intel/rpl/doc/index.rst b/boards/intel/rpl/doc/index.rst index 4c078ab765e..e6bc4015256 100644 --- a/boards/intel/rpl/doc/index.rst +++ b/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 compact single board computer with high performance for IoT edge devices. The -supported boards are `intel_rpl_s_crb` and `intel_rpl_p_crb`. +supported boards are ``intel_rpl_s_crb`` and ``intel_rpl_p_crb``. These board configurations enable kernel support for the supported Raptor Lake boards. diff --git a/boards/intel/socfpga/agilex5_socdk/doc/index.rst b/boards/intel/socfpga/agilex5_socdk/doc/index.rst index 006ca066251..4208d8b70be 100644 --- a/boards/intel/socfpga/agilex5_socdk/doc/index.rst +++ b/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. 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 ************************* diff --git a/boards/m5stack/m5stack_core2/doc/index.rst b/boards/m5stack/m5stack_core2/doc/index.rst index 3e492af3532..c7a907a3e34 100644 --- a/boards/m5stack/m5stack_core2/doc/index.rst +++ b/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. | | | | For details please refer to :ref:`m5stack_core2_ext` | | +------------------+--------------------------------------------------------------------------+-----------+ -| Grove port | Note: Grove port requires 5V to be enabled via `bus_5v` regulator | supported | +| Grove port | Note: Grove port requires 5V to be enabled via ``bus_5v`` regulator | supported | +------------------+--------------------------------------------------------------------------+-----------+ | Built-in | The `SPM-1423`_ I2S driven microphone. | todo | | microphone | | | diff --git a/boards/native/doc/arch_soc.rst b/boards/native/doc/arch_soc.rst index 36fd1b01ecf..d07a9c589a2 100644 --- a/boards/native/doc/arch_soc.rst +++ b/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`, :kconfig:option:`CONFIG_STACK_CANARIES`, and :kconfig:option:`CONFIG_THREAD_ANALYZER`. - This is due to how Zephyr allocated threads' stacks are not `actually` being used like they are + This is due to how Zephyr allocated threads' stacks are not *actually* being used like they are in other architectures. Check :ref:`the architecture section's architecture layer paragraph ` for more information. @@ -355,7 +355,7 @@ while this newly created thread will be the first "SW" thread and start executing the boot of the embedded code (including the POSIX arch code). During this MCU boot process, the Zephyr kernel will be initialized and -eventually this will call into the embedded application `main()`, +eventually this will call into the embedded application ``main()``, just like in the embedded target. As the embedded SW execution progresses, more Zephyr threads may be spawned, and for each the POSIX architecture will create a dedicated pthread. @@ -413,7 +413,7 @@ Busy waits Busy waits work thanks to provided board functionality. This does not need to be the same for all boards, but both native_sim and the nrf52_bsim board work similarly thru the combination of a board specific -`arch_busy_wait()` and a special fake HW timer (provided by the board). +:c:func:`arch_busy_wait()` and a special fake HW timer (provided by the board). When a SW thread wants to busy wait, this fake timer will be programmed in the future time corresponding to the end of the busy wait and the CPU will @@ -422,7 +422,7 @@ When this fake HW timer expires the CPU will be waken with a special non-maskable phony interrupt which does not have a corresponding interrupt handler but will resume the busy_wait SW execution. Note that other interrupts may arrive while the busy wait is in progress, -which may delay the `k_busy_wait()` return just like in real life. +which may delay the :c:func:`k_busy_wait()` return just like in real life. Interrupts may be locked out or masked during this time, but the special fake-timer non-maskable interrupt will wake the CPU nonetheless. diff --git a/boards/native/doc/bsim_boards_design.rst b/boards/native/doc/bsim_boards_design.rst index 7fef9d1b522..a8d45a5d705 100644 --- a/boards/native/doc/bsim_boards_design.rst +++ b/boards/native/doc/bsim_boards_design.rst @@ -16,7 +16,7 @@ Bsim boards This page covers the design, architecture and rationale, of the nrf5x_bsim boards and other similar bsim boards. -These boards are postfixed with `_bsim` as they use BabbleSim_ +These boards are postfixed with ``_bsim`` as they use BabbleSim_ (shortened bsim), to simulate the radio environment. These boards use the `native simulator`_ and the :ref:`POSIX architecture` to build and execute the embedded code natively on Linux. @@ -135,13 +135,13 @@ The basic architecture layering of these boards is as follows: simulation specific ones. - The architecture (arch) is the Zephyr :ref:`POSIX architecture` layer. - The SOC layer is `inf_clock`. And the board layer is dependent on + The SOC layer is ``inf_clock``. And the board layer is dependent on the specific device we are simulating. - The POSIX architecture provides an adaptation from the Zephyr arch API (which handles mostly the thread context switching) to the native simulator CPU thread emulation. See :ref:`POSIX arch architecture` -- The SOC `inf_clock` layer provides an adaptation to the native simulator CPU "simulation" +- The SOC ``inf_clock`` layer provides an adaptation to the native simulator CPU "simulation" and the handling of control between the "CPU simulation" (Zephyr threads) and the HW models thread ( See `Threading`_ ). - The board layer provides all SOC/ IC specific content, including @@ -149,13 +149,13 @@ The basic architecture layering of these boards is as follows: busy wait API (see :ref:`posix_busy_wait`), and Zephyr's printk backend. Note that in a normal Zephyr target interrupt handling and a custom busy wait would be provided by the SOC layer, but abusing Zephyr's layering, and for the - `inf_clock` layer to be generic, these were delegated to the board. + ``inf_clock`` layer to be generic, these were delegated to the board. The board layer provides other test specific functionality like bs_tests hooks, trace control, etc, and by means of the native simulator, provides the :c:func:`main` entry point for the Linux program, command line argument handling, and the overall time scheduling of the simulated device. - Note that the POSIX arch and `inf_clock` soc expect a set of APIs being provided by + Note that the POSIX arch and ``inf_clock`` soc expect a set of APIs being provided by the board. This includes the busy wait API, a basic tracing API, the interrupt controller and interrupt handling APIs, :c:func:`posix_exit`, and :c:func:`posix_get_hw_cycle` (see :file:`posix_board_if.h` and :file:`posix_soc_if.h`). @@ -173,7 +173,7 @@ Important limitations and unsupported features All native and bsim boards share the same set of :ref:`important limitations which` -are inherited from the POSIX arch and `inf_clock` design. +are inherited from the POSIX arch and ``inf_clock`` design. Similarly, they inherit the POSIX architecture :ref:`unsupported features set `. @@ -261,7 +261,7 @@ posix_print and nsi_print backends ================================== The bsim board provides a backend for the ``posix_print`` API which is expected by the posix -ARCH and `inf_clock` code, and for the ``nsi_print`` API expected by the native simulator. +ARCH and ``inf_clock`` code, and for the ``nsi_print`` API expected by the native simulator. These simply route this API calls into the ``bs_trace`` bsim API. Any message printed to these APIs, and by extension by default to Zephyr's ``printk``, @@ -287,12 +287,12 @@ callbacks are assigned to the respective hooks. There is a set of one time hooks at different levels of initialization of the HW and Zephyr OS, a hook to process possible command line arguments, and, a hook that can be used to sniff or capture interrupts. -`bs_tests` also provides a hook which will be called from the embedded application +``bs_tests`` also provides a hook which will be called from the embedded application :c:func:`main`, but this will only work if the main application supports it, that is, if the main app is a version for simulation which calls :c:func:`bst_main` when running in the bsim board. -Apart from these hooks, the `bs_tests` system provides facilities to build a +Apart from these hooks, the ``bs_tests`` system provides facilities to build a dedicated test "task". This will be executed in the HW models thread context, but will have access to all SW variables. This task will be driven with a special timer which can be configured to produce either periodic or one time @@ -302,15 +302,15 @@ at specific points in time. This can be combined with Babblesim's tb_defs macros to build quite complex test tasks which can wait for a given amount of time, for conditions to be fulfilled, etc. -Note when writing the tests with `bs_tests` one needs to be aware that other +Note when writing the tests with ``bs_tests`` one needs to be aware that other bs tests will probably be built with the same application, and that therefore the tests should not be registering initialization or callback functions using NATIVE_TASKS or Zephyr's PRE/POST kernel driver initialization APIs as this will execute even if the test is not selected. -Instead the equivalent `bs_tests` provided hooks should be used. +Instead the equivalent ``bs_tests`` provided hooks should be used. Note also that, for AMP targets like the :ref:`nrf5340bsim `, each embedded MCU has -its own separate `bs_tests` built with that MCU. You can select if and what test is used +its own separate ``bs_tests`` built with that MCU. You can select if and what test is used for each MCU separatedly with the command line options. Command line argument parsing diff --git a/boards/nxp/lpcxpresso54114/doc/index.rst b/boards/nxp/lpcxpresso54114/doc/index.rst index 644de94e415..0402d19d239 100644 --- a/boards/nxp/lpcxpresso54114/doc/index.rst +++ b/boards/nxp/lpcxpresso54114/doc/index.rst @@ -74,8 +74,8 @@ features: The default configuration for each core can be found in the defconfig files: - `boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m4_defconfig` - `boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m0_defconfig` +- :zephyr_file:`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m4_defconfig` +- :zephyr_file:`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m0_defconfig` Other hardware features are not currently supported by the port. diff --git a/boards/nxp/lpcxpresso55s69/doc/index.rst b/boards/nxp/lpcxpresso55s69/doc/index.rst index 59177094363..4c157c9f5f0 100644 --- a/boards/nxp/lpcxpresso55s69/doc/index.rst +++ b/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. - 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` ------------------------------------------ diff --git a/boards/nxp/mimxrt1040_evk/doc/index.rst b/boards/nxp/mimxrt1040_evk/doc/index.rst index 227ad4ff720..c6322960f24 100644 --- a/boards/nxp/mimxrt1040_evk/doc/index.rst +++ b/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. -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 ----------- diff --git a/boards/nxp/mimxrt1170_evk/doc/index.rst b/boards/nxp/mimxrt1170_evk/doc/index.rst index f3260f9c273..c3de9f8fd3b 100644 --- a/boards/nxp/mimxrt1170_evk/doc/index.rst +++ b/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 Zephyr, to better enable the entire RT11xx family. NXP prioritizes enabling this board with new support for Zephyr features. Note that this table -covers two boards: the RT1170 EVK (`mimxrt1170_evk//cm7/cm4`), and -RT1170 EVKB (`mimxrt1170_evk@B//cm7/cm4`) +covers two boards: the RT1170 EVK (``mimxrt1170_evk//cm7/cm4``), and +RT1170 EVKB (``mimxrt1170_evk@B//cm7/cm4``) +-----------+------------+-------------------------------------+-----------------+-----------------+ | Interface | Controller | Driver/Component | RT1170 EVK | RT1170 EVKB | @@ -478,4 +478,4 @@ ENET1G Driver Current default of ethernet driver is to use 100M Ethernet instance ENET. To use the 1G Ethernet instance ENET1G, include the overlay to west build with -the option `-DEXTRA_DTC_OVERLAY_FILE=nxp,enet1g.overlay` instead. +the option ``-DEXTRA_DTC_OVERLAY_FILE=nxp,enet1g.overlay`` instead. diff --git a/boards/nxp/rd_rw612_bga/doc/index.rst b/boards/nxp/rd_rw612_bga/doc/index.rst index e195913e45c..558effd60a3 100644 --- a/boards/nxp/rd_rw612_bga/doc/index.rst +++ b/boards/nxp/rd_rw612_bga/doc/index.rst @@ -196,7 +196,7 @@ Remove resistors: - R508 - R505 -Then, build for the board target `rd_rw612_bga//ethernet`. +Then, build for the board target ``rd_rw612_bga//ethernet``. Resources ********* diff --git a/boards/nxp/s32z2xxdc2/doc/index.rst b/boards/nxp/s32z2xxdc2/doc/index.rst index 1b7423c693d..58e5ea3660c 100644 --- a/boards/nxp/s32z2xxdc2/doc/index.rst +++ b/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 -be accessed by default on the USB micro-B connector `J119`. +be accessed by default on the USB micro-B connector J119. Watchdog ======== diff --git a/boards/phytec/phyboard_electra/doc/index.rst b/boards/phytec/phyboard_electra/doc/index.rst index 4fe9c5afd55..372f8d3cd73 100644 --- a/boards/phytec/phyboard_electra/doc/index.rst +++ b/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 -to build and run the `basic/blinky` sample. +to build and run the :zephyr:code-sample:`blinky` sample. SD Card ******* @@ -111,9 +111,11 @@ To test the M4F core, we build the :ref:`hello_world` sample with the following :zephyr-app: samples/hello_world :goals: build -This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`. +This builds the program and the binary is present in the :file:`build/zephyr` directory as +:file:`zephyr.elf`. -We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am64-mcu-m4f0_0-fw`. +We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as +:file:`am64-mcu-m4f0_0-fw`. .. code-block:: console diff --git a/boards/phytec/phyboard_lyra/doc/phyboard_lyra_am62xx_m4.rst b/boards/phytec/phyboard_lyra/doc/phyboard_lyra_am62xx_m4.rst index bfd3ff5579f..55d4939529f 100644 --- a/boards/phytec/phyboard_lyra/doc/phyboard_lyra_am62xx_m4.rst +++ b/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 load it while booting using remoteproc. -To test the M4F core, we build the `hello_world` sample with the following command. +To test the M4F core, we build the :ref:`hello_world` sample with the following command. .. code-block:: console # From the root of the Zephyr repository west build -p -b phyboard_lyra/am6234/m4 samples/hello_world -This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`. +This builds the program and the binary is present in the :file:`build/zephyr` directory as +:file:`zephyr.elf`. -We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am62-mcu-m4f0_0-fw`. +We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as +:file:`am62-mcu-m4f0_0-fw`. .. code-block:: console @@ -134,7 +136,8 @@ port. Debugging ********* -The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the `debug` build target: +The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the ``debug`` build +target: .. zephyr-app-commands:: :app: diff --git a/boards/rak/rak11720/doc/index.rst b/boards/rak/rak11720/doc/index.rst index 7f4054a90d5..ff8e90a962b 100644 --- a/boards/rak/rak11720/doc/index.rst +++ b/boards/rak/rak11720/doc/index.rst @@ -92,7 +92,7 @@ Build the Zephyr kernel and application, then flash it to the device: :goals: flash .. note:: - `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module + ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module to be installed on you host computer. Open a serial terminal (minicom, putty, etc.) with the following settings: diff --git a/boards/raspberrypi/rpi_5/doc/index.rst b/boards/raspberrypi/rpi_5/doc/index.rst index 46db56cff26..1c63e5a94ad 100644 --- a/boards/raspberrypi/rpi_5/doc/index.rst +++ b/boards/raspberrypi/rpi_5/doc/index.rst @@ -69,7 +69,7 @@ In brief, * `bcm2712-rpi-5.dtb`_ 3. Insert the Micro SD card and power on the Raspberry Pi 5. -then, You will see the Raspberry Pi 5 running the `zephyr.bin`. +then, You will see the Raspberry Pi 5 running the :file:`zephyr.bin`. config.txt ---------- @@ -83,14 +83,15 @@ config.txt zephyr.bin ---------- -Build an app `samples/basic/blinky` +Build an app, for example :zephyr:code-sample:`blinky` .. zephyr-app-commands:: :zephyr-app: samples/basic/blinky :board: rpi_5 :goals: build -Copy `zephyr.bin` from `build/zephyr` directory to the root directory of the Micro SD card. +Copy :file:`zephyr.bin` from :file:`build/zephyr` directory to the root directory of the Micro SD +card. Insert the Micro SD card and power on the Raspberry Pi 5. And then, the STAT LED will start to blink. @@ -125,14 +126,14 @@ config.txt zephyr.bin ---------- -Build an app `samples/hello_world` +Build an app, for example :ref:`hello_world`: .. zephyr-app-commands:: :zephyr-app: samples/hello_world :board: rpi_5 :goals: build -Copy `zephyr.bin` from `build/zephyr` directory to the root directory of the Micro SD card. +Copy :file:`zephyr.bin` from :file:`build/zephyr` directory to the root directory of the Micro SD card. Insert the Micro SD card into your Raspberry Pi 5. diff --git a/boards/raspberrypi/rpi_pico/doc/index.rst b/boards/raspberrypi/rpi_pico/doc/index.rst index d88d1bf4f35..b2af4693b01 100644 --- a/boards/raspberrypi/rpi_pico/doc/index.rst +++ b/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 co-processors that are designed for I/O operations. The PIOs run a custom instruction set, generated from a custom assembly language. -PIO programs are assembled using `pioasm`, a tool provided by Raspberry Pi. +PIO programs are assembled using :command:`pioasm`, a tool provided by Raspberry Pi. Zephyr does not (currently) assemble PIO programs. Rather, they should be manually assembled and embedded in source code. An example of how this is done -can be found at `drivers/serial/uart_rpi_pico_pio.c`. +can be found at :zephyr_file:`drivers/serial/uart_rpi_pico_pio.c`. Sample: SPI via PIO ==================== @@ -187,7 +187,7 @@ Create a file in /etc/udev.rules.d with any name, and write the line below. ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess" -This example is valid for the case that the user joins to `plugdev` groups. +This example is valid for the case that the user joins to ``plugdev`` groups. The Raspberry Pi Pico has an SWD interface that can be used to program and debug the on board RP2040. This interface can be utilized by OpenOCD. @@ -208,22 +208,23 @@ Here is an example of building and flashing the :zephyr:code-sample:`blinky` app :goals: build flash :gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=cmsis-dap -Set the environment variables **OPENOCD** to `/usr/local/bin/openocd` -and **OPENOCD_DEFAULT_PATH** to `/usr/local/share/openocd/scripts`. This should work +Set the environment variables **OPENOCD** to :file:`/usr/local/bin/openocd` +and **OPENOCD_DEFAULT_PATH** to :file:`/usr/local/share/openocd/scripts`. This should work with the OpenOCD that was installed with the default configuration. This configuration also works with an environment that is set up by the `pico_setup.sh`_ script. **RPI_PICO_DEBUG_ADAPTER** specifies what debug adapter is used for debugging. -If **RPI_PICO_DEBUG_ADAPTER** was not assigned, `cmsis-dap` is used by default. -The other supported adapters are `raspberrypi-swd`, `jlink` and `blackmagicprobe`. -How to connect `cmsis-dap` and `raspberrypi-swd` is described in `Getting Started with Raspberry Pi Pico`_. +If **RPI_PICO_DEBUG_ADAPTER** was not assigned, ``cmsis-dap`` is used by default. +The other supported adapters are ``raspberrypi-swd``, ``jlink`` and ``blackmagicprobe``. +How to connect ``cmsis-dap`` and ``raspberrypi-swd`` is described in `Getting Started with Raspberry Pi Pico`_. Any other SWD debug adapter maybe also work with this configuration. The value of **RPI_PICO_DEBUG_ADAPTER** is cached, so it can be omitted from -`west flash` and `west debug` if it was previously set while running `west build`. +``west flash`` and ``west debug`` if it was previously set while running +``west build``. -**RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as `"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"`. +**RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as ``"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"``. Thus, **RPI_PICO_DEBUG_ADAPTER** needs to be assigned the file name of the debug adapter. You can also flash the board with the following @@ -238,7 +239,7 @@ Using UF2 If you don't have an SWD adapter, you can flash the Raspberry Pi Pico with a UF2 file. By default, building an app for this board will generate a -`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the `BOOTSEL` +:file:`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the ``BOOTSEL`` button pressed, it will appear on the host as a mass storage device. The UF2 file should be drag-and-dropped to the device, which will flash the Pico. @@ -270,7 +271,7 @@ Here is an example for debugging the :zephyr:code-sample:`blinky` application. :gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=raspberrypi-swd As with flashing, you can specify the debug adapter by specifying **RPI_PICO_DEBUG_ADAPTER** -at `west build` time. No needs to specify it at `west debug` time. +at ``west build`` time. No needs to specify it at ``west debug`` time. You can also debug with OpenOCD and gdb launching from command-line. Run the following command: diff --git a/boards/renesas/rzt2m_starterkit/doc/index.rst b/boards/renesas/rzt2m_starterkit/doc/index.rst index 72dc6615f64..eecaa1bc3c6 100644 --- a/boards/renesas/rzt2m_starterkit/doc/index.rst +++ b/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), * UART3 connected to the PMOD Header (J25, pins H16, G20), -* LEDs defined as `led0`, `led1`, `led2` and `led3`, +* LEDs defined as ``led0``, ``led1``, ``led2`` and ``led3``, The Zephyr console uses UART0. @@ -78,7 +78,7 @@ Debugging ========= Connect to the board using the J-Link On-board USB connector. -Use `west` to start the debug server: +Use ``west`` to start the debug server: .. code-block:: console diff --git a/boards/seeed/xiao_ble/doc/index.rst b/boards/seeed/xiao_ble/doc/index.rst index eda1476149e..d91729dccd6 100644 --- a/boards/seeed/xiao_ble/doc/index.rst +++ b/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 double tap the reset botton to the left of the USB connector. A mass storage -device named `XIAO BLE` should appear on the host. Using the command line, or -your file manager copy the `zephyr/zephyr.uf2` file from your build to the base -of the `XIAO BLE` mass storage device. The XIAO BLE will automatically reset +device named ``XIAO BLE`` should appear on the host. Using the command line, or +your file manager copy the :file:`zephyr/zephyr.uf2` file from your build to the base +of the ``XIAO BLE`` mass storage device. The XIAO BLE will automatically reset and launch the newly flashed application. External Debugger diff --git a/boards/seeed/xiao_esp32c3/doc/index.rst b/boards/seeed/xiao_esp32c3/doc/index.rst index ae2fe7a58ed..e8346632b96 100644 --- a/boards/seeed/xiao_esp32c3/doc/index.rst +++ b/boards/seeed/xiao_esp32c3/doc/index.rst @@ -172,7 +172,7 @@ For the :code:`Hello, world!` application, follow the instructions below. :board: xiao_esp32c3 :goals: build flash -Since the Zephyr console is by default on the `usb_serial` device, we use +Since the Zephyr console is by default on the ``usb_serial`` device, we use the espressif monitor to view. .. code-block:: console diff --git a/boards/shields/mikroe_mcp2518fd_click/doc/index.rst b/boards/shields/mikroe_mcp2518fd_click/doc/index.rst index ad87d2a4559..e54bf7509c7 100644 --- a/boards/shields/mikroe_mcp2518fd_click/doc/index.rst +++ b/boards/shields/mikroe_mcp2518fd_click/doc/index.rst @@ -16,7 +16,7 @@ Requirements ************ The shield uses a mikroBUS interface. The target board must define -a `mikrobus_spi` and `mikrobus_header` node labels +a ``mikrobus_spi`` and ``mikrobus_header`` node labels (see :ref:`shields` for more details). The target board must also support level triggered interrupts. diff --git a/boards/shields/rpi_pico_uno_flexypin/doc/index.rst b/boards/shields/rpi_pico_uno_flexypin/doc/index.rst index 203578b5a43..f7d19831e6e 100644 --- a/boards/shields/rpi_pico_uno_flexypin/doc/index.rst +++ b/boards/shields/rpi_pico_uno_flexypin/doc/index.rst @@ -6,12 +6,13 @@ RaspberryPi Pico to UNO FlexyPin Adapter Overview ******** -Raspberry Pi Pico to Uno `FlexyPin Adapter` is a converter-PCB to Arduino UNO form-factor -from Raspberry Pi Pico that is released in Open Source Hardware. -This board design to use with `FlexyPin`. +The Raspberry Pi Pico to Uno FlexyPin Adapter is an open-source hardware converter PCB that adapts +the Raspberry Pi Pico to the Arduino UNO form factor +This board is designed to be use with FlexyPin connector pins. The FlexyPin holds Pico and contacts to castellated through-hole. -With simple soldering, it can also be used as a board to convert the RapsberryPi Pico -o the Arduino UNO form factor. + +With simple soldering, it can also be used as a board to convert the Rapsberry Pi Pico +to the Arduino UNO form factor. .. image:: img/rpi_pico_uno_flexypin.png :align: center diff --git a/boards/silabs/dev_kits/sltb010a/doc/index.rst b/boards/silabs/dev_kits/sltb010a/doc/index.rst index c7f3452ce48..bbca08c762c 100644 --- a/boards/silabs/dev_kits/sltb010a/doc/index.rst +++ b/boards/silabs/dev_kits/sltb010a/doc/index.rst @@ -149,7 +149,7 @@ BRD4184B: :goals: flash .. note:: - `west flash` requires `SEGGER J-Link software`_ to be installed on you host + ``west flash`` requires `SEGGER J-Link software`_ to be installed on you host computer. Open a serial terminal (minicom, putty, etc.) with the following settings: diff --git a/boards/silabs/dev_kits/xg27_dk2602a/doc/index.rst b/boards/silabs/dev_kits/xg27_dk2602a/doc/index.rst index 8bf44f5edbd..abaafbf0d2a 100644 --- a/boards/silabs/dev_kits/xg27_dk2602a/doc/index.rst +++ b/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. - If Simplicity Commander is installed in the system and the directory in - which `commander` executable is located is present in the `PATH` environment + which ``commander`` executable is located is present in the :envvar:`PATH` environment variable: .. code-block:: console west flash -- Otherwise, one should specify full path to the `commander` executable: +- Otherwise, one should specify full path to the ``commander`` executable: .. code-block:: console @@ -114,7 +114,7 @@ Build the Zephyr kernel and application: :goals: build Connect your device to your host computer using the USB port and you -should see a USB connection. Use `west`'s flash command +should see a USB connection. Use ``west``'s flash command Open a serial terminal (minicom, putty, etc.) with the following settings: diff --git a/boards/sparkfun/micromod/doc/index.rst b/boards/sparkfun/micromod/doc/index.rst index 0ba4c37bbef..294441f66d7 100644 --- a/boards/sparkfun/micromod/doc/index.rst +++ b/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). The flashing tool will depend on the carrier used along with the board. -In the case of `Sparkfun asset tracking carrier`, it is possible to use +In the case of `Sparkfun asset tracking carrier`_, it is possible to use the SWD interface along with a J-Link. Here is an example for the :ref:`hello_world` application. @@ -199,6 +199,7 @@ References .. target-notes:: .. _Micromod specification website: https://www.sparkfun.com/micromod +.. _Sparkfun asset tracking carrier: https://www.sparkfun.com/products/17272 .. _Micromod nRF52840 guide: https://learn.sparkfun.com/tutorials/micromod-nrf52840-processor-hookup-guide .. _J-Link Software and documentation pack: https://www.segger.com/jlink-software.html .. _nRF52840 Product Specification: http://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.0.pdf diff --git a/boards/sparkfun/pro_micro_rp2040/doc/index.rst b/boards/sparkfun/pro_micro_rp2040/doc/index.rst index cc8188aa3f1..f538a04b1ce 100644 --- a/boards/sparkfun/pro_micro_rp2040/doc/index.rst +++ b/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 debugger. You can also flash the SparkFun ProMicro RP2040 with a UF2 file. By default, building an app for this board will generate a -`build/zephyr/zephyr.uf2` file. If the Pro Micro RP2040 is powered on with -the `BOOTSEL` button pressed, it will appear on the host as a mass storage +:file:`build/zephyr/zephyr.uf2` file. If the Pro Micro RP2040 is powered on with +the ``BOOTSEL`` button pressed, it will appear on the host as a mass storage device. The UF2 file should be copied to the device, which will flash the Pro Micro RP2040. diff --git a/boards/sparkfun/thing_plus/doc/index.rst b/boards/sparkfun/thing_plus/doc/index.rst index a6c7aee9742..1e9994eb0ff 100644 --- a/boards/sparkfun/thing_plus/doc/index.rst +++ b/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. 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 ======== diff --git a/boards/st/b_u585i_iot02a/doc/index.rst b/boards/st/b_u585i_iot02a/doc/index.rst index f057800aed3..f39be8503ce 100644 --- a/boards/st/b_u585i_iot02a/doc/index.rst +++ b/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, -using `tfm_ipc_` sample: +using :ref:`tfm_ipc` sample: .. code-block:: bash @@ -236,7 +236,7 @@ option bit TZEN will be set). $ west flash Please note that, after having run a TFM sample on the board, you will need to -run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure +run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure options and get back the platform back to a "normal" state and be able to run usual, non-TFM, binaries. Also note that, even then, TZEN will remain set, and you will need to use diff --git a/boards/st/nucleo_l552ze_q/doc/nucleol552ze_q.rst b/boards/st/nucleo_l552ze_q/doc/nucleol552ze_q.rst index 7339c0b10bd..fa9fa9ef43c 100644 --- a/boards/st/nucleo_l552ze_q/doc/nucleol552ze_q.rst +++ b/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, -using `tfm_ipc_` sample: +using :ref:`tfm_ipc` sample: - .. code-block:: bash + .. code-block:: console $ west build -b nucleo_l552ze_q/stm32l552xx/ns samples/tfm_integration/tfm_ipc/ @@ -213,7 +213,7 @@ option bit TZEN will be set). $ west flash Please note that, after having run a TFM sample on the board, you will need to -run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure +run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure options and get back the platform back to a "normal" state and be able to run usual, non-TFM, binaries. Also note that, even then, TZEN will remain set, and you will need to use diff --git a/boards/st/stm32l562e_dk/doc/index.rst b/boards/st/stm32l562e_dk/doc/index.rst index 5982ec34f8f..7fe566172dd 100644 --- a/boards/st/stm32l562e_dk/doc/index.rst +++ b/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, -using `tfm_ipc_` sample: +using :ref:`tfm_ipc` sample: .. code-block:: bash @@ -239,7 +239,7 @@ option bit TZEN will be set). $ west flash Please note that, after having run a TFM sample on the board, you will need to -run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure +run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure options and get back the platform back to a "normal" state and be able to run usual, non-TFM, binaries. Also note that, even then, TZEN will remain set, and you will need to use diff --git a/boards/st/stm32wb5mm_dk/doc/stm32wb5mm_dk.rst b/boards/st/stm32wb5mm_dk/doc/stm32wb5mm_dk.rst index 254bd38fe6e..9ee025f45e9 100644 --- a/boards/st/stm32wb5mm_dk/doc/stm32wb5mm_dk.rst +++ b/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`_ in the ``hal_stm32`` repo. -Note that since STM32WB Cube package V1.13.2, `"full stack"` binaries are not -compatible anymore for a use in Zephyr and only `"HCI Only"` versions should be +Note that since STM32WB Cube package V1.13.2, "full stack" binaries are not +compatible anymore for a use in Zephyr and only "HCI Only" versions should be used on the M0 side. Connections and IOs diff --git a/boards/st/stm32wb5mmg/doc/stm32wb5mmg.rst b/boards/st/stm32wb5mmg/doc/stm32wb5mmg.rst index 4781fa0f7bc..7b8ee9f0062 100644 --- a/boards/st/stm32wb5mmg/doc/stm32wb5mmg.rst +++ b/boards/st/stm32wb5mmg/doc/stm32wb5mmg.rst @@ -248,8 +248,8 @@ the ``--runner`` (or ``-r``) option: $ west flash --runner openocd -Flashing `hci_uart` application to STM32WB5MMG ----------------------------------------------- +Flashing ``hci_uart`` application to STM32WB5MMG +------------------------------------------------ Connect the B-U585I-IOT02A to your host computer using the USB port. Put the SW4 (MCU SWD) in OFF mode and SW5 (SWD BLE) in ON mode. Then build diff --git a/boards/telink/tlsr9518adk80d/doc/index.rst b/boards/telink/tlsr9518adk80d/doc/index.rst index e80db259a77..97413403889 100644 --- a/boards/telink/tlsr9518adk80d/doc/index.rst +++ b/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 ========= -This port supports UART debug and OpenOCD+GDB. The `west debug` command also supported. You may run +This port supports UART debug and OpenOCD+GDB. The ``west debug`` command also supported. You may run it in a simple way, like: .. code-block:: console diff --git a/boards/ti/sk_am62/doc/index.rst b/boards/ti/sk_am62/doc/index.rst index f7bb4f66b91..98f03bf7dff 100644 --- a/boards/ti/sk_am62/doc/index.rst +++ b/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. -To test the M4F core, we build the `hello_world` sample with the following command. +To test the M4F core, we build the :ref:`hello_world` sample with the following command. .. code-block:: console # From the root of the Zephyr repository west build -p -b sk_am62/am6234/m4 samples/hello_world -This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`. +This builds the program and the binary is present in the :file:`build/zephyr` directory as +:file:`zephyr.elf`. -We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am62-mcu-m4f0_0-fw`. +We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as +:file:`am62-mcu-m4f0_0-fw`. .. code-block:: console @@ -122,7 +124,7 @@ The binary will run and print Hello world to the MCU_UART0 port. Debugging ********* -The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the `debug` build target: +The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the ``debug`` build target: .. zephyr-app-commands:: :app: diff --git a/boards/wiznet/w5500_evb_pico/doc/index.rst b/boards/wiznet/w5500_evb_pico/doc/index.rst index 63d63370f76..4763f5e5398 100644 --- a/boards/wiznet/w5500_evb_pico/doc/index.rst +++ b/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" -This example is valid for the case that the user joins to `plugdev` groups. +This example is valid for the case that the user joins to ``plugdev`` groups. The Raspberry Pi Pico, and thus the W55500 Evaluation Board, has an SWD interface that can be used to program and debug the on board RP2040. This @@ -189,26 +189,26 @@ application. :goals: build flash :gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=picoprobe -Set the environment variables **OPENOCD** to `/usr/local/bin/openocd` and -**OPENOCD_DEFAULT_PATH** to `/usr/local/share/openocd/scripts`. This should +Set the environment variables **OPENOCD** to :file:`/usr/local/bin/openocd` and +**OPENOCD_DEFAULT_PATH** to :file:`/usr/local/share/openocd/scripts`. This should work with the OpenOCD that was installed with the default configuration. This configuration also works with an environment that is set up by the `pico_setup.sh`_ script. **RPI_PICO_DEBUG_ADAPTER** specifies what debug adapter is used for debugging. -If **RPI_PICO_DEBUG_ADAPTER** was not assigned, `picoprobe` is used by default. -The other supported adapters are `raspberrypi-swd`, `jlink` and -`blackmagicprobe`. How to connect `picoprobe` and `raspberrypi-swd` is +If **RPI_PICO_DEBUG_ADAPTER** was not assigned, ``picoprobe`` is used by default. +The other supported adapters are ``raspberrypi-swd``, ``jlink`` and +``blackmagicprobe``. How to connect ``picoprobe`` and ``raspberrypi-swd`` is described in `Getting Started with Raspberry Pi Pico`_. Any other SWD debug adapter maybe also work with this configuration. The value of **RPI_PICO_DEBUG_ADAPTER** is cached, so it can be omitted from -`west flash` and `west debug` if it was previously set while running -`west build`. +``west flash`` and ``west debug`` if it was previously set while running +``west build``. **RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as -`"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"`. Thus, +``"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"``. Thus, **RPI_PICO_DEBUG_ADAPTER** needs to be assigned the file name of the debug adapter. @@ -224,7 +224,7 @@ Using UF2 If you don't have an SWD adapter, you can flash the Raspberry Pi Pico with a UF2 file. By default, building an app for this board will generate a -`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the `BOOTSEL` +:file:`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the ``BOOTSEL`` button pressed, it will appear on the host as a mass storage device. The UF2 file should be drag-and-dropped to the device, which will flash the Pico. @@ -256,8 +256,8 @@ Here is an example for debugging the :zephyr:code-sample:`blinky` application. :gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=raspberrypi-swd As with flashing, you can specify the debug adapter by specifying -**RPI_PICO_DEBUG_ADAPTER** at `west build` time. No needs to specify it at -`west debug` time. +**RPI_PICO_DEBUG_ADAPTER** at ``west build`` time. No needs to specify it at +``west debug`` time. You can also debug with OpenOCD and gdb launching from command-line. Run the following command: diff --git a/doc/connectivity/bluetooth/api/audio/bluetooth-le-audio-arch.rst b/doc/connectivity/bluetooth/api/audio/bluetooth-le-audio-arch.rst index 9065f9e11cd..1156f2a4e89 100644 --- a/doc/connectivity/bluetooth/api/audio/bluetooth-le-audio-arch.rst +++ b/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, both in terms of structure but also naming. Most API functions are prefixed by the specification acronym -(e.g. `bt_bap` for the Basic Audio Profile (BAP) and `bt_vcp` for the Volume Control Profile (VCP)). -The functions are then further prefixed with the specific role from each profile where applicable -(e.g. :c:func:`bt_bap_unicast_client_discover` and :c:func:`bt_vcp_vol_rend_set_vol`). +(e.g. ``bt_bap`` for the Basic Audio Profile (BAP) and ``bt_vcp`` for the Volume Control Profile +(VCP)). The functions are then further prefixed with the specific role from each profile where +applicable (e.g. :c:func:`bt_bap_unicast_client_discover` and :c:func:`bt_vcp_vol_rend_set_vol`). There are usually a function per procedure defined by the profile or service specifications, and additional helper or meta functions that do not correspond to procedures. The structure of the files generally also follow this, -where BAP related files are prefixed with `bap` and VCP related files are prefixed with `vcp`. +where BAP related files are prefixed with ``bap`` and VCP related files are prefixed with ``vcp``. If the file is specific for a profile role, the role is also embedded in the file name. Generic Audio Framework (GAF) @@ -1065,8 +1065,8 @@ but the GTBS instance will report 2 calls, making it possible for a simple Call Control Client to control all calls from a single bearer. Similarly the supported URIs for each bearer are also made into a union in GTBS, and when placing a call using the GTBS the server will pick the most suited bearer depending on the URI. -For example calls with URI `tel` would go to the regular phone application, -and calls with the URI `skype` would go to the Teams application. +For example calls with URI ``tel`` would go to the regular phone application, +and calls with the URI ``skype`` would go to the Teams application. In conclusion the GTBS implementation in Zephyr is a union of the non-generic telephone bearers. @@ -1175,8 +1175,8 @@ the data is kept in and controlled by the application. As a rule of thumb, the return types of the callbacks for each profile implementation indicate whether the data is controlled by the stack or the application. -For example all the callbacks for the VCP Volume Renderer have the return type of `void`, -but the return type of the BAP Unicast Server callbacks are `int`, +For example all the callbacks for the VCP Volume Renderer have the return type of ``void``, +but the return type of the BAP Unicast Server callbacks are ``int``, indicating that the application not only controls a lot of the Unicast Server data, but can also reject the requests. The choice of what the return type of the callbacks often depend on the specifications, @@ -1202,7 +1202,7 @@ In Zephyr we do not force the device to always use these, as a device that uses use other profiles and services that do not require such security. We guard all access to services using a custom security check implemented in :zephyr_file:`subsys/bluetooth/audio/audio.c`, where all LE Audio services must use the -internal `BT_AUDIO_CHRC` macro for proper security verification. +internal :c:macro:`BT_AUDIO_CHRC` macro for proper security verification. Access to the LTK for encrypted SIRKs in CSIS --------------------------------------------- @@ -1235,10 +1235,10 @@ The LE audio channel on Discord Zephyr has a specific Discord channel for LE Audio development, which is open to all. Find it here at https://discordapp.com/channels/720317445772017664/1207326649591271434 or simply -search for `ble-audio` from within Discord. -Since the `ble-audio` channel is open for all, +search for "ble-audio" from within Discord. +Since the ``#ble-audio`` channel is open for all, we cannot discuss any specifications that are in development in that channel. -For discussions that require a Bluetooth SIG membership we refer to the `bluetooth-sig` +For discussions that require a Bluetooth SIG membership we refer to the ``#bluetooth-sig`` Discord channel found at https://discordapp.com/channels/720317445772017664/869172014018097162. Zephyr weekly meetings diff --git a/doc/connectivity/bluetooth/bluetooth-shell.rst b/doc/connectivity/bluetooth/bluetooth-shell.rst index 94a0c2d9e70..ad906e3ba8a 100644 --- a/doc/connectivity/bluetooth/bluetooth-shell.rst +++ b/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 -`ext-adv` parameter. +``ext-adv`` parameter. .. code-block:: console diff --git a/doc/connectivity/networking/api/coap_client.rst b/doc/connectivity/networking/api/coap_client.rst index 8d01d72a44d..518e697b106 100644 --- a/doc/connectivity/networking/api/coap_client.rst +++ b/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 - The request failed for some reason -The callback contains a flag `last_block`, which indicates if there is more data to come in the -response and means that the current response is part of a blockwise transfer. When the `last_block` -is set to true, the response is finished and the client is ready for the next request after -returning from the callback. +The callback contains a flag ``last_block``, which indicates if there is more data to come in the +response and means that the current response is part of a blockwise transfer. When the +``last_block`` is set to true, the response is finished and the client is ready for the next request +after returning from the callback. If the server responds to the request, the library provides the response to the application through the response callback registered in the request structure. diff --git a/doc/connectivity/networking/api/tls_credentials_shell.rst b/doc/connectivity/networking/api/tls_credentials_shell.rst index 76c074ae67d..df2818fd039 100644 --- a/doc/connectivity/networking/api/tls_credentials_shell.rst +++ b/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 credentials found. -Where `` is the number of credentials found, and is zero if none are found. +Where ```` is the number of credentials found, and is zero if none are found. .. _tls_credentials_shell_cred_types: diff --git a/doc/connectivity/networking/api/wifi.rst b/doc/connectivity/networking/api/wifi.rst index 9ae9b8cb26c..7803a456055 100644 --- a/doc/connectivity/networking/api/wifi.rst +++ b/doc/connectivity/networking/api/wifi.rst @@ -18,7 +18,8 @@ Only personal mode security is supported with below types: * WPA3-PSK-256 * WPA3-SAE -The Wi-Fi management API is implemented in the `wifi_mgmt` module as a part of the networking L2 stack. +The Wi-Fi management API is implemented in the ``wifi_mgmt`` module as a part of the networking L2 +stack. Currently, two types of Wi-Fi drivers are supported: * Networking or socket offloaded drivers @@ -29,7 +30,7 @@ Wi-Fi Enterprise test: X.509 Certificate header generation Wi-Fi enterprise security requires use of X.509 certificates, test certificates in PEM format are committed to the repo at :zephyr_file:`samples/net/wifi/test_certs` and the during the -build process the certificates are converted to a `C` header file that is included by the Wi-Fi shell +build process the certificates are converted to a C header file that is included by the Wi-Fi shell module. .. code-block:: bash @@ -46,16 +47,16 @@ To initiate Wi-Fi connection, the following command can be used: uart:~$ wifi connect -s -k 5 -a anon -K whatever Server certificate is also provided in the same directory for testing purposes. -Any `AAA` server can be used for testing purposes, for example, `FreeRADIUS` or `hostapd`. +Any AAA server can be used for testing purposes, for example, ``FreeRADIUS`` or ``hostapd``. .. important:: - The passphrase for the client-key.pem and the server-key.pem is `whatever`. + The passphrase for the :file:`client-key.pem`` and the :file:`server-key.pem` is ``whatever``. .. note:: The certificates are for testing purposes only and should not be used in production. - The certificates are generated using `FreeRADIUS raddb _` scripts. + They are generated using `FreeRADIUS raddb `_ scripts. API Reference ************* diff --git a/doc/connectivity/usb/device_next/usb_device.rst b/doc/connectivity/usb/device_next/usb_device.rst index f2e3556000b..1213c85fb51 100644 --- a/doc/connectivity/usb/device_next/usb_device.rst +++ b/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, while others use a general Zephyr RTOS driver API, such as MSC and CDC class implementations. The *Identification string* identifies a class or function -instance (`n`) and is used as an argument to the :c:func:`usbd_register_class`. +instance (``n``) and is used as an argument to the :c:func:`usbd_register_class`. +-----------------------------------+-------------------------+-------------------------+ | Class or function | User API (if any) | Identification string | diff --git a/doc/contribute/index.rst b/doc/contribute/index.rst index 44106539d53..19f872226a5 100644 --- a/doc/contribute/index.rst +++ b/doc/contribute/index.rst @@ -27,7 +27,7 @@ General Guidelines merged. :ref:`contributor-expectations` - This document is another mandatory read that describes the expected behavior of `all` + This document is another mandatory read that describes the expected behavior of *all* contributors to the project. :ref:`coding_guidelines` diff --git a/doc/develop/debug/index.rst b/doc/develop/debug/index.rst index 932d6484add..e7547b3edc7 100644 --- a/doc/develop/debug/index.rst +++ b/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. This feature is enabled by the Kconfig option :kconfig:option:`CONFIG_I2C_DUMP_MESSAGES`, but it -uses the ``LOG_DBG`` function to print the contents so the +uses the :c:macro:`LOG_DBG` function to print the contents so the :kconfig:option:`CONFIG_I2C_LOG_LEVEL_DBG` option must also be enabled. The sample output of the dump looks like this:: diff --git a/doc/develop/manifest/index.rst b/doc/develop/manifest/index.rst index a24c32de61c..bf1d4cc31d1 100644 --- a/doc/develop/manifest/index.rst +++ b/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 -call `west update`. Many of the projects or modules listed below are +call :command:`west update`. Many of the projects or modules listed below are essential for building generic Zephyr application and include among others hardware support for many of the platforms available in Zephyr. @@ -30,7 +30,7 @@ Inactive and Optional Projects/Modules The projects below are optional and will not be downloaded when you -call `west update`. You can add any of the projects or modules listed below +call :command:`west update`. You can add any of the projects or modules listed below and use them to write application code and extend your workspace with the added functionality. diff --git a/doc/develop/modules.rst b/doc/develop/modules.rst index 8188e12bc00..1a3107111a8 100644 --- a/doc/develop/modules.rst +++ b/doc/develop/modules.rst @@ -52,7 +52,7 @@ In summary: Modules are repositories that contain a :file:`zephyr/module.yml` file, so that the Zephyr build system can pull in the source code from the repository. -:ref:`West projects ` are entries in the `projects:` +:ref:`West projects ` are entries in the ``projects:`` section in the :file:`west.yml` manifest file. West projects are often also modules, but not always. There are west projects that are not included in the final firmware image (eg. tools) and thus do not @@ -545,7 +545,7 @@ The ``sysbuild-cmake: `` part specifies that use. Here is an example :file:`module.yml` file referring to -:file:`CMakeLists.txt` and :file:`Kconfig` files in the `sysbuild` directory of +:file:`CMakeLists.txt` and :file:`Kconfig` files in the ``sysbuild`` directory of the module: .. code-block:: yaml @@ -592,7 +592,7 @@ be monitored for your module. The supported formats are: - - -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 diff --git a/doc/develop/test/pytest.rst b/doc/develop/test/pytest.rst index 3b8d1de95af..3f6db41fd3c 100644 --- a/doc/develop/test/pytest.rst +++ b/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”* (``_). Python is known for its free libraries and ease of using it for scripting. In addition, pytest utilizes the concept of plugins and fixtures, increasing its expendability and reusability. -A pytest plugin `pytest-twister-harness` was introduced to provide an integration between pytest +A pytest plugin ``pytest-twister-harness`` was introduced to provide an integration between pytest and twister, allowing Zephyr’s community to utilize pytest functionality with keeping twister as the main framework. diff --git a/doc/develop/test/twister.rst b/doc/develop/test/twister.rst index 2b3b896986e..a362c79861a 100644 --- a/doc/develop/test/twister.rst +++ b/doc/develop/test/twister.rst @@ -261,11 +261,11 @@ test application and has to follow basic rules: two sections: * Ztest tests: The individual test cases in the ztest testsuite will be - concatenated by dot (`.`) to the identifier in the ``testcase.yaml`` file + concatenated by dot (``.``) to the identifier in the ``testcase.yaml`` file generating unique identifiers for every test case in the suite. * Standalone tests and samples: This type of test should at least have 3 - sections concatnated by dot (`.`) in the test scenario identifier in the + sections concatnated by dot (``.``) in the test scenario identifier in the ``testcase.yaml`` (or ``sample.yaml``) file. The last section of the name shall signify the test case itself. @@ -851,10 +851,10 @@ Command line arguments define the initial scope in the following way: * ``-l/--all``: all available platforms; * ``-G/--integration``: all platforms from an ``integration_platforms`` list in a given test configuration file. If a test has no ``integration_platforms`` - `"scope presumption"` will happen; -* No scope argument: `"scope presumption"` will happen. + *"scope presumption"* will happen; +* No scope argument: *"scope presumption"* will happen. -`"Scope presumption"`: A list of Twister's :ref:`default platforms ` +*"Scope presumption"*: A list of Twister's :ref:`default platforms ` is used as the initial list. If nothing is left after the filtration, the ``platform_allow`` list is used as the initial scope. @@ -1338,7 +1338,7 @@ locally. As of now, those options are available: CI) - Option to specify your own list of default platforms overriding what upstream defines. -- Ability to override `build_on_all` options used in some test scenarios. +- Ability to override ``build_on_all`` options used in some test scenarios. This will treat tests or sample as any other just build for default platforms you specify in the configuration file or on the command line. - Ignore some logic in twister to expand platform coverage in cases where @@ -1350,16 +1350,16 @@ Platform Configuration The following options control platform filtering in twister: -- `override_default_platforms`: override default key a platform sets in board +- ``override_default_platforms``: override default key a platform sets in board configuration and instead use the list of platforms provided in the configuration file as the list of default platforms. This option is set to False by default. -- `increased_platform_scope`: This option is set to True by default, when +- ``increased_platform_scope``: This option is set to True by default, when disabled, twister will not increase platform coverage automatically and will only build and run tests on the specified platforms. -- `default_platforms`: A list of additional default platforms to add. This list +- ``default_platforms``: A list of additional default platforms to add. This list can either be used to replace the existing default platforms or can extend it - depending on the value of `override_default_platforms`. + depending on the value of ``override_default_platforms``. And example platforms configuration: diff --git a/doc/develop/test/ztest.rst b/doc/develop/test/ztest.rst index 5def69164f2..a14ebad2d42 100644 --- a/doc/develop/test/ztest.rst +++ b/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 randomize the order. The output from the test will display the seed for failed tests. For native simulator builds you can provide the seed as an argument to -twister with `--seed` +twister with ``--seed``. Static configuration of ZTEST_SHUFFLE contains: diff --git a/doc/develop/tools/vscode.rst b/doc/develop/tools/vscode.rst index f82d7c7c8bc..b3f0781b1c8 100644 --- a/doc/develop/tools/vscode.rst +++ b/doc/develop/tools/vscode.rst @@ -17,7 +17,7 @@ Get VS Code `Download VS Code`_ and install it. -Install the required extensions through the `Extensions` marketplace in the left panel. +Install the required extensions through the :guilabel:`Extensions` marketplace in the left panel. Search for the `C/C++ Extension Pack`_ and install it. Initialize a new workspace diff --git a/doc/develop/west/sign.rst b/doc/develop/west/sign.rst index ef98631be1c..355682c032d 100644 --- a/doc/develop/west/sign.rst +++ b/doc/develop/west/sign.rst @@ -116,7 +116,7 @@ for all images, for example: west build -b -DSIGNING_SCRIPT= 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 diff --git a/doc/glossary.rst b/doc/glossary.rst index 7c643a9495e..95507c4e924 100644 --- a/doc/glossary.rst +++ b/doc/glossary.rst @@ -60,7 +60,7 @@ Glossary of Terms See :ref:`board_terminology` for additional details. board qualifiers - The set of additional tokens, separated by a forward slash (`/`) that + The set of additional tokens, separated by a forward slash (``/``) that follow the :term:`board name` (and optionally :term:`board revision`) to form the :term:`board target`. The currently accepted qualifiers are :term:`SoC`, :term:`CPU cluster` and :term:`variant`. diff --git a/doc/hardware/arch/risc-v.rst b/doc/hardware/arch/risc-v.rst index cd5db3aa6a6..1484781f658 100644 --- a/doc/hardware/arch/risc-v.rst +++ b/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) -are available on a given platform, by setting the appropriate `RISCV_ISA_*` +are available on a given platform, by setting the appropriate ``CONFIG_RISCV_ISA_*`` kconfig. Look at :file:`arch/riscv/Kconfig.isa` for more information. Note that Zephyr SDK toolchain support may not be defined for all @@ -33,5 +33,5 @@ SMP support *********** SMP is supported on RISC-V, but currently only on Qemu platforms. In -order to test the SMP support, one can use `qemu_riscv32_smp` or -`qemu_riscv64_smp` boards. +order to test the SMP support, one can use ``qemu_riscv32_smp`` or +``qemu_riscv64_smp`` boards. diff --git a/doc/hardware/emulator/bus_emulators.rst b/doc/hardware/emulator/bus_emulators.rst index e46ba985946..381f0a1ad58 100644 --- a/doc/hardware/emulator/bus_emulators.rst +++ b/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. Emulators for peripheral devices reuse the same devicetree node as the real -device driver. This means that your emulator defines `DT_DRV_COMPAT` using the +device driver. This means that your emulator defines ``DT_DRV_COMPAT`` using the same ``compat`` value from the real driver. .. code-block:: C diff --git a/doc/hardware/peripherals/uart.rst b/doc/hardware/peripherals/uart.rst index 177a54dbbfe..644068eb7f8 100644 --- a/doc/hardware/peripherals/uart.rst +++ b/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` Polling is the most basic method to access the UART peripheral. The reading -function, `uart_poll_in`, is a non-blocking function and returns a character -or `-1` when no valid data is available. The writing function, -`uart_poll_out`, is a blocking function and the thread waits until the given +function, :c:func:`uart_poll_in`, is a non-blocking function and returns a character +or ``-1`` when no valid data is available. The writing function, +:c:func:`uart_poll_out`, is a blocking function and the thread waits until the given character is sent. With the Interrupt-driven API, possibly slow communication can happen in the diff --git a/doc/kernel/object_cores/index.rst b/doc/kernel/object_cores/index.rst index 3e8a72d68a5..ae28d33082c 100644 --- a/doc/kernel/object_cores/index.rst +++ b/doc/kernel/object_cores/index.rst @@ -13,7 +13,7 @@ perform operations on registered objects. Object Core Concepts ******************** -Each instance of an object embeds an object core field named `obj_core`. +Each instance of an object embeds an object core field named ``obj_core``. Objects of the same type are linked together via their respective object cores to form a singly linked list. Each object core also links to the their respective object type. Each object type contains a singly linked list diff --git a/doc/kernel/services/interrupts.rst b/doc/kernel/services/interrupts.rst index 3a0cfec22ab..044e9ddea1f 100644 --- a/doc/kernel/services/interrupts.rst +++ b/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. See details of this option for the information about currently supported configurations. -Any invocation of :c:macro:`IRQ_CONNECT` or `IRQ_DIRECT_CONNECT` will declare an instance of struct -_isr_list_sname which is placde in a special .intList section: +Any invocation of :c:macro:`IRQ_CONNECT` or :c:macro:`IRQ_DIRECT_CONNECT` will declare an instance +of ``struct _isr_list_sname`` which is placed in a special .intList section: .. code-block:: c @@ -619,7 +619,7 @@ _isr_list_sname which is placde in a special .intList section: }; Note that the section name is placed in flexible array member. -It means that the size of the initialized structure will warry depending on the +It means that the size of the initialized structure will vary depending on the structure name length. The whole entry is used by the script during the build of the application and has all the information needed for proper interrupt placement. @@ -720,7 +720,7 @@ aggregator. In this case it may be desirable to override these defaults and use number of bits per level. Regardless of how many bits used for each level, the sum of the total bits used between all levels must sum to be less than or equal to 32-bits, fitting into a single 32-bit integer. To modify the bit total per level, override the -default 8 in `Kconfig.multilevel` by setting :kconfig:option:`CONFIG_1ST_LEVEL_INTERRUPT_BITS` +default 8 in :file:`Kconfig.multilevel` by setting :kconfig:option:`CONFIG_1ST_LEVEL_INTERRUPT_BITS` for the first level, :kconfig:option:`CONFIG_2ND_LEVEL_INTERRUPT_BITS` for the second level and :kconfig:option:`CONFIG_3RD_LEVEL_INTERRUPT_BITS` for the third level. These masks control the length of the bit masks and shift to apply when generating interrupt values, when checking the diff --git a/doc/project/release_process.rst b/doc/project/release_process.rst index 50534e14c05..82fd5e30349 100644 --- a/doc/project/release_process.rst +++ b/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 created. -A fix for a bug that is granted `blocker` status can be merged to 'main' and included in +A fix for a bug that is granted ``blocker`` status can be merged to 'main' and included in the release all the way until the final release date. Bugs of moderate severity and higher that have impact on all users are typically diff --git a/doc/releases/index.rst b/doc/releases/index.rst index 0ec12aace53..0f4c7f8ccdd 100644 --- a/doc/releases/index.rst +++ b/doc/releases/index.rst @@ -73,7 +73,7 @@ Release Notes Release notes contain a list of changes that have been made to the different areas of the project during the development cycle of the release. Changes that require the user to modify their own application to support the new -release may be mentioned in the release notes, but the details regarding `what` +release may be mentioned in the release notes, but the details regarding *what* needs to be changed are to be detailed in the release's migration guide. .. toctree:: diff --git a/doc/releases/migration-guide-4.0.rst b/doc/releases/migration-guide-4.0.rst index ac3e30269b1..f7bf9213cc3 100644 --- a/doc/releases/migration-guide-4.0.rst +++ b/doc/releases/migration-guide-4.0.rst @@ -30,14 +30,14 @@ Boards to define default flash and ram partitioning based on TF-M. * STM32WBA: The command used for fetching blobs required to build ble applications is now - `west blobs fetch hal_stm32` instead of `west blobs fetch stm32`. + ``west blobs fetch hal_stm32`` instead of ``west blobs fetch stm32``. STM32 ===== -* On all official STM32 boards, `west flash` selects STM32CubeProgrammer as the default west runner. +* On all official STM32 boards, ``west flash`` selects STM32CubeProgrammer as the default west runner. If you want to enforce the selection of another runner like OpenOCD or pyOCD for flashing, you should - specify it using the west `--runner` or `-r` option. (:github:`75284`) + specify it using the west ``--runner`` or ``-r`` option. (:github:`75284`) Modules ******* @@ -69,10 +69,10 @@ zcbor Migration guide at https://github.com/NordicSemiconductor/zcbor/blob/0.9.0/MIGRATION_GUIDE.md Migration guide copied here: - * `zcbor_simple_*()` functions have been removed to avoid confusion about their use. + * ``zcbor_simple_*()`` functions have been removed to avoid confusion about their use. They are still in the C file because they are used by other functions. Instead, use the specific functions for the currently supported simple values, i.e. - `zcbor_bool_*()`, `zcbor_nil_*()`, and `zcbor_undefined_*()`. + ``zcbor_bool_*()``, ``zcbor_nil_*()``, and ``zcbor_undefined_*()``. If a removed variant is strictly needed, add your own forward declaration in your code. * Code generation naming: diff --git a/doc/releases/release-notes-4.0.rst b/doc/releases/release-notes-4.0.rst index abff147cdcd..841e4eaadb4 100644 --- a/doc/releases/release-notes-4.0.rst +++ b/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, which can be accessed in :c:func:`k_sys_fatal_error_handler` by ``esf->csf``. - * For SoCs that select `RISCV_SOC_HAS_ISR_STACKING`, the `SOC_ISR_STACKING_ESF_DECLARE` has to - include the `csf` member, otherwise the build would fail. + * For SoCs that select ``RISCV_SOC_HAS_ISR_STACKING``, the ``SOC_ISR_STACKING_ESF_DECLARE`` has to + include the ``csf`` member, otherwise the build would fail. * Xtensa diff --git a/doc/security/standards/etsi-303645.rst b/doc/security/standards/etsi-303645.rst index 6acb51ee7ea..7870a492884 100644 --- a/doc/security/standards/etsi-303645.rst +++ b/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 European Telecommunications Standards Institute (ETSI). diff --git a/doc/services/device_mgmt/ec_host_cmd.rst b/doc/services/device_mgmt/ec_host_cmd.rst index 2be0e4c244d..8419e767c58 100644 --- a/doc/services/device_mgmt/ec_host_cmd.rst +++ b/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``. The supported backend and peripheral drivers: @@ -120,10 +120,10 @@ Logging The host command has an embedded logging system of the ongoing communication. The are a few logging levels: -* `LOG_INF` is used to log a command id of a new command and not success responses. Repeats of the +* :c:macro:`LOG_INF` is used to log a command id of a new command and not success responses. Repeats of the same command are not logged -* `LOG_DBG` logs every command, even repeats -* `LOG_DBG` + :kconfig:option:`CONFIG_EC_HOST_CMD_LOG_DBG_BUFFERS` logs every command and responses +* :c:macro:`LOG_DBG` logs every command, even repeats +* :c:macro:`LOG_DBG` + :kconfig:option:`CONFIG_EC_HOST_CMD_LOG_DBG_BUFFERS` logs every command and responses with the data buffers API Reference diff --git a/doc/services/device_mgmt/smp_groups/smp_group_0.rst b/doc/services/device_mgmt/smp_groups/smp_group_0.rst index eb3b90b3a1d..b33a90a9241 100644 --- a/doc/services/device_mgmt/smp_groups/smp_group_0.rst +++ b/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 is issued and can be used to perform any necessary tidy operations prior to the module rebooting, or to reject the reset request outright altogether with an -error response. For details on this functionality, see `ref:`mcumgr_callbacks`. +error response. For details on this functionality, see :ref:`mcumgr_callbacks`. System reset request ==================== diff --git a/doc/services/device_mgmt/smp_transport.rst b/doc/services/device_mgmt/smp_transport.rst index af3eba4dd84..d0130047576 100644 --- a/doc/services/device_mgmt/smp_transport.rst +++ b/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 SMP client: -- **Service UUID**: `8D53DC1D-1DB7-4CD3-868B-8A527460AA84` -- **Characteristic UUID**: `DA2E7828-FBCE-4E01-AE9E-261174997C48` +- **Service UUID**: ``8D53DC1D-1DB7-4CD3-868B-8A527460AA84`` +- **Characteristic UUID**: ``DA2E7828-FBCE-4E01-AE9E-261174997C48`` All SMP communication utilizes a single GATT characteristic. An SMP request is sent via a GATT Write Without Response command. An SMP response is sent in the form diff --git a/doc/services/input/gpio-kbd.rst b/doc/services/input/gpio-kbd.rst index 162e7cb9740..f93d16a5efd 100644 --- a/doc/services/input/gpio-kbd.rst +++ b/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 -populated can be specified using the `actual-key-mask` property. This allows +populated can be specified using the ``actual-key-mask`` property. This allows the matrix state to be filtered to remove keys that are not present before ghosting detection, potentially allowing key combinations that would otherwise be blocked by it. diff --git a/doc/services/llext/build.rst b/doc/services/llext/build.rst index 78522fc8162..eae96259d24 100644 --- a/doc/services/llext/build.rst +++ b/doc/services/llext/build.rst @@ -112,18 +112,18 @@ The different build steps are: ``PRE_BUILD`` Before the extension code is linked, if the architecture uses dynamic - libraries. This step can access `lib_target` and its own properties. + libraries. This step can access ``lib_target`` and its own properties. ``POST_BUILD`` After the extension code is built, but before packaging it in an ``.llext`` - file. This step is expected to create a `pkg_input` file by reading the - contents of `lib_output`. + file. This step is expected to create a :file:`pkg_input` file by reading the + contents of :file:`lib_output`. ``POST_PKG`` After the extension output file has been created. The command can operate - on the final llext file `pkg_output`. + on the final llext file :file:`pkg_output`. Anything else after ``COMMAND`` will be passed to ``add_custom_command()`` as-is (including multiple commands and other options). diff --git a/doc/services/llext/config.rst b/doc/services/llext/config.rst index 3772c26a445..5fec87908bd 100644 --- a/doc/services/llext/config.rst +++ b/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 extensions being built, converting every string in the symbol tables to - a pointer-sized hash called `Symbol Link Identifier` (SLID), which is + a pointer-sized hash called Symbol Link Identifier (SLID), which is stored in the binary. This speeds up the symbol lookup process by allowing usage of diff --git a/doc/services/logging/index.rst b/doc/services/logging/index.rst index f9717c075a5..5aa868362b8 100644 --- a/doc/services/logging/index.rst +++ b/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, :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) --------------------------------------------------------- diff --git a/doc/services/mem_mgmt/index.rst b/doc/services/mem_mgmt/index.rst index 3f63edf39a5..86d36b3961c 100644 --- a/doc/services/mem_mgmt/index.rst +++ b/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 ``tests/subsys/mem_mgmt/mem_attr/``. -Migration guide from `zephyr,memory-region-mpu` -*********************************************** +Migration guide from ``zephyr,memory-region-mpu`` +************************************************* When the ``zephyr,memory-attr`` property was introduced, the ``zephyr,memory-region-mpu`` property was removed and deprecated. diff --git a/doc/services/pm/device_runtime.rst b/doc/services/pm/device_runtime.rst index a1ffb0a670e..c6173ef66f1 100644 --- a/doc/services/pm/device_runtime.rst +++ b/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. For the previous to automatically control the power domain state, device runtime PM must be enabled -on the power domain device (either through the `zephyr,pm-device-runtime-auto` devicetree property +on the power domain device (either through the ``zephyr,pm-device-runtime-auto`` devicetree property or :c:func:`pm_device_runtime_enable`). .. graphviz:: diff --git a/doc/services/portability/posix/conformance/index.rst b/doc/services/portability/posix/conformance/index.rst index a2b391f143e..acba97e6d85 100644 --- a/doc/services/portability/posix/conformance/index.rst +++ b/doc/services/portability/posix/conformance/index.rst @@ -3,7 +3,9 @@ POSIX Conformance ################# -As per `IEEE 1003.1-2017`, this section details Zephyr's POSIX conformance. +As per `IEEE 1003.1-2017`_, this section details Zephyr's POSIX conformance. + +.. _IEEE 1003.1-2017: https://standards.ieee.org/ieee/1003.1/7101/ .. _posix_system_interfaces: diff --git a/doc/services/storage/flash_map/flash_map.rst b/doc/services/storage/flash_map/flash_map.rst index 801e75bd6bc..6a90cc628f2 100644 --- a/doc/services/storage/flash_map/flash_map.rst +++ b/doc/services/storage/flash_map/flash_map.rst @@ -32,7 +32,7 @@ Most ```` API functions require a :c:struct:`flash_a characterizing the flash area they will be working on. There are two possible methods to obtain such a pointer: - * obtain it using `flash_area_open`; + * obtain it using :c:func:`flash_area_open`; * defining a :c:struct:`flash_area` type object, which requires providing a valid :c:struct:`device` object pointer with offset and size of the area diff --git a/doc/services/tracing/index.rst b/doc/services/tracing/index.rst index 17552781c32..2519df266a0 100644 --- a/doc/services/tracing/index.rst +++ b/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 :zephyr:code-sample:`synchronization` sample to visualize fast switching between threads. SystemView can also be used for post-mortem tracing, which can be enabled with -`CONFIG_SEGGER_SYSVIEW_POST_MORTEM_MODE`. In this mode, a debugger can +:kconfig:option:`CONFIG_SEGGER_SYSVIEW_POST_MORTEM_MODE`. In this mode, a debugger can be attached after the system has crashed using ``west attach`` after which the latest data from the internal RAM buffer can be loaded into SystemView:: diff --git a/doc/services/zbus/index.rst b/doc/services/zbus/index.rst index 1b685bb2bbf..401fd47c701 100644 --- a/doc/services/zbus/index.rst +++ b/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 arise. ZBus will not solve every problem, so it is necessary to analyze the situation to be sure zbus is applicable. For instance, based on the zbus benchmark, it would not be well suited to a -high-speed stream of bytes between threads. The `Pipe` kernel object solves this kind of need. +high-speed stream of bytes between threads. The :ref:`Pipe ` kernel object solves this +kind of need. Delivery guarantees ------------------- @@ -524,12 +525,12 @@ sequence of the static observers. notified. -Channels can have a `validator function` that enables a channel to accept only valid messages. +Channels can have a *validator function* that enables a channel to accept only valid messages. Publish attempts invalidated by hard channels will return immediately with an error code. This allows original creators of a channel to exert some authority over other developers/publishers who may want to piggy-back on their channels. The following code defines and initializes a :dfn:`hard channel` and its dependencies. Only valid messages can be published to a :dfn:`hard channel`. It is -possible because a `validator function` was passed to the channel's definition. In this example, +possible because a *validator function* was passed to the channel's definition. In this example, only messages with ``move`` equal to 0, -1, and 1 are valid. Publish function will discard all other values to ``move``. diff --git a/samples/bluetooth/bap_broadcast_sink/README.rst b/samples/bluetooth/bap_broadcast_sink/README.rst index 0ec8fb70542..efbb69e3810 100644 --- a/samples/bluetooth/bap_broadcast_sink/README.rst +++ b/samples/bluetooth/bap_broadcast_sink/README.rst @@ -16,9 +16,9 @@ This sample can be found under Check the :ref:`bluetooth samples section ` for general information. -Use `CONFIG_TARGET_BROADCAST_NAME` Kconfig to specify the name (CONFIG_BT_DEVICE_NAME) -of a broadcast source to listen to. With default value (empty string), sink -device will listen to all available broadcast sources. +Use :kconfig:option:`CONFIG_TARGET_BROADCAST_NAME` Kconfig to specify the name +(:kconfig:option:`CONFIG_BT_DEVICE_NAME`) of a broadcast source to listen to. With default value +(empty string), sink device will listen to all available broadcast sources. Requirements ************ @@ -30,7 +30,7 @@ Building and Running ******************** When building targeting an nrf52 series board with the Zephyr Bluetooth Controller, -use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO +use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO feature support. Building for an nrf5340dk @@ -67,7 +67,7 @@ Similarly to how you would for real HW, you can do: :goals: build :west-args: --sysbuild -Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`. +Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`. For more information, check :ref:`this board documentation `. Building for a simulated nrf52_bsim diff --git a/samples/bluetooth/bap_broadcast_source/README.rst b/samples/bluetooth/bap_broadcast_source/README.rst index 4afa96da77e..1baf971623b 100644 --- a/samples/bluetooth/bap_broadcast_source/README.rst +++ b/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, -use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO +use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO feature support. Building for an nrf5340dk @@ -66,7 +66,7 @@ Similarly to how you would for real HW, you can do: :goals: build :west-args: --sysbuild -Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`. +Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`. For more information, check :ref:`this board documentation `. Building for a simulated nrf52_bsim diff --git a/samples/bluetooth/bap_unicast_client/README.rst b/samples/bluetooth/bap_unicast_client/README.rst index 7ff7a387afd..b99826f5fa0 100644 --- a/samples/bluetooth/bap_unicast_client/README.rst +++ b/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, -use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO +use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO feature support. Building for an nrf52840dk @@ -71,7 +71,7 @@ Similarly to how you would for real HW, you can do: :goals: build :gen-args: -DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf -Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`. +Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`. For more information, check :ref:`this board documentation `. Building for a simulated nrf5340bsim diff --git a/samples/bluetooth/bap_unicast_server/README.rst b/samples/bluetooth/bap_unicast_server/README.rst index 8ef31b73736..b24c6385443 100644 --- a/samples/bluetooth/bap_unicast_server/README.rst +++ b/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, -use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO +use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO feature support. Building for an nrf52840dk @@ -71,7 +71,7 @@ Similarly to how you would for real HW, you can do: :goals: build :gen-args: -DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf -Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`. +Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`. For more information, check :ref:`this board documentation `. Building for a simulated nrf5340bsim diff --git a/samples/bluetooth/broadcaster_multiple/README.rst b/samples/bluetooth/broadcaster_multiple/README.rst index ab24c541270..5170cf9dbff 100644 --- a/samples/bluetooth/broadcaster_multiple/README.rst +++ b/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 two different SID. Number of advertising sets can be increased by updating the -`CONFIG_BT_EXT_ADV_MAX_ADV_SET` value in the project configuration file. +:kconfig:option:`CONFIG_BT_EXT_ADV_MAX_ADV_SET` value in the project configuration file. When building this sample combined with a Bluetooth LE Controller, the advertising data length can be increased from the default 31 bytes by updating -the Controller's `CONFIG_BT_CTLR_ADV_DATA_LEN_MAX` value. The size of the +the Controller's :kconfig:option:`CONFIG_BT_CTLR_ADV_DATA_LEN_MAX` value. The size of the manufacturer data is calculated to maximize the use of supported AD data length. Requirements diff --git a/samples/bluetooth/cap_acceptor/README.rst b/samples/bluetooth/cap_acceptor/README.rst index b964ae544ce..0a9854616f1 100644 --- a/samples/bluetooth/cap_acceptor/README.rst +++ b/samples/bluetooth/cap_acceptor/README.rst @@ -61,7 +61,7 @@ Similarly to how you would for real HW, you can do: :goals: build :west-args: --sysbuild -Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`. +Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`. For more information, check :ref:`this board documentation `. Building for a simulated nrf52_bsim diff --git a/samples/bluetooth/cap_initiator/README.rst b/samples/bluetooth/cap_initiator/README.rst index 71e01a07713..b3c84ff9dec 100644 --- a/samples/bluetooth/cap_initiator/README.rst +++ b/samples/bluetooth/cap_initiator/README.rst @@ -62,7 +62,7 @@ Similarly to how you would for real HW, you can do: :goals: build :west-args: --sysbuild -Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`. +Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`. For more information, check :ref:`this board documentation `. Building for a simulated nrf52_bsim diff --git a/samples/bluetooth/encrypted_advertising/README.rst b/samples/bluetooth/encrypted_advertising/README.rst index 8079acb672b..b62a479fcca 100644 --- a/samples/bluetooth/encrypted_advertising/README.rst +++ b/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, - and the update of the Randomizer field whenever the RPA is changed. -To use the `bt_ead_encrypt` and `bt_ead_decrypt` functions, you must enable +To use the :c:func:`bt_ead_encrypt` and :c:func:`bt_ead_decrypt` functions, you must enable the Kconfig symbol :kconfig:option:`CONFIG_BT_EAD`. While this sample uses extended advertising, it is **not** mandatory when using diff --git a/samples/bluetooth/extended_adv/README.rst b/samples/bluetooth/extended_adv/README.rst index a88244642eb..b7901fd8e6b 100644 --- a/samples/bluetooth/extended_adv/README.rst +++ b/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 practices. Even though it is not strictly required, scheduling from another context is strongly recommended (e.g. using a work item), as re-starting an advertiser or -scanner from within the `recycled` callback exposes the application to deadlocking. +scanner from within the ``recycled`` callback exposes the application to deadlocking. Requirements ************ diff --git a/samples/bluetooth/hci_uart/README.rst b/samples/bluetooth/hci_uart/README.rst index e671927095a..d07ddd4421e 100644 --- a/samples/bluetooth/hci_uart/README.rst +++ b/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 an application that uses the Zephyr host. -On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen` +On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen`` block) is used to select which uart device to use. For example if we want to keep the console logs, we can keep console on uart0 and the HCI on uart1 like so: @@ -180,7 +180,7 @@ driver instead of the built-in controller: CONFIG_BT_HCI=y CONFIG_BT_CTLR=n -Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use. +Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use. The UART needs to have as its child node a HCI UART node: .. code-block:: dts diff --git a/samples/bluetooth/hci_uart_3wire/README.rst b/samples/bluetooth/hci_uart_3wire/README.rst index f4a809be2a1..effd001c760 100644 --- a/samples/bluetooth/hci_uart_3wire/README.rst +++ b/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 an application that uses the Zephyr host. -On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen` +On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen`` block) is used to select which uart device to use. For example if we want to keep the console logs, we can keep console on uart0 and the HCI on uart1 like so: @@ -180,7 +180,7 @@ driver instead of the built-in controller: CONFIG_BT_HCI=y CONFIG_BT_CTLR=n -Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use. +Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use. The UART needs to have as its child node a HCI UART node: .. code-block:: dts diff --git a/samples/bluetooth/hci_uart_async/README.rst b/samples/bluetooth/hci_uart_async/README.rst index 6dca7b85ecc..0bf85fdb765 100644 --- a/samples/bluetooth/hci_uart_async/README.rst +++ b/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 an application that uses the Zephyr host. -On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen` +On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen`` block) is used to select which uart device to use. For example if we want to keep the console logs, we can keep console on uart0 and the HCI on uart1 like so: @@ -148,7 +148,7 @@ driver instead of the built-in controller: CONFIG_BT_HCI=y CONFIG_BT_CTLR=n -Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use. +Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use. The UART needs to have as its child node a HCI UART node: .. code-block:: dts diff --git a/samples/bluetooth/iso_broadcast/README.rst b/samples/bluetooth/iso_broadcast/README.rst index c560e0e5fab..a27f302247f 100644 --- a/samples/bluetooth/iso_broadcast/README.rst +++ b/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 -the Zephyr tree. Use `-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf` to enable +the Zephyr tree. Use ``-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf`` to enable required ISO feature support in Zephyr Bluetooth Controller on supported boards. Use the sample found under :zephyr_file:`samples/bluetooth/iso_receive` in the diff --git a/samples/bluetooth/iso_receive/README.rst b/samples/bluetooth/iso_receive/README.rst index b93db57b92b..85201981c7f 100644 --- a/samples/bluetooth/iso_receive/README.rst +++ b/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 -the Zephyr tree. Use `-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf` to enable +the Zephyr tree. Use ``-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf`` to enable required ISO feature support in Zephyr Bluetooth Controller on supported boards. Use the sample found under :zephyr_file:`samples/bluetooth/iso_broadcast` on diff --git a/samples/bluetooth/observer/README.rst b/samples/bluetooth/observer/README.rst index 8f807b915b4..42001e36242 100644 --- a/samples/bluetooth/observer/README.rst +++ b/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. If the used Bluetooth Low Energy Controller supports Extended Scanning, you may -enable `CONFIG_BT_EXT_ADV` in the project configuration file. Refer to the +enable :kconfig:option:`CONFIG_BT_EXT_ADV` in the project configuration file. Refer to the project configuration file for further details. Requirements diff --git a/samples/bluetooth/pbp_public_broadcast_sink/README.rst b/samples/bluetooth/pbp_public_broadcast_sink/README.rst index 8414eba7e33..72ec4fc3c8f 100644 --- a/samples/bluetooth/pbp_public_broadcast_sink/README.rst +++ b/samples/bluetooth/pbp_public_broadcast_sink/README.rst @@ -27,7 +27,7 @@ Building and Running ******************** When building targeting an nrf52 series board with the Zephyr Bluetooth Controller, -use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO +use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO feature support. Building for an nrf5340dk @@ -64,7 +64,7 @@ Similarly to how you would for real HW, you can do: :goals: build :west-args: --sysbuild -Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`. +Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`. For more information, check :ref:`this board documentation `. Building for a simulated nrf52_bsim diff --git a/samples/bluetooth/pbp_public_broadcast_source/README.rst b/samples/bluetooth/pbp_public_broadcast_source/README.rst index 5e5f855137c..c12c2b762f4 100644 --- a/samples/bluetooth/pbp_public_broadcast_source/README.rst +++ b/samples/bluetooth/pbp_public_broadcast_source/README.rst @@ -27,7 +27,7 @@ Building and Running ******************** When building targeting an nrf52 series board with the Zephyr Bluetooth Controller, -use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO +use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO feature support. Building for an nrf5340dk @@ -64,7 +64,7 @@ Similarly to how you would for real HW, you can do: :goals: build :west-args: --sysbuild -Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`. +Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`. For more information, check :ref:`this board documentation `. Building for a simulated nrf52_bsim diff --git a/samples/bluetooth/peripheral_hids/README.rst b/samples/bluetooth/peripheral_hids/README.rst index 00c579957a4..72be337fc88 100644 --- a/samples/bluetooth/peripheral_hids/README.rst +++ b/samples/bluetooth/peripheral_hids/README.rst @@ -15,7 +15,7 @@ In the default configuration the sample uses passkey authentication (displays a code on the peripheral and requires that to be entered on the host during pairing) and requires an authenticated link to access the GATT characteristics. To disable authentication and just use encrypted channels instead, build the -sample with `CONFIG_SAMPLE_BT_USE_AUTHENTICATION=n`. +sample with ``CONFIG_SAMPLE_BT_USE_AUTHENTICATION=n``. Requirements ************ diff --git a/samples/boards/espressif/flash_memory_mapped/README.rst b/samples/boards/espressif/flash_memory_mapped/README.rst index 11b53851def..5605c970948 100644 --- a/samples/boards/espressif/flash_memory_mapped/README.rst +++ b/samples/boards/espressif/flash_memory_mapped/README.rst @@ -13,7 +13,7 @@ contents of flash memory by writing to a mapped memory region. Mapping happens in 64 KB pages. Memory mapping hardware can map flash into the data address space and the instruction address space. See the technical reference manual for more details and -limitations about memory mapping hardware. For more information, check `_ESP32 Flash Memory-Mapping`. +limitations about memory mapping hardware. For more information, check `ESP32 Flash Memory-Mapping`_. Supported SoCs ************** diff --git a/samples/boards/espressif/spiram_test/README.rst b/samples/boards/espressif/spiram_test/README.rst index a4bf818978c..e91e2b24ed8 100644 --- a/samples/boards/espressif/spiram_test/README.rst +++ b/samples/boards/espressif/spiram_test/README.rst @@ -7,7 +7,7 @@ Overview ******** This sample shows how to allocate memory from SPIRAM by using -:c:func:`shared_multi_heap_aligned_alloc` with `SMH_REG_ATTR_EXTERNAL` attribute. Checks if the +:c:func:`shared_multi_heap_aligned_alloc` with ``SMH_REG_ATTR_EXTERNAL`` attribute. Checks if the memory was correctly allocated then frees it by calling :c:func:`shared_multi_heap_free`. It also allocates memory from internal memory and checks if the address range is correct. @@ -31,7 +31,7 @@ Make sure you have your board connected over USB port. west flash If using another supported Espressif board, replace the argument in the above -command with a proper board name (e.g., `esp32s2_saola`). +command with a proper board name (e.g., ``esp32s2_saola``). Sample Output ============= diff --git a/samples/boards/espressif/xt_wdt/README.rst b/samples/boards/espressif/xt_wdt/README.rst index 0e4ab9d1eba..782188dd523 100644 --- a/samples/boards/espressif/xt_wdt/README.rst +++ b/samples/boards/espressif/xt_wdt/README.rst @@ -36,7 +36,7 @@ to pins XTAL_32K_P and XTAL_32K_N. west flash If using another supported Espressif board, replace the argument in the above -command with a proper board name (e.g., `esp32s2_saola`). +command with a proper board name (e.g., ``esp32s2_saola``). Sample Output ============= diff --git a/samples/boards/nxp/s32/netc/README.rst b/samples/boards/nxp/s32/netc/README.rst index 35652cb479f..ea2ee66ef1b 100644 --- a/samples/boards/nxp/s32/netc/README.rst +++ b/samples/boards/nxp/s32/netc/README.rst @@ -88,8 +88,8 @@ Setting up Host To be able to reach the board from the host, it's needed to configure the host network interface IP's and default routes. This guide assumes the host IPv4 and -IPv6 addresses are `192.0.2.3` and `2001:db8::3`, respectively. For example, -using a network interface named `enp1s0` in a GNU/Linux host or `Ethernet` in +IPv6 addresses are ``192.0.2.3`` and ``2001:db8::3``, respectively. For example, +using a network interface named ``enp1s0`` in a GNU/Linux host or ``Ethernet`` in a Windows host, this can be done with the following commands: .. tabs:: @@ -121,4 +121,4 @@ the following commands from the Zephyr shell: net ping -I 192.0.2.3 net ping -I 2001:db8::3 -Where `` is the interface number starting from 1. +Where ```` is the interface number starting from 1. diff --git a/samples/boards/st/uart/single_wire/README.rst b/samples/boards/st/uart/single_wire/README.rst index f9f41198d56..09c01c81725 100644 --- a/samples/boards/st/uart/single_wire/README.rst +++ b/samples/boards/st/uart/single_wire/README.rst @@ -12,7 +12,7 @@ functionality of STM32. Without adaptions this example runs on STM32F3 discovery board. You need to establish a physical connection between pins PA2 (USART2_TX) and PC10 (UART4_TX). -Add a `single_wire_uart_loopback` fixture to your board in the hardware map to allow +Add a ``single_wire_uart_loopback`` fixture to your board in the hardware map to allow twister to verify this sample's output automatically. Building and Running diff --git a/samples/drivers/auxdisplay/README.rst b/samples/drivers/auxdisplay/README.rst index 67bfb0e5677..813e91ca431 100644 --- a/samples/drivers/auxdisplay/README.rst +++ b/samples/drivers/auxdisplay/README.rst @@ -14,7 +14,7 @@ Building and Running ******************** Note that this sample requires a board with an auxiliary display setup. A -sample overlay is provided for the `nucleo_f746zg` board fly-wired to a Hitachi +sample overlay is provided for the ``nucleo_f746zg`` board fly-wired to a Hitachi HD44780-compatible 20 character by 4 line display. See the overlay file :zephyr_file:`samples/drivers/auxdisplay/boards/nucleo_f746zg.overlay` for wiring configuration. @@ -26,4 +26,4 @@ wiring configuration. :goals: build flash :compact: -If successful, the display will show `Hello World from `. +If successful, the display will show "Hello World from ". diff --git a/samples/drivers/dac/README.rst b/samples/drivers/dac/README.rst index a9983494389..c58d7f3de27 100644 --- a/samples/drivers/dac/README.rst +++ b/samples/drivers/dac/README.rst @@ -201,8 +201,7 @@ The sample can be built and executed for the :goals: build flash :compact: -also can run for the -:ref: `longan_nano_lite` as follows: +also can run for the Longan Nano Lite as follows: .. zephyr-app-commands:: :zephyr-app: samples/drivers/dac diff --git a/samples/drivers/fpga/fpga_controller/README.rst b/samples/drivers/fpga/fpga_controller/README.rst index d971c138541..371cc23a372 100644 --- a/samples/drivers/fpga/fpga_controller/README.rst +++ b/samples/drivers/fpga/fpga_controller/README.rst @@ -82,8 +82,8 @@ To upload the bitstream again you need to reset the FPGA: FPGA: resetting FPGA You can also use your own bitstream. -To load a bitstream into device memory, use `devmem load` command. -It is important to use the -e option when sending a bitstream via `xxd`: +To load a bitstream into device memory, use ``devmem load`` command. +It is important to use the -e option when sending a bitstream via ``xxd``: .. code-block:: console @@ -92,14 +92,14 @@ It is important to use the -e option when sending a bitstream via `xxd`: Press ctrl-x + ctrl-q to stop Now, the loader is waiting for data. -You can either type it directly from the console or send it from the host PC (replace `ttyX` with the appropriate one for your shell console): +You can either type it directly from the console or send it from the host PC (replace ``ttyX`` with the appropriate one for your shell console): .. code-block:: console xxd -p data > /dev/ttyX (It is important to use plain-style hex dump) -Once the data is transferred, use `ctrl-x + ctrl-q` to quit loader. +Once the data is transferred, use :kbd:`Ctrl-X Ctrl-Q` to quit loader. It will print the sum of the read bytes and return to the shell: .. code-block:: console diff --git a/samples/drivers/led/is31fl3733/README.rst b/samples/drivers/led/is31fl3733/README.rst index 8f0f30e61cf..eefa04b184f 100644 --- a/samples/drivers/led/is31fl3733/README.rst +++ b/samples/drivers/led/is31fl3733/README.rst @@ -29,7 +29,7 @@ Building and Running ******************** This sample can be run on any board with an IS31FL3733 LED driver connected via -I2C, and a node with the `issi,is31fl3733` compatible present in its devicetree. +I2C, and a node with the :dtcompatible:`issi,is31fl3733` compatible present in its devicetree. This sample provides a DTS overlay for the :ref:`frdm_k22f` board (:file:`boards/frdm_k22f.overlay`). It assumes that the IS31FL3733 LED diff --git a/samples/drivers/mspi/mspi_async/README.rst b/samples/drivers/mspi/mspi_async/README.rst index 08a5bdd92a8..a3c52013cc5 100644 --- a/samples/drivers/mspi/mspi_async/README.rst +++ b/samples/drivers/mspi/mspi_async/README.rst @@ -18,7 +18,7 @@ Building and Running The application will build only for a target that has a :ref:`devicetree ` ``dev0`` alias that refers to an entry with the following bindings as a compatible: -* :dtcompatible:`ambiq,mspi-device`, `mspi-aps6404l` +* :dtcompatible:`ambiq,mspi-device`, :dtcompatible:`mspi-aps6404l` .. zephyr-app-commands:: :zephyr-app: samples/drivers/mspi/mspi_async diff --git a/samples/drivers/mspi/mspi_flash/README.rst b/samples/drivers/mspi/mspi_flash/README.rst index 06875e5bd66..991143992b6 100644 --- a/samples/drivers/mspi/mspi_flash/README.rst +++ b/samples/drivers/mspi/mspi_flash/README.rst @@ -18,7 +18,7 @@ Building and Running The application will build only for a target that has a :ref:`devicetree ` ``flash0`` alias that refers to an entry with the following bindings as a compatible: -* :dtcompatible:`ambiq,mspi-device`, `mspi-atxp032` +* :dtcompatible:`ambiq,mspi-device`, :dtcompatible:`mspi-atxp032` .. zephyr-app-commands:: :zephyr-app: samples/drivers/mspi/mspi_flash diff --git a/samples/fuel_gauge/max17048/README.rst b/samples/fuel_gauge/max17048/README.rst index bd26aa31523..f2fd2618220 100644 --- a/samples/fuel_gauge/max17048/README.rst +++ b/samples/fuel_gauge/max17048/README.rst @@ -6,7 +6,7 @@ MAX17048 Li-Ion battery fuel gauge Overview ******** -This sample shows how to use the Zephyr :ref:`fuel_gauge_api` API driver for the `MAX17048` fuel gauge. +This sample shows how to use the Zephyr :ref:`fuel_gauge_api` API driver for the MAX17048 fuel gauge. .. _MAX17048: https://www.maximintegrated.com/en/products/power/battery-management/MAX17048.html diff --git a/samples/modules/tflite-micro/hello_world/README.rst b/samples/modules/tflite-micro/hello_world/README.rst index f88e12f1323..10192c337c8 100644 --- a/samples/modules/tflite-micro/hello_world/README.rst +++ b/samples/modules/tflite-micro/hello_world/README.rst @@ -61,7 +61,7 @@ or as a that can be emulated on a host machine. Assuming that the Corstone-300 FVP has been downloaded, installed and added to -the `PATH` variable, then building and testing can be done with following +the :envvar:`PATH` variable, then building and testing can be done with following commands. ``` diff --git a/samples/philosophers/README.rst b/samples/philosophers/README.rst index 2392af05165..d0701832cbe 100644 --- a/samples/philosophers/README.rst +++ b/samples/philosophers/README.rst @@ -19,7 +19,7 @@ is waiting for the second fork to be available. Each Philosopher will randomly alternate between the ``EATING`` and ``THINKING`` states. -It is possible to run the demo in `coop-only` or `preempt-only` mode. To achieve this, set these +It is possible to run the demo in ``coop-only`` or ``preempt-only`` mode. To achieve this, set these values for ``CONFIG_NUM_COOP_PRIORITIES`` and ``CONFIG_NUM_PREEMPT_PRIORITIES`` in :file:`prj.conf`: preempt-only diff --git a/samples/subsys/dap/README.rst b/samples/subsys/dap/README.rst index 7d3d117358b..1f34f02c523 100644 --- a/samples/subsys/dap/README.rst +++ b/samples/subsys/dap/README.rst @@ -14,8 +14,8 @@ Requirements This sample supports multiple hardware configurations: -The simplest configuration would be to connect `SWDIO` to `dio`, `SWDCLK` to `clk` -and optionally `nRESET` to `reset`. The optional `noe` pin is used to enable the port, +The simplest configuration would be to connect ``SWDIO`` to ``dio``, ``SWDCLK`` to ``clk`` +and optionally ``nRESET`` to ``reset``. The optional ``noe`` pin is used to enable the port, e.g. if the SWD connections are multiplexed. Building and Running diff --git a/samples/subsys/fs/format/README.rst b/samples/subsys/fs/format/README.rst index 4840ddb5341..59029d2dbfa 100644 --- a/samples/subsys/fs/format/README.rst +++ b/samples/subsys/fs/format/README.rst @@ -21,7 +21,8 @@ To run this sample, build it for the desired board and scenario and flash it. The Flash scenario is supported on the nrf52dk/nrf52832 board. The RAM disk scenario is supported on the mimxrt1064_evk board. -To build the RAM disk sample, the configuration `prj_ram.conf` needs to be used by setting `CONF_FILE=prj_ram.conf`. +To build the RAM disk sample, the configuration :file:`prj_ram.conf` needs to be used by setting +``CONF_FILE=prj_ram.conf``. The Flash sample for the nrf 52DK board can be built as follow: diff --git a/samples/subsys/fs/littlefs/README.rst b/samples/subsys/fs/littlefs/README.rst index 69be12cfefe..342614b5914 100644 --- a/samples/subsys/fs/littlefs/README.rst +++ b/samples/subsys/fs/littlefs/README.rst @@ -91,19 +91,19 @@ To build the test: At the moment, only two types of block devices are acceptable in this sample: SDMMC and MMC. -It is possible that both the `zephyr,sdmmc-disk` and `zephyr,mmc-disk` block devices will be +It is possible that both the ``zephyr,sdmmc-disk`` and ``zephyr,mmc-disk`` block devices will be present and enabled in the final board dts and configuration files simultaneously, the mount -point name for the `littlefs` file system block device will be determined based on the +point name for the ``littlefs`` file system block device will be determined based on the following logic: -* if the ``CONFIG_SDMMC_VOLUME_NAME`` configuration is defined, it will be used +* if the :kconfig:option:`CONFIG_SDMMC_VOLUME_NAME` configuration is defined, it will be used as the mount point name; -* if the ``CONFIG_SDMMC_VOLUME_NAME`` configuration is not defined, but the - ``CONFIG_MMC_VOLUME_NAME`` configuration is defined, ``CONFIG_MMC_VOLUME_NAME`` will - be used as the mount point name; -* if neither ``CONFIG_SDMMC_VOLUME_NAME`` nor ``CONFIG_MMC_VOLUME_NAME`` configurations - are defined, the mount point name will not be determined, and an appropriate error will - apear during the sample build. +* if the :kconfig:option:`CONFIG_SDMMC_VOLUME_NAME` configuration is not defined, but the + :kconfig:option:`CONFIG_MMC_VOLUME_NAME` configuration is defined, + :kconfig:option:`CONFIG_MMC_VOLUME_NAME` will be used as the mount point name; +* if neither :kconfig:option:`CONFIG_SDMMC_VOLUME_NAME` nor :kconfig:option:`CONFIG_MMC_VOLUME_NAME` + configurations are defined, the mount point name will not be determined, and an appropriate error + will appear during the sample build. NRF52840 Development Kit ======================== diff --git a/samples/subsys/llext/shell_loader/README.rst b/samples/subsys/llext/shell_loader/README.rst index ec6d8427bbd..681a9487ced 100644 --- a/samples/subsys/llext/shell_loader/README.rst +++ b/samples/subsys/llext/shell_loader/README.rst @@ -136,9 +136,9 @@ The resulting hex string can be used to load the extension. uart:~$ llext load_hex hello_world 7f454c4601010100000000000000000001002800010000000000000000000000680200000000000534000000000028000b000a0080b500af084b1800084b00f013f82a22074b11001800054b00f00cf8c046bd4680bc01bc0047c0460400000000000000140000001847c0462a00000068656c6c6f20776f726c640a0000000041206e756d62657220697320256c750a00004743433a20285a65706879722053444b20302e31362e31292031322e322e30004129000000616561626900011f000000053454000602080109011204140115011703180119011a011e06000000000000000000000000000000000100000000000000000000000400f1ff000000000000000000000000030001000000000000000000000000000300030000000000000000000000000003000400000000000000000000000000030005000f00000000000000000000000000050012000000000000000400000001000500190000000000000000000000000001000f0000002800000000000000000001001900000034000000000000000000010000000000000000000000000003000600000000000000000000000000030007001c000000010000003400000012000100280000000000000000000000100000000068656c6c6f5f776f726c642e63002464006e756d6265720024740068656c6c6f5f776f726c64007072696e746b000028000000020500002c000000020e00003000000002050000002e73796d746162002e737472746162002e7368737472746162002e72656c2e74657874002e64617461002e627373002e726f64617461002e636f6d6d656e74002e41524d2e6174747269627574657300000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f0000000100000006000000000000003400000038000000000000000000000004000000000000001b000000090000004000000000000000fc0100001800000008000000010000000400000008000000250000000100000003000000000000006c00000000000000000000000000000001000000000000002b0000000800000003000000000000006c0000000000000000000000000000000100000000000000300000000100000002000000000000006c00000025000000000000000000000004000000000000003800000001000000300000000000000091000000210000000000000000000000010000000100000041000000030000700000000000000000b20000002a0000000000000000000000010000000000000001000000020000000000000000000000dc000000f0000000090000000d000000040000001000000009000000030000000000000000000000cc0100002f0000000000000000000000010000000000000011000000030000000000000000000000140200005100000000000000000000000100000000000000 -This extension can then be seen in the list of loaded extensions (`list`), its symbols printed -(`list_symbols`), and the hello_world function which the extension exports can be called and -run (`call_fn`). +This extension can then be seen in the list of loaded extensions (``list``), its symbols printed +(``list_symbols``), and the hello_world function which the extension exports can be called and +run (``call_fn``). .. code-block:: console diff --git a/samples/subsys/usb/shell/README.rst b/samples/subsys/usb/shell/README.rst index 9f2ddb8898d..5e5437b56dc 100644 --- a/samples/subsys/usb/shell/README.rst +++ b/samples/subsys/usb/shell/README.rst @@ -36,7 +36,7 @@ currently it is only MAX3421E. The example can be built as follows: It is theoretically possible to build USB support using virtual USB controllers for all platforms, eventually the devicetree overlay has to be adjusted slightly if -the platform has already defined or not `zephyr_uhc0` or `zephyr_udc0` nodelabels. +the platform has already defined or not ``zephyr_uhc0`` or ``zephyr_udc0`` nodelabels. .. zephyr-app-commands:: :zephyr-app: samples/subsys/usb/shell diff --git a/samples/sysbuild/with_mcuboot/README.rst b/samples/sysbuild/with_mcuboot/README.rst index 7428406a62e..6ae3b81e6ec 100644 --- a/samples/sysbuild/with_mcuboot/README.rst +++ b/samples/sysbuild/with_mcuboot/README.rst @@ -19,7 +19,7 @@ sysbuild. This is achieved with a sysbuild specific Kconfig configuration, :file:`sysbuild.conf`. -The `SB_CONFIG_BOOTLOADER_MCUBOOT=y` setting in the sysbuild Kconfig file +The ``SB_CONFIG_BOOTLOADER_MCUBOOT=y`` setting in the sysbuild Kconfig file enables the bootloader when building with sysbuild. The :file:`sysbuild/mcuboot.conf` file will be used as an extra fragment that diff --git a/scripts/pylib/pytest-twister-harness/README.rst b/scripts/pylib/pytest-twister-harness/README.rst index 2c7baf4e892..99e0045ee08 100644 --- a/scripts/pylib/pytest-twister-harness/README.rst +++ b/scripts/pylib/pytest-twister-harness/README.rst @@ -7,8 +7,8 @@ Installation If you plan to use this plugin with Twister, then you don't need to install it separately by pip. When Twister uses this plugin for pytest tests, it updates -`PYTHONPATH` variable, and then extends pytest command by -`-p twister_harness.plugin` argument. +:envvar:`PYTHONPATH` variable, and then extends pytest command by +``-p twister_harness.plugin`` argument. Usage diff --git a/snippets/xen_dom0/README.rst b/snippets/xen_dom0/README.rst index a871d9f4f51..b9a83452dcb 100644 --- a/snippets/xen_dom0/README.rst +++ b/snippets/xen_dom0/README.rst @@ -29,12 +29,14 @@ For example: QEMU example with Xen *********************** -Overlay for qemu_cortex_a53 board, that is present in `board/` directory of this snippet is QEMU -Xen control domain example. To run such setup, you need to: +Overlay for qemu_cortex_a53 board, that is present in :zephyr_file:`snippets/xen_dom0/boards/` +directory of this snippet is QEMU Xen control domain example. + +To run such setup, you need to: * fetch and build Xen (e.g. RELEASE-4.17.0) for arm64 platform -* take and compile sample device tree from `example/` directory -* build your Zephyr sample/application with `xen_dom0` snippet and start it as Xen control domain +* take and compile sample device tree from :file:`example/` directory +* build your Zephyr sample/application with ``xen_dom0`` snippet and start it as Xen control domain For starting you can use QEMU from Zephyr SDK by following command: @@ -47,5 +49,7 @@ For starting you can use QEMU from Zephyr SDK by following command: -dtb /xen.dtb -kernel /xen This will start you a Xen hypervisor with your application as Xen control domain. To make it usable, -you can add `zephyr-xenlib` by Xen-troops library to your project. It'll provide basic domain +you can add `zephyr-xenlib`_ by Xen-troops library to your project. It'll provide basic domain management functionalities - domain creation and configuration. + +.. _zephyr-xenlib: https://github.com/xen-troops/zephyr-xenlib diff --git a/tests/boards/espressif_esp32/rtc_clk/README.rst b/tests/boards/espressif_esp32/rtc_clk/README.rst index f629ae1ae2a..5e48922de0e 100644 --- a/tests/boards/espressif_esp32/rtc_clk/README.rst +++ b/tests/boards/espressif_esp32/rtc_clk/README.rst @@ -34,7 +34,7 @@ To run the test with twister, use the following command: west twister -p --device-testing --device-serial=/dev/ttyUSB0 -vv --flash-before -T tests/boards/espressif_esp32/rtc_clk -If the external 32K crystal is connect to pins 32K_XP and 32K_XN, the test can be run with `external_xtal` fixture enabled: +If the external 32K crystal is connect to pins 32K_XP and 32K_XN, the test can be run with ``external_xtal`` fixture enabled: .. code-block:: console diff --git a/tests/ztest/fail/README.rst b/tests/ztest/fail/README.rst index ab5788ba821..a87cccf4a0f 100644 --- a/tests/ztest/fail/README.rst +++ b/tests/ztest/fail/README.rst @@ -8,7 +8,7 @@ Overview In order to test the actual framework's failure cases, this test suite has to do something unique. There's a subdirectory to this test called 'core'. This project builds a sample as a -:ref:`native_sim ` or `:ref:unit_testing ` +:ref:`native_sim ` or :ref:`unit_testing ` binary which is expected to fail by calling one of the following: - ``ztest_test_fail()`` during either the ``after`` or ``teardown`` phase of the test suite - ``ztest_test_skip()`` during either the ``after`` or ``teardown`` phase of the test suite