Searched full:and (Results 1 – 25 of 5918) sorted by relevance
12345678910>>...237
/Zephyr-Core-3.6.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.6.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.6.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.6.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.6.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.6.0/tests/lib/cmsis_dsp/transform/ |
D | testcase.yaml | 3 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED 8 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED 22 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU 23 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX 36 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED 50 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU 51 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX 64 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED 78 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU 79 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX [all …]
|
/Zephyr-Core-3.6.0/tests/lib/cmsis_dsp/matrix/ |
D | testcase.yaml | 3 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED 8 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED 22 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU 23 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX 37 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED 51 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU 52 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX 66 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_FULL_LIBC_SUPPORTED 80 filter: ((CONFIG_CPU_AARCH32_CORTEX_R or CONFIG_CPU_CORTEX_M) and CONFIG_CPU_HAS_FPU 81 and CONFIG_FULL_LIBC_SUPPORTED) or CONFIG_ARCH_POSIX [all …]
|
/Zephyr-Core-3.6.0/modules/hal_nordic/nrfx/ |
D | nrfx_config_nrf54l15_enga_application.h | 17 * Boolean. Accepted values 0 and 1. 39 * Boolean. Accepted values 0 and 1. 48 * Boolean. Accepted values 0 and 1. 66 * Boolean. Accepted values 0 and 1. 90 * Boolean. Accepted values 0 and 1. 108 * Boolean. Accepted values 0 and 1. 132 * Boolean. Accepted values 0 and 1. 141 * Boolean. Accepted values 0 and 1. 150 * Boolean. Accepted values 0 and 1. 159 * Boolean. Accepted values 0 and 1. [all …]
|
D | nrfx_config_nrf54h20_enga_radiocore.h | 26 * Boolean. Accepted values: 0 and 1. 44 * Boolean. Accepted values: 0 and 1. 53 * Boolean. Accepted values: 0 and 1. 62 * Boolean. Accepted values: 0 and 1. 71 * Boolean. Accepted values: 0 and 1. 80 * Boolean. Accepted values: 0 and 1. 98 * Boolean. Accepted values: 0 and 1. 122 * Boolean. Accepted values: 0 and 1. 131 * Boolean. Accepted values: 0 and 1. 295 * Boolean. Accepted values: 0 and 1. [all …]
|
D | nrfx_config_nrf54h20_enga_ppr.h | 27 * Boolean. Accepted values: 0 and 1. 45 * Boolean. Accepted values: 0 and 1. 69 * Boolean. Accepted values: 0 and 1. 78 * Boolean. Accepted values: 0 and 1. 214 * Boolean. Accepted values: 0 and 1. 241 * Boolean. Accepted values: 0 and 1. 265 * Boolean. Accepted values: 0 and 1. 274 * Boolean. Accepted values: 0 and 1. 308 * Boolean. Accepted values: 0 and 1. 332 * Boolean. Accepted values: 0 and 1. [all …]
|
D | nrfx_config_nrf54h20_enga_application.h | 27 * Boolean. Accepted values: 0 and 1. 45 * Boolean. Accepted values: 0 and 1. 54 * Boolean. Accepted values: 0 and 1. 63 * Boolean. Accepted values: 0 and 1. 72 * Boolean. Accepted values: 0 and 1. 81 * Boolean. Accepted values: 0 and 1. 99 * Boolean. Accepted values: 0 and 1. 123 * Boolean. Accepted values: 0 and 1. 132 * Boolean. Accepted values: 0 and 1. 268 * Boolean. Accepted values: 0 and 1. [all …]
|
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. 115 * Boolean. Accepted values 0 and 1. 149 * Boolean. Accepted values 0 and 1. 158 * Boolean. Accepted values 0 and 1. 176 * Boolean. Accepted values 0 and 1. 200 * Boolean. Accepted values 0 and 1. 218 * Boolean. Accepted values 0 and 1. 242 * Boolean. Accepted values 0 and 1. 251 * Boolean. Accepted values 0 and 1. 275 * 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 …]
|
/Zephyr-Core-3.6.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.6.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 We as members, contributors, and leaders pledge to make participation in our 8 identity and expression, level of experience, education, socio-economic status, 10 identity and orientation. 12 We pledge to act and interact in ways that contribute to an open, welcoming, 13 diverse, inclusive, and healthy community. 20 * Demonstrating empathy and kindness toward other people 21 * Being respectful of differing opinions, viewpoints, and experiences 22 * Giving and gracefully accepting constructive feedback 23 * Accepting responsibility and apologizing to those affected by our mistakes, 24 and learning from the experience [all …]
|
/Zephyr-Core-3.6.0/boards/posix/doc/ |
D | bsim_boards_design.rst | 16 This page covers the design, architecture and rationale, of the 17 nrf5x_bsim boards and other similar bsim boards. 20 These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build 21 and execute the embedded code natively on Linux. 23 Particular details on the :ref:`nRF52<nrf52_bsim>` and :ref:`nRF5340<nrf5340bsim>` 33 .. _Architecture of HW models used for FW development and testing: 59 without the need for real HW, and in a deterministic/reproducible fashion. 62 peripherals, and their execution is independent of the host load, or timing. 64 These boards are also designed to be used as prototyping and development environments, 69 Different types of tests and how the bsim boards relate to them [all …]
|
/Zephyr-Core-3.6.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.6.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 …]
|
12345678910>>...237