51b885019e
The one page on devicetree is too long. Split it into multiple pages to make it easier to digest and more squintable. This is basically just moving content around; minimal changes have been made apart from redoing some transitions and adding a couple of introductory paragraphs. Rename the 'device-tree' Sphinx :ref: target while we are here. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
56 lines
2.7 KiB
ReStructuredText
56 lines
2.7 KiB
ReStructuredText
.. _dt_vs_kconfig:
|
|
|
|
Devicetree versus Kconfig
|
|
#########################
|
|
|
|
Along with devicetree, Zephyr also uses the Kconfig language to configure the
|
|
source code. Whether to use devicetree or Kconfig for a particular purpose can
|
|
sometimes be confusing. This section should help you decide which one to use.
|
|
|
|
In short:
|
|
|
|
* Use devicetree to describe **hardware** and its **boot-time configuration**.
|
|
Examples include peripherals on a board, boot-time clock frequencies,
|
|
interrupt lines, etc.
|
|
* Use Kconfig to configure **software support** to build into the final
|
|
image. Examples include whether to add networking support, which drivers are
|
|
needed by the application, etc.
|
|
|
|
In other words, devicetree mainly deals with hardware, and Kconfig with
|
|
software.
|
|
|
|
For example, consider a board containing a SoC with 2 UART, or serial port,
|
|
instances.
|
|
|
|
* The fact that the board has this UART **hardware** is described with two UART
|
|
nodes in the devicetree. These provide the UART type (via the ``compatible``
|
|
property) and certain settings such as the address range of the hardware
|
|
peripheral registers in memory (via the ``reg`` property).
|
|
* Additionally, the UART **boot-time configuration** is also described with
|
|
devicetree. This could include configuration such as the RX IRQ line's
|
|
priority and the UART baud rate. These may be modifiable at runtime, but
|
|
their boot-time configuration is described in devicetree.
|
|
* Whether or not to include **software support** for UART in the build is
|
|
controlled via Kconfig. Applications which do not need to use the UARTs can
|
|
remove the driver source code from the build using Kconfig, even though the
|
|
board's devicetree still includes UART nodes.
|
|
|
|
As another example, consider a device with a 2.4GHz, multi-protocol radio
|
|
supporting both the Bluetooth Low Energy and 802.15.4 wireless technologies.
|
|
|
|
* Devicetree should be used to describe the presence of the radio **hardware**,
|
|
what driver or drivers it's compatible with, etc.
|
|
* **Boot-time configuration** for the radio, such as TX power in dBm, should
|
|
also be specified using devicetree.
|
|
* Kconfig should determine which **software features** should be built for the
|
|
radio, such as selecting a BLE or 802.15.4 protocol stack.
|
|
|
|
There are two noteworthy **exceptions** to these rules:
|
|
|
|
* Devicetree's ``chosen`` keyword, which allows the user to select a specific
|
|
instance of a hardware device to be used for a particular purpose. An example
|
|
of this is selecting a particular UART for use as the system's console.
|
|
* Devicetree's ``status`` keyword, which allows the user to enable or disable a
|
|
particular instance of a hardware device. This takes precedence over related
|
|
Kconfig options which serve a similar purpose.
|