| /Zephyr-Core-3.7.0/modules/ |
| D | Kconfig.mcux | 18 String describing the core identifer used by MCUX SDK when using
24 Set if the 12B1MSPS SAR ADC module is present in the SoC.
29 Set if the 12-bit ADC (ADC12) module is present in the SoC.
34 Set if the 16-bit ADC (ADC16) module is present in the SoC.
39 Set if the LPADC module is present in the SoC.
44 Set if the L1 or L2 cache is present in the SoC.
49 Set if the clock control module (CCM) module is present in the SoC.
54 Set if the revision 2 of clock control module (CCM) module is present in the SoC.
60 Set if the syscon module is present in the SoC.
65 Set if the peripheral clock controller module (PCC) module is
[all …]
|
| /Zephyr-Core-3.7.0/doc/connectivity/bluetooth/api/mesh/ |
| D | dfu_srv.rst | 6 The Firmware Update Server model implements the Target node functionality of the
7 :ref:`bluetooth_mesh_dfu` subsystem. It extends the :ref:`bluetooth_mesh_blob_srv`, which it uses to
8 receive the firmware image binary from the Distributor node.
10 Together with the extended BLOB Transfer Server model, the Firmware Update Server model implements
11 all the required functionality for receiving firmware updates over the mesh network, but does not
12 provide any functionality for storing, applying or verifying the images.
17 The Firmware Update Server holds a list of all the updatable firmware images on the device. The full
18 list shall be passed to the server through the ``_imgs`` parameter in
19 :c:macro:`BT_MESH_DFU_SRV_INIT`, and must be populated before the Bluetooth Mesh subsystem is
20 started. Each firmware image in the image list must be independently updatable, and should have its
[all …]
|
| D | dfu.rst | 6 Bluetooth Mesh supports the distribution of firmware images across a mesh network. The Bluetooth
7 mesh DFU subsystem implements the Bluetooth Mesh Device Firmware Update Model specification version
11 restrictions on the size, format or usage of the images. The primary design goal of the subsystem is
12 to provide the qualifiable parts of the Bluetooth Mesh DFU specification, and leave the usage,
13 firmware validation and deployment to the application.
15 The DFU specification is implemented in the Zephyr Bluetooth Mesh DFU subsystem as three separate
31 The Bluetooth Mesh DFU subsystem defines three different roles the mesh nodes have to assume in the
35 Target node is the receiver and user of the transferred firmware images. All its functionality is
36 implemented by the :ref:`bluetooth_mesh_dfu_srv` model. A transfer may be targeting any number of
40 The Distributor role serves two purposes in the DFU process. First, it's acting as the Target
[all …]
|
| D | proxy.rst | 6 The Proxy feature allows legacy devices like phones to access the Bluetooth Mesh network through
7 GATT. The Proxy feature is only compiled in if the :kconfig:option:`CONFIG_BT_MESH_GATT_PROXY`
8 option is set. The Proxy feature state is controlled by the :ref:`bluetooth_mesh_models_cfg_srv`,
9 and the initial value can be set with :c:member:`bt_mesh_cfg_srv.gatt_proxy`.
11 Nodes with the Proxy feature enabled can advertise with Network Identity and Node Identity,
12 which is controlled by the :ref:`bluetooth_mesh_models_cfg_cli`.
14 The GATT Proxy state indicates if the Proxy feature is supported.
19 A node supporting the Proxy feature and the :ref:`bluetooth_mesh_models_priv_beacon_srv` model can
20 advertise with Private Network Identity and Private Node Identity types, which is controlled by the
22 the node allows the legacy device to connect to the network over GATT while maintaining the
[all …]
|
| D | provisioning.rst | 6 Provisioning is the process of adding devices to a mesh network. It requires
7 two devices operating in the following roles:
9 * The *provisioner* represents the network owner, and is responsible for
10 adding new nodes to the mesh network.
11 * The *provisionee* is the device that gets added to the network through the
12 Provisioning process. Before the provisioning process starts, the
15 The Provisioning module in the Zephyr Bluetooth Mesh stack supports both the
16 Advertising and GATT Provisioning bearers for the provisionee role, as well as
17 the Advertising Provisioning bearer for the provisioner role.
19 The Provisioning process
[all …]
|
| D | core.rst | 6 The core provides functionality for managing the general Bluetooth Mesh
14 The Low Power Node (LPN) role allows battery powered devices to participate in
15 a mesh network as a leaf node. An LPN interacts with the mesh network through
16 a Friend node, which is responsible for relaying any messages directed to the
17 LPN. The LPN saves power by keeping its radio turned off, and only wakes up to
18 either send messages or poll the Friend node for any incoming messages.
20 The radio control and polling is managed automatically by the mesh stack, but
21 the LPN API allows the application to trigger the polling at any time through
22 :c:func:`bt_mesh_lpn_poll`. The LPN operation parameters, including poll
23 interval, poll event timing and Friend requirements is controlled through the
[all …]
|
| D | blob_srv.rst | 6 The Binary Large Object (BLOB) Transfer Server model implements reliable receiving of large binary
7 objects. It serves as the backend of the :ref:`bluetooth_mesh_dfu_srv`, but can also be used for
13 As described in :ref:`bluetooth_mesh_blob`, the binary objects transferred by the BLOB Transfer
14 models are divided into blocks, which are divided into chunks. As the transfer is controlled by the
15 BLOB Transfer Client model, the BLOB Transfer Server must allow blocks to come in any order. The
17 the next block is started.
19 The BLOB Transfer Server keeps track of the received blocks and chunks, and will process each block
20 and chunk only once. The BLOB Transfer Server also ensures that any missing chunks are resent by the
26 The BLOB Transfer Server is instantiated on an element with a set of event handler callbacks:
42 A BLOB Transfer Server is capable of receiving a single BLOB transfer at a time. Before the BLOB
[all …]
|
| D | blob.rst | 6 The Binary Large Object (BLOB) Transfer models implement the Bluetooth Mesh Binary Large Object
8 from a single source to many Target nodes over the Bluetooth Mesh network. It is the underlying
9 transport method for the :ref:`bluetooth_mesh_dfu`, but may be used for other object transfer
10 purposes. The implementation is in experimental state.
12 The BLOB Transfer models support transfers of continuous binary objects of up to 4 GB (2 \ :sup:`32`
13 bytes). The BLOB transfer protocol has built-in recovery procedures for packet losses, and sets up
14 checkpoints to ensure that all targets have received all the data before moving on. Data transfer
17 BLOB transfers are constrained by the transfer speed and reliability of the underlying mesh network.
18 Under ideal conditions, the BLOBs can be transferred at a rate of up to 1 kbps, allowing a 100 kB
20 other limiting factors can easily degrade the data rate by several orders of magnitude. Tuning the
[all …]
|
| D | sar_cfg.rst | 7 in a mesh network, with a purpose of enhancing the Bluetooth Mesh throughput. The segmentation and
8 reassembly mechanism is used by the lower transport layer.
10 The lower transport layer defines how the upper transport layer PDUs are segmented and reassembled
11 into multiple Lower Transport PDUs, and sends them to the lower transport layer on a peer device.
12 If the Upper Transport PDU fits, it is sent in a single Lower Transport PDU. For longer packets,
13 which do not fit into a single Lower Transport PDU, the lower transport layer performs segmentation,
14 splitting the Upper Transport
17 The lower transport layer on the receiving device reassembles the segments into a single Upper
18 Transport PDU before passing it up the stack. Delivery of a segmented message is acknowledged by the
19 lower transport layer of the receiving node, while an unsegmented message delivery is not
[all …]
|
| D | access.rst | 6 The access layer is the application's interface to the Bluetooth Mesh network.
7 The access layer provides mechanisms for compartmentalizing the node behavior
8 into elements and models, which are implemented by the application.
13 The functionality of a mesh node is represented by models. A model implements
14 a single behavior the node supports, like being a light, a sensor or a
15 thermostat. The mesh models are grouped into *elements*. Each element is
17 model. Conventionally, each element represents a single aspect of the mesh
20 element instantiating all the models required for a single aspect of the
23 The node's element and model structure is specified in the node composition
24 data, which is passed to :c:func:`bt_mesh_init` during initialization. The
[all …]
|
| /Zephyr-Core-3.7.0/doc/develop/api/ |
| D | api_lifecycle.rst | 7 given API will not change in future releases. At the same time, developers
10 no longer optimal or supported by the underlying platforms.
20 An up-to-date table of all APIs and their maturity level can be found in the
31 to the community via the `Developer mailing list <https://lists.zephyrproject.org/g/devel>`_.
33 The following requirements apply to all new APIs:
35 - Documentation of the API (usage)
38 - The API introduction should be accompanied by at least one implementation
39 of said API (in the case of peripheral APIs, this corresponds to one driver)
40 - At least one sample using the new API (may only build on one single board)
42 When introducing a new and experimental API, mark the API version in the headers
[all …]
|
| /Zephyr-Core-3.7.0/doc/services/llext/ |
| D | build.rst | 4 The LLEXT subsystem allows for the creation of extensions that can be loaded
6 often useful to have access to the headers and compiler flags used by the main
9 The easiest path to achieve this is to build the extension as part of the
10 Zephyr application, using the `native Zephyr CMake features
11 <llext_build_native_>`_. This will result in a single build providing both the
12 main Zephyr application and the extension(s), which will all automatically be
13 built with the same parameters.
15 In some cases, involving the full Zephyr build system may not be feasible or
16 convenient; maybe the extension is built using a different compiler suite or as
17 part of a different project altogether. In this case, the extension developer
[all …]
|
| /Zephyr-Core-3.7.0/arch/xtensa/core/ |
| D | README_MMU.txt | 3 As with other elements of the architecture, paged virtual memory
6 to introduce the architecture at an overview/tutorial level, and to
11 The Xtensa MMU operates on top of a fairly conventional TLB cache.
12 The TLB stores virtual to physical translation for individual pages of
20 Like the L1 cache, the TLB is split into separate instruction and data
21 entries. Zephyr manages both as needed, but symmetrically. The
23 and data spaces, but the hardware page table refill mechanism (see
26 The TLB may be loaded with permissions and attributes controlling
27 cacheability, access control based on ring (i.e. the contents of the
28 RING field of the PS register) and togglable write and execute access.
[all …]
|
| /Zephyr-Core-3.7.0/samples/userspace/shared_mem/ |
| D | README.rst | 9 unique memory domains with protected partitions. The
11 simulating an enigma-like machine, but the implementation of the
18 The sample is dependent on the subsystem app_memory, and it will
19 not run on boards that do not support the subsystem. The sample
20 was tested on the following boards qemu_x86,frdm_k64, and ``96b_carbon/stm32f401xe``.
25 This example will only cover the qemu_x86 board, since the sample
34 After starting, the console will display multiple starting messages
35 followed by two series of repeating messages. The repeating messages
36 are the input and output of the enigma-like machine. The second
37 message is the output of the first message, and the resulting
[all …]
|
| /Zephyr-Core-3.7.0/doc/contribute/ |
| D | contributor_expectations.rst | 6 The Zephyr project encourages :ref:`contributors <contributor>` to submit
7 changes as smaller pull requests. Smaller pull requests (PRs) have the following
14 - Less wasted work if reviewers or maintainers reject the direction of the
18 changes in the tree.
20 - Easier to revert if the PR breaks functionality.
25 Draft PRs have no review expectation and PRs created as drafts from the start
34 - When adding a new large feature or API, the PR should address only one part of
35 the feature. In this case create an :ref:`RFC proposal <rfcs>` to describe the
36 additional parts of the feature for reviewers.
38 - PRs should include tests or samples under the following conditions:
[all …]
|
| D | external.rst | 10 This section describes the circumstances under which external source code can be
11 imported into Zephyr, and the process that governs the inclusion.
13 There are three main factors that will be considered during the inclusion
15 described in the following sections.
18 compiled and linked into the final image, and programmed into the target
20 code analysis, testing or simulation please refer to the
21 :ref:`external-tooling` section at the end of the page.
28 External source code licensed under the Apache-2.0 license is not subject to
31 Integrating code into the Zephyr Project from other projects that use a license
32 other than the Apache 2.0 license needs to be fully understood in
[all …]
|
| /Zephyr-Core-3.7.0/doc/security/ |
| D | sensor-threat.rst | 13 relays this sensor data to this service. The cloud service is also able
14 to send configuration data to the device, as well as software update
21 In this sensor device, the sensor connects with the SoC via an SPI bus,
22 and the SoC has a network interface that it uses to communicate with the
23 cloud service. The particulars of these interfaces can impact the threat
28 This model also focuses on communicating via the MQTT-over-TLS protocol,
34 One aspect of the threat model to consider are assets involved in the
35 operation of the device. The following list enumerates the assets
38 1. **The bootloader**. This is a small code/data image contained in
39 on-device flash that is the first code to run. In order to establish
[all …]
|
| D | reporting.rst | 9 Vulnerabilities to the Zephyr project may be reported via email to the
11 acknowledged and analyzed by the security response team within 1 week.
12 Each vulnerability will be entered into the Zephyr Project security
13 advisory GitHub_. The original submitter will be granted permission to
14 view the issues that they have reported.
53 directly by a reporter. When entered by the response team in
54 response to an email, the issue shall be transitioned directly to
57 - Triage: This issue is awaiting Triage by the response team. The
58 response team will analyze the issue, determine a responsible
59 entity, assign it to that individual, and move the
[all …]
|
| /Zephyr-Core-3.7.0/doc/ |
| D | zephyr.doxyfile.in | 3 # This file describes the settings to be used by the documentation system
7 # front of the TAG it is preceding.
10 # The format is:
18 # Use doxygen to compare the used configuration file with the template
21 # Use doxygen to compare the used configuration file with the template
22 # configuration file without replacing the environment variables or CMake type
30 # This tag specifies the encoding used for all characters in the configuration
31 # file that follow. The default is UTF-8 which is also the encoding used for all
32 # text before the first occurrence of this tag. Doxygen uses libiconv (or the
33 # iconv built into libc) for the transcoding. See
[all …]
|
| /Zephyr-Core-3.7.0/doc/develop/languages/c/ |
| D | newlib.rst | 6 `Newlib`_ is a complete C library implementation written for the embedded
8 code form with Zephyr. Instead, the :ref:`toolchain_zephyr_sdk` includes a
14 the Newlib as a precompiled library.
16 Zephyr implements the "API hook" functions that are invoked by the C standard
17 library functions in the Newlib. These hook functions are implemented in
18 :file:`lib/libc/newlib/libc-hooks.c` and translate the library internal system
19 calls to the equivalent Zephyr API calls.
24 The Newlib included in the :ref:`toolchain_zephyr_sdk` comes in two versions:
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
[all …]
|
| /Zephyr-Core-3.7.0/doc/services/device_mgmt/ |
| D | mcumgr_backporting.rst | 6 The processes described in this document apply to both the zephyr repository itself and the MCUmgr …
9 Currently, the backporting process, described in this document, is required only when providing
12 There are two different processes: one for issues that have also been fixed in the current
15 The upstream MCUmgr repository is located `in this page <https://github.com/apache/mynewt-mcumgr>`_.
16 The Zephyr fork used in version 2.7 and earlier is `located here <https://github.com/zephyrproject-…
17 Versions of Zephyr past 2.7 use the MCUmgr library that is `part of the Zephyr code base <https://g…
22 In Zephyr version 2.7 and earlier, you must first apply the fix
23 to the upstream repository of MCUmgr and then bring it to Zephyr with snapshot updates.
25 As such, there are four possible ways to apply a change to the 2.7 branch:
27 …* The fix, done directly to the Zephyr held code of the MCUmgr library, is backported to the ``v2.…
[all …]
|
| /Zephyr-Core-3.7.0/doc/safety/ |
| D | safety_overview.rst | 9 This document is the safety documentation providing an overview over the safety-relevant activities
10 and what the Zephyr Project and the Zephyr Safety Working Group / Committee try to achieve.
12 This overview is provided for people who are interested in the functional safety development part
13 of the Zephyr RTOS and project members who want to contribute to the safety aspects of the
19 In this section we give the reader an overview of what the general goal of the safety certification
29 #. Changes will be submitted from the interested party(ies) via pull requests to the Zephyr
32 #. The Zephyr Safety Committee will review these changes and provide feedback or acceptance of
33 the changes.
35 #. Once accepted, these changes will become part of the document.
40 The general scope of the Safety Committee is to achieve a certification for the `IEC 61508
[all …]
|
| /Zephyr-Core-3.7.0/subsys/bluetooth/audio/ |
| D | csip_crypto.h | 21 * The RSI hash function sih is used to generate a hash value that is
22 * used in RSIs - Used by the Coordinated Set Identification service and
36 * The SIRK encryption function sef is used by the server to encrypt the SIRK
37 * with a key K. The value of K depends on the transport on which the pairing
38 * between the client and the server was performed.
40 * If the pairing was performed on BR/EDR, K is equal to the Link Key shared by
41 * the server and the client.
44 * If the pairing was performed on LE, the 64 LSBs of K correspond to the 64
45 * LSBs of the IRK that the server sent to the client during the Phase 3
46 * (Transport Specific Key Distribution) of the pairing procedure (see Volume 3,
[all …]
|
| /Zephyr-Core-3.7.0/include/zephyr/sys/ |
| D | sys_io.h | 29 * This function writes a byte to the given port.
31 * @param data the byte to write
32 * @param port the port address where to write the byte
39 * This function reads a byte from the port.
41 * @param port the port address from where to read the byte
43 * @return the byte read
50 * This function writes a 16 bits to the given port.
52 * @param data the 16 bits to write
53 * @param port the port address where to write the 16 bits
60 * This function reads 16 bits from the port.
[all …]
|
| /Zephyr-Core-3.7.0/doc/kernel/services/data_passing/ |
| D | mailboxes.rst | 7 capabilities that go beyond the capabilities of a message queue object.
21 A mailbox has the following key properties:
31 A thread that sends a message is known as the **sending thread**,
32 while a thread that receives the message is known as the **receiving thread**.
38 (and even specify) the identity of the other thread.
44 data is located, and how the message is to be handled by the mailbox.
45 Both the sending thread and the receiving thread supply a message descriptor
46 when accessing a mailbox. The mailbox uses the message descriptors to perform
48 The mailbox also updates certain message descriptor fields during the exchange,
52 The size and format of the message data is application-defined, and can vary
[all …]
|
