|  | .. _introducing_zephyr: | 
|  |  | 
|  | Introduction | 
|  | ############ | 
|  |  | 
|  | The Zephyr OS is based on a small-footprint kernel designed for use on | 
|  | resource-constrained and embedded systems: from simple embedded environmental | 
|  | sensors and LED wearables to sophisticated embedded controllers, smart | 
|  | watches, and IoT wireless applications. | 
|  |  | 
|  | The Zephyr kernel supports multiple architectures, including: | 
|  |  | 
|  | - ARCv2 (EM and HS) and ARCv3 (HS6X) | 
|  | - ARMv6-M, ARMv7-M, and ARMv8-M (Cortex-M) | 
|  | - ARMv7-A and ARMv8-A (Cortex-A, 32- and 64-bit) | 
|  | - ARMv7-R, ARMv8-R (Cortex-R, 32- and 64-bit) | 
|  | - Intel x86 (32- and 64-bit) | 
|  | - MIPS (MIPS32 Release 1 specification) | 
|  | - NIOS II Gen 2 | 
|  | - RISC-V (32- and 64-bit) | 
|  | - SPARC V8 | 
|  | - Tensilica Xtensa | 
|  |  | 
|  | The full list of supported boards based on these architectures can be found :ref:`here <boards>`. | 
|  |  | 
|  | In the context of the Zephyr OS, a :term:`subsystem` refers to a logically distinct | 
|  | part of the operating system that handles specific functionality or provides | 
|  | certain services. Subsystems can include components such as networking, | 
|  | file systems, device driver classes, power management, and communication protocols, | 
|  | among others. Each subsystem is designed to be modular and can be configured, | 
|  | customized, and extended to meet the requirements of different embedded | 
|  | applications. | 
|  |  | 
|  | Licensing | 
|  | ********* | 
|  |  | 
|  | Zephyr is permissively licensed using the `Apache 2.0 license`_ | 
|  | (as found in the ``LICENSE`` file in the | 
|  | project's `GitHub repo`_).  There are some | 
|  | imported or reused components of the Zephyr project that use other licensing, | 
|  | as described in :ref:`Zephyr_Licensing`. | 
|  |  | 
|  | .. _Apache 2.0 license: | 
|  | https://github.com/zephyrproject-rtos/zephyr/blob/main/LICENSE | 
|  |  | 
|  | .. _GitHub repo: https://github.com/zephyrproject-rtos/zephyr | 
|  |  | 
|  |  | 
|  | Distinguishing Features | 
|  | *********************** | 
|  |  | 
|  | Zephyr offers a large and ever growing number of features including: | 
|  |  | 
|  | **Extensive suite of Kernel services** | 
|  | Zephyr offers a number of familiar services for development: | 
|  |  | 
|  | * *Multi-threading Services* for cooperative, priority-based, | 
|  | non-preemptive, and preemptive threads with optional round robin | 
|  | time-slicing. Includes POSIX pthreads compatible API support. | 
|  |  | 
|  | * *Interrupt Services* for compile-time registration of interrupt handlers. | 
|  |  | 
|  | * *Memory Allocation Services* for dynamic allocation and freeing of | 
|  | fixed-size or variable-size memory blocks. | 
|  |  | 
|  | * *Inter-thread Synchronization Services* for binary semaphores, | 
|  | counting semaphores, and mutex semaphores. | 
|  |  | 
|  | * *Inter-thread Data Passing Services* for basic message queues, enhanced | 
|  | message queues, and byte streams. | 
|  |  | 
|  | * *Power Management Services* such as overarching, application or | 
|  | policy-defined, System Power Management and fine-grained, driver-defined, | 
|  | Device Power Management. | 
|  |  | 
|  | **Multiple Scheduling Algorithms** | 
|  | Zephyr provides a comprehensive set of thread scheduling choices: | 
|  |  | 
|  | * Cooperative and Preemptive Scheduling | 
|  | * Earliest Deadline First (EDF) | 
|  | * Meta IRQ scheduling implementing "interrupt bottom half" or "tasklet" | 
|  | behavior | 
|  | * Timeslicing: Enables time slicing between preemptible threads of equal | 
|  | priority | 
|  | * Multiple queuing strategies: | 
|  |  | 
|  | * Simple linked-list ready queue | 
|  | * Red/black tree ready queue | 
|  | * Traditional multi-queue ready queue | 
|  |  | 
|  | .. _zephyr_intro_configurability: | 
|  |  | 
|  | **Highly configurable / Modular for flexibility** | 
|  | Allows an application to incorporate *only* the capabilities it needs as it | 
|  | needs them, and to specify their quantity and size. | 
|  |  | 
|  | **Cross Architecture** | 
|  | Supports a wide variety of :ref:`supported boards<boards>` with different CPU | 
|  | architectures and developer tools. Contributions have added support | 
|  | for an increasing number of SoCs, platforms, and drivers. | 
|  |  | 
|  | **Memory Protection** | 
|  | Implements configurable architecture-specific stack-overflow protection, | 
|  | kernel object and device driver permission tracking, and thread isolation | 
|  | with thread-level memory protection on x86, ARC, and ARM architectures, | 
|  | userspace, and memory domains. | 
|  |  | 
|  | For platforms without MMU/MPU and memory constrained devices, supports | 
|  | combining application-specific code with a custom kernel to create a | 
|  | monolithic image that gets loaded and executed on a system's hardware. Both | 
|  | the application code and kernel code execute in a single shared address | 
|  | space. | 
|  |  | 
|  | **Compile-time resource definition** | 
|  | Allows system resources to be defined at compile-time, which reduces code | 
|  | size and increases performance for resource-limited systems. | 
|  |  | 
|  | **Optimized Device Driver Model** | 
|  | Provides a consistent device model for configuring the drivers that are part | 
|  | of the platform/system and a consistent model for initializing all the | 
|  | drivers configured into the system and allows the reuse of drivers across | 
|  | platforms that have common devices/IP blocks. | 
|  |  | 
|  | **Devicetree Support** | 
|  | Use of :ref:`devicetree <dt-guide>` 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 | 
|  | sockets compatible support.  OpenThread support (on Nordic chipsets) is also | 
|  | provided - a mesh network designed to securely and reliably connect hundreds | 
|  | of products around the home. | 
|  |  | 
|  | **Bluetooth Low Energy 5.0 support** | 
|  | Bluetooth 5.0 compliant (ESR10) and Bluetooth Low Energy Controller support | 
|  | (LE Link Layer). Includes Bluetooth Mesh and a Bluetooth qualification-ready | 
|  | Bluetooth controller. | 
|  |  | 
|  | * Generic Access Profile (GAP) with all possible LE roles | 
|  | * Generic Attribute Profile (GATT) | 
|  | * Pairing support, including the Secure Connections feature from Bluetooth | 
|  | 4.2 | 
|  | * Clean HCI driver abstraction | 
|  | * Raw HCI interface to run Zephyr as a Controller instead of a full Host | 
|  | stack | 
|  | * Verified with multiple popular controllers | 
|  | * Highly configurable | 
|  |  | 
|  | Mesh Support: | 
|  |  | 
|  | * Relay, Friend Node, Low-Power Node (LPN) and GATT Proxy features | 
|  | * Both Provisioning bearers supported (PB-ADV & PB-GATT) | 
|  | * Highly configurable, fitting in devices with at least 16k RAM | 
|  |  | 
|  | **Native Linux, macOS, and Windows Development** | 
|  | A command-line CMake build environment runs on popular developer OS | 
|  | systems. A native port (:ref:`native_sim <native_sim>`) lets you build and run Zephyr as a native | 
|  | application on Linux, aiding development and testing. | 
|  |  | 
|  | **Virtual File System Interface with ext2, FatFs, and LittleFS Support** | 
|  | ext2, LittleFS and FatFS support; FCB (Flash Circular Buffer) for memory constrained | 
|  | applications. | 
|  |  | 
|  | **Powerful multi-backend logging Framework** | 
|  | Support for log filtering, object dumping, panic mode, multiple backends | 
|  | (memory, networking, filesystem, console, ...) and integration with the shell | 
|  | subsystem. | 
|  |  | 
|  | **User friendly and full-featured Shell interface** | 
|  | A multi-instance shell subsystem with user-friendly features such as | 
|  | autocompletion, wildcards, coloring, metakeys (arrows, backspace, ctrl+u, | 
|  | etc.) and history. Support for static commands and dynamic sub-commands. | 
|  |  | 
|  | **Settings on non-volatile storage** | 
|  | The settings subsystem gives modules a way to store persistent per-device | 
|  | configuration and runtime state. Settings items are stored as key-value pair | 
|  | strings. | 
|  |  | 
|  | **Non-volatile storage (NVS)** | 
|  | NVS allows storage of binary blobs, strings, integers, longs, and any | 
|  | combination of these. | 
|  |  | 
|  | **Native port** | 
|  | :ref:`Native sim <native_sim>` allows running Zephyr as a Linux application with support | 
|  | for various subsystems and networking. | 
|  |  | 
|  |  | 
|  | .. include:: ../../README.rst | 
|  | :start-after: start_include_here | 
|  |  | 
|  |  | 
|  | Fundamental Terms and Concepts | 
|  | ****************************** | 
|  |  | 
|  | See :ref:`glossary` |