Searched refs:very (Results 76 – 100 of 165) sorted by relevance
1234567
| /Zephyr-latest/doc/build/dts/ |
| D | bindings-upstream.rst | 87 My very long string
189 manufacturer datasheet, and would only change under very
|
| /Zephyr-latest/doc/kernel/services/scheduling/ |
| D | index.rst | 65 very fast constant time performance for single threads and very low code size.
91 O(1) time in almost all circumstances with very low constant factor. But it
|
| /Zephyr-latest/doc/project/ |
| D | proposals.rst | 67 they have very different purposes and should not be confused. A project roadmap
|
| /Zephyr-latest/boards/renesas/ek_ra4w1/doc/ |
| D | index.rst | 11 that require a high-performance Arm® Cortex®-M4 core at a very attractive price point. The RA4W1 MCU
|
| /Zephyr-latest/boards/shields/amg88xx/doc/ |
| D | index.rst | 12 The sensor comes in a compact surface mount package and can be very easily
|
| /Zephyr-latest/cmake/compiler/arcmwdt/ |
| D | compiler_flags.cmake | 34 # C implicit promotion rules will want to make floats into doubles very easily
|
| /Zephyr-latest/doc/build/version/ |
| D | index.rst | 16 which makes it a very versatile system for lifecycle management of applications. In addition, it
|
| /Zephyr-latest/arch/x86/zefi/ |
| D | README.txt | 73 No support for 32 bit EFI environments. This would be a very tall
|
| /Zephyr-latest/boards/atmel/sam/sam4l_ek/doc/ |
| D | index.rst | 12 (<1.5μs) and a very low consumption of, respectively, 3 μA and 1.5 μA. In
|
| /Zephyr-latest/drivers/wifi/nxp/ |
| D | Kconfig.nxp | 112 Murata Type 1ZM is a small and very high performance module based on
124 Murata Type 1ZM is a small and very high performance module based on
214 Murata Type 2EL is a small and very high performance module based on
226 Murata Type 2EL is a small and very high performance module based on
237 Murata Type 2DL is a small and very high performance module based on
249 Murata Type 2DL is a small and very high performance module based on
|
| /Zephyr-latest/kernel/ |
| D | Kconfig | 92 int "Number of very-high priority 'preemptor' threads"
312 as a simple unordered list, with very fast constant time
313 performance for single threads and very low code size.
329 this on platforms where you may have many threads (very
342 in almost all circumstances with very low constant factor.
857 system timer support. If accuracy is very important then
|
| /Zephyr-latest/subsys/net/ip/ |
| D | Kconfig | 101 This is a very specific option used to built only the very minimal
650 is used when listening or sending network traffic. This is very
1007 in RX path. This is very special configuration and will increase
1032 in TX path. This is very special configuration and will increase
|
| /Zephyr-latest/boards/renesas/ek_ra6m1/doc/ |
| D | index.rst | 11 a very attractive price point. The RA6M1 is built on a highly efficient 40nm process
|
| /Zephyr-latest/drivers/espi/ |
| D | Kconfig | 77 This depends on SPI boot configuration. It could be either very
|
| /Zephyr-latest/doc/connectivity/bluetooth/ |
| D | bluetooth-tools.rst | 42 The Linux Bluetooth Protocol Stack, BlueZ, comes with a very useful set of
180 is very useful to be able to see the full log of exchanges between the two,
|
| /Zephyr-latest/doc/hardware/porting/ |
| D | arch.rst | 42 for putting the CPU to sleep (partly optional, most likely very desired).
65 initialization sequence. Most of the time, very few steps are needed, while
341 The kernel requires very few hardware devices to function. In theory, the only
370 All these differences mean that very little, if anything, can be shared between
398 The kernel depends on a few functions that can be implemented with very few
444 Normally, idling the CPU should be left to the idle thread, but in some very
545 the initial stack pointer from the very end of the stack object, taking into
|
| /Zephyr-latest/subsys/mgmt/osdp/ |
| D | Kconfig.pd | 22 very quickly.
|
| /Zephyr-latest/boards/mediatek/ |
| D | index.rst | 25 These devices are Xtensa DSP cores, very similar to the Intel ADSP
|
| /Zephyr-latest/samples/bluetooth/hci_uart_3wire/ |
| D | README.rst | 37 controller and expose it to Linux's BlueZ. This can be very useful for testing
|
| /Zephyr-latest/boards/native/doc/ |
| D | arch_soc.rst | 379 Another is the runner context, which is always built with the host C library and which has very
429 This SOC layer is mainly a very thin layer on top of the native simulator CPU emulation layer,
453 This was done to enable very different real SOC simulations to share a common architecture and SOC
|
| /Zephyr-latest/doc/kernel/usermode/ |
| D | syscalls.rst | 10 When defining system calls, it is very important to ensure that access to the
59 The :c:macro:`__syscall` attribute is very special. To the C compiler, it
84 header at the very bottom of the header file. This header follows the
292 uninitialized. This is not used very often, currently only for
|
| /Zephyr-latest/cmake/compiler/gcc/ |
| D | compiler_flags.cmake | 41 # C implicit promotion rules will want to make floats into doubles very easily
|
| /Zephyr-latest/samples/bluetooth/hci_uart/ |
| D | README.rst | 37 controller and expose it to Linux's BlueZ. This can be very useful for testing
|
| /Zephyr-latest/doc/services/logging/ |
| D | cs_stm.rst | 65 There may be cases when logging is too slow (even though it is very fast). For cases like that a de…
116 …sages are not stored in the binary itself. Logging infrastructure is also very limited. On local d…
|
| /Zephyr-latest/doc/kernel/services/ |
| D | interrupts.rst | 9 allowing the response to occur with very low overhead.
226 the shared_irq interrupt controller), which doesn't scale very well.
319 very time-consuming
734 very rapid response, and can be done quickly without blocking.
|
1234567
