| /Zephyr-latest/doc/build/dts/api/ |
| D | api.rst | 7 based. Use of these macros has no impact on scheduling. They can be used from
10 Some of these -- the ones beginning with ``DT_INST_`` -- require a special
11 macro named ``DT_DRV_COMPAT`` to be defined before they can be used; these are
12 discussed individually below. These macros are generally meant for use within
56 Property values can be read using these macros even if the node is disabled,
66 Use these APIs instead of :ref:`devicetree-property-access` to access the
68 devicetree specification, these macros can be used even for nodes without
83 Use these APIs instead of :ref:`devicetree-property-access` to access the
85 devicetree specification, these macros can be used even for nodes without
95 Use these APIs instead of :ref:`devicetree-property-access` to access the
[all …]
|
| /Zephyr-latest/include/zephyr/ |
| D | syscall.h | 26 * These macros are used in public header files to declare system calls.
30 * - Kernel-only code, or CONFIG_USERSPACE disabled, these inlines will
32 * - User-only code, these inlines will marshal parameters and elevate
34 * - Mixed or indeterminate code, these inlines will do a runtime check
38 * function. These must follow a naming convention. For a system call
54 * These are kernel-side skeleton functions for system calls. They are
61 * assertions. The handler must check all of these conditions using
69 * Even if the system call implementation has no return value, these always
|
| /Zephyr-latest/tests/benchmarks/wait_queues/ |
| D | README.rst | 5 implementations: dumb and scalable. These two queue implementations perform
7 the performance of these two implementations vary under varying conditions.
9 These conditions include:
16 By default, these tests show the minimum, maximum, and averages of the measured
|
| /Zephyr-latest/doc/hardware/cache/ |
| D | index.rst | 13 :kconfig:option:`CONFIG_CPU_HAS_ICACHE`: these hidden options should be
18 These options have the goal to document an available hardware feature and
22 * :kconfig:option:`CONFIG_DCACHE` / :kconfig:option:`CONFIG_ICACHE`: these
24 present and working in zephyr. Note that if these options are disabled,
28 depending on these symbols. When the symbol is set the cache is considered
31 These symbols say nothing about the actual API interface exposed to the user.
|
| /Zephyr-latest/subsys/bluetooth/host/classic/ |
| D | avrcp_internal.h | 70 * within the target. These fields enable the target to determine whether the command is
71 * addressed to the target unit, or to a specific subunit within the target. The values in these
76 * within the target. These fields enable the target to determine whether the command is
77 * addressed to the target unit, or to a specific subunit within the target. The values in these
86 * within the target. These fields enable the target to determine whether the command is
87 * addressed to the target unit, or to a specific subunit within the target. The values in these
93 * within the target. These fields enable the target to determine whether the command is
94 * addressed to the target unit, or to a specific subunit within the target. The values in these
|
| /Zephyr-latest/tests/drivers/watchdog/wdt_error_cases/ |
| D | README.txt | 15 These tests were written to increase test coverage for the Watchdog driver.
20 These tests were prepared on a target that had a bug in the wdt_disable()
30 Follow these guidelines when enabling test execution on a new target.
47 Support for these flags varies between vendors and products.
56 3. These tests assume that watchdog driver supports multiple timeouts. Set
70 Support for these options varies between vendors and products.
|
| /Zephyr-latest/tests/subsys/fs/multi-fs/src/ |
| D | main.c | 17 * These tests are order-dependent. in ZTEST()
28 * These tests are order-dependent. in ZTEST()
41 * These tests are order-dependent. in ZTEST()
52 * These tests are order-dependent. in ZTEST()
|
| /Zephyr-latest/doc/develop/toolchains/ |
| D | other_x_compilers.rst | 17 Follow these steps to use one of these toolchains.
32 #. :ref:`Set these environment variables <env_vars>`:
39 #. To check that you have set these variables correctly in your current
40 environment, follow these example shell sessions (the
|
| D | designware_arc_mwdt.rst | 15 generation. We used Zephyr SDK as a source of these ARC GNU tools as well.
20 #. :ref:`Set these environment variables <env_vars>`:
31 #. To check that you have set these variables correctly in your current
32 environment, follow these example shell sessions (the
|
| /Zephyr-latest/doc/kernel/usermode/ |
| D | mpu_stack_objects.rst | 37 memory. These constraints include determining the alignment of the stack and
38 the correct sizing of the stack. During linking of the binary, these
42 MPU design may require specific constraints on the region definition. These
46 Some MPUs require that each region be aligned to a power of two. These SoCs
51 v7m MPU will have these constraints.
|
| /Zephyr-latest/samples/basic/threads/ |
| D | README.rst | 14 The first two each control an LED. These LEDs, ``led0`` and ``led1``, have
20 When either of these threads toggles its LED, it also pushes information into a
30 The board must have two LEDs connected via GPIO pins. These are called "User
35 You will see one of these errors if you try to build this sample for an
|
| /Zephyr-latest/doc/develop/west/ |
| D | without-west.rst | 8 particular, you will have to do work "by hand" to replace these
13 - specifying the locations of these repositories to the Zephyr build
66 these repositories, the build will still work.
69 of these repositories, you must set :makevar:`ZEPHYR_MODULES`
89 If you want to use these build system targets but do not want to
122 specifically run one of these build system targets with a command
126 flash``. This is because these build system targets depend on an
|
| /Zephyr-latest/include/zephyr/dt-bindings/dai/ |
| D | esai.h | 11 * the values of these macros are meant to match
13 * with each of these pins.
29 * the values of these macros are set according to
|
| /Zephyr-latest/doc/build/dts/ |
| D | dt-vs-kconfig.rst | 26 nodes in the devicetree. These provide the UART type (via the ``compatible``
31 priority and the UART baud rate. These may be modifiable at runtime, but
54 There are **exceptions** to these rules:
57 configuration parameters, such as the size of an internal buffer, these
59 specific to Zephyr drivers and not hardware description or configuration these
|
| /Zephyr-latest/arch/arm64/core/ |
| D | tls.c | 18 * thread data and bss. These fields are supposed to be in arch_tls_stack_setup()
21 * this so we can simply skip these. However, since GCC in arch_tls_stack_setup()
22 * is generating code assuming these fields are there, in arch_tls_stack_setup()
|
| /Zephyr-latest/tests/drivers/uart/uart_elementary/ |
| D | README.txt | 5 Hardware setup required for these tests:
9 These test cases cover:
|
| /Zephyr-latest/boards/native/doc/ |
| D | bsim_boards_design.rst | 19 These boards are postfixed with ``_bsim`` as they use BabbleSim_
21 These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build
50 The main purpose of these bsim boards is to be test-benches for
54 :ref:`POSIX arch based board<posix_arch_rationale>`, but in addition these
58 These tests are run in workstation, that is, without using real embedded HW.
65 These boards are also designed to be used as prototyping and development environments,
75 That comparison applies fully to these boards, but in this section we expand
78 to these boards.
84 these bsim boards.
93 - Integration tests on workstation (what the POSIX arch and these boards enable)
[all …]
|
| /Zephyr-latest/soc/intel/intel_adsp/ace/include/ace15_mtpm/ |
| D | adsp_boot.h | 16 * These registers are added by Intel outside of the Tensilica Core for general operation
18 * Note: These registers are accessible through the host space or DSP space depending on
31 * These registers are added by Intel outside of the Tensilica Core for boot / recovery
|
| /Zephyr-latest/soc/intel/intel_adsp/ace/include/ace20_lnl/ |
| D | adsp_boot.h | 16 * These registers are added by Intel outside of the Tensilica Core for general operation
18 * Note: These registers are accessible through the host space or DSP space depending on
31 * These registers are added by Intel outside of the Tensilica Core for boot / recovery
|
| /Zephyr-latest/soc/intel/intel_adsp/ace/include/ace30/ |
| D | adsp_boot.h | 16 * These registers are added by Intel outside of the Tensilica Core for general operation
18 * Note: These registers are accessible through the host space or DSP space depending on
31 * These registers are added by Intel outside of the Tensilica Core for boot / recovery
|
| /Zephyr-latest/soc/espressif/esp32/ |
| D | Kconfig.mac | 14 administered MAC address. These are generated sequentially by adding 0, 1, 2 and 3 (respectively)
17 These are generated sequentially by adding 0 and 1 (respectively) to the base MAC address.
19 These are derived from the universal WiFi station and Bluetooth MAC addresses, respectively.
|
| /Zephyr-latest/doc/kernel/data_structures/ |
| D | index.rst | 8 These include list and balanced tree structures for storing ordered
23 Note also that these libraries are generally unsynchronized; access to
24 them is not threadsafe by default. These are data structures, not
|
| /Zephyr-latest/arch/xtensa/core/ |
| D | tls.c | 22 * thread data and bss. These fields are supposed to be in arch_tls_stack_setup()
25 * this so we can simply skip these. However, since GCC in arch_tls_stack_setup()
26 * is generating code assuming these fields are there, in arch_tls_stack_setup()
|
| /Zephyr-latest/doc/services/portability/ |
| D | index.rst | 8 These APIs make it easier and quicker to develop for, and port code to
11 These sections describe the software and hardware abstraction layers
|
| /Zephyr-latest/doc/security/ |
| D | security-overview.rst | 24 in detail. As depicted in Figure 1, these main steps are:
40 how these assets are protected. Certification claims shall be
62 These words are used to define absolute requirements (or prohibitions),
64 noted in RFC-2119, "These terms are frequently used to specify behavior
83 2. The Zephyr Security Subcommittee will review these changes and provide feedback
86 3. Once accepted, these changes will become part of the document.
117 These topics are discussed in more detail in the following subsections.
220 examples of these would be:
235 Some of these categories are interconnected and rely on multiple pieces
241 The development of secure code shall adhere to certain criteria. These
[all …]
|
