| /Zephyr-latest/dts/bindings/gpio/ |
| D | microbit,edge-connector.yaml | 10 There are 25 strips/pins including 5 rings for using with 4mm banana
11 plugs or crocodile clips. 3 of these rings are for general purpose
12 input and output (GPIO) and are also capable of analog, PWM and touch
13 sensing, and two are connected to the micro:bit power supply.
16 signals, some of which are used by the micro:bit, and others that are free
17 for you to use. There are a number of external PCB connectors for purchase
20 Only the pins on the front are connected to signals. The back rings are
21 connected to the front rings, but the back small strips are unconnected.
|
| D | panasonic,reduced-arduino-header.yaml | 29 pins are not available due to the lack of pins on the Panasonic module.
30 These unconnected pins are labeled "NC" in the mapping above.
36 2. Analog Input header, like on Arduino UNO layout, but A4 and A5 are
41 and D7 are not connected.
45 but D8 and D9 are not connected.
|
| /Zephyr-latest/boards/snps/em_starterkit/ |
| D | pmodmux.c | 58 /* all pins are configured as GPIO inputs */
65 /* Pmod1[4:1] are connected to DW GPIO Port C[11:8] */
67 /* Pmod1[4:1] are connected to DW UART0 signals */
70 /* Pmod1[10:7] are connected to DW GPIO Port A[11:8] */
72 /* Pmod1[10:7] are connected to DW SPI Slave signals */
75 * Pmod2[4:1] are connected to DW GPIO Port C[15:12],
76 * Pmod2[10:7] are connected to DW GPIO Port A[15:12]
82 * Pmod3[4:1] are connected to DW GPIO Port C[19:16],
83 * Pmod3[10:7] are connected to DW GPIO Port A[19:16]
87 * Pmod3[4:3] are connected to DW I2C signals,
[all …]
|
| /Zephyr-latest/doc/services/resource_management/ |
| D | index.rst | 6 There are various situations where it's necessary to coordinate resource
14 managers are embedded into services that use them for specific
27 which has a binary state. Example applications are power rails, clocks,
32 * The stable states are off, on, and error. The service always begins
35 * The core operations are request (add a dependency) and release (remove
36 a dependency). Supporting operations are reset (to clear an error
48 * The request and reset operations are asynchronous using
56 Requests are reference counted, but not tracked. That means clients are
63 Failures in executing a transition are recorded and inhibit further
64 requests or releases until the manager is reset. Pending requests are
[all …]
|
| /Zephyr-latest/subsys/logging/ |
| D | Kconfig.mode | 15 Log messages are buffered and processed later. This mode has the
23 performance of the system since time consuming operations are
35 logging macros. Hexdump macros are also supported, with a small
37 but not runtime filtering. There are no timestamps, prefixes,
38 colors, or asynchronous logging, and all messages are simply
46 When enabled, logs are redirected to a custom frontend which is the
47 fastest way of getting logs out. The logs are redirected at the function
54 Option indicates that there are no backends intended to be used.
60 When enabled, frontend implements functions which are optimized versions
|
| /Zephyr-latest/tests/bsim/bluetooth/mesh/tests_scripts/bridge/ |
| D | brg_simple_va.sh | 9 # - Messages are bridged to virtual address subscribers, only for subnets in the bridging table.
10 # - Messages are not bridged when the Subnet Bridge state is disabled.
12 # 3 roles are used in this test: Tester, Subnet Bridge node, and Mesh node.
27 # (*) - All nodes are in the tester's range
28 # (**) - Messages are not bridged to subnet 3 via the virtual address. If the node belonging to
32 # The same procedure as in the `mesh_brg_simple` test is used. The main differences are:
34 # - Each of the nodes are subscribed to the same virtual address. Messages are bridged from the
|
| D | brg_simple_group.sh | 9 # - Messages are bridged to group address subscribers, only for subnets in the bridging table.
10 # - Messages are not bridged when the Subnet Bridge state is disabled.
12 # 3 roles are used in this test: Tester, Subnet Bridge node, and Mesh node.
27 # (*) - All nodes are in the tester's range
28 # (**) - Messages are not bridged to subnet 3 via the group address. If the node belonging to subnet
32 # The same procedure as in the `mesh_brg_simple` test is used. The main differences are:
34 # - Each of the nodes are subscribed to the same group address. Messages are bridged from the tester
|
| /Zephyr-latest/modules/cmsis/ |
| D | cmsis_core_m.h | 27 #error "NUM_IRQ_PRIO_BITS and __NVIC_PRIO_BITS are not set to the same value"
31 #error "__MPU_PRESENT and CONFIG_CPU_HAS_ARM_MPU are not set to the same value"
35 #error "__FPU_PRESENT and CONFIG_CPU_HAS_FPU are not set to the same value"
44 #error "__VTOR_PRESENT and CONFIG_CPU_CORTEX_M_HAS_VTOR are not set to the same value."
52 #error "__DSP_PRESENT and CONFIG_ARMV8_M_DSP are not set to the same value"
56 #error "__ICACHE_PRESENT and CONFIG_CPU_HAS_ICACHE are not set to the same value"
60 #error "__DCACHE_PRESENT and CONFIG_CPU_HAS_DCACHE are not set to the same value"
64 #error "__MVE_PRESENT and CONFIG_ARMV8_1_M_MVEI are not set to the same value"
68 #error "__SAUREGION_PRESENT and CONFIG_CPU_HAS_ARM_SAU are not set to the same value"
|
| /Zephyr-latest/lib/hash/ |
| D | Kconfig.hash_map | 12 Hashmaps are data structures that are used when insertion, removal, and
22 They are perhaps more useful on resource-constrained systems where
23 large contiguous memory regions are scarce.
25 The main disadvantage of Separate-Chaining Hashmaps are that their
26 use tends to incur more cache-misses as nodes are spread throughout
36 The main advantage of Open-Addressing Hashmaps are due to their
|
| /Zephyr-latest/modules/hal_nordic/nrfx/ |
| D | nrfx_config_reserved_resources.h | 24 /** @brief Bitmask that defines EGU instances that are reserved for use outside
29 /** @brief Bitmask that defines TIMER instances that are reserved for use outside
39 * are to be built.
455 /** @brief Bitmask that defines DPPI channels that are reserved for use outside
462 /** @brief Bitmask that defines DPPI groups that are reserved for use outside
469 /** @brief Bitmask that defines DPPI channels that are reserved for use outside
476 /** @brief Bitmask that defines DPPI groups that are reserved for use outside
483 /** @brief Bitmask that defines DPPI channels that are reserved for use outside
490 /** @brief Bitmask that defines DPPI groups that are reserved for use outside
497 /** @brief Bitmask that defines DPPI channels that are reserved for use outside
[all …]
|
| /Zephyr-latest/doc/kernel/usermode/ |
| D | overview.rst | 9 User mode threads are considered to be untrusted by Zephyr and are therefore
25 with their own group of threads and private data structures, which are
45 that are not members of the same memory domain.
59 - By default, program text and read-only data are accessible to all threads
62 - User threads by default are not granted default access to any memory
80 - Use of kernel objects that are not in a proper initialization state.
96 We are specifically not protecting against the following attacks:
98 - The kernel itself, and any threads that are executing in supervisor mode,
99 are assumed to be trusted.
101 - The toolchain and any supplemental programs used by the build system are
[all …]
|
| /Zephyr-latest/arch/arc/core/ |
| D | isr_wrapper.S | 33 The symbols in this file are not real functions, and neither are
34 _rirq_enter/_firq_enter: they are jump points.
78 For FIRQ, there are two cases, depending upon the value of
82 Scratch registers are pushed onto the current stack just as they are with
84 registers are where status32 and the program counter are located, so these
90 (lp_count, lp_end, lp_start), however, are not present in the
97 The contexts are saved 'lazily': the minimum amount of work is
102 All needed registers to run C code in the ISR are saved automatically
107 are then saved in the thread's stack.
117 Registers are saved on the stack frame just as they are for RIRQ.
[all …]
|
| /Zephyr-latest/dts/bindings/memory-controllers/ |
| D | st,stm32-fmc-sdram.yaml | 8 memories. Up to 2 SDRAM banks are supported with independent configuration. It
9 is worth to note that while settings are independent, some are shared or are
13 The FMC SDRAM controller is defined below the FMC node and SDRAM banks are
73 respectively. Memory addresses are 0xc0000000 and 0xd0000000 for bank 1 and
104 register bits are also used to program the extended mode register for
127 SDRAM control configuration. Expected fields, in order, are,
134 - SDCLK: SDRAM clock period. If two SDRAM devices are used both should
136 - RBURST: Enable burst read mode. If two SDRAM devices are used both
139 latency. If two SDRAM devices are used both should have the same
146 SDRAM timing configuration. Expected fields, in order, are,
[all …]
|
| D | st,stm32-bbram.yaml | 7 STM32 BBRAM are 32-bit registers which can be used for storing user
8 application data. They are implemented in the backup domain that remains
9 powered-on by VBAT when the VDD power is switched off. They are not reset
10 by system reset or when the device wakes up from Standby mode. They are
|
| /Zephyr-latest/doc/connectivity/bluetooth/api/mesh/ |
| D | health_srv.rst | 16 device's lifetime. Typically, the faults are events or conditions that may
18 Faults are split into warnings and errors. Warnings indicate conditions that
19 are close to the limits of what the node is designed to withstand, but not
20 necessarily damaging to the device. Errors indicate conditions that are
24 Fault values ``0x01`` to ``0x7f`` are reserved for the Bluetooth Mesh
25 specification, and the full list of specification defined faults are available
26 in :ref:`bluetooth_mesh_health_faults`. Fault values ``0x80`` to ``0xff`` are
27 vendor specific. The list of faults are always reported with a company ID to
|
| /Zephyr-latest/drivers/bbram/ |
| D | Kconfig.stm32 | 13 STM32 BBRAM are 32-bit registers which can be used for storing user
14 application data. They are implemented in the backup domain that remains
15 powered-on by VBAT when the VDD power is switched off. They are not reset
16 by system reset or when the device wakes up from Standby mode. They are
|
| /Zephyr-latest/include/zephyr/internal/ |
| D | syscall_handler.h | 34 * Return true if we are currently handling a system call from user mode
36 * Inside z_vrfy functions, we always know that we are handling
39 * However, some checks that are only relevant to user mode must
44 * in the relevant z_vrfy function since these are completely skipped
47 * This will return true only if we are handling a syscall for a
49 * or we are not handling a system call, this will return false.
51 * @note This is an internal API. Do not use unless you are extending
84 * @note This is an internal API. Do not use unless you are extending
102 * @note This is an internal API. Do not use unless you are extending
118 * @note This is an internal API. Do not use unless you are extending
[all …]
|
| /Zephyr-latest/doc/security/ |
| D | security-overview.rst | 14 documents are created, this document is a top-level overview and entry
23 In subsequent sections, the individual parts of the process are treated
24 in detail. As depicted in Figure 1, these main steps are:
32 relevant sub-modules is created, threats are identified, and
34 validity of the threat models are checked by code reviews.
40 how these assets are protected. Certification claims shall be
60 "OPTIONAL" are to be interpreted as described in [RFC2119]_.
62 These words are used to define absolute requirements (or prohibitions),
64 noted in RFC-2119, "These terms are frequently used to specify behavior
77 changes are identified, they will be added to this document through the
[all …]
|
| /Zephyr-latest/doc/safety/ |
| D | safety_requirements.rst | 14 The requirements are gathered in the separate repository:
21 Below are the guidelines for the requirements repository and the expectations of the safety
45 Project as the requirements are specific to an RTOS.
64 After doing this, the requirements are ready and a pull request can be created.
65 The CI in the PR will check if the requirements UIDs are valid or if there are duplicates in it.
66 If there are duplicates in the PR, these need to be resolved by rebasing and re-executing
85 * As long as they are applicable to the requirements repository.
117 * `EARS <https://alistairmavin.com/ears/>`_ is a good reference. Particularly if you are
120 * Other formats are accepted as long as the characteristics of a requirement from above are met.
|
| /Zephyr-latest/arch/xtensa/core/ |
| D | README_WINDOWS.rst | 9 When register windows are configured in the CPU, there are either 32
11 Registers are grouped and rotated in units of 4, so there are 8 or 16
12 such "quads" (my term, not Tensilica's) in hardware of which 4 are
21 window by a immediate number of quads that are added to WINDOWBASE.
26 There are CALL4/CALL8/CALL12 instructions to effect rotated calls
49 a WINDOWSTART register used to detect which register quads are in use.
74 the frame bit to detect how many quads are represented by the one
75 frame. So there are six separate exception handlers to spill/fill
102 registers. But if those 0-2 register quads are in use, they appear at
106 There is no spill area for A12-A15. Those registers are always
|
| /Zephyr-latest/doc/kernel/data_structures/ |
| D | spsc_pbuf.rst | 7 buffer, whose contents are stored in first-in-first-out order. Variable size
8 packets are stored in the buffer. Packet buffer works under assumption that there
14 Packets are added to the buffer using :c:func:`spsc_pbuf_write` which copies a
17 Packets are copied out of the buffer using :c:func:`spsc_pbuf_read`.
|
| D | index.rst | 12 Note that in general, the collections are implemented as "intrusive"
17 user-defined struct. Macros are provided to retrieve a user struct
23 Note also that these libraries are generally unsynchronized; access to
24 them is not threadsafe by default. These are data structures, not
27 structures are thread safe in specific usage scenarios (see
|
| /Zephyr-latest/soc/st/stm32/stm32u5x/ |
| D | Kconfig | 29 All clocks in the core domain are stopped.
30 The PLL, MSIS, MSIK, HSI16, and HSE oscillators are disabled.
31 All SRAMs and register contents are preserved.
33 GPIOs are left floating and additional pull-up or pull-down can be applied
|
| /Zephyr-latest/scripts/native_simulator/common/src/ |
| D | nsi_tasks.h | 31 * * PRE_BOOT_1: Will be called before the command line parameters are parsed,
32 * or the HW models are initialized
34 * * PRE_BOOT_2: Will be called after the command line parameters are parsed,
35 * but before the HW models are initialized
40 * the "CPUs are booted" and embedded SW in them is started.
42 * * FIRST_SLEEP: Will be called after the 1st time all CPUs are sent to sleep
|
| /Zephyr-latest/dts/bindings/w1/ |
| D | maxim,ds2477_85_common.yaml | 20 Only the following values are allowed:
39 Only the following values are allowed:
55 For most configurations with a single slave "1000" ohms are recommended,
61 Only the following values are allowed:
75 Default slew for standard speed mode in ns. Only the following values are
88 Default slew for overdrive speed mode in ns. Only the following values are
|
