Searched +full:feature +full:- +full:specific (Results 1 – 25 of 232) sorted by relevance
12345678910
| /Zephyr-latest/dts/bindings/usb/ |
| D | usb-audio-hp.yaml | 2 # SPDX-License-Identifier: Apache-2.0
4 # Specific fields for USB audio headphones.
6 description: USB Audio headphones specific fields.
8 compatible: "usb-audio-hp"
10 include: [usb-audio.yaml, usb-audio-feature-volume.yaml]
17 - 8
18 - 16
19 - 24
20 - 32
21 sample-rate-hz:
[all …]
|
| D | usb-audio-mic.yaml | 2 # SPDX-License-Identifier: Apache-2.0
4 # Specific fields for USB audio microphone.
6 description: USB Audio microphone specific fields.
8 compatible: "usb-audio-mic"
10 include: usb-audio.yaml
17 - 8
18 - 16
19 - 24
20 - 32
21 sync-type:
[all …]
|
| D | usb-audio-hs.yaml | 2 # SPDX-License-Identifier: Apache-2.0
4 # Specific fields for USB audio headset.
6 description: USB Audio headset specific fields.
8 compatible: "usb-audio-hs"
10 include: [usb-audio.yaml, usb-audio-feature-volume.yaml]
13 mic-resolution:
17 - 8
18 - 16
19 - 24
20 - 32
[all …]
|
| D | usb-audio-feature-volume.yaml | 2 # SPDX-License-Identifier: Apache-2.0
4 # Specific fields for USB volume control.
6 description: USB volume control specific fields.
8 compatible: "usb-audio-feature-volume"
13 volume-max:
19 The range from +127.9961 dB (0x7FFF) down to -127.9961 dB (0x8001).
20 Valid range: 0 - 0xFFFF
21 volume-min:
27 The range from +127.9961 dB (0x7FFF) down to -127.9961 dB (0x8001).
28 Valid range: 0 - 0xFFFF
[all …]
|
| /Zephyr-latest/doc/develop/api/ |
| D | design_guidelines.rst | 23 * The next parameter(s) should be additional information specific to the
35 specific to the code that also defines the callback function. In those
63 counter channel timed-out and the counter value at which the timeout
73 implemented without them. Examples of such feature include
79 In the case where a feature is determined to be optional the following
82 * Any data that is accessed only when the feature is enabled should be
89 feature is enabled, referencing the required Kconfig symbol by name.
92 the unsupported API will result in a link-time error.
93 * Where code specific to the feature is isolated in a source file that
98 * Where code specific to the feature is part of a source file that has
[all …]
|
| /Zephyr-latest/doc/project/ |
| D | proposals.rst | 1 .. _feature-tracking:
3 Feature Tracking
6 For feature tracking we use Github labels to classify new features and
11 block a release. This is an incremental enhancement to a feature that already
14 Feature request
19 Feature
25 A request or plan to port an existing feature or enhancement to a particular
31 A label to group other GitHub issues that are part of a single feature or unit
36 This is the formal way for asking for a new feature in Zephyr and indicating its
38 willingness to drive implementation of the feature in an upcoming release, and
[all …]
|
| /Zephyr-latest/doc/build/snippets/ |
| D | design.rst | 4 This page documents design goals for the snippets feature.
7 .. _Issue #51834: https://github.com/zephyrproject-rtos/zephyr/issues/51834
9 - **extensible**: for example, it is possible to add board support for an
10 existing built-in snippet without modifying the zephyr repository
12 - **composable**: it is possible to use multiple snippets at once, for example
15 .. code-block:: console
17 west build -S <snippet1> -S <snippet2> ...
19 - **able to combine multiple types of configuration**: snippets make it possible
23 - **specializable**: for example, it is possible to customize a snippet's
26 - **future-proof and backwards-compatible**: arbitrary future changes to the
[all …]
|
| /Zephyr-latest/dts/bindings/mspi/ |
| D | mspi-device.yaml | 2 # SPDX-License-Identifier: Apache-2.0
8 on-bus: mspi
14 mspi-max-frequency:
22 mspi-io-mode:
25 - "MSPI_IO_MODE_SINGLE"
26 - "MSPI_IO_MODE_DUAL"
27 - "MSPI_IO_MODE_DUAL_1_1_2"
28 - "MSPI_IO_MODE_DUAL_1_2_2"
29 - "MSPI_IO_MODE_QUAD"
30 - "MSPI_IO_MODE_QUAD_1_1_4"
[all …]
|
| /Zephyr-latest/kernel/ |
| D | compiler_stack_protect.c | 2 * Copyright (c) 2012-2014 Wind River Systems, Inc.
4 * SPDX-License-Identifier: Apache-2.0
12 * using canaries. This feature is enabled with configuration
16 * When this feature is enabled, the compiler generated code refers to
20 #include <zephyr/toolchain.h> /* compiler specific configurations */
|
| /Zephyr-latest/doc/connectivity/bluetooth/ |
| D | features.rst | 1 .. _bluetooth-features:
15 grown to be mature and feature-rich, as can be seen in the section below.
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)
33 * :ref:`Bluetooth-SIG qualifiable <bluetooth-qual>`
38 * :ref:`Bluetooth Low Energy Controller <bluetooth-ctlr-arch>` (LE Link Layer)
42 * Concurrent multi-protocol support ready
47 real-time specifics so that they can be encapsulated in a hardware-specific
70 * Pairing support, including the Secure Connections feature from Bluetooth 4.2
[all …]
|
| /Zephyr-latest/subsys/bluetooth/controller/ |
| D | Kconfig.df | 4 # SPDX-License-Identifier: Apache-2.0
8 # It is required to enable it when Controller supports any DF related feature
73 # BT Core spec 5.1, Vol 6, Part B, sec. 4.6 Feature Support
76 bool "Antenna switching during CTE transmission (AoD) feature"
84 bool "Antenna switching during CTE reception (AoA) feature"
92 bool "Reception of Constant Tone Extension feature"
100 bool "Connection CTE Request feature"
103 Enable support for Bluetooth v5.1 Connection CTE Request feature
107 bool "Connection CTE Response feature"
110 Enable support for Bluetooth v5.1 Connection CTE Response feature
[all …]
|
| /Zephyr-latest/dts/bindings/gpio/ |
| D | richtek,rt1718s.yaml | 2 # SPDX-License-Identifier: Apache-2.0
9 address. Feature-specific(GPIO, TCPC) properties should be placed in a child
17 irq-gpios = <&gpioe 1 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
20 compatible = "richtek,rt1718s-gpio-port";
22 gpio-controller;
23 #gpio-cells = <2>;
31 include: [i2c-device.yaml]
34 irq-gpios:
35 type: phandle-array
|
| /Zephyr-latest/doc/connectivity/bluetooth/api/mesh/ |
| D | brg_cfg.rst | 6 With Bluetooth Mesh Protocol Specification version 1.1, the Bluetooth Mesh Subnet Bridge feature was
8 This feature allows mesh networks to use subnets for area isolation, but to also allow communication
9 between specific devices in different, adjacent subnets without compromising security.
11 The Bluetooth Mesh Subnet Bridge feature makes it possible for selected nodes in the network to act
15 The Subnet Bridge feature includes two models:
17 - :ref:`bluetooth_mesh_models_brg_cfg_srv`
18 - :ref:`bluetooth_mesh_models_brg_cfg_cli`
20 The Bridge Configuration Server model is mandatory for supporting the Subnet Bridge feature.
24 Subnet Bridge feature.
26 The configuration and management of the Subnet Bridge feature are handled using the Bridge
[all …]
|
| /Zephyr-latest/samples/bluetooth/periodic_adv_conn/ |
| D | README.rst | 1 .. zephyr:code-sample:: ble_periodic_adv_conn
3 :relevant-api: bt_gap bluetooth
14 is application specific. This sample will connect to any synced device
22 * A controller that supports the Periodic Advertising with Responses (PAwR) - Advertiser feature
33 See :zephyr:code-sample-category:`bluetooth` samples for details.
|
| /Zephyr-latest/samples/bluetooth/periodic_adv_rsp/ |
| D | README.rst | 1 .. zephyr:code-sample:: ble_periodic_adv_rsp
3 :relevant-api: bt_gap bluetooth
20 application specific. In this sample it is decided by the PAwR advertiser.
28 * A controller that supports the Periodic Advertising with Responses (PAwR) - Advertiser feature
39 See :zephyr:code-sample-category:`bluetooth` samples for details.
|
| /Zephyr-latest/samples/bluetooth/periodic_sync_rsp/ |
| D | README.rst | 1 .. zephyr:code-sample:: ble_periodic_adv_sync_rsp
3 :relevant-api: bt_gap bluetooth
17 application specific. In this sample it is decided by the PAwR advertiser.
29 * A controller that supports the Periodic Advertising with Responses (PAwR) - Scanner feature
41 See :zephyr:code-sample-category:`bluetooth` samples for details.
|
| /Zephyr-latest/subsys/bluetooth/controller/ll_sw/ |
| D | ull_conn_types.h | 2 * Copyright (c) 2018-2019 Nordic Semiconductor ASA
4 * SPDX-License-Identifier: Apache-2.0
69 uint32_t ticks_at_expire; /* Vendor specific tick units */
70 uint32_t remainder; /* Vendor specific remainder fraction of a tick unit */
82 * As of today only 36 feature bits are in use,
93 * verified when feature exchange procedure has completed, valid member is set to 1.
97 * Stores features common for two connected devices. Before feature exchange
99 * supported by local device. After completion of the procedure, the feature set
|
| /Zephyr-latest/include/zephyr/usb/class/ |
| D | usb_audio.h | 6 * SPDX-License-Identifier: Apache-2.0
14 * - USB Device Class Definition for Audio Devices (audio10.pdf)
17 * - USB Device Class Definition for Audio Data Formats (frmts10.pdf)
18 * - USB Device Class Definition for Terminal Types (termt10.pdf)
30 * Refer to Table A-2 from audio10.pdf
39 /** Audio Class-Specific AC Interface Descriptor Subtypes.
40 * Refer to Table A-5 from audio10.pdf
54 /** Audio Class-Specific AS Interface Descriptor Subtypes
55 * Refer to Table A-6 from audio10.pdf
64 /** Audio Class-Specific Request Codes
[all …]
|
| /Zephyr-latest/.github/ISSUE_TEMPLATE/ |
| D | 001_bug_report.md | 1 ---
8 ---
9 <!--
11 Github Discussions (https://github.com/zephyrproject-rtos/zephyr/discussions)
16 (https://github.com/zephyrproject-rtos/zephyr/). If the bug is for a project
17 fork (such as NCS) specific feature, please open an issue in the fork project
19 -->
22 <!--
27 - What target platform are you using?
28 - What have you tried to diagnose or workaround this issue?
[all …]
|
| /Zephyr-latest/doc/safety/ |
| D | safety_requirements.rst | 10 …route 3s <https://docs.zephyrproject.org/latest/safety/safety_overview.html#general-safety-scope>`_
16 <https://github.com/zephyrproject-rtos/reqmgmt>`__
40 They describe the functionality of the Zephyr RTOS from a very high-level perspective,
45 Project as the requirements are specific to an RTOS.
48 Software requirements refine the system-level requirements at a more granular level so
50 These requirements define the specific actions the feature shall be able to execute and the
51 behavior of the feature.
61 #. After completing work on the new requirements execute: ``strictDoc manage auto-uid .``
66 If there are duplicates in the PR, these need to be resolved by rebasing and re-executing
73 * Non-Functional
[all …]
|
| /Zephyr-latest/samples/bluetooth/hci_vs_scan_req/src/ |
| D | main.c | 1 /* main.c - Application main entry point */
6 * SPDX-License-Identifier: Apache-2.0
14 "This app requires Zephyr-specific HCI vendor extensions");
17 #define DEVICE_NAME_LENGTH (sizeof(DEVICE_NAME) - 1)
60 * Added a Vendor Specific command to add this feature and save RAM.
75 cp->enable = (uint8_t) enable; in enable_legacy_adv_scan_request_event()
90 evt = (void *)buf->data; in vs_scanned()
93 vs->subevent, bt_addr_le_str(&evt->addr), evt->rssi); in vs_scanned()
137 printk("Vendor-Specific Scan Request sample started\n"); in bt_ready()
144 printk("Starting Vendor-Specific Scan Request sample\n"); in main()
|
| /Zephyr-latest/doc/hardware/peripherals/ |
| D | mspi.rst | 3 Multi-bit SPI Bus
6 The MSPI (multi-bit SPI) is provided as a generic API to accommodate
16 .. _mspi-controller-api:
21 Zephyr's MSPI controller API may be used when a multi-bit SPI controller
25 not limited to high-speed, high density flash/psram memory devices, displays
28 The MSPI interface contains controller drivers that are SoC platform specific
30 The relationship between the controller and device drivers is many-to-many to
53 platform specific settings.
57 to re-initialize the hardware with new parameters during runtime.
65 #. Call :c:func:`mspi_dev_config` with device specific hardware settings obtained
[all …]
|
| /Zephyr-latest/doc/contribute/ |
| D | contributor_expectations.rst | 1 .. _contributor-expectations:
10 - Reviewed more quickly and reviewed more thoroughly. It's easier for reviewers
14 - Less wasted work if reviewers or maintainers reject the direction of the
17 - Easier to rebase and merge. Smaller PRs are less likely to conflict with other
20 - Easier to revert if the PR breaks functionality.
32 - Smaller PRs should encompass one self-contained logical change.
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 …]
|
| /Zephyr-latest/include/zephyr/bluetooth/mesh/ |
| D | cfg.h | 8 * SPDX-License-Identifier: Apache-2.0
29 /** Bluetooth Mesh feature states */
31 /** Feature is supported, but disabled. */
33 /** Feature is supported and enabled. */
35 /** Feature is not supported, and cannot be enabled. */
45 /* Legacy feature defines */
80 * @returns Whether the Secure Network Beacon feature is enabled.
93 * @retval 0 Successfully changed the Mesh Private beacon feature state.
94 * @retval -ENOTSUP The Mesh Private beacon feature is not supported.
95 * @retval -EINVAL Invalid parameter.
[all …]
|
| /Zephyr-latest/subsys/bluetooth/host/ |
| D | Kconfig | 3 # Copyright (c) 2016-2020 Nordic Semiconductor ASA
4 # Copyright (c) 2015-2016 Intel Corporation
5 # SPDX-License-Identifier: Apache-2.0
8 bool "Dedicated workqueue for long-running tasks."
11 Adds an API for a workqueue dedicated to long-running tasks.
23 int "Long workqueue priority. Should be pre-emptible."
58 # the worst-case stack size if an out-of-tree controller is used.
70 # Hidden option for Co-Operative Tx thread priority
97 bool "Process low priority HCI packets in the bluetooth-specific work queue"
100 in the bluetooth-specific work queue. The HCI driver shall not call bt_recv_prio().
[all …]
|
12345678910
