doc: use :zephyr_file: where appropriate
A new role :zephyr_file: is available that renders to a link to the file or folder in GitHub. Find appropriate references using :file: and convert to :zephyr_file: to take advantage of its linking capability. Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
This commit is contained in:
David B. Kinder
Anas Nashif
parent
214ef00db3
commit
505cc2bb0e
108 changed files with 167 additions and 155 deletions
|
|
@ -27,18 +27,18 @@ See also this URL for details about the board:
|
|||
The latest version of EM Starter Kit is 2.3, developer can upgrade from
|
||||
2.0/2.1/2.2 to 2.3 using latest firmware.
|
||||
The default configuration for EM Starter Kit boards can be found in
|
||||
:file:`boards/arc/em_starterkit/em_starterkit_defconfig`.
|
||||
:zephyr_file:`boards/arc/em_starterkit/em_starterkit_defconfig`.
|
||||
|
||||
The default SoC for this board supported in Zephyr is the EM9D.
|
||||
This configuration is a Harvard Architecture, with a separate
|
||||
instruction bus and data bus. Instruction memory is called ICCM
|
||||
and data memory is called DCCM. The configuration file for EM9D
|
||||
is found in :file:`soc/arc/snps_emsk/Kconfig.defconfig.em9d`.
|
||||
is found in :zephyr_file:`soc/arc/snps_emsk/Kconfig.defconfig.em9d`.
|
||||
|
||||
If you have a larger program, you can select the EM7D or EM11D, which gives
|
||||
access to 128KB DRAM with i-cache and d-cache. The configuration file for EM7D
|
||||
is found in :file:`soc/arc/snps_emsk/Kconfig.defconfig.em7d` and EM11D is
|
||||
found in :file:`soc/arc/snps_emsk/Kconfig.defconfig.em11d`.
|
||||
is found in :zephyr_file:`soc/arc/snps_emsk/Kconfig.defconfig.em7d` and EM11D is
|
||||
found in :zephyr_file:`soc/arc/snps_emsk/Kconfig.defconfig.em11d`.
|
||||
|
||||
|
||||
Hardware
|
||||
|
|
@ -185,7 +185,7 @@ Building Sample Applications
|
|||
|
||||
You can try many of the sample applications or tests, but let us discuss
|
||||
the one called :ref:`hello_world`.
|
||||
It is found in :file:`$ZEPHYR_BASE/samples/hello_world`.
|
||||
It is found in :zephyr_file:`samples/hello_world`.
|
||||
|
||||
Configuring
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ Building Sample Applications
|
|||
|
||||
You can try many of the sample applications or tests, but let us discuss
|
||||
the one called :ref:`hello_world`.
|
||||
It is found in :file:`$ZEPHYR_BASE/samples/hello_world`.
|
||||
It is found in :zephyr_file:`samples/hello_world`.
|
||||
|
||||
Configuring
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -19,8 +19,8 @@ There are two sub configurations in board:
|
|||
* nsim_sem which includes secure em features and ARC MPUv3
|
||||
|
||||
For detailed arc features, please refer to
|
||||
:file:`boards/arc/nsim_em/support/nsim.props` and
|
||||
:file:`boards/arc/nsim_em/support/nsim_sem.props`.
|
||||
:zephyr_file:`boards/arc/nsim_em/support/nsim.props` and
|
||||
:zephyr_file:`boards/arc/nsim_em/support/nsim_sem.props`.
|
||||
|
||||
|
||||
Hardware
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ following hardware features:
|
|||
Other hardware features are not currently supported by Zephyr.
|
||||
|
||||
The default configuration can be found in the Kconfig file
|
||||
:file:`boards/arm/adafruit_feather_m0_basic_proto/adafruit_feather_m0_basic_proto_defconfig`.
|
||||
:zephyr_file:`boards/arm/adafruit_feather_m0_basic_proto/adafruit_feather_m0_basic_proto_defconfig`.
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ features:
|
|||
Other hardware features are not currently supported by Zephyr.
|
||||
|
||||
The default configuration can be found in the Kconfig file
|
||||
:file:`boards/arm/adafruit_trinket_m0/adafruit_trinket_m0_defconfig`.
|
||||
:zephyr_file:`boards/arm/adafruit_trinket_m0/adafruit_trinket_m0_defconfig`.
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ See `Arduino Due website`_ and `Atmel SAM3X8E Datasheet`_ for a complete
|
|||
list of Arduino Due board hardware features.
|
||||
|
||||
The default configuration can be found in the Kconfig
|
||||
:file:`boards/arm/arduino_due/arduino_due_defconfig`.
|
||||
:zephyr_file:`boards/arm/arduino_due/arduino_due_defconfig`.
|
||||
|
||||
.. note::
|
||||
For I2C, pull-up resistors are required for using SCL1 and SDA1 (near IO13).
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ features:
|
|||
Other hardware features are not currently supported by Zephyr.
|
||||
|
||||
The default configuration can be found in the Kconfig
|
||||
:file:`boards/arm/arduino_zero/arduino_zero_defconfig`.
|
||||
:zephyr_file:`boards/arm/arduino_zero/arduino_zero_defconfig`.
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ features:
|
|||
Other hardware features are not currently supported by Zephyr.
|
||||
|
||||
The default configuration can be found in the Kconfig
|
||||
:file:`boards/arm/atsamd20_xpro/atsamd20_xpro_defconfig`.
|
||||
:zephyr_file:`boards/arm/atsamd20_xpro/atsamd20_xpro_defconfig`.
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -261,7 +261,8 @@ the board are working properly with Zephyr:
|
|||
* :ref:`button-sample`
|
||||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in :file:`boards/arm/bl652_dvk/bl652_dvk.dts`.
|
||||
your board. The button and LED definitions can be found in
|
||||
:zephyr_file:`boards/arm/bl652_dvk/bl652_dvk.dts`.
|
||||
|
||||
References
|
||||
**********
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ the board are working properly with Zephyr:
|
|||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in
|
||||
:file:`boards/arm/bl654_dvk/bl654_dvk.dts`.
|
||||
:zephyr_file:`boards/arm/bl654_dvk/bl654_dvk.dts`.
|
||||
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ Connections and IOs
|
|||
|
||||
The SensorTag has one GPIO controller, along with a flexible pin
|
||||
multiplexer. In practice, the pins are routed as described in
|
||||
:file:`boards/arm/cc2650_sensortag/board.h`; the most commonly used being:
|
||||
:zephyr_file:`boards/arm/cc2650_sensortag/board.h`; the most commonly used being:
|
||||
|
||||
+----------------+---------------+----------------------+
|
||||
| Physical pin # | Digital I/O # | Signal |
|
||||
|
|
@ -135,7 +135,7 @@ CCFG ("Customer Configuration" area). A 32-bit word in this area,
|
|||
pass control to your program. You can find more information on the CCFG
|
||||
in the `CC2650 reference manual`_, section 9.1. The current CC2650 port
|
||||
for Zephyr already does this by default; if you wish to check or modify
|
||||
the CCFG content, see :file:`soc/arm/ti_simplelink/cc2650/soc.c`.
|
||||
the CCFG content, see :zephyr_file:`soc/arm/ti_simplelink/cc2650/soc.c`.
|
||||
|
||||
Building
|
||||
========
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ Connections and IOs
|
|||
====================
|
||||
|
||||
Peripherals on the CC3220SF LaunchXL are mapped to the following pins in
|
||||
the file :file:`boards/arm/cc3220sf_launchxl/pinmux.c`.
|
||||
the file :zephyr_file:`boards/arm/cc3220sf_launchxl/pinmux.c`.
|
||||
|
||||
+------------+-------+-------+
|
||||
| Function | PIN | GPIO |
|
||||
|
|
@ -96,7 +96,7 @@ the file :file:`boards/arm/cc3220sf_launchxl/pinmux.c`.
|
|||
+------------+-------+-------+
|
||||
|
||||
The default configuration can be found in the Kconfig file at
|
||||
:file:`boards/arm/cc3220sf_launchxl/cc3220sf_launchxl_defconfig`.
|
||||
:zephyr_file:`boards/arm/cc3220sf_launchxl/cc3220sf_launchxl_defconfig`.
|
||||
|
||||
|
||||
Programming and Debugging
|
||||
|
|
@ -162,7 +162,7 @@ Prerequisites:
|
|||
and /usr/local/share/, you may want to backup any current openocd
|
||||
installations there.
|
||||
If you decide to change the default installation location, also update
|
||||
the OPENOCD path variable in :file:`boards/arm/cc3220sf_launchxl/board.cmake`.
|
||||
the OPENOCD path variable in :zephyr_file:`boards/arm/cc3220sf_launchxl/board.cmake`.
|
||||
|
||||
#. Ensure CONFIG_XIP=y (default) is set.
|
||||
|
||||
|
|
@ -219,14 +219,14 @@ WiFi Support
|
|||
The SimpleLink Host Driver, imported from the SimpleLink SDK, has been ported
|
||||
to Zephyr, and communicates over a dedicated SPI to the network co-processor.
|
||||
It is available as a Zephyr WiFi device driver in
|
||||
:file:`drivers/wifi/simplelink`.
|
||||
:zephyr_file:`drivers/wifi/simplelink`.
|
||||
|
||||
Usage:
|
||||
======
|
||||
|
||||
Set :option:`CONFIG_WIFI_SIMPLELINK` and :option:`CONFIG_WIFI` to ``y``
|
||||
to enable WiFi.
|
||||
See :file:`samples/net/wifi/boards/cc3220sf_launchxl.conf`.
|
||||
See :zephyr_file:`samples/net/wifi/boards/cc3220sf_launchxl.conf`.
|
||||
|
||||
Provisioning:
|
||||
=============
|
||||
|
|
@ -265,7 +265,7 @@ and enabled by:
|
|||
Root-Certificate Catalog.
|
||||
|
||||
See :ref:`sockets-http-get` and
|
||||
:file:`samples/net/sockets/http_get/boards/cc3220sf_launchxl.conf` for an
|
||||
:zephyr_file:`samples/net/sockets/http_get/boards/cc3220sf_launchxl.conf` for an
|
||||
example.
|
||||
|
||||
See the document `Simplelink WiFi Certificates Handling`_ for details on
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ The board configuration supports the following hardware features:
|
|||
|
||||
|
||||
The default configuration can be found in the Kconfig
|
||||
:file:`boards/arm/cy8ckit_062_wifi_bt_m0/cy8ckit_062_wifi_bt_m0_defconfig`.
|
||||
:zephyr_file:`boards/arm/cy8ckit_062_wifi_bt_m0/cy8ckit_062_wifi_bt_m0_defconfig`.
|
||||
|
||||
|
||||
System Clock
|
||||
|
|
|
|||
|
|
@ -19,4 +19,4 @@ In order to have CM4 core working FW for both cores should be written into
|
|||
Flash. CM0+ FW should starts the CM4 core at one point using
|
||||
Cy_SysEnableCM4(CM4_START_ADDRESS); call. CM4_START_ADDRESS is 0x10060000 in
|
||||
the current configuration. The CM0+/CM4 Flash/SRAM areas are defined in
|
||||
:file:'dts/arm/cypress/psoc6.dtsi'.
|
||||
:zephyr_file:`dts/arm/cypress/psoc6.dtsi`.
|
||||
|
|
|
|||
|
|
@ -201,7 +201,8 @@ the board are working properly with Zephyr:
|
|||
- :ref:`96b_carbon_multi_thread_blinky`
|
||||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in :file:`boards/arm/nrf51_ble400/board.h`.
|
||||
your board. The button and LED definitions can be found in
|
||||
:zephyr_file:`boards/arm/nrf51_ble400/nrf51_ble400.dts`.
|
||||
|
||||
References
|
||||
**********
|
||||
|
|
|
|||
|
|
@ -147,7 +147,8 @@ the board are working properly with Zephyr:
|
|||
samples/basic/button
|
||||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in :file:`boards/arm/nrf51_pca10028/nrf51_pca10028.dts`.
|
||||
your board. The button and LED definitions can be found in
|
||||
:zephyr_file:`boards/arm/nrf51_pca10028/nrf51_pca10028.dts`.
|
||||
|
||||
References
|
||||
**********
|
||||
|
|
|
|||
|
|
@ -180,7 +180,8 @@ the board are working properly with Zephyr:
|
|||
* :ref:`button-sample`
|
||||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in :file:`boards/arm/nrf52840_blip/nrf52840_blip.dts`.
|
||||
your board. The button and LED definitions can be found in
|
||||
:zephyr_file:`boards/arm/nrf52840_blip/nrf52840_blip.dts`.
|
||||
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -163,8 +163,8 @@ the board are working properly with Zephyr:
|
|||
samples/basic/button
|
||||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in :file:
|
||||
`boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts`.
|
||||
your board. The button and LED definitions can be found in
|
||||
:zephyr_file:`boards/arm/nrf52840_pca10056/nrf52840_pca10056.dts`.
|
||||
|
||||
Using UART1
|
||||
***********
|
||||
|
|
|
|||
|
|
@ -175,7 +175,8 @@ the board are working properly with Zephyr:
|
|||
- :ref:`96b_carbon_multi_thread_blinky`
|
||||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in :file:`boards/arm/nrf52_adafruit_feather/board.h`.
|
||||
your board. The button and LED definitions can be found in
|
||||
:zephyr_file:`boards/arm/nrf52_adafruit_feather/board.h`.
|
||||
|
||||
|
||||
References
|
||||
|
|
|
|||
|
|
@ -394,7 +394,8 @@ the board are working properly with Zephyr:
|
|||
samples/basic/button
|
||||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in :file:`boards/arm/nrf52_pca10040/nrf52_pca10040.dts`.
|
||||
your board. The button and LED definitions can be found in
|
||||
:zephyr_file:`boards/arm/nrf52_pca10040/nrf52_pca10040.dts`.
|
||||
|
||||
References
|
||||
**********
|
||||
|
|
|
|||
|
|
@ -189,8 +189,8 @@ the board are working properly with Zephyr:
|
|||
* :ref:`button-sample`
|
||||
|
||||
You can build and flash the examples to make sure Zephyr is running correctly on
|
||||
your board. The button and LED definitions can be found in :file:
|
||||
`boards/arm/nrf9160_pca10090/nrf9160_pca10090_common.dts`.
|
||||
your board. The button and LED definitions can be found in
|
||||
:zephyr_file:`boards/arm/nrf9160_pca10090/nrf9160_pca10090_common.dts`.
|
||||
|
||||
References
|
||||
**********
|
||||
|
|
|
|||
|
|
@ -82,7 +82,7 @@ The mode is controlled by MODE pin (P1.00).
|
|||
.. note::
|
||||
Actually there is no possibility to reduce energy consumption by the
|
||||
Low Power mode. Both voltages are always on, see:
|
||||
:file:`boards/arm/reel_board/board.c`
|
||||
:zephyr_file:`boards/arm/reel_board/board.c`
|
||||
|
||||
Supported Features
|
||||
==================
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ features:
|
|||
Other hardware features are not currently supported by Zephyr.
|
||||
|
||||
The default configuration can be found in the Kconfig
|
||||
:file:`boards/arm/sam4s_xplained/sam4s_xplained_defconfig`.
|
||||
:zephyr_file:`boards/arm/sam4s_xplained/sam4s_xplained_defconfig`.
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ features:
|
|||
Other hardware features are not currently supported by Zephyr.
|
||||
|
||||
The default configuration can be found in the Kconfig
|
||||
:file:`boards/arm/sam_e70_xplained/sam_e70_xplained_defconfig`.
|
||||
:zephyr_file:`boards/arm/sam_e70_xplained/sam_e70_xplained_defconfig`.
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ The Zephyr stm3210c_eval board configuration supports the following hardware fea
|
|||
Other hardware features are not yet supported in this Zephyr port.
|
||||
|
||||
The default configuration can be found in the defconfig file
|
||||
:file:`boards/arm/stm3210c_eval/stm3210c_eval_defconfig`.
|
||||
:zephyr_file:`boards/arm/stm3210c_eval/stm3210c_eval_defconfig`.
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ The Zephyr stm32373c_eval board configuration supports the following hardware fe
|
|||
Other hardware features are not yet supported in this Zephyr port.
|
||||
|
||||
The default configuration can be found in the defconfig file
|
||||
:file:`boards/arm/stm32373c_eval/stm32373c_eval_defconfig`
|
||||
:zephyr_file:`boards/arm/stm32373c_eval/stm32373c_eval_defconfig`
|
||||
|
||||
Connections and IOs
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ hardware features:
|
|||
Other hardware features are not yet supported on Zephyr porting.
|
||||
|
||||
The default configuration can be found in the defconfig file
|
||||
:file:`boards/arm/stm32f411e_disco/stm32f411e_disco_defconfig`
|
||||
:zephyr_file:`boards/arm/stm32f411e_disco/stm32f411e_disco_defconfig`
|
||||
|
||||
|
||||
Pin Mapping
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Zephyr project developers are continually adding board-specific support as
|
|||
documented below.
|
||||
|
||||
To add support documentation for a new board, please use the template available
|
||||
under :file:`doc/templates/board.tmpl`
|
||||
under :zephyr_file:`doc/templates/board.tmpl`
|
||||
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -94,11 +94,11 @@ Reference CPU
|
|||
=============
|
||||
|
||||
A reference CPU design of a Nios II/f core is included in the Zephyr tree
|
||||
in the :file:`soc/nios2/nios2f-zephyr/cpu` directory.
|
||||
in the :zephyr_file:`soc/nios2/nios2f-zephyr/cpu` directory.
|
||||
|
||||
Flash this CPU using the ``nios2-configure-sof`` SDK tool with the FPGA
|
||||
configuration file
|
||||
:file:`soc/nios2/nios2f-zephyr/cpu/ghrd_10m50da.sof`:
|
||||
:zephyr_file:`soc/nios2/nios2f-zephyr/cpu/ghrd_10m50da.sof`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
|
|||
|
|
@ -246,7 +246,7 @@ Additional Pins
|
|||
For an up-to-date description of additional pins (such as buttons,
|
||||
LEDs, etc.) supported by Zephyr, see the board DTS files in the Zephyr
|
||||
source code, i.e.
|
||||
:file:`boards/riscv32/rv32m1_vega/rv32m1_vega_ri5cy.dts` for RI5CY.
|
||||
:zephyr_file:`boards/riscv32/rv32m1_vega/rv32m1_vega_ri5cy.dts` for RI5CY.
|
||||
|
||||
See the schematic in the documentation available from the `OpenISA
|
||||
GitHub releases`_ page for additional details.
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ When using the Zephyr kernel, the pinout mapping for the Arduino 101 becomes a
|
|||
little more complicated. The table below details which pins in Zephyr map to
|
||||
those on the Arduino 101 board for control. Full details of the pinmux
|
||||
implementation, what valid options can be configured, and where things map can
|
||||
be found in the :file:`boards/x86/arduino_101/pinmux.c` file.
|
||||
be found in the :zephyr_file:`boards/x86/arduino_101/pinmux.c` file.
|
||||
|
||||
|
||||
+-------------+----------+------------+
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Programming and Debugging
|
|||
*************************
|
||||
|
||||
The D2000 board configuration details are found in the project's tree at
|
||||
:file:`boards/x86/quark_d2000_crb`.
|
||||
:zephyr_file:`boards/x86/quark_d2000_crb`.
|
||||
|
||||
Applications for the ``quark_d2000_crb`` board configuration can be built and
|
||||
flashed in the usual way (see :ref:`build_an_application` and
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Programming and Debugging
|
|||
*************************
|
||||
|
||||
The board configuration details are found in the project's tree at
|
||||
:file:`boards/x86/quark_se_c1000_devboard`.
|
||||
:zephyr_file:`boards/x86/quark_se_c1000_devboard`.
|
||||
|
||||
Applications for the ``quark_se_c1000_devboard`` board configuration can be built and
|
||||
flashed in the usual way (see :ref:`build_an_application` and
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ The file "soc/xtensa/linker_more.ld" contains Zephyr-specific linker
|
|||
sections that should be added to the default linker script linker.ld (inside
|
||||
SECTIONS region). If you are not using a linker script, you must create one
|
||||
and add these sections. The memory segment and PHDR should be replaced by
|
||||
appropriate values. See :file:`soc/xtensa/hifi3_bd5/linker.ld` for an example.
|
||||
appropriate values. See :zephyr_file:`soc/xtensa/hifi3_bd5/linker.ld` for an example.
|
||||
|
||||
The linker script should be named ``linker.ld`` and placed in the directory
|
||||
``soc/xtensa/${XTENSA_CORE}``.
|
||||
|
|
|
|||
|
|
@ -175,7 +175,7 @@ of the build folder and run ``cmake`` and then ``ninja`` again.
|
|||
|
||||
If you add or remove a file from the documentation, you need to re-run CMake.
|
||||
|
||||
On Unix platforms a convenience :file:`Makefile` at the root folder
|
||||
On Unix platforms a convenience :zephyr_file:`Makefile` at the root folder
|
||||
of the Zephyr repository can be used to build the documentation directly from
|
||||
there:
|
||||
|
||||
|
|
|
|||
|
|
@ -1469,7 +1469,7 @@ be useful for glue code to have access to Zephyr kernel header files.
|
|||
To make it easier to integrate third-party components, the Zephyr
|
||||
build system has defined CMake functions that give application build
|
||||
scripts access to the zephyr compiler options. The functions are
|
||||
documented and defined in :file:`$ZEPHYR_BASE/cmake/extensions.cmake`
|
||||
documented and defined in :zephyr_file:`cmake/extensions.cmake`
|
||||
and follow the naming convention ``zephyr_get_<type>_<format>``.
|
||||
|
||||
The following variables will often need to be exported to the
|
||||
|
|
@ -1480,7 +1480,7 @@ third-party build system.
|
|||
* ``ARCH`` and ``BOARD``, together with several variables that identify the
|
||||
Zephyr kernel version.
|
||||
|
||||
:file:`samples/application_development/external_lib` is a sample
|
||||
:zephyr_file:`samples/application_development/external_lib` is a sample
|
||||
project that demonstrates some of these features.
|
||||
|
||||
.. _Eclipse IDE for C/C++ Developers: https://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/oxygen2
|
||||
|
|
|
|||
|
|
@ -708,7 +708,7 @@ these additional steps must be followed:
|
|||
|
||||
#. Complete a README for your code component and add it to your source
|
||||
code pull request (PR). A recommended README template can be found in
|
||||
:file:`doc/contribute/code_component_README` (and included
|
||||
:zephyr_file:`doc/contribute/code_component_README` (and included
|
||||
`below`_ for reference)
|
||||
|
||||
#. The Zephyr Technical Steering Committee (TSC) will evaluate the code
|
||||
|
|
|
|||
|
|
@ -248,12 +248,12 @@ Tagging
|
|||
Every time a release candidate (or the final release) needs to be tagged, the
|
||||
following steps need to be followed:
|
||||
|
||||
#. Update the :file:`VERSION` file in the root of the Git repository. If it's a
|
||||
#. Update the :zephyr_file:`VERSION` file in the root of the Git repository. If it's a
|
||||
release candidate, use `EXTRAVERSION` variable::
|
||||
|
||||
EXTRAVERSION = rc1
|
||||
|
||||
#. Commit the update to the :file:`VERSION` file, use `release:` as a commit
|
||||
#. Commit the update to the :zephyr_file:`VERSION` file, use `release:` as a commit
|
||||
tag.
|
||||
#. Check that CI has completed successfully before tagging.
|
||||
#. Tag and push the version, using annotated tags:
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ the code base.
|
|||
The Zephyr project uses GitHub for code reviews and Git tree management. When
|
||||
submitting a change or an enhancement to any Zephyr component, a developer
|
||||
should use GitHub. GitHub automatically assigns a responsible reviewer on a
|
||||
component basis, as defined in the :file:`CODEOWNERS` file stored with the code
|
||||
component basis, as defined in the :zephyr_file:`CODEOWNERS` file stored with the code
|
||||
tree in the Zephyr project repository. A limited set of release managers are
|
||||
allowed to merge a pull request into the master branch once reviews are complete.
|
||||
|
||||
|
|
|
|||
|
|
@ -294,13 +294,13 @@ build target from an initialized build directory to get a list.
|
|||
:board: reel_board
|
||||
:goals: build
|
||||
|
||||
The main build products are in :file:`zephyr/samples/hello_world/build/zephyr`.
|
||||
The main build products are in :file:`samples/hello_world/build/zephyr`.
|
||||
The final application binary in ELF format is named :file:`zephyr.elf` by
|
||||
default. Other binary formats and byproducts such as disassembly and map files
|
||||
will be present depending on the target and build system configuration.
|
||||
|
||||
Other sample projects demonstrating Zephyr's features are located in
|
||||
:file:`zephyr/samples` and are documented in :ref:`samples-and-demos`.
|
||||
:zephyr_file:`samples` and are documented in :ref:`samples-and-demos`.
|
||||
|
||||
Run the Application by Flashing to a Board
|
||||
==========================================
|
||||
|
|
|
|||
|
|
@ -26,8 +26,8 @@ systems.
|
|||
|
||||
The management subsystem is split in two different locations in the Zephyr tree:
|
||||
|
||||
* :file:`ext/lib/mgmt/mcumgr/` contains a clean import of the MCUmgr project
|
||||
* :file:`subsys/mgmt/` contains the Zephyr-specific bindings to MCUmgr
|
||||
* :zephyr_file:`ext/lib/mgmt/mcumgr/` contains a clean import of the MCUmgr project
|
||||
* :zephyr_file:`subsys/mgmt/` contains the Zephyr-specific bindings to MCUmgr
|
||||
|
||||
Additionally there is a :ref:`sample <smp_svr_sample>` that provides management
|
||||
functionality over BLE and serial.
|
||||
|
|
|
|||
|
|
@ -246,6 +246,12 @@ For example, there are roles for marking :file:`filenames`
|
|||
(``:command:`make```). You can also use the \`\`inline code\`\`
|
||||
markup (double backticks) to indicate a ``filename``.
|
||||
|
||||
For references to files that are in the Zephyr GitHub tree, a special
|
||||
role can be used that creates a hyperlink to that file. For example a
|
||||
reference to the reST file used to create this document can be generated
|
||||
using ``:zephyr_file:\`doc/guides/documentation/index.rst\``` that will
|
||||
show up as :zephyr_file:`doc/guides/documentation/index.rst`.
|
||||
|
||||
.. _internal-linking:
|
||||
|
||||
Internal Cross-Reference Linking
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Network Connectivity API
|
|||
########################
|
||||
|
||||
Applications should use the BSD socket API defined in
|
||||
:file:`include/net/socket.h` to create a connection, send or receive data,
|
||||
:zephyr_file:`include/net/socket.h` to create a connection, send or receive data,
|
||||
and close a connection. The same API can be used when working with UDP or
|
||||
TCP data. See :ref:`BSD socket API <bsd_sockets_interface>` for more details.
|
||||
|
||||
|
|
@ -12,5 +12,5 @@ See :ref:`sockets-echo-server-sample` and :ref:`sockets-echo-client-sample`
|
|||
applications how to create a simple server or client BSD socket based
|
||||
application.
|
||||
|
||||
The legacy connectivity API in :file:`include/net/net_context.h` should not be
|
||||
The legacy connectivity API in :zephyr_file:`include/net/net_context.h` should not be
|
||||
used by applications.
|
||||
|
|
|
|||
|
|
@ -143,7 +143,7 @@ parameter.
|
|||
and ARM architectures via the :option:`CONFIG_GEN_ISR_TABLES` implementation.
|
||||
You can find examples of the stubs by looking at :code:`_interrupt_enter()` in
|
||||
x86, :code:`_IntExit()` in ARM, :code:`_isr_wrapper()` in ARM, or the full
|
||||
implementation description for ARC in :file:`arch/arc/core/isr_wrapper.S`.
|
||||
implementation description for ARC in :zephyr_file:`arch/arc/core/isr_wrapper.S`.
|
||||
|
||||
Each architecture also has to implement primitives for interrupt control:
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ we strongly suggest that handlers at least print some debug information. The
|
|||
information helps figuring out what went wrong when hitting an exception that
|
||||
is a fault, like divide-by-zero or invalid memory access, or an interrupt that
|
||||
is not expected (:dfn:`spurious interrupt`). See the ARM implementation in
|
||||
:file:`arch/arm/core/fault.c` for an example.
|
||||
:zephyr_file:`arch/arm/core/fault.c` for an example.
|
||||
|
||||
Thread Context Switching
|
||||
************************
|
||||
|
|
@ -302,7 +302,7 @@ gracefully exits its entry point function.
|
|||
This means implementing an architecture-specific version of
|
||||
:c:func:`k_thread_abort`, and setting the Kconfig option
|
||||
:option:`CONFIG_ARCH_HAS_THREAD_ABORT` as needed for the architecture (e.g. see
|
||||
:file:`arch/arm//core/cortex_m/Kconfig`).
|
||||
:zephyr_file:`arch/arm//core/cortex_m/Kconfig`).
|
||||
|
||||
Device Drivers
|
||||
**************
|
||||
|
|
@ -457,7 +457,7 @@ Toolchain and Linking
|
|||
|
||||
Toolchain support has to be added to the build system.
|
||||
|
||||
Some architecture-specific definitions are needed in :file:`include/toolchain/gcc.h`.
|
||||
Some architecture-specific definitions are needed in :zephyr_file:`include/toolchain/gcc.h`.
|
||||
See what exists in that file for currently supported architectures.
|
||||
|
||||
Each architecture also needs its own linker script, even if most sections can
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Shield porting and configuration
|
|||
********************************
|
||||
|
||||
Shield configuration files are available in the board directory
|
||||
under :file:`/boards/shields`:
|
||||
under :zephyr_file:`/boards/shields`:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ integration testing, or for unit testing specific modules.
|
|||
Quick start - Integration testing
|
||||
*********************************
|
||||
|
||||
A simple working base is located at :file:`samples/testing/integration`. Just
|
||||
A simple working base is located at :zephyr_file:`samples/testing/integration`. Just
|
||||
copy the files to ``tests/`` and edit them for your needs. The test will then
|
||||
be automatically built and run by the sanitycheck script. If you are testing
|
||||
the **bar** component of **foo**, you should copy the sample folder to
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ your application and allows enabled backends to visualize the inner-working of
|
|||
the kernel and various subsystems.
|
||||
|
||||
Applications and supported tools can define empty macros declared in
|
||||
:file:`include/tracing.h` that are called across the kernel in key spots.
|
||||
:zephyr_file:`include/tracing.h` that are called across the kernel in key spots.
|
||||
|
||||
|
||||
SEGGER SystemView Support
|
||||
|
|
|
|||
|
|
@ -303,7 +303,7 @@ outside the west repository. Some reasons this choice was made are:
|
|||
|
||||
The extension commands are a thin wrapper around a package called
|
||||
``runners`` (this package is also in the Zephyr tree, in
|
||||
:file:`scripts/west_commands/runners`).
|
||||
:zephyr_file:`scripts/west_commands/runners`).
|
||||
|
||||
The central abstraction within this library is ``ZephyrBinaryRunner``,
|
||||
an abstract class which represents *runner* objects, which can flash
|
||||
|
|
@ -323,7 +323,7 @@ upstream Zephyr, the runner should be added into a new or existing
|
|||
|
||||
.. note::
|
||||
|
||||
The test cases in :file:`scripts/west_commands/tests` add unit test
|
||||
The test cases in :zephyr_file:`scripts/west_commands/tests` add unit test
|
||||
coverage for the runners package and individual runner classes.
|
||||
|
||||
Please try to add tests when adding new runners. Note that if your
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ time filtering is independent for each backend and each source of log messages.
|
|||
Source of log messages can be a module or specific instance of the module.
|
||||
|
||||
There are four severity levels available in the system: error, warning, info
|
||||
and debug. For each severity level the logger API (:file:`include/logging/log.h`)
|
||||
and debug. For each severity level the logger API (:zephyr_file:`include/logging/log.h`)
|
||||
has set of dedicated macros. Logger API also has macros for logging data.
|
||||
|
||||
For each level following set of macros are available:
|
||||
|
|
@ -82,7 +82,7 @@ arguments. Hexdump message contains copied data.
|
|||
Global Kconfig Options
|
||||
**********************
|
||||
|
||||
These options can be found in the following path :file:`subsys/logging/Kconfig`.
|
||||
These options can be found in the following path :zephyr_file:`subsys/logging/Kconfig`.
|
||||
|
||||
:option:`CONFIG_LOG`: Global switch, turns on/off the logger.
|
||||
|
||||
|
|
@ -204,7 +204,7 @@ provided.
|
|||
LOG_INF("foo");
|
||||
}
|
||||
|
||||
Dedicated Kconfig template (:file:`subsys/logging/Kconfig.template.log_config`)
|
||||
Dedicated Kconfig template (:zephyr_file:`subsys/logging/Kconfig.template.log_config`)
|
||||
can be used to create local log level configuration.
|
||||
|
||||
Example below presents usage of the template. As a result CONFIG_FOO_LOG_LEVEL
|
||||
|
|
@ -280,7 +280,7 @@ Controlling the logger
|
|||
======================
|
||||
|
||||
Logger can be controlled using API defined in
|
||||
:file:`include/logging/log_ctrl.h`. Logger must be initialized before it can be
|
||||
:zephyr_file:`include/logging/log_ctrl.h`. Logger must be initialized before it can be
|
||||
used. Optionally, user can provide function which returns timestamp value. If
|
||||
not provided, :c:macro:`k_cycle_get_32` is used for timestamping.
|
||||
:cpp:func:`log_process` function is used to trigger processing of one log
|
||||
|
|
@ -450,7 +450,7 @@ Once message is processed, backend puts back the message
|
|||
:cpp:func:`log_msg_put`, when reference counter reaches 0, message is returned
|
||||
to the pool. It is up to the backend how message is processed. If backend
|
||||
intends to format message into the string, helper function for that are
|
||||
available in :file:`include/logging/log_output.h`.
|
||||
available in :zephyr_file:`include/logging/log_output.h`.
|
||||
|
||||
Example message formatted using :cpp:func:`log_output_msg_process`.
|
||||
|
||||
|
|
|
|||
|
|
@ -25,14 +25,14 @@ There are two configuration categories: configurations per module and global
|
|||
configurations. When logging is enabled globally, it works for modules. However,
|
||||
modules can disable logging locally. Every module can specify its own logging
|
||||
level. The module must define the :c:macro:`SYS_LOG_LEVEL` macro before
|
||||
including the :file:`include/logging/sys_log.h` header file to do so. Unless a global
|
||||
including the :zephyr_file:`include/logging/sys_log.h` header file to do so. Unless a global
|
||||
override is set, the module logging level will be honored. The global override
|
||||
can only increase the logging level. It cannot be used to lower module logging
|
||||
levels that were previously set higher.
|
||||
|
||||
You can set a local domain to differentiate messages. When no domain is set,
|
||||
then the ``[general]`` domain appears before the message. Define the
|
||||
:c:macro:`SYS_LOG_DOMAIN` macro before including the :file:`include/logging/sys_log.h`
|
||||
:c:macro:`SYS_LOG_DOMAIN` macro before including the :zephyr_file:`include/logging/sys_log.h`
|
||||
header file to set the domain.
|
||||
|
||||
When several macros are active, the printed messages can be differentiated in
|
||||
|
|
@ -41,7 +41,7 @@ two ways: by a tag printed before the message or by ANSI colors. See the
|
|||
Kconfig options for more information.
|
||||
|
||||
Define the :c:macro:`SYS_LOG_NO_NEWLINE` macro before including the
|
||||
:file:`include/logging/sys_log.h` header file to prevent macros appending a new line at the
|
||||
:zephyr_file:`include/logging/sys_log.h` header file to prevent macros appending a new line at the
|
||||
end of the logging message.
|
||||
|
||||
.. _global_kconfig:
|
||||
|
|
@ -49,7 +49,7 @@ end of the logging message.
|
|||
Global Kconfig Options
|
||||
**********************
|
||||
|
||||
These options can be found in the following path :file:`subsys/logging/Kconfig`.
|
||||
These options can be found in the following path :zephyr_file:`subsys/logging/Kconfig`.
|
||||
|
||||
:option:`CONFIG_SYS_LOG`: Global switch, turns on/off all system logging.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ setup the system:
|
|||
then the user can optionally configure static IP addresses to be set to the
|
||||
first network interface in the system. Typically setting static IP addresses
|
||||
is only usable in testing and should not be used in production code. See
|
||||
the config library Kconfig file :file:`subsys/net/lib/config/Kconfig`
|
||||
the config library Kconfig file :zephyr_file:`subsys/net/lib/config/Kconfig`
|
||||
for specific options to set the static IP addresses."
|
||||
":option:`CONFIG_NET_CONFIG_AUTO_INIT`", "The networking system is
|
||||
automatically configured when the device is started."
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ The ``net_if_get_default()`` returns a *default* network interface. What
|
|||
this default interface means can be configured via options like
|
||||
:option:`CONFIG_NET_DEFAULT_IF_FIRST` and
|
||||
:option:`CONFIG_NET_DEFAULT_IF_ETHERNET`.
|
||||
See Kconfig file :file:`subsys/net/ip/Kconfig` what options are available for
|
||||
See Kconfig file :zephyr_file:`subsys/net/ip/Kconfig` what options are available for
|
||||
selecting the default network interface.
|
||||
|
||||
The transmitted and received network packets can be classified via a network
|
||||
|
|
|
|||
|
|
@ -12,11 +12,11 @@ Overview
|
|||
|
||||
The L2 stack is designed to hide the whole networking link-layer part
|
||||
and the related device drivers from the upper network stack. This is made
|
||||
through a :c:type:`struct net_if` declared in :file:`include/net/net_if.h`.
|
||||
through a :c:type:`struct net_if` declared in :zephyr_file:`include/net/net_if.h`.
|
||||
|
||||
The upper layers are unaware of implementation details beyond the net_if
|
||||
object and the generic API provided by the L2 layer in
|
||||
:file:`include/net/net_l2.h` as :c:type:`struct net_l2`.
|
||||
:zephyr_file:`include/net/net_l2.h` as :c:type:`struct net_l2`.
|
||||
|
||||
Only the L2 layer can talk to the device driver, linked to the net_if
|
||||
object. The L2 layer dictates the API provided by the device driver,
|
||||
|
|
@ -117,7 +117,7 @@ here as well. There are two specific differences however:
|
|||
ieee802154_radio_api`, which overloads :c:type:`struct
|
||||
net_if_api`. This is because 802.15.4 L2 needs more from the device
|
||||
driver than just ``send()`` and ``recv()`` functions. This dedicated API is
|
||||
declared in :file:`include/net/ieee802154_radio.h`. Each and every IEEE
|
||||
declared in :zephyr_file:`include/net/ieee802154_radio.h`. Each and every IEEE
|
||||
802.15.4 device driver must provide a valid pointer on such
|
||||
relevantly filled-in API structure.
|
||||
|
||||
|
|
|
|||
|
|
@ -113,9 +113,9 @@ associated mgmt_request code.
|
|||
Management request code are defined in relevant places depending on
|
||||
the targeted layer or eventually, if l2 is the layer, on the
|
||||
technology as well. For instance, all IP layer management request code
|
||||
will be found in the :file:`include/net/net_mgmt.h` header file. But in case
|
||||
will be found in the :zephyr_file:`include/net/net_mgmt.h` header file. But in case
|
||||
of an L2 technology, let's say Ethernet, these would be found in
|
||||
:file:`include/net/ethernet.h`
|
||||
:zephyr_file:`include/net/ethernet.h`
|
||||
|
||||
You define your handler modeled with this signature:
|
||||
|
||||
|
|
@ -142,9 +142,9 @@ Signaling a network event
|
|||
|
||||
You can signal a specific network event using the :cpp:func:`net_mgmt_notify()`
|
||||
function and provide the network event code. See
|
||||
:file:`include/net/net_mgmt.h` for details. As for the management request
|
||||
:zephyr_file:`include/net/net_mgmt.h` for details. As for the management request
|
||||
code, event code can be also found on specific L2 technology mgmt headers,
|
||||
for example :file:`include/net/ieee802154_mgmt.h` would be the right place if
|
||||
for example :zephyr_file:`include/net/ieee802154_mgmt.h` would be the right place if
|
||||
802.15.4 L2 is the technology one wants to listen to events.
|
||||
|
||||
API Reference
|
||||
|
|
|
|||
|
|
@ -23,6 +23,6 @@ and chapter 34.5 table 34-1. Each traffic class is in turn mapped to a certain
|
|||
kernel work queue. The maximum number of traffic classes for both Rx and Tx
|
||||
is 8.
|
||||
|
||||
See :file:`subsys/net/ip/net_tc.c` for details of how various mappings are done.
|
||||
See :zephyr_file:`subsys/net/ip/net_tc.c` for details of how various mappings are done.
|
||||
|
||||
.. _IEEE 802.1Q spec: https://ieeexplore.ieee.org/document/6991462/
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ Use the following macros for adding shell commands:
|
|||
* :c:macro:`SHELL_DYNAMIC_CMD_CREATE` - Create a dynamic subcommands array.
|
||||
|
||||
Commands can be created in any file in the system that includes
|
||||
:file:`include/shell/shell.h`. All created commands are available for all
|
||||
:zephyr_file:`include/shell/shell.h`. All created commands are available for all
|
||||
shell instances.
|
||||
|
||||
Static commands
|
||||
|
|
@ -117,7 +117,7 @@ subcommands.
|
|||
SHELL_CMD_REGISTER(demo, &sub_demo, "Demo commands", NULL);
|
||||
|
||||
Example implementation can be found under following location:
|
||||
:file:`samples/subsys/shell/shell_module/src/main.c`.
|
||||
:zephyr_file:`samples/subsys/shell/shell_module/src/main.c`.
|
||||
|
||||
Dynamic commands
|
||||
----------------
|
||||
|
|
@ -182,7 +182,7 @@ Newly added commands can be prompted or autocompleted with the :kbd:`Tab` key.
|
|||
"Demonstrate dynamic command usage.", cmd_dynamic);
|
||||
|
||||
Example implementation can be found under following location:
|
||||
:file:`samples/subsys/shell/shell_module/src/dynamic_cmd.c`.
|
||||
:zephyr_file:`samples/subsys/shell/shell_module/src/dynamic_cmd.c`.
|
||||
|
||||
Commands execution
|
||||
==================
|
||||
|
|
@ -434,10 +434,10 @@ These commands are registered by various modules, for example:
|
|||
|
||||
* :command:`clear`, :command:`shell`, :command:`history`, and :command:`resize`
|
||||
are built-in commands which have been registered by
|
||||
:file:`subsys/shell/shell.c`
|
||||
:zephyr_file:`subsys/shell/shell.c`
|
||||
* :command:`demo` and :command:`version` have been registered in example code
|
||||
above by main.c
|
||||
* :command:`log` has been registered by :file:`subsys/logging/log_cmds.c`
|
||||
* :command:`log` has been registered by :zephyr_file:`subsys/logging/log_cmds.c`
|
||||
|
||||
Then, if a user types a :command:`demo` command and presses the :kbd:`Tab` key,
|
||||
the shell will only print the subcommands registered for this command:
|
||||
|
|
|
|||
|
|
@ -50,5 +50,5 @@ The SDHC card will be automatically detected and initialized by the
|
|||
filesystem driver when the board boots.
|
||||
|
||||
To read and write files and directories, see the :ref:`file_system` in
|
||||
:file:`include/fs.h` such as :c:func:`fs_open()`,
|
||||
:zephyr_file:`include/fs.h` such as :c:func:`fs_open()`,
|
||||
:c:func:`fs_read()`, and :c:func:`fs_write()`.
|
||||
|
|
|
|||
|
|
@ -29,4 +29,4 @@ in an alternating pattern.
|
|||
This project does not output to the serial console, but instead causes two LEDs
|
||||
connected to the GPIO device to blink in an alternating pattern.
|
||||
|
||||
The sample can be found here: :file:`samples/basic/disco`.
|
||||
The sample can be found here: :zephyr_file:`samples/basic/disco`.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/beacon` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/beacon` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Requirements
|
|||
|
||||
Building and Running
|
||||
********************
|
||||
This sample can be found under :file:`samples/bluetooth/central` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/central` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/central_hr` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/central_hr` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Requirements
|
|||
|
||||
Building and Running
|
||||
********************
|
||||
This sample can be found under :file:`samples/bluetooth/eddystone` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/eddystone` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/handsfree` in
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/handsfree` in
|
||||
the Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ By default the controller builds use the following settings:
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/hci_uart` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/hci_uart` in the
|
||||
Zephyr tree, and it is built as a standard Zephyr application.
|
||||
|
||||
Using the controller with QEMU and BlueZ
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Requirements
|
|||
|
||||
Building and Running
|
||||
********************
|
||||
This sample can be found under :file:`samples/bluetooth/hci_usb` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/hci_usb` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/ibeacon` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/ibeacon` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details on how
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ you IPv6 connectivity over BLE.
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/ipsp` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/ipsp` in the
|
||||
Zephyr tree.
|
||||
Sample can be built and executed for the nRF52840 PCA10056 as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/mesh` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/mesh` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details on how
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/mesh_demo` in
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/mesh_demo` in
|
||||
the Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details on how
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/peripheral` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/peripheral` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/peripheral_csc` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/peripheral_csc` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Requirements
|
|||
|
||||
Building and Running
|
||||
********************
|
||||
This sample can be found under :file:`samples/bluetooth/peripheral_dis` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/peripheral_dis` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/peripheral_esp` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/peripheral_esp` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/peripheral_hids` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/peripheral_hids` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/peripheral_hr` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/peripheral_hr` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/peripheral_sc_only`
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/peripheral_sc_only`
|
||||
in the Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Requirements
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/bluetooth/scan_adv` in the
|
||||
This sample can be found under :zephyr_file:`samples/bluetooth/scan_adv` in the
|
||||
Zephyr tree.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -63,14 +63,14 @@ Five seconds of acquisition at a 16KHz sampling rate yields 80,000 16-bit sample
|
|||
The microphone PDM requested clock should lead the MP34DT05 driver to select an
|
||||
oversampling/decimation factor equal to 128, resulting in a 2.048MHz bit clock.
|
||||
|
||||
See pcm and pdm configuration in file :file:`samples/boards/96b_argonkey/microphone/src/main.c`.
|
||||
See pcm and pdm configuration in file :zephyr_file:`samples/boards/96b_argonkey/microphone/src/main.c`.
|
||||
|
||||
.. note:: It is possible to change the AUDIO_FREQ to 32000 acquiring only 2500 ms. In this
|
||||
case the oversampling/decimation factor will be 64.
|
||||
|
||||
At the end of the acquisition the PCM data will be printed on the terminal
|
||||
emulator in either binary or ASCII format. The output is controlled by
|
||||
following macro, off by default, in :file:`samples/boards/96b_argonkey/microphone/src/main.c`:
|
||||
following macro, off by default, in :zephyr_file:`samples/boards/96b_argonkey/microphone/src/main.c`:
|
||||
|
||||
* :c:macro:`PCM_OUTPUT_IN_ASCII`
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ in either one of the following two ways:
|
|||
- standalone mode, supplying 5V directly on P1 connector
|
||||
|
||||
The user may select or unselect the sensors from
|
||||
:file:`samples/boards/96b_argonkey/sensors/prj.conf`.
|
||||
:zephyr_file:`samples/boards/96b_argonkey/sensors/prj.conf`.
|
||||
|
||||
Please note that all sensor related code is conditionally compiled
|
||||
using the `#ifdef` directive, so this sample is supposed to always
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ likely also run on the nrf52_pca10040 board.
|
|||
Building and Running
|
||||
********************
|
||||
|
||||
This sample can be found under :file:`samples/boards/nrf52/mesh/onoff-app` in the
|
||||
This sample can be found under :zephyr_file:`samples/boards/nrf52/mesh/onoff-app` in the
|
||||
Zephyr tree.
|
||||
|
||||
The following commands build the application.
|
||||
|
|
@ -94,6 +94,6 @@ that has that LED's model and issuing the onoff command.
|
|||
Group addresses are not supported.
|
||||
|
||||
This application was derived from the sample mesh skeleton at
|
||||
:file:`samples/bluetooth/mesh`.
|
||||
:zephyr_file:`samples/bluetooth/mesh`.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ likely also run on the nrf52_pca10040 board.
|
|||
|
||||
Building and Running
|
||||
********************
|
||||
This sample can be found under :file:`samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app` in the
|
||||
This sample can be found under :zephyr_file:`samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app` in the
|
||||
Zephyr tree.
|
||||
|
||||
The following commands build the application.
|
||||
|
|
@ -111,6 +111,6 @@ that has that LED's model and issuing the onoff command.
|
|||
Group addresses are not supported.
|
||||
|
||||
This application was derived from the sample mesh skeleton at
|
||||
:file:`samples/bluetooth/mesh`.
|
||||
:zephyr_file:`samples/bluetooth/mesh`.
|
||||
|
||||
See :ref:`bluetooth setup section <bluetooth_setup>` for details.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ a PNG image, and then uses the generated header (``cfb_font_dice.h``)
|
|||
to show the font elements on the display of a supported board.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/display/cfb_custom_font`.
|
||||
:zephyr_file:`samples/display/cfb_custom_font`.
|
||||
|
||||
Building and Running
|
||||
********************
|
||||
|
|
|
|||
|
|
@ -26,4 +26,4 @@ Samples and Demos
|
|||
|
||||
.. comment
|
||||
To add a new sample document, please use the template available under
|
||||
:file:`doc/templates/sample.tmpl`
|
||||
``doc/templates/sample.tmpl``
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ interface to the host system. One can communicate with Zephyr via this network
|
|||
interface.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/eth_native_posix`.
|
||||
:zephyr_file:`samples/net/eth_native_posix`.
|
||||
|
||||
Building And Running
|
||||
********************
|
||||
|
|
@ -69,7 +69,7 @@ in QEMU.
|
|||
If you want to connect two Zephyr instances together, you can do it like this:
|
||||
|
||||
Create two Zephyr config files prj1.conf and prj2.conf. You can use
|
||||
:file:`samples/net/eth_native_posix/prj.conf` as a base.
|
||||
:zephyr_file:`samples/net/eth_native_posix/prj.conf` as a base.
|
||||
|
||||
Set prj1.conf IP address configuration like this:
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ currently is able to
|
|||
- Send/Receive keep alive / pings from cloud server
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/google_iot_mqtt`.
|
||||
:zephyr_file:`samples/net/google_iot_mqtt`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ queues) and setup VLANs (if enabled). The net-shell is also enabled so that
|
|||
user can monitor gPTP functionality.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/gptp`.
|
||||
:zephyr_file:`samples/net/gptp`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
@ -48,7 +48,7 @@ Setting up Linux Host
|
|||
=====================
|
||||
|
||||
If you need VLAN support in your network, then the
|
||||
:file:`samples/net/vlan/vlan-setup-linux.sh` provides a script that can be
|
||||
:zephyr_file:`samples/net/vlan/vlan-setup-linux.sh` provides a script that can be
|
||||
executed on the Linux host. It creates two VLANs on the Linux host and creates
|
||||
routes to Zephyr. If you are using native_posix board, then
|
||||
the ``net-setup.sh`` will create VLAN setup automatically with this command:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ The Link Layer Discovery Protocol sample application for Zephyr will enable
|
|||
LLDP support and setup VLANs if needed.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/lldp`.
|
||||
:zephyr_file:`samples/net/lldp`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
@ -38,6 +38,6 @@ Setting up Linux Host
|
|||
=====================
|
||||
|
||||
If you need VLAN support in your network, then the
|
||||
:file:`samples/net/vlan/vlan-setup-linux.sh` provides a script that can be
|
||||
:zephyr_file:`samples/net/vlan/vlan-setup-linux.sh` provides a script that can be
|
||||
executed on the Linux host. It creates two VLANs on the Linux host and creates
|
||||
routes to Zephyr.
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ and establishes a connection to an LwM2M server using the
|
|||
http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/lwm2m_client`.
|
||||
:zephyr_file:`samples/net/lwm2m_client`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ See the `MQTT V3.1.1 spec`_ for more information.
|
|||
.. _MQTT V3.1.1 spec: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
|
||||
|
||||
The source code of this sample application can be found at:
|
||||
:file:`samples/net/mqtt_publisher`.
|
||||
:zephyr_file:`samples/net/mqtt_publisher`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
@ -94,7 +94,7 @@ following macros to specify those values:
|
|||
#define BLUEMIX_FORMAT "json"
|
||||
|
||||
On your Linux host computer, open a terminal window, locate the source code
|
||||
of this sample application (i.e. :file:`samples/net/mqtt_publisher`) and type:
|
||||
of this sample application (i.e. :zephyr_file:`samples/net/mqtt_publisher`) and type:
|
||||
|
||||
.. zephyr-app-commands::
|
||||
:zephyr-app: samples/net/mqtt_publisher
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ transferred. Thus, it can serve as a "load testing" application for
|
|||
the Zephyr IP stack.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/sockets/big_http_download`.
|
||||
:zephyr_file:`samples/net/sockets/big_http_download`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ perform performance/regression testing using existing HTTP diagnostic
|
|||
tools.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/sockets/dumb_http_server`.
|
||||
:zephyr_file:`samples/net/sockets/dumb_http_server`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ show how it's possible to develop a sockets application portable to both
|
|||
POSIX and Zephyr. As such, it is kept minimal and supports only IPv4 and TCP.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/sockets/echo`.
|
||||
:zephyr_file:`samples/net/sockets/echo`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ supporting both IPv4 and IPv6 with concurrent connections, limiting
|
|||
maximum number of simultaneous connections, and basic error handling.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/sockets/echo_async`.
|
||||
:zephyr_file:`samples/net/sockets/echo_async`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ with non-blocking sockets and a ``select()`` call. This is a variant of
|
|||
the :ref:`async-sockets-echo-sample` sample.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/sockets/echo_async_select`.
|
||||
:zephyr_file:`samples/net/sockets/echo_async_select`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ that will send IPv4 or IPv6 packets, wait for the data to be sent back,
|
|||
and then verify it matches the data that was sent.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/sockets/echo_client`.
|
||||
:zephyr_file:`samples/net/sockets/echo_client`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ for incoming IPv4 or IPv6 packets (sent by the echo client) and simply sends
|
|||
them back.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/sockets/echo_server`.
|
||||
:zephyr_file:`samples/net/sockets/echo_server`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ portable to both POSIX and Zephyr. As such, it is kept minimal and
|
|||
supports only IPv4.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/sockets/http_get`.
|
||||
:zephyr_file:`samples/net/sockets/http_get`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ This sample shows how to query (and display) network statistics from a user
|
|||
application.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/stats`.
|
||||
:zephyr_file:`samples/net/stats`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ See https://tools.ietf.org/html/rfc5424 and https://tools.ietf.org/html/rfc5426
|
|||
for more details about syslog protocol over UDP.
|
||||
|
||||
The source code for this sample application can be found at:
|
||||
:file:`samples/net/syslog_net`.
|
||||
:zephyr_file:`samples/net/syslog_net`.
|
||||
|
||||
Requirements
|
||||
************
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ configured for the I2C Arduino connector (both for pin muxing
|
|||
and device tree). See for example the :ref:`nucleo_f401re_board` board
|
||||
source code:
|
||||
|
||||
- :file:`$ZEPHYR_BASE/boards/arm/nucleo_f401re/nucleo_f401re.dts`
|
||||
- :file:`$ZEPHYR_BASE/boards/arm/nucleo_f401re/pinmux.c`
|
||||
- :zephyr_file:`boards/arm/nucleo_f401re/nucleo_f401re.dts`
|
||||
- :zephyr_file:`boards/arm/nucleo_f401re/pinmux.c`
|
||||
|
||||
Please note that this sample can't be used with boards already supporting
|
||||
one of the sensors available on the shield (such as disco_l475_iot1) as zephyr
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue