1:orphan:
2
3.. _glossary:
4
5Glossary of Terms
6#################
7
8.. glossary::
9   :sorted:
10
11   API
12      (Application Program Interface) A defined set of routines and protocols for
13      building application software.
14
15   application
16      The set of user-supplied files that the Zephyr build system uses
17      to build an application image for a specified board configuration.
18      It can contain application-specific code, kernel configuration settings,
19      and at least one CMakeLists.txt file.
20      The application's kernel configuration settings direct the build system
21      to create a custom kernel that makes efficient use of the board's
22      resources.
23      An application can sometimes be built for more than one type of board
24      configuration (including boards with different CPU architectures),
25      if it does not require any board-specific capabilities.
26
27   application image
28      A binary file that is loaded and executed by the board for which
29      it was built.
30      Each application image contains both the application's code and the
31      Zephyr kernel code needed to support it. They are compiled as a single,
32      fully-linked binary.
33      Once an application image is loaded onto a board, the image takes control
34      of the system, initializes it, and runs as the system's sole application.
35      Both application code and kernel code execute as privileged code
36      within a single shared address space.
37
38   board
39      A target system with a defined set of devices and capabilities,
40      which can load and execute an application image. It may be an actual
41      hardware system or a simulated system running under QEMU.
42      The Zephyr kernel supports a :ref:`variety of boards <boards>`.
43
44   board configuration
45      A set of kernel configuration options that specify how the devices
46      present on a board are used by the kernel.
47      The Zephyr build system defines one or more board configurations
48      for each board it supports. The kernel configuration settings that are
49      specified by the build system can be over-ridden by the application,
50      if desired.
51
52   device runtime power management
53      Device Runtime Power Management (PM) refers the capability of devices to
54      save energy independently of the system power state. Devices will keep
55      reference of their usage and will automatically be suspended or resumed.
56      This feature is enabled via the :kconfig:option:`CONFIG_PM_DEVICE_RUNTIME`
57      Kconfig option.
58
59   idle thread
60      A system thread that runs when there are no other threads ready to run.
61
62   IDT
63      (Interrupt Descriptor Table) a data structure used by the x86
64      architecture to implement an interrupt vector table. The IDT is used
65      to determine the correct response to interrupts and exceptions.
66
67   ISR
68      (Interrupt Service Routine) Also known as an interrupt handler, an ISR
69      is a callback function whose execution is triggered by a hardware
70      interrupt (or software interrupt instructions) and is used to handle
71      high-priority conditions that require interrupting the current code
72      executing on the processor.
73
74   kernel
75      The set of Zephyr-supplied files that implement the Zephyr kernel,
76      including its core services, device drivers, network stack, and so on.
77
78   power domain
79      A power domain is a collection of devices for which power is
80      applied and removed collectively in a single action. Power
81      domains are represented by :c:struct:`device`.
82
83   power gating
84      Power gating reduces power consumption by shutting off areas of an
85      integrated circuit that are not in use.
86
87   SoC
88      `System on a chip`_
89
90   system power state
91      System power states describe the power consumption of the system as a
92      whole. System power states are represented by :c:enum:`pm_state`.
93
94   west
95      A multi-repo meta-tool developed for the Zephyr project. See :ref:`west`.
96
97   west installation
98      An obsolete term for a :term:`west workspace` used prior to west 0.7.
99
100   west manifest
101      A YAML file, usually named :file:`west.yml`, which describes projects, or
102      the Git repositories which make up a :term:`west workspace`, along with
103      additional metadata. See :ref:`west-basics` for general information
104      and :ref:`west-manifests` for details.
105
106   west manifest repository
107      The Git repository in a :term:`west workspace` which contains the
108      :term:`west manifest`. Its location is given by the :ref:`manifest.path
109      configuration option <west-config-index>`. See :ref:`west-basics`.
110
111   west workspace
112      A directory on your system with a :file:`.west` subdirectory and
113      a :term:`west manifest repository`. You clone the Zephyr source
114      code onto your system by creating a west workspace using the
115      ``west init`` command. See :ref:`west-basics`.
116
117   XIP
118      (eXecute In Place) a method of executing programs directly from long
119      term storage rather than copying it into RAM, saving writable memory for
120      dynamic data and not the static program code.
121
122.. _System on a chip: https://en.wikipedia.org/wiki/System_on_a_chip
123