| /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/doc/project/ |
| 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 | 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 | 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 | communication.rst | 1 .. _communication-and-collaboration:
3 Communication and Collaboration
7 chat forum used by Zephyr developers, contributors, and users.
11 communication tool by project members, contributors, and the community. There
13 and open. Mailing lists are always available for use in situations where
16 In general, bug reports and other issues should be reported as `GitHub Issues
17 <https://github.com/zephyrproject-rtos/zephyr/issues>`_ and not broadcasted to
|
| 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 …]
|
| 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 …]
|
| /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/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/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/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/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/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/samples/drivers/dac/ |
| D | README.rst | 12 Building and Running
15 The DAC output is defined in the board's devicetree and pinmux file.
18 ``dac-channel-id``, and ``dac-resolution`` properties set. See the predefined
21 Building and Running for ST Nucleo L073RZ
23 The sample can be built and executed for the
32 Building and Running for ST Nucleo L152RE
34 The sample can be built and executed for the
43 Building and Running for ST Nucleo F767ZI
45 The sample can be built and executed for the
54 Building and Running for ST Disco F3
[all …]
|
| /Zephyr-latest/boards/qorvo/decawave_dwm3001cdk/doc/ |
| D | index.rst | 7 and charging circuit, LEDs, buttons, Raspberry Pi connector, and USB connector.
8 In addition, the board comes with J-Link OB adding debugging and Virtual COM
13 itself, and `nRF52833 website`_ for the official reference on the IC itself.
15 Programming and Debugging
19 and debugged in the usual way. See :ref:`build_an_application` and
20 :ref:`application_run` for more details on building and running.
26 and configure all the necessary software. Further information can be
27 found in :ref:`nordic_segger_flashing`. Then build and flash
28 applications as usual (see :ref:`build_an_application` and
33 Connect to the bottom micro-USB port labeled as J-Link and run your favorite
[all …]
|
| /Zephyr-latest/drivers/sensor/sensirion/shtcx/ |
| D | Kconfig | 1 # SHTCX temperature and humidity sensor configuration options
7 bool "SHTCX: SHTC1 and SHTC3 Temperature and Humidity Sensor"
13 Enable driver for SHTC1 and SHTC3 temperature and humidity sensors.
|
| /Zephyr-latest/boards/bbc/microbit/doc/ |
| D | index.rst | 10 The board is 4 cm × 5 cm and has an ARM Cortex-M0 processor, accelerometer and
11 magnetometer sensors, Bluetooth and USB connectivity, a display consisting of
12 25 LEDs, two programmable buttons, and can be powered by either USB or an
13 external battery pack. The device inputs and outputs are through five ring
26 * Light and temperature sensors
27 * Motion sensors (accelerometer and compass)
28 * Wireless Communication, via Radio and Bluetooth
37 Programming and Debugging
43 Build and flash applications as usual (see :ref:`build_an_application` and
57 Then build and flash the application in the usual way.
|
| /Zephyr-latest/tests/arch/arc/arc_dsp_sharing/ |
| D | README.txt | 5 This test is only for ARC targets and uses two tasks to:
7 1) Test load and store dsp registers (including arch specific registers)
8 2) compute complex vector product and check for any errors
15 The demonstration utilizes semaphores, round robin scheduling, DSP and XY
25 Load and store OK after 0 (high) + 84 (low) tests
26 Load and store OK after 100 (high) + 11926 (low) tests
27 Load and store OK after 200 (high) + 23767 (low) tests
28 Load and store OK after 300 (high) + 35607 (low) tests
29 Load and store OK after 400 (high) + 47448 (low) tests
30 Load and store OK after 500 (high) + 59287 (low) tests
|
| /Zephyr-latest/doc/connectivity/bluetooth/ |
| 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/boards/qorvo/decawave_dwm1001_dev/doc/ |
| D | index.rst | 7 connector and charging circuit, LEDs, buttons, Raspberry-Pi and USB
9 debugging and Virtual COM Port capabilities.
12 board, `Qorvo (Decawave) DWM1001 website`_ about the board itself, and `nRF52832 website`_ for the
15 Programming and Debugging
19 flashed, and debugged in the usual way. See :ref:`build_an_application` and
20 :ref:`application_run` for more details on building and running.
26 and configure all the necessary software. Further information can be
27 found in :ref:`nordic_segger_flashing`. Then build and flash
28 applications as usual (see :ref:`build_an_application` and
42 Then build and flash the application in the usual way.
|
| /Zephyr-latest/boards/bbc/microbit_v2/doc/ |
| D | index.rst | 10 The board is 4 cm × 5 cm and has an ARM Cortex-M4F processor, accelerometer and
11 magnetometer sensors, Bluetooth and USB connectivity, a display consisting of
12 25 LEDs, a microphone, two programmable buttons, and can be powered by either
13 USB or an external battery pack. The device inputs and outputs are through five
27 * Light and temperature sensors
28 * Motion sensors (accelerometer and compass)
29 * Wireless Communication, via Radio and Bluetooth 5
38 Programming and Debugging
44 Build and flash applications as usual (see :ref:`build_an_application` and
58 Then build and flash the application in the usual way.
|
| /Zephyr-latest/boards/snps/em_starterkit/ |
| D | Kconfig.em_starterkit | 14 Both version 2.2 and 2.3 firmware have EM7D, EM9D and EM11D configurations.
15 EM9D using CCM memories and is a Harvard Architecture.
16 EM7D and EM11D have access to 128MB DRAM and use i-cache and d-cache.
|
| /Zephyr-latest/boards/atmarktechno/degu_evk/doc/ |
| D | index.rst | 3 The Degu Evaluation Kit is an IoT device for sensors and actuators
4 and can connect to an OpenThread mesh network. The Kit has a
5 Nordic nRF52840 SoC and NXP A71CH Secure Element, and can
7 and UART.
|
| /Zephyr-latest/doc/connectivity/networking/ |
| D | network_tracing.rst | 10 User can enable network core stack and socket API calls tracing.
13 stack tracing. This option is enabled by default if tracing and networking
14 are enabled. The system will start to collect the receiving and sending call
17 it took to deliver the network packet, and the network interface, priority
18 and traffic class used.
21 BSD socket call usage in the system. It is enabled if tracing and BSD socket
23 API calls are made and what parameters the API calls are using and returning.
|
| /Zephyr-latest/boards/fysetc/ucan/doc/ |
| D | index.rst | 7 the `UCAN website`_ and in the `UCAN wiki`_.
12 The UCAN board is equipped with a STM32F072CB microcontroller and features an USB-C connector, a
13 terminal block for connecting to the CAN bus, and two user LEDs. Schematics and component placement
24 The STM32F072CB PLL is driven by an external crystal oscillator (HSE) running at 8 MHz and
27 Programming and Debugging
30 Build and flash applications as usual (see :ref:`build_an_application` and
33 If flashing via USB DFU, short pins ``B0`` and ``3V3`` when applying power to the UCAN board in
|
