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 IDT 53 (Interrupt Descriptor Table) a data structure used by the x86 54 architecture to implement an interrupt vector table. The IDT is used 55 to determine the correct response to interrupts and exceptions. 56 57 ISR 58 (Interrupt Service Routine) Also known as an interrupt handler, an ISR 59 is a callback function whose execution is triggered by a hardware 60 interrupt (or software interrupt instructions) and is used to handle 61 high-priority conditions that require interrupting the current code 62 executing on the processor. 63 64 kernel 65 The set of Zephyr-supplied files that implement the Zephyr kernel, 66 including its core services, device drivers, network stack, and so on. 67 68 SoC 69 `System on a chip`_ 70 71 west 72 A multi-repo meta-tool developed for the Zephyr project. See :ref:`west`. 73 74 west installation 75 An obsolete term for a :term:`west workspace` used prior to west 0.7. 76 77 west manifest 78 A YAML file, usually named :file:`west.yml`, which describes projects, or 79 the Git repositories which make up a :term:`west workspace`, along with 80 additional metadata. See :ref:`west-basics` for general information 81 and :ref:`west-manifests` for details. 82 83 west manifest repository 84 The Git repository in a :term:`west workspace` which contains the 85 :term:`west manifest`. Its location is given by the :ref:`manifest.path 86 configuration option <west-config-index>`. See :ref:`west-basics`. 87 88 west workspace 89 A directory on your system with a :file:`.west` subdirectory and 90 a :term:`west manifest repository`. You clone the Zephyr source 91 code onto your system by creating a west workspace using the 92 ``west init`` command. See :ref:`west-basics`. 93 94 XIP 95 (eXecute In Place) a method of executing programs directly from long 96 term storage rather than copying it into RAM, saving writable memory for 97 dynamic data and not the static program code. 98 99.. _System on a chip: https://en.wikipedia.org/wiki/System_on_a_chip 100