| /Zephyr-Core-3.5.0/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)
44 Zephyr offers a large and ever growing number of features including:
[all …]
|
| /Zephyr-Core-3.5.0/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-Core-3.5.0/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
23 **Issues** to track feature, enhancement, and bug reports together with GitHub
24 **Pull Requests** (PRs) for submitting and reviewing changes. Zephyr
25 community members work together to review these Issues and PRs, managing
26 feature enhancements and quality improvements of Zephyr through its regular
30 We can only manage the volume of Issues and PRs, by requiring timely reviews,
31 feedback, and responses from the community and contributors, both for initial
32 submissions and for followup questions and clarifications. Read about the
33 project's :ref:`development processes and tools <dev-environment-and-tools>`
34 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 | 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-Core-3.5.0/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-Core-3.5.0/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-Core-3.5.0/tests/drivers/uart/uart_async_api/ |
| D | testcase.yaml | 11 filter: CONFIG_UART_CONSOLE and CONFIG_SERIAL_SUPPORT_ASYNC and not CONFIG_UART_MCUX_LPUART
17 filter: CONFIG_UART_CONSOLE and CONFIG_SERIAL_SUPPORT_ASYNC and not CONFIG_UART_MCUX_LPUART
29 filter: CONFIG_UART_CONSOLE and CONFIG_SERIAL_SUPPORT_ASYNC
39 filter: CONFIG_UART_CONSOLE and CONFIG_SERIAL_SUPPORT_ASYNC and CONFIG_HAS_SEGGER_RTT
40 and not CONFIG_UART_MCUX_LPUART and not CONFIG_UART_MCUX_FLEXCOMM
52 filter: CONFIG_UART_CONSOLE and CONFIG_SERIAL_SUPPORT_ASYNC and CONFIG_UART_MCUX_LPUART
56 filter: CONFIG_UART_CONSOLE and CONFIG_SERIAL_SUPPORT_ASYNC and CONFIG_SOC_FAMILY_SAM0
|
| /Zephyr-Core-3.5.0/tests/lib/cmsis_dsp/transform/ |
| D | testcase.yaml | 3 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and TOOLCHAIN_HAS_NEWLIB
8 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and TOOLCHAIN_HAS_NEWLIB
22 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
23 and TOOLCHAIN_HAS_NEWLIB == 1) or CONFIG_ARCH_POSIX
36 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and TOOLCHAIN_HAS_NEWLIB
50 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
51 and TOOLCHAIN_HAS_NEWLIB == 1) or CONFIG_ARCH_POSIX
64 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and TOOLCHAIN_HAS_NEWLIB
78 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
79 and TOOLCHAIN_HAS_NEWLIB == 1) or CONFIG_ARCH_POSIX
[all …]
|
| /Zephyr-Core-3.5.0/tests/lib/cmsis_dsp/matrix/ |
| D | testcase.yaml | 3 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and TOOLCHAIN_HAS_NEWLIB
8 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and TOOLCHAIN_HAS_NEWLIB
22 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
23 and TOOLCHAIN_HAS_NEWLIB == 1) or CONFIG_ARCH_POSIX
37 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and TOOLCHAIN_HAS_NEWLIB
51 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
52 and TOOLCHAIN_HAS_NEWLIB == 1) or CONFIG_ARCH_POSIX
66 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and TOOLCHAIN_HAS_NEWLIB
80 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU
81 and TOOLCHAIN_HAS_NEWLIB == 1) or CONFIG_ARCH_POSIX
[all …]
|
| /Zephyr-Core-3.5.0/doc/connectivity/bluetooth/ |
| D | overview.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 BLE radio hardware, the protocol stack in Zephyr has
15 grown to be mature and feature-rich, as can be seen in the section below.
20 Zephyr comes integrated with a feature-rich and highly configurable
29 * Portable to all architectures supported by Zephyr (including big and
30 little endian, alignment flavors and more)
32 * Support for all combinations of Host and Controller builds:
34 * Controller-only (HCI) over UART, SPI, USB and IPC physical transports
35 * Host-only over UART, SPI, and IPC (shared memory)
[all …]
|
| D | bluetooth-arch.rst | 26 * **Host**: This layer sits right below the application, and is comprised of
27 multiple (non real-time) network and transport protocols enabling
28 applications to communicate with peer devices in a standard and interoperable
33 packet reception and transmission, guarantees the delivery of data, and
35 * **Radio Hardware**: Hardware implements the required analog and digital
36 baseband functional blocks that permit the Link Layer firmware to send and
48 can send to a Controller and the events that it can expect in return, and also
49 the format for user and protocol data that needs to go over the air. The HCI
50 ensures that different Host and Controller implementations can communicate
51 in a standard way making it possible to combine Hosts and Controllers from
[all …]
|
| /Zephyr-Core-3.5.0/ |
| 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 …]
|
| D | CODE_OF_CONDUCT.md | 5 In the interest of fostering an open and welcoming environment, we as
6 contributors and maintainers pledge to making participation in our project and
8 size, disability, ethnicity, sex characteristics, gender identity and expression,
10 appearance, race, religion, or sexual identity and orientation.
17 * Using welcoming and inclusive language
18 * Being respectful of differing viewpoints and experiences
25 * The use of sexualized language or imagery and unwelcome sexual attention or
27 * Trolling, insulting/derogatory comments, and personal or political attacks
37 behavior and are expected to take appropriate and fair corrective action in
40 Project maintainers have the right and responsibility to remove, edit, or
[all …]
|
| /Zephyr-Core-3.5.0/boards/posix/doc/ |
| D | bsim_boards_design.rst | 6 This page covers the design, architecture and rationale, of the
7 :ref:`nrf52_bsim<nrf52_bsim>`, :ref:`nrf5340bsim<nrf5340bsim>` and other similar bsim boards.
8 Particular details on the nRF52 and nRF5340 simulation boards, including how to use them,
13 These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build
14 and execute the embedded code natively on Linux.
27 .. _Architecture of HW models used for FW development and testing:
53 without the need for real HW, and in a deterministic/reproducible fashion.
56 peripherals, and their execution is independent of the host load, or timing.
60 Different types of tests and how the bsim boards relate to them
66 further on the differences, benefits and drawbacks of different testing
[all …]
|
| /Zephyr-Core-3.5.0/modules/hal_nordic/nrfx/ |
| D | nrfx_config_nrf52840.h | 27 * Boolean. Accepted values 0 and 1.
51 * Boolean. Accepted values 0 and 1.
60 * Boolean. Accepted values 0 and 1.
69 * Boolean. Accepted values 0 and 1.
87 * Boolean. Accepted values 0 and 1.
111 * Boolean. Accepted values 0 and 1.
129 * Boolean. Accepted values 0 and 1.
153 * Boolean. Accepted values 0 and 1.
171 * Boolean. Accepted values 0 and 1.
180 * Boolean. Accepted values 0 and 1.
[all …]
|
| D | nrfx_config_nrf52833.h | 27 * Boolean. Accepted values 0 and 1.
51 * Boolean. Accepted values 0 and 1.
60 * Boolean. Accepted values 0 and 1.
69 * Boolean. Accepted values 0 and 1.
87 * Boolean. Accepted values 0 and 1.
111 * Boolean. Accepted values 0 and 1.
129 * Boolean. Accepted values 0 and 1.
153 * Boolean. Accepted values 0 and 1.
171 * Boolean. Accepted values 0 and 1.
180 * Boolean. Accepted values 0 and 1.
[all …]
|
| D | nrfx_config_nrf5340_application.h | 83 * between secure and non-secure mapping.
120 * Boolean. Accepted values 0 and 1.
154 * Boolean. Accepted values 0 and 1.
163 * Boolean. Accepted values 0 and 1.
181 * Boolean. Accepted values 0 and 1.
205 * Boolean. Accepted values 0 and 1.
223 * Boolean. Accepted values 0 and 1.
247 * Boolean. Accepted values 0 and 1.
256 * Boolean. Accepted values 0 and 1.
280 * Boolean. Accepted values 0 and 1.
[all …]
|
| D | nrfx_config_nrf52832.h | 27 * Boolean. Accepted values 0 and 1.
51 * Boolean. Accepted values 0 and 1.
60 * Boolean. Accepted values 0 and 1.
69 * Boolean. Accepted values 0 and 1.
87 * Boolean. Accepted values 0 and 1.
111 * Boolean. Accepted values 0 and 1.
129 * Boolean. Accepted values 0 and 1.
153 * Boolean. Accepted values 0 and 1.
171 * Boolean. Accepted values 0 and 1.
180 * Boolean. Accepted values 0 and 1.
[all …]
|
| D | nrfx_config_nrf52820.h | 27 * Boolean. Accepted values 0 and 1.
51 * Boolean. Accepted values 0 and 1.
60 * Boolean. Accepted values 0 and 1.
69 * Boolean. Accepted values 0 and 1.
87 * Boolean. Accepted values 0 and 1.
111 * Boolean. Accepted values 0 and 1.
129 * Boolean. Accepted values 0 and 1.
153 * Boolean. Accepted values 0 and 1.
171 * Boolean. Accepted values 0 and 1.
180 * Boolean. Accepted values 0 and 1.
[all …]
|
| /Zephyr-Core-3.5.0/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-Core-3.5.0/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-Core-3.5.0/doc/develop/languages/c/ |
| D | newlib.rst | 7 systems. It is a separate open source project and is not included in source
9 precompiled library for each supported architecture (:file:`libc.a` and
18 :file:`lib/libc/newlib/libc-hooks.c` and translate the library internal system
25 'full' and 'nano' variants.
30 The Newlib full variant (:file:`libc.a` and :file:`libm.a`) is the most capable
31 variant of the Newlib available in the Zephyr SDK, and supports almost all
33 performance over code size) and its footprint is significantly larger than the
37 :kconfig:option:`CONFIG_NEWLIB_LIBC` and de-selecting the
44 The Newlib nano variant (:file:`libc_nano.a` and :file:`libm_nano.a`) is the
45 size-optimized version of the Newlib, and supports all features that the full
[all …]
|
| /Zephyr-Core-3.5.0/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 …]
|
