michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: s/device tree/devicetree/

Browse source 
DTSpec writes this as a single word, presumably to make it easier to
grep for / more precise. Follow along in the rest of the docs now that
our main DT docs page agrees with this usage.

Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
This commit is contained in:
Marti Bolivar 2019-10-07 10:37:09 -07:00 • committed by Carles Cufí
commit 27e5dd131f
23 changed files with 59 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

2
boards/arm/96b_avenger96/doc/index.rst
View file

@ -195,7 +195,7 @@ Serial Port
by default to the RAM console to be dumped by the Linux Remoteproc Framework
on Cortex®-A7 core. Alternatively, Zephyr console output can be assigned to
UART7 which is disabled by default. UART console can be enabled through
board's device tree and 96b_avenger96_defconfig board file (or prj.conf
board's devicetree and 96b_avenger96_defconfig board file (or prj.conf
project files), and will disable existing RAM console output. Default UART
console settings are 115200 8N1.

7
boards/arm/nrf52840_pca10056/doc/index.rst
View file

@ -172,7 +172,7 @@ Using UART1
The following approach can be used when an application needs to use
more than one UART for connecting peripheral devices:
1. Add device tree overlay file to the main directory of your application:
1. Add devicetree overlay file to the main directory of your application:
.. code-block:: console
@ -195,8 +195,9 @@ more than one UART for connecting peripheral devices:
Overlay file naming
===================
The file has to be named ``<board>.overlay`` and placed in the app main directory to be
picked up automatically by the device tree compiler.
picked up automatically by the build system.
Selecting the pins
==================
@ -211,7 +212,7 @@ In the table 7.1.1 'aQFN73 ball assignments' select the pins marked
'General purpose I/O'. Note that pins marked as 'low frequency I/O only' can only be used
in under-10KHz applications. They are not suitable for 115200 speed of UART.
Translate 'Pin' into number for Device tree by using the following formula::
Translate the 'Pin' into number for devicetree by using the following formula::
pin_no = b\*32 + a

4
boards/arm/nucleo_f429zi/doc/index.rst
View file

@ -187,8 +187,8 @@ Flash partitions for MCUBoot bootloader
The on-board STM32F429ZI MCU has 2MBs of internal flash memory. To use `MCUboot`_,
define a :ref:`Zephyr partition table <flash_partitions>` for the flash memory in
its device tree file ``nucleo_f429zi.dts``. As a reference, a partition table for
MCUBoot is already defined in the device tree file, with these settings:
its devicetree file ``nucleo_f429zi.dts``. As a reference, a partition table for
MCUBoot is already defined in the devicetree file, with these settings:
- `MCUBoot`_ bootloader partition takes 64K bytes.
- Zephyr settings partition takes 64K bytes.

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

@ -119,7 +119,7 @@ two cores. This is done in 3 ways:
- **Compilation**: Clock configuration is only accessible to M7 core. M4 core only
has access to bus clock activation and deactivation.
- **Static pre-compilation assignment**: Peripherals such as a UART are assigned in
device tree before compilation. The user must ensure peripherals are not assigned
devicetree before compilation. The user must ensure peripherals are not assigned
to both cores at the same time.
- **Run time protection**: Interrupt-controller and GPIO configurations could be
accessed by both cores at run time. Accesses are protected by a hardware semaphore

2
boards/arm/stm32mp157c_dk2/doc/stm32mp157_dk2.rst
View file

@ -214,7 +214,7 @@ The Zephyr console output is assigned by default to the RAM console to be dumped
by the Linux Remoteproc Framework on Cortex®-A7 core. In order to keep the UART7
free for future serial interactions with Arduino shield, the Zephyr UART console
output is USART3 and is disabled by default. UART console can be enable through
board's device tree and stm32mp157c_dk2_defconfig board file (or prj.conf
board's devicetree and stm32mp157c_dk2_defconfig board file (or prj.conf
project files), and will disable existing RAM console output. Default UART
console settings are 115200 8N1.

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

@ -111,7 +111,7 @@ accelerometer and magnetometer for sensor values
In order to support FXOS8700 triggers (interrupts) the 0 ohm resistors
``R47`` and and ``R57`` must be mounted on the TWR-KE18F board. The
device tree must also be modified to describe the FXOS8700 interrupt
devicetree must also be modified to describe the FXOS8700 interrupt
GPIOs:
.. code-block:: none

4
boards/posix/native_posix/doc/index.rst
View file

@ -540,7 +540,7 @@ The following peripherals are currently provided with this board:
on the host file system.
The size of the flash device can be configured through the native POSIX board
device tree and the sector size is configurable via the Kconfig option
devicetree and the sector size is configurable via the Kconfig option
:option:`CONFIG_FLASH_NATIVE_POSIX_SECTOR_SIZE`. The sector size will only be
used to return flash page layout related information and no restrictions are
imposed by the driver based on the configured sector size. As such an erase
@ -552,7 +552,7 @@ The following peripherals are currently provided with this board:
By default the binary data is located in the file *flash.bin* in the current
working directory. The location of this file can be changed through the
command line parameter *--flash*. The flash data will be stored in raw format
and the file will be truncated to match the size specified in the device tree
and the file will be truncated to match the size specified in the devicetree
configuration. In case the file does not exists the driver will take care of
creating the file, else the existing file is used.

46
doc/application/index.rst
View file

@ -118,9 +118,8 @@ subdirectories which are not described here.
Device driver code.
:file:`dts`
Device tree source (.dts) files used to describe non-discoverable
board-specific hardware details previously hard coded in the OS
source code.
:ref:`device-tree` source files used to describe non-discoverable
board-specific hardware details.
:file:`ext`
Externally created code that has been integrated into Zephyr
@ -232,11 +231,8 @@ Follow these steps to create a new application directory. (Refer to
are interested in. See :ref:`application_kconfig` for more details, and
:ref:`configuration_options` for a complete list of available options.
#. Optionally, you can also configure any Device Tree overlays needed by your
application. Zephyr uses the same Device Tree system as the Linux kernel,
but with its own definitions.
This is usually not necessary; see :ref:`application_dt` below for details.
#. Optionally, you can also configure any devicetree overlays needed by your
application. See :ref:`application_dt` below for details.
.. _important-build-vars:
@ -276,10 +272,10 @@ should know about.
semicolons. Each file includes Kconfig configuration values that override
the default configuration values.
* :makevar:`DTC_OVERLAY_FILE`: Indicates the name of one or more Device Tree
* :makevar:`DTC_OVERLAY_FILE`: Indicates the name of one or more devicetree
overlay files. Multiple filenames can be separated with either spaces or
semicolons. Each file includes Device Tree values that override the default
DT values. See :ref:`application_dt` below for details on device tree
semicolons. Each file includes devicetree values that override the default
DT values. See :ref:`application_dt` below for details on devicetree
overlays, and :ref:`device-tree` for an overview on devicetree and Zephyr.
* :makevar:`ZEPHYR_MODULES`: A CMake list containing absolute paths of
@ -1093,7 +1089,7 @@ Make sure to follow these steps in order.
More details are available below in :ref:`application_kconfig`.
#. If your application uses a Device Tree overlay file or files other than
#. If your application uses a devicetree overlay file or files other than
the usual :file:`<board>.overlay`, add lines setting the
:makevar:`DTC_OVERLAY_FILE` variable to these files appropriately.
@ -1490,33 +1486,33 @@ docstrings at the top of ``scripts/kconfig/menuconfig.py`` and
.. _application_dt:
Device Tree Overlays
====================
Devicetree Overlays
===================
As described in :ref:`device-tree`, Zephyr uses Device Tree to describe the
As described in :ref:`device-tree`, Zephyr uses devicetree to describe the
hardware it runs on. This section describes how you can modify an application
build's device tree using overlay files. For additional information regarding
the relationship between Device Tree and Kconfig see :ref:`dt_vs_kconfig`. For
build's devicetree using overlay files. For additional information regarding
the relationship between devicetree and Kconfig see :ref:`dt_vs_kconfig`. For
an example of how to use custom overlays with ``west build``, see
:ref:`west-building-cmake-args`.
In some cases the information contained in Device Tree files is closely
In some cases the information contained in devicetree files is closely
connected to the software and might need to be modified using the overlay file
concept. This can be relevant for many of the different Device Tree nodes, but
concept. This can be relevant for many of the different devicetree nodes, but
is particularly useful for :ref:`certain types of nodes <dt-alias-chosen>`.
Overlay files, which customarily have the :file:`.overlay` extension,
contain device tree fragments which add to or modify the device tree
contain devicetree fragments which add to or modify the devicetree
used while building a Zephyr application. To add an overlay file or
files to the build, set the CMake variable :makevar:`DTC_OVERLAY_FILE`
to a whitespace-separated list of your overlay files.
The Zephyr build system begins creation of a device tree by running
The Zephyr build system begins creation of a devicetree by running
the C preprocessor on a file which includes the following:
#. Configuration options from :ref:`Kconfig <configuration_options>`.
#. The board's device tree source file, which by default is the Zephyr
#. The board's devicetree source file, which by default is the Zephyr
file :file:`boards/<ARCHITECTURE>/<BOARD>/<BOARD>.dts`. (This location
can be overridden by setting the :makevar:`DTS_SOURCE` CMake
variable.)
@ -1526,7 +1522,7 @@ the C preprocessor on a file which includes the following:
overlays can be overridden by setting the
:makevar:`DTS_COMMON_OVERLAYS` CMake variable.)
The file :file:`common.dts` conditionally includes device tree
The file :file:`common.dts` conditionally includes devicetree
fragments based on Kconfig settings. For example, it includes a
fragment for MCUboot chain-loading, located at
:file:`dts/common/mcuboot.overlay`, if
@ -1551,8 +1547,8 @@ is determined, and then stops looking:
If :makevar:`DTC_OVERLAY_FILE` specifies multiple files, they are
included in order by the C preprocessor.
After running the preprocessor, the final device tree used in the
build is created by running the device tree compiler, ``dtc``, on the
After running the preprocessor, the final devicetree used in the
build is created by running the devicetree compiler, ``dtc``, on the
preprocessor output.
Application-Specific Code

2
doc/guides/dts/index.rst
View file

@ -5,7 +5,7 @@ Devicetree
Zephyr uses the *devicetree* data structure to describe the hardware available
on a board, as well as its initial configuration in an application. Note that
"devicetree" -- without spaces -- is preferred to "device tree". The
"devicetree" -- without spaces -- is preferred to "devicetree". The
`Devicetree specification`_ fully defines this data structure and its source
and binary representations.

2
doc/guides/env_vars.rst
View file

@ -146,7 +146,7 @@ behavior.
:ref:`important-build-vars`.
- :envvar:`CONF_FILE`: allows adding Kconfig fragments to an application build;
see :ref:`important-build-vars`.
- :envvar:`DTC_OVERLAY_FILE`: allows adding device tree overlays to an
- :envvar:`DTC_OVERLAY_FILE`: allows adding devicetree overlays to an
application build; see :ref:`important-build-vars`.
- :envvar:`ZEPHYR_BASE`: the absolute path to the main ``zephyr`` repository.
This is set whenever you run the ``zephyr-env.sh`` or ``zephyr-env.cmd``

12
doc/guides/kconfig/index.rst
View file

@ -34,7 +34,7 @@ sense for the user to change its value.
In Zephyr, Kconfig configuration is done after selecting a machine, so in
general, it does not make sense to put a prompt on a symbol that corresponds to
a fixed machine-specific setting. Usually, such settings should be handled via
device tree (``.dts``) files instead.
devicetree (``.dts``) files instead.
Symbols without prompts can't be configured directly by the user (they derive
their value from other symbols), so less restrictions apply to them. If some
@ -808,12 +808,12 @@ Kconfig Functions
*****************
Kconfiglib provides user-defined preprocessor functions that
we use in Zephyr to expose Device Tree information to Kconfig.
we use in Zephyr to expose devicetree information to Kconfig.
For example, we can get the default value for a Kconfig symbol
from the device tree.
from the devicetree.
Device Tree Related Functions
=============================
Devicetree Related Functions
============================
See the Python docstrings in ``scripts/kconfig/kconfigfunctions.py`` for more
details on the functions.
@ -831,7 +831,7 @@ Example Usage
-------------
The following example shows the usage of the ``dt_node_reg_addr`` function.
This function will take a path to a device tree node and register the register
This function will take a path to a devicetree node and register the register
address of that node:
.. code-block:: none

8
doc/guides/porting/shields.rst
View file

@ -23,8 +23,8 @@ under :zephyr_file:`/boards/shields`:
These files provides shield configuration as follows:
* **<shield>.overlay**: This file provides a shield description in device tree
format that is merged with the board's device tree information before
* **<shield>.overlay**: This file provides a shield description in devicetree
format that is merged with the board's devicetree information before
compilation.
* **<shield>.conf**: This file defines values for Kconfig symbols that are
@ -47,8 +47,8 @@ This should be done at two different level:
* Pinmux: Connector pins should be correctly configured to match shield pins
* Device tree: A board device tree file should define a node alias for each
connector interface. For example, for Arduino I2C:
* Devicetree: A board :ref:`device-tree` file should define a node alias for
each connector interface. For example, for Arduino I2C:
.. code-block:: none

2
doc/guides/west/build-flash-debug.rst
View file

@ -191,7 +191,7 @@ are given. All command-line arguments to ``west build`` after a ``--`` are
passed to CMake.
To set :ref:`DTC_OVERLAY_FILE <application_dt>` to :file:`enable-modem.overlay`,
using that file as a :ref:`device tree overlay <device-tree>`::
using that file as a :ref:`devicetree overlay <device-tree>`::
west build -b reel_board -- -DDTC_OVERLAY_FILE=enable-modem.overlay

8
doc/introduction/index.rst
View file

@ -99,11 +99,9 @@ Zephyr offers a large and ever growing number of features including:
drivers configured into the system and Allows the reuse of drivers across
platforms that have common devices/IP blocks
**Device Tree Support**
Use of Device Tree (DTS) to describe hardware and configuration information for
boards. The DTS information will be used only during compile time.
Information about the system is extracted from the compiled DTS and used to
create the application image.
**Devicetree Support**
Use of :ref:`device-tree` to describe hardware. Information from devicetree
is used to create the application image.
**Native Networking Stack supporting multiple protocols**
Networking support is fully featured and optimized, including LwM2M and BSD

2
doc/reference/storage/disk/sdhc.rst
View file

@ -25,7 +25,7 @@ MMC cards are not supported and will be ignored.
Enabling
********
For example, this device tree fragment adds an SDHC card slot on ``spi1``,
For example, this devicetree fragment adds an SDHC card slot on ``spi1``,
uses ``PA27`` for chip select, and runs the SPI bus at 24 MHz once the
SDHC card has been initialized:

2
samples/basic/blinky/README.rst
View file

@ -15,7 +15,7 @@ Requirements
The demo assumes that an LED is connected to one of GPIO lines. The
sample code is configured to work on boards that have defined the led0
alias in their board device tree description file. Doing so will generate
alias in their board devicetree description file. Doing so will generate
these variables:
- DT_ALIAS_LED0_GPIOS_CONTROLLER

2
samples/basic/button/README.rst
View file

@ -22,7 +22,7 @@ header file. The :file:`board.h` must define the following variables:
- DT_ALIAS_SW0_GPIOS_PIN
Alternatively, this could also be done by defining 'sw0' alias in the board
device tree description file.
devicetree description file.
Building and Running

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

@ -21,8 +21,8 @@ In order to use this application, you need a board with a Bluetooth
controller and SPI slave drivers, and a spare GPIO to use as an
interrupt line to the SPI master.
You then need to ensure that your Device Tree settings provide a definition
for the slave HCI SPI device::
You then need to ensure that your :ref:`device-tree` settings provide a
definition for the slave HCI SPI device::
bt-hci@0 {
compatible = "zephyr,bt-hci-spi-slave";

2
samples/drivers/CAN/README.rst
View file

@ -18,7 +18,7 @@ In loopback mode, the board receives its own messages. This could be used for
standalone testing.
The sample can be built and executed on boards supporting CAN.
The LED output pin is defined in the board's device tree.
The LED output pin is defined in the board's devicetree.
Sample output
=============

2
samples/shields/x_nucleo_iks01a1/README.rst
View file

@ -19,7 +19,7 @@ Requirements
This sample communicates over I2C with the X-NUCLEO-IKS01A1 shield
stacked on a board with an Arduino connector. The board's I2C must be
configured for the I2C Arduino connector (both for pin muxing
and device tree).
and devicetree).
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
does not yet support sensors multiple instances.

2
samples/shields/x_nucleo_iks01a2/README.rst
View file

@ -19,7 +19,7 @@ Requirements
This sample communicates over I2C with the X-NUCLEO-IKS01A2 shield
stacked on a board with an Arduino connector. The board's I2C must be
configured for the I2C Arduino connector (both for pin muxing
and device tree). See for example the :ref:`nucleo_f401re_board` board
and devicetree). See for example the :ref:`nucleo_f401re_board` board
source code:
- :zephyr_file:`boards/arm/nucleo_f401re/nucleo_f401re.dts`

2
samples/shields/x_nucleo_iks01a3/sensorhub/README.rst
View file

@ -32,7 +32,7 @@ Requirements
This sample communicates over I2C with the X-NUCLEO-IKS01A3 shield
stacked on a board with an Arduino connector. The board's I2C must be
configured for the I2C Arduino connector (both for pin muxing
and device tree). See for example the :ref:`nucleo_f401re_board` board
and devicetree). See for example the :ref:`nucleo_f401re_board` board
source code:
- :file:`$ZEPHYR_BASE/boards/arm/nucleo_f401re/nucleo_f401re.dts`

2
samples/shields/x_nucleo_iks01a3/standard/README.rst
View file

@ -25,7 +25,7 @@ Requirements
This sample communicates over I2C with the X-NUCLEO-IKS01A3 shield
stacked on a board with an Arduino connector. The board's I2C must be
configured for the I2C Arduino connector (both for pin muxing
and device tree). See for example the :ref:`nucleo_f401re_board` board
and devicetree). See for example the :ref:`nucleo_f401re_board` board
source code:
- :file:`$ZEPHYR_BASE/boards/arm/nucleo_f401re/nucleo_f401re.dts`