Searched +full:application +full:- +full:specific (Results 1 – 25 of 517) sorted by relevance
12345678910>>...21
| /Zephyr-latest/doc/services/tfm/ |
| D | testsuites.rst | 4 TF-M includes two sets of test suites:
6 * tf-m-tests - Standard TF-M specific regression tests
7 * psa-arch-tests - Test suites for specific PSA APIs (secure storage, etc.)
9 These test suites can be run from Zephyr via an appropriate sample application
12 TF-M Regression Tests
20 application (TF-M).
27 being followed by the secure application, TF-M being an implementation of
37 your specific board, RTOS (Zephyr here), and PSA implementation (TF-M in this
41 changes to TF-M, such as enabling a new TF-M board target, or making changes
42 to the core TF-M module(s). They should generally be run as a coherence check
|
| /Zephyr-latest/dts/common/nordic/ |
| D | nrf5340_shared_sram_partition.dtsi | 5 * SPDX-License-Identifier: Apache-2.0
7 * This file specifies the default shared memory region used for inter-procesor
8 * communication between the application and network cores.
10 * This file, or a board specific variant of it, must be included by both
11 * cpuapp and cpunet application to ensure both processors have the same
12 * expectations of the memory region used. If a board specific variant is
14 * the memory range allocated to the non-secure image (sram0_ns).
16 * By default the last 64 kB of application core SRAM is allocated as shared
18 * - 32 kB CPUAPP to CPUNET communication (cpuapp_cpunet_ipc_shm)
19 * - 32 kB CPUNET to CPUAPP communication (cpunet_cpuapp_ipc_shm)
[all …]
|
| /Zephyr-latest/samples/boards/arc_secure_services/ |
| D | README.rst | 12 demonstrate how a secure zephyr application runs together with a normal
13 Zephyr application.
17 * Secure application will be in the secure memory space defined in
21 * Memory not allocated to the secure application is allocated to
22 the normal application.
43 * secure application: em_starterkit_em7d_secure
44 * normal application: em_starterkit_em7d_normal
46 * secure application: nsim_sem
47 * normal application: nsim_sem_normal
55 Secure application
[all …]
|
| /Zephyr-latest/samples/bluetooth/hci_spi/ |
| D | README.rst | 1 .. zephyr:code-sample:: bluetooth_hci_spi
3 :relevant-api: hci_raw bluetooth spi_interface
21 You then need to ensure that your :ref:`devicetree <dt-guide>` defines a node
23 :dtcompatible:`zephyr,bt-hci-spi-slave`. This node sets an interrupt line to
24 the host and associates the application with a SPI bus to use.
30 You can then build this application and flash it onto your board in
31 the usual way; see :ref:`boards` for board-specific building and
35 application is compatible with the HCI SPI master driver provided by
39 Refer to :zephyr:code-sample-category:`bluetooth` for general Bluetooth information, and
40 to :ref:`96b_carbon_nrf51_bluetooth` for instructions specific to the
|
| /Zephyr-latest/drivers/input/ |
| D | Kconfig.kbd_matrix | 2 # SPDX-License-Identifier: Apache-2.0
34 If enabled, the actual-key-mask devicetree property data is stored in
56 Call an application specific hook after the driver specific
57 drive_column implementation. The application must implement the
|
| /Zephyr-latest/soc/nxp/imxrt/ |
| D | Kconfig | 2 # SPDX-License-Identifier: Apache-2.0
15 # Note- When SECOND_CORE_MCUX is set, the dependencies for this Kconfig
17 # requires the boot header is SOC specific.
24 application from an external flash device.
57 FlexSPI configuration block consists of parameters regarding specific
68 the application entry point and device configuration data. The boot
76 useful if your application expects components like SDRAM to be
97 placed in a specific address location to be pointed by the boot ROM.
105 setting should be enabled when the application uses SDRAM, or
113 This setting should be enabled when the application uses HYPERRAM,
[all …]
|
| /Zephyr-latest/doc/services/input/ |
| D | index.rst | 7 devices to the application.
16 The :c:struct:`input_event` structure describes the specific event, and
19 multi-axis device have been reported.
25 or any related function; for example buttons or other on-off input entities
33 to only receive events from a specific device. If there's no actual device
37 Application API
40 An application can register a callback using the
42 callback is only invoked for events from the specific device, otherwise the
53 The synchronous mode can be used in a simple application to keep a minimal
54 footprint, or in a complex application with an existing event model, where the
[all …]
|
| /Zephyr-latest/include/zephyr/bluetooth/mesh/ |
| D | dfu_metadata.h | 4 * SPDX-License-Identifier: Apache-2.0
42 /** Application core. */
46 /** Application-specific BLOB. */
62 /** Application-specific data for new firmware. This field is optional. */
64 /** Length of the application-specific field. */
93 * @param key 128-bit key to be used in the hash computation.
102 * @param key 128-bit key to be used in the hash computation.
|
| /Zephyr-latest/samples/userspace/prod_consumer/ |
| D | README.rst | 1 .. zephyr:code-sample:: userspace_prod_consumer
10 and generates interrupts with pointers to this data. The application needs
16 - Multiple logical applications, each with their own memory domain
17 - Creation of a sys_heap and assignment to a memory partition
18 - Use of APIs like ``k_queue_alloc_append()`` which require thread resource
20 - Management of permissions for kernel objects and drivers
21 - Show how application-specific system calls are defined
22 - Show IPC between ISR and application (using ``k_msgq``) and
23 application-to-application IPC (using ``k_queue``)
24 - Show how to create application-specific system calls
[all …]
|
| /Zephyr-latest/doc/services/ |
| D | notify.rst | 7 operation is initiated and the application needs to be informed when it
9 often a good method, but some application architectures may be more
12 available so a busy-wait for completion may be needed.
14 This API is intended to be embedded within specific subsystems such as
17 operation-specific data from requests that include a notification
27 * neither the spin-wait nor callback notification methods can be
|
| /Zephyr-latest/include/zephyr/net/ |
| D | dhcpv4.h | 8 * SPDX-License-Identifier: Apache-2.0
74 * @brief Define the application callback handler function signature
78 * greater than cb->max_length, only cb->max_length bytes
79 * will be available in cb->data
129 * @param callback A valid Application's callback structure pointer.
145 callback->handler = handler; in net_dhcpv4_init_option_callback()
146 callback->option = option; in net_dhcpv4_init_option_callback()
147 callback->data = data; in net_dhcpv4_init_option_callback()
148 callback->max_length = max_length; in net_dhcpv4_init_option_callback()
152 * @brief Add an application callback.
[all …]
|
| /Zephyr-latest/doc/connectivity/networking/api/ |
| D | http_server.rst | 19 The server operation is generally transparent for the application, running in a
20 background thread. The application can control the server activity with
23 Certain resource types (for example dynamic resource) provide resource-specific
24 application callbacks, allowing the server to interact with the application (for
29 * Static resources - content defined compile-time, cannot be modified at runtime
32 * Dynamic resources - content provided at runtime by respective application
35 * Websocket resources - allowing to establish Websocket connections with the
39 resource types usage. See :zephyr:code-sample:`sockets-http-server` for more
46 the application.
51 .. code-block:: cfg
[all …]
|
| /Zephyr-latest/doc/develop/application/ |
| D | index.rst | 3 Application Development
10 …- your **application directory**, :file:`<app>`, is something like :file:`<home>/zephyrproject/app`
11 - its **build directory** is :file:`<app>/build`
16 Keeping your application inside the workspace (:file:`<home>/zephyrproject`)
18 put your application anywhere as long as :ref:`ZEPHYR_BASE
19 <important-build-vars>` is set appropriately, though.)
26 The build system is application-centric, and requires Zephyr-based applications
27 to initiate building the Zephyr source code. The application build controls
28 the configuration and build process of both the application and Zephyr itself,
36 The files in the **application directory** link Zephyr and any modules with the
[all …]
|
| /Zephyr-latest/include/zephyr/platform/ |
| D | hooks.h | 4 * SPDX-License-Identifier: Apache-2.0
14 * zephyr architecture and initialization code and the SoC and board specific logic
18 * soc and board specific logic to OS internal logic. These should never be accessed
19 * directly from application code but may be freely used within the OS.
27 * SoC-specific initialization.
35 * SoC-specific initialization.
43 * SoC-specific initialization.
51 * SoC-specific initialization.
56 * @brief SoC per-core initialization
59 * SoC-specific per-core initialization
[all …]
|
| /Zephyr-latest/samples/sensor/mcux_lpcmp/ |
| D | README.rst | 1 .. zephyr:code-sample:: mcux_lpcmp
2 :name: NXP MCUX Low-power Analog Comparator (LPCMP)
3 :relevant-api: sensor_interface
5 Get analog comparator data from an NXP MCUX Low-power Analog Comparator (LPCMP).
10 This sample show how to use the NXP MCUX Low-power Analog Comparator (LPCMP) driver.
12 In this application, the negative input port of the LPCMP is set to 7 which
14 voltage of the DAC is set to 0 (for the specific chip, the user needs to
19 manual and board schematic to confirm which specific port is used and can
28 Building and Running for NXP FRDM-MCXN947
30 Build the application for the :zephyr:board:`frdm_mcxn947` board, and adjust the
[all …]
|
| /Zephyr-latest/lib/posix/options/ |
| D | Kconfig.pthread | 5 # SPDX-License-Identifier: Apache-2.0
10 Select 'y' here to enable POSIX threads, mutexes, condition variables, and thread-specific
22 Maximum simultaneously active threads in a POSIX application.
31 Maximum simultaneously active mutexes in a POSIX application.
37 Maximum simultaneously active condition variables in a POSIX application.
40 int "Maximum number of POSIX thread-specific-storage keys"
43 Maximum simultaneously active thread-specific-storage keys in a POSIX application.
71 This option was removed in IEEE 1003.1-2017 in favour of
100 Enabling this option allows the application to configure different priorities and
107 https://man7.org/linux/man-pages/man7/posixoptions.7.html
[all …]
|
| /Zephyr-latest/tests/drivers/gpio/gpio_basic_api/ |
| D | README.txt | 1 GPIO 2-Pin Test
4 This application tests the GPIO subsystem using a hardware configuration
6 identified through a test-specific devicetree binding in the `dts/`
7 subdirectory, implemented for specific boards by overlay files in the
|
| /Zephyr-latest/doc/develop/ |
| D | beyond-GSG.rst | 1 .. _beyond-gsg:
6 The :ref:`getting_started` gives a straight-forward path to set up
11 .. _python-pip:
22 ``--user`` flag to the ``pip3`` command when installing new packages. This is
25 information about pip\ [#pip]_, including `information on -\\-user`_.
27 - On Linux, make sure ``~/.local/bin`` is at the front of your :envvar:`PATH`
28 :ref:`environment variable <env_vars>`, or programs installed with ``--user``
29 won't be found. Installing with ``--user`` avoids conflicts between pip
30 and the system package manager, and is the default on Debian-based
33 - On macOS, `Homebrew disables -\\-user`_.
[all …]
|
| /Zephyr-latest/doc/hardware/peripherals/sensor/ |
| D | power_management.rst | 4 Power management of sensors is often a non-trivial task as sensors may have multiple power states
9 All this is to say that power management of sensors is typically application specific! Often the
10 channel states are mutable using :ref:`sensor-attribute`. While total device suspending and resume
15 :ref:`pm-device-runtime` using explicit calls at an application level to :c:func:`pm_device_runtime…
18 In the future, with :ref:`sensor-read-and-decode` its possible that automatic management of device …
19 would be possible in the streaming case as the application informs the driver of usage at all times
|
| /Zephyr-latest/samples/bluetooth/hci_ipc/ |
| D | README.rst | 1 .. zephyr:code-sample:: bluetooth_hci_ipc
3 :relevant-api: hci_raw bluetooth
24 To use this application, you need a board with a Bluetooth controller
26 You can then build this application and flash it onto your board in
27 the usual way. See :ref:`boards` for board-specific building and
37 compatible with the peer application. For example, :kconfig:option:`CONFIG_BT_MAX_CONN`
38 must be equal to the maximum number of connections supported by the peer application.
40 Refer to :zephyr:code-sample-category:`bluetooth` for general information about Bluetooth samples.
|
| /Zephyr-latest/doc/ |
| D | glossary.rst | 12 (Application Program Interface) A defined set of routines and protocols for
13 building application software.
15 application
16 The set of user-supplied files that the Zephyr build system uses
17 to build an application image for a specified board configuration.
18 It can contain application-specific code, kernel configuration settings,
20 The application's kernel configuration settings direct the build system
23 An application can sometimes be built for more than one type of board
25 if it does not require any board-specific capabilities.
27 application image
[all …]
|
| /Zephyr-latest/boards/nxp/lpcxpresso55s16/ |
| D | lpcxpresso55s16.dts | 5 * SPDX-License-Identifier: Apache-2.0
8 /dts-v1/;
19 * Default for this board is to allocate SRAM0-2 for data. But the
20 * application can have an application specific device tree to
34 tx-d-cal = <5>;
35 tx-cal-45-dp-ohms = <10>;
36 tx-cal-45-dm-ohms = <10>;
|
| /Zephyr-latest/soc/arm/mps2/ |
| D | soc.c | 5 * Copyright (c) 2013-2015 Wind River Systems, Inc.
7 * SPDX-License-Identifier: Apache-2.0
12 #include <zephyr/linker/linker-defs.h>
22 /* We expect there to be 3 arm,mps2-fpgaio-gpio devices:
35 /* The base address that the application image will start at on the secondary
36 * (non-TrustZone) Cortex-M33 mcu.
40 /* The memory map offset for the application image, which is used
46 * @brief Wake up CPU 1 from another CPU, this is platform specific.
53 CPU1_FLASH_ADDRESS - in wakeup_cpu1()
61 * @brief Get the current CPU ID, this is platform specific.
|
| /Zephyr-latest/samples/bluetooth/hci_pwr_ctrl/ |
| D | README.rst | 1 .. zephyr:code-sample:: bluetooth_hci_pwr_ctrl
3 :relevant-api: bt_hrs bluetooth
5 Dynamically control the Tx power of a Bluetooth LE Controller using HCI vendor-specific commands.
10 This sample application demonstrates the dynamic Tx power control over the LL
11 of the Bluetooth LE controller via Zephyr HCI VS commands. The application implements a
13 for the first 5s of the application is the Kconfig set default TX power. Then,
15 pattern ranging from -4 dBm to -30 dBm where the Tx power levels decrease every
38 See :zephyr:code-sample-category:`bluetooth` samples for details.
|
| /Zephyr-latest/samples/bluetooth/hci_vs_scan_req/ |
| D | README.rst | 1 .. zephyr:code-sample:: bluetooth_hci_vs_scan_req
2 :name: HCI Vendor-Specific Scan Request
3 :relevant-api: bluetooth
5 Use vendor-specific HCI commands to enable Scan Request events when using legacy advertising.
10 This simple application is a usage example to manage HCI VS commands to obtain
31 See :zephyr:code-sample-category:`bluetooth` samples for details.
|
12345678910>>...21
