| /Zephyr-latest/doc/introduction/ |
| D | index.rst | 7 resource-constrained and embedded systems: from simple embedded environmental
8 sensors and LED wearables to sophisticated embedded controllers, smart
9 watches, and IoT wireless applications.
13 - ARCv2 (EM and HS) and ARCv3 (HS6X)
14 - ARMv6-M, ARMv7-M, and ARMv8-M (Cortex-M)
15 - ARMv7-A and ARMv8-A (Cortex-A, 32- and 64-bit)
16 - ARMv7-R, ARMv8-R (Cortex-R, 32- and 64-bit)
17 - Intel x86 (32- and 64-bit)
20 - RISC-V (32- and 64-bit)
29 file systems, device driver classes, power management, and communication protocols,
[all …]
|
| /Zephyr-latest/doc/security/ |
| D | security-overview.rst | 12 the key ideas of the security process and outlines which documents need
13 to be created. After the process is implemented and all supporting
14 documents are created, this document is a top-level overview and entry
17 Overview and Scope
26 1. **Secure Development:** Defines the system architecture and
28 principles and quality assurance procedures.
30 2. **Secure Design:** Defines security procedures and implement measures
31 to enforce them. A security architecture of the system and
32 relevant sub-modules is created, threats are identified, and
33 countermeasures designed. Their correct implementation and the
[all …]
|
| /Zephyr-latest/doc/project/ |
| D | proposals.rst | 6 For feature tracking we use Github labels to classify new features and
10 Changes to existing features that are not considered a bug and would not
16 that is not part of any release plans yet, that has not been vetted, and needs
17 further discussion and details.
20 A committed and planned unit of functionality with a detailed design and
21 implementation proposal and an owner. Features must go through an RFC process
22 and must be vetted and discussed in the TSC before a target milestone is set.
36 This is the formal way for asking for a new feature in Zephyr and indicating its
37 importance to the project. Often, the requester may have a readiness and
38 willingness to drive implementation of the feature in an upcoming release, and
[all …]
|
| D | index.rst | 3 Project and Governance
24 **Issues** to track feature, enhancement, and bug reports together with GitHub
25 **Pull Requests** (PRs) for submitting and reviewing changes. Zephyr
26 community members work together to review these Issues and PRs, managing
27 feature enhancements and quality improvements of Zephyr through its regular
31 We can only manage the volume of Issues and PRs, by requiring timely reviews,
32 feedback, and responses from the community and contributors, both for initial
33 submissions and for followup questions and clarifications. Read about the
34 project's :ref:`development processes and tools <dev-environment-and-tools>`
35 and specifics about :ref:`review timelines <review_time>` to learn about the
[all …]
|
| D | release_process.rst | 8 companies, and individuals from the community.
11 balance of the latest technologies and features and excellent overall quality. A
26 changes such as bug fixes and documentation will be merged unless granted a
29 - Development phase: all changes are considered and merged, subject to
31 - Stabilisation phase: the release manager creates a vN-rc1 tag and the tree
33 - CI sees the tag, builds and runs tests; Test teams analyse the report from the
34 build and test run and give an ACK/NAK to the build
35 - The release owner, with test teams and any other needed input, determines if the
60 sufficiently stable (and which is accepted by the maintainers and the wide community) is
62 (and all of the major changes) will be merged during this time.
[all …]
|
| D | tsc.rst | 7 The TSC role and its responsibilities is defined in the `Zephyr project charter`_.
14 contributors, and stakeholders to ensure the project's success and
17 By fulfilling the rights and responsibilities below, TSC members contribute to
18 the overall success and growth of the Zephyr Project, ensuring that it remains a
19 vibrant and thriving open-source community for years to come.
27 including architectural changes, feature additions, and release planning.
31 including feature proposals, code contributions, and community initiatives.
34 Gain access to relevant project repositories, documentation, and communication
35 channels to stay informed and contribute effectively.
43 interests of contributors, users, and stakeholders.
[all …]
|
| D | code_flow.rst | 1 .. _code-flow-and-branches:
3 Code Flow and Branches
17 collaboration branch requires a justification and TSC approval. Collaboration branches
18 shall be based off the main branch and any changes developed in the collab
20 Zephyr, the introduction of fixes and new features, if approved by the TSC,
28 work independently on a subsystem or a feature, improves efficiency and
29 turnaround time, and encourages collaboration and streamlines communication
32 Changes submitted to a collaboration branch can evolve and improve
40 Collaboration branches are ephemeral and shall be removed once the collaboration work
49 Roles and Responsibilities
[all …]
|
| /Zephyr-latest/samples/subsys/sip_svc/ |
| D | README.rst | 21 Building and Running
31 at address 0x00100000 and ATF BL31 at 0x00001000 from SD Card or QSPI Flash
39 Got response of transaction id 0x00 and voltage is 0.846878v
40 Got response of transaction id 0x01 and voltage is 0.858170v
41 Got response of transaction id 0x02 and voltage is 0.860168v
42 Got response of transaction id 0x03 and voltage is 0.846832v
43 Got response of transaction id 0x04 and voltage is 0.858337v
44 Got response of transaction id 0x05 and voltage is 0.871704v
45 Got response of transaction id 0x06 and voltage is 0.859421v
46 Got response of transaction id 0x07 and voltage is 0.857254v
[all …]
|
| /Zephyr-latest/doc/safety/ |
| D | safety_overview.rst | 10 and what the Zephyr Project and the Zephyr Safety Working Group / Committee try to achieve.
13 of the Zephyr RTOS and project members who want to contribute to the safety aspects of the
20 is, what standard we aim to achieve and what quality standards and processes need to be implemented
26 This document is a living document and may evolve over time as new requirements, guidelines, or
32 #. The Zephyr Safety Committee will review these changes and provide feedback or acceptance of
41 <https://en.wikipedia.org/wiki/IEC_61508>`__ standard and the Safety Integrity Level (SIL) 3 /
50 *Compliant development. Compliance with the requirements of this standard for the avoidance and
57 electrical, electronic, and programmable electronic safety-related systems. Here's an overview of
60 #. **Hazard and Risk Analysis**: The IEC 61508 standard requires a thorough analysis of potential
61 hazards and risks associated with a system in order to determine the appropriate level of safety
[all …]
|
| /Zephyr-latest/tests/lib/cmsis_dsp/transform/ |
| D | testcase.yaml | 7 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED
12 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED
26 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
27 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX
40 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED
54 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
55 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX
68 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED
82 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
83 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX
[all …]
|
| /Zephyr-latest/tests/cmake/sysbuild_snippets/sysbuild/test_module/ |
| D | CMakeLists.txt | 8 …message(FATAL_ERROR "Values match (sysbuild and app): ${SB_CONFIG_TEST_FOO_VAL} and ${CONFIG_TEST_…
10 message(NOTICE "Values diverge (sysbuild and app)")
14 …message(NOTICE "Values match (sysbuild and snippet): ${SB_CONFIG_EXPECTED_SB_TEST_FOO_VAL} and ${S…
16 …message(FATAL_ERROR "Values diverge (sysbuild and snippet): ${SB_CONFIG_EXPECTED_SB_TEST_FOO_VAL} …
20 …message(NOTICE "Values match (app and snippet): ${SB_CONFIG_EXPECTED_APP_TEST_FOO_VAL} and ${CONFI…
22 …message(FATAL_ERROR "Values diverge (app and snippet): ${SB_CONFIG_EXPECTED_APP_TEST_FOO_VAL} and …
|
| /Zephyr-latest/boards/native/doc/ |
| D | bsim_boards_design.rst | 17 This page covers the design, architecture and rationale, of the
18 nrf5x_bsim boards and other similar bsim boards.
21 These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build
22 and execute the embedded code natively on Linux.
24 Particular details on the :ref:`nRF52<nrf52_bsim>`, :ref:`nRF5340<nrf5340bsim>` and
34 .. _Architecture of HW models used for FW development and testing:
60 without the need for real HW, and in a deterministic/reproducible fashion.
63 peripherals, and their execution is independent of the host load, or timing.
65 These boards are also designed to be used as prototyping and development environments,
70 Different types of tests and how the bsim boards relate to them
[all …]
|
| /Zephyr-latest/include/zephyr/platform/ |
| D | hooks.h | 11 * @brief Soc and Board hooks
14 * zephyr architecture and initialization code and the SoC and board specific logic
15 * that resides under boards/ and soc/
17 * @note These are all standard soc and board interfaces that are exported from
18 * soc and board specific logic to OS internal logic. These should never be accessed
26 * This hook is implemented by the SoC and can be used to perform any
34 * This hook is implemented by the SoC and can be used to perform any
40 * @brief SoC hook executed before the kernel and devices are initialized.
42 * This hook is implemented by the SoC and can be used to perform any
48 * @brief SoC hook executed after the kernel and devices are initialized.
[all …]
|
| /Zephyr-latest/tests/lib/cmsis_dsp/matrix/ |
| D | testcase.yaml | 7 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED
12 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED
26 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
27 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX
41 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED
55 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
56 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX
70 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED
84 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
85 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX
[all …]
|
| /Zephyr-latest/ |
| D | LICENSE | 5 TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
9 "License" shall mean the terms and conditions for use, reproduction,
10 and distribution as defined by Sections 1 through 9 of this document.
15 "Legal Entity" shall mean the union of the acting entity and all
28 source, and configuration files.
33 and conversions to other media types.
41 form, that is based on (or derived from) the Work and for which the
46 the Work and Derivative Works thereof.
49 the original version of the Work and any modifications or additions
57 and issue tracking systems that are managed by, or on behalf of, the
[all …]
|
| /Zephyr-latest/doc/connectivity/bluetooth/ |
| D | bluetooth-arch.rst | 25 * **Host**: This layer sits right below the application, and is comprised of
26 multiple (non real-time) network and transport protocols enabling
27 applications to communicate with peer devices in a standard and interoperable
32 packet reception and transmission, guarantees the delivery of data, and
34 * **Radio Hardware**: Hardware implements the required analog and digital
35 baseband functional blocks that permit the Link Layer firmware to send and
47 can send to a Controller and the events that it can expect in return, and also
48 the format for user and protocol data that needs to go over the air. The HCI
49 ensures that different Host and Controller implementations can communicate
50 in a standard way making it possible to combine Hosts and Controllers from
[all …]
|
| D | features.rst | 10 Since its inception, Zephyr has had a strong focus on Bluetooth and, in
12 several companies and individuals involved in existing open source
14 design and development of Bluetooth LE radio hardware, the protocol stack in Zephyr has
15 grown to be mature and feature-rich, as can be seen in the section below.
23 * Portable to all architectures supported by Zephyr (including big and
24 little endian, alignment flavors and more)
26 * Support for :ref:`all combinations <bluetooth-hw-setup>` of Host and
29 * Controller-only (HCI) over UART, SPI, USB and IPC physical transports
30 * Host-only over UART, SPI, and IPC (shared memory)
35 * Conformance tests run regularly on all layers (Controller and Host, except
[all …]
|
| /Zephyr-latest/doc/security/standards/ |
| D | index.rst | 3 Security standards and Zephyr
7 with cyber security on their own. This included how to assess the scale and impact
8 of the problem and who to properly respond it.
10 Now, governments started looking how to regulate it and several regulations
11 and enforcements are rapidly emerging, and consequently, security standards. These
12 standards provide guidelines and outline requirements that products have to follow
15 This section aims to identify and assess which Zephyr project components are impacted
16 by security standards requirements and provide the right information to enable
|
| /Zephyr-latest/doc/develop/west/ |
| D | why.rst | 3 History and Motivation
9 * The ability to provide an extensible and user-friendly command-line interface
20 along with a clear justification of the choice not to use existing tools and
28 * **R2**: Provide a tool that both Zephyr users and distributors can make use of
29 to benefit from and extend
30 * **R3**: Allow users and downstream distributions to override or remove
32 * **R4**: Support both continuous tracking and commit-based (bisectable) project
40 `Git Submodules <https://git-scm.com/book/en/v2/Git-Tools-Submodules>`_ and
43 Existing tools were considered during west's initial design and development.
69 an RTOS kernel, and is instead a collection of components that work together.
[all …]
|
| /Zephyr-latest/doc/kernel/data_structures/ |
| D | slist.rst | 9 constant-time access to the first (head) and last (tail) elements of
10 the list, insertion before the head and after the tail of the list and
12 requires access to the "previous" pointer and thus can only be
18 before use. Its interior fields are opaque and should not be accessed
22 :c:func:`sys_slist_peek_head` and :c:func:`sys_slist_peek_tail`, which will
31 containing struct and the field name of the node. Internally, the
36 :c:func:`sys_slist_prepend` and :c:func:`sys_slist_append`. They may also
45 subset of an existing list in constant time. And
47 for a given node and remove it if present.
55 extra scratch variable for storage and allows the user to delete the
[all …]
|
| /Zephyr-latest/doc/develop/languages/cpp/ |
| D | index.rst | 12 Zephyr supports applications written in both C and C++. However, to use C++ in
17 and the included compiler must be supported by the Zephyr build system. The
19 is supported by Zephyr, and the features and their availability documented
25 :kconfig:option:`CONFIG_STD_CPP98`. The oldest standard supported and
37 should not return status information and should, instead, return zero.
59 * Dynamic object management with the **new** and **delete** operators
76 of the C++ standard library and application binary interface (ABI) functions to
79 * ``new`` and ``delete`` operators
80 * virtual function stub and vtables
84 C++ language support, and it does not implement any `Standard Template Library
[all …]
|
| /Zephyr-latest/samples/boards/nordic/nrfx_prs/ |
| D | README.rst | 4 Use nRF peripherals that share the same ID and base address.
10 and base address. Such peripherals cannot be used simultaneously because they
11 share certain hardware resources, but it is possible to switch between them and
13 and the lack of possibility to deinitialize a peripheral that is initialized by
16 are to be switched (SPIM2 and UARTE2) while the standard Zephyr drivers are used
18 Zephyr console and SPIM1 is used for performing additional sample transfers).
28 The sample outputs on the standard console the hex codes of all sent and
30 board (between the MOSI and MISO pins for SPIMs and between the TX and RX pins
32 is also received back. Without such wiring, no data is received by UARTE and
35 on the boards supported by the sample are assigned as MOSI/MISO and TX/RX pins.
[all …]
|
| /Zephyr-latest/boards/ti/cc3235sf_launchxl/doc/ |
| D | index.rst | 7 1MB internal flash, 4MB external serial flash, 256KB of RAM, and enhanced
8 security features. It supports 802.11 a/b/g/n, both 2.4 GHz and 5 GHz.
16 Cortex-M4 MCU and a network processor MCU to run all Wi-Fi and
19 * On-board accelerometer and temperature sensor
20 * Two buttons and a RGB LED for user interaction
23 codecs, antenna selection, environmental sensing, and more
24 * Power from USB for the LaunchPad and optional external BoosterPack
36 and access to external serial 4MB flash with bootloader and peripheral
40 offloads Wi-Fi and internet protocols from the application MCU.
54 For consistency with TI SimpleLink SDK and BoosterPack examples,
[all …]
|
| /Zephyr-latest/samples/drivers/rtc/ |
| D | README.rst | 5 Set and read the date/time from a Real-Time Clock.
11 to set and read the date/time from RTC and display on the console
12 and can be built and executed on boards supporting RTC.
14 Building and Running
17 Build and flash as follows, replacing ``stm32f3_disco`` with your board:
30 RTC date and time: 2024-11-17 04:19:00
31 RTC date and time: 2024-11-17 04:19:01
|
| /Zephyr-latest/tests/crypto/tinycrypt/src/ |
| D | test_ecc_utils.h | 6 * Redistribution and use in source and binary forms, with or without
9 * this list of conditions and the following disclaimer.
11 * this list of conditions and the following disclaimer in the documentation
12 * and/or other materials provided with the distribution.
14 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
15 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
16 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
21 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
29 * Redistribution and use in source and binary forms, with or without
33 * this list of conditions and the following disclaimer.
[all …]
|
