blob: 6633cd4153fbd5fb228c853b20f24769123e7d62 [file] [log] [blame]
.. _devicetree-scope-purpose:
Scope and purpose
*****************
A *devicetree* is primarily a hierarchical data structure that describes
hardware. The `Devicetree specification`_ defines its source and binary
representations.
.. _Devicetree specification: https://www.devicetree.org/
Zephyr uses devicetree to describe:
- the hardware available on its :ref:`boards`
- that hardware's initial configuration
As such, devicetree is both a hardware description language and a configuration
language for Zephyr. See :ref:`dt_vs_kconfig` for some comparisons between
devicetree and Zephyr's other main configuration language, Kconfig.
There are two types of devicetree input files: *devicetree sources* and
*devicetree bindings*. The sources contain the devicetree itself. The bindings
describe its contents, including data types. The :ref:`build system
<build_overview>` uses devicetree sources and bindings to produce a generated C
header. The generated header's contents are abstracted by the ``devicetree.h``
API, which you can use to get information from your devicetree.
Here is a simplified view of the process:
.. figure:: zephyr_dt_build_flow.png
:figclass: align-center
Devicetree build flow
All Zephyr and application source code files can include and use
``devicetree.h``. This includes :ref:`device drivers <device_model_api>`,
:ref:`applications <application>`, :ref:`tests <testing>`, the kernel, etc.
The API itself is based on C macros. The macro names all start with ``DT_``. In
general, if you see a macro that starts with ``DT_`` in a Zephyr source file,
it's probably a ``devicetree.h`` macro. The generated C header contains macros
that start with ``DT_`` as well; you might see those in compiler error
messages. You always can tell a generated- from a non-generated macro:
generated macros have some lowercased letters, while the ``devicetree.h`` macro
names have all capital letters.