Home
last modified time | relevance | path

Searched refs:should (Results 1 – 25 of 1262) sorted by relevance

12345678910>>...51

/Zephyr-latest/samples/
Dsample_definition_and_criteria.rst11 Samples should be limited in scope and should focus only on demonstrating non-trivial or
27 * If a sample can provide output that can be verified, then output should be evaluated against
32 functionality is working as expected, this should not replace dedicated and
38 2. Twister should be able to build every sample.
59 * Do not mark the test as build only. A sample should be able to build *and*
64 file and should be operational on all supported platforms. Do not rely on the
67 * The tests should verify the default configuration of the sample and any
68 optional features documented in the sample's README file. Sample should
73 ``extra_configs`` options in the YAML file. The :file:`prj.conf` file should have the
78 verified on. Those platforms should be listed in the sample's README file.
[all …]
/Zephyr-latest/doc/connectivity/usb/device/api/
Dusb_device.rst13 To transmit data to the host, the class driver should call usb_write().
15 sending another packet the class driver should wait for the completion of
17 is called. usb_read() should be used for retrieving the received data.
25 not have to implement endpoint callback and should set this callback to the
/Zephyr-latest/samples/boards/st/power_mgmt/serial_wakeup/
DREADME.rst18 1. The board should support enabling PM. For a STM32 based target, it means that
19 it should support a clock source alternative to Cortex Systick that can be used
22 2. The serial port used by the shell should be configured, using device tree, to
27 - Matching oscillator sources should be enabled
29 should be adapted (9600 bauds)
30 - Port should be set as "wakeup-source"
60 Also note that after debug mode has been disabled, target should also be powered off in order
78 In order to reach lower power consumption numbers following parameters should be taken
/Zephyr-latest/doc/develop/api/
Ddesign_guidelines.rst7 maintenance and enhancements there are some general policies that should
14 configuration structure. The following policies should be followed when
17 * The first parameter should be a pointer to the object most closely
23 * The next parameter(s) should be additional information specific to the
27 * The final parameter should be a ``void *user_data`` pointer carrying
80 practices should be followed.
82 * Any data that is accessed only when the feature is enabled should be
87 enabled should be provided unconditionally. Add a note in the
94 has no other content that file should be conditionally included in
99 other content the feature-specific code should be conditionally
[all …]
/Zephyr-latest/doc/security/standards/
Detsi-303645.rst250 - Disclosed vulnerabilities should be acted on in a timely manner.
257 - Manufacturers should continually monitor for, identify and rectify security
266 - All software components in consumer IoT devices should be securely updatable.
288 - Automatic mechanisms should be used for software updates.
295 - The device should check after initialization, and then periodically, whether
304 should be enabled in the initialized state and configurable so that the user
327 - The device should verify the authenticity and integrity of software updates.
343 - The manufacturer should inform the user in a recognizable and apparent manner
352 - The device should notify the user when the application of a software update
370 support and a defined support period should be published by the manufacturer in an
[all …]
/Zephyr-latest/doc/services/portability/posix/implementation/
Dindex.rst31 - The POSIX interface and implementations should be part of Zephyr's POSIX library, and not
33 example where the implementation should remain part of the POSIX implementation is
34 ``getopt()``. Examples where the implementation should be part of separate libraries are
38 that feature should be as a separate Zephyr library that can be used by both the POSIX API and
40 practical, that rule should expand to include macros. In the example below, ``libposix``
75 - POSIX API calls should be provided as regular callable C functions; if a Zephyr
77 implementation of that system call should be hidden behind the POSIX API.
/Zephyr-latest/samples/net/sockets/coap_download/
DKconfig10 CoAP server port that the application should send requests to.
17 the application should download.
/Zephyr-latest/subsys/logging/
DKconfig.template.log_format_config35 # The numbering of the format types should be consistent across
38 # Example : LOG_BACKEND_XXX_OUTPUT_TEXT should be numbered 0 across all backends
39 # and should match the value of LOG_OUTPUT_TEXT defined in log_output.h
/Zephyr-latest/doc/hardware/peripherals/
Ddma.rst27 From an API point of view, a DMA channel is a single-owner object, meaning the drivers should not
29 DMA channels require mutating shared registers, those register updates should be wrapped in a spin
38 Drivers should not attempt to use heap allocations of any kind. If object pools are needed for
39 transfer descriptors then those should be setup in a way that does not break the promise of
46 DMA channels should be viewed as state machines that the DMA API provides transition events for in
48 state of the channel should be inspectable at any time with :c:func:`dma_get_status()`.
/Zephyr-latest/boards/gd/gd32a503v_eval/doc/
Dindex.rst82 terminal should be :code:`/dev/ttyUSB0`. For example:
89 string. Connection should be configured as follows:
104 You should see "Hello World! gd32a503v_eval" in your terminal.
119 should install `GD32 ISP Console`_ software at some Linux path. The recommended
142 terminal should be :code:`/dev/ttyUSB0`. For example:
149 string. Connection should be configured as follows:
158 You should see "Hello World! gd32a503v_eval" in your terminal.
/Zephyr-latest/scripts/coccinelle/
Dsame_identifier.cocci32 msg = "WARNING: Violation to rule 5.7 (Tag name should be unique) tag: {}".format(v)
53 msg = "WARNING: Violation to rule 5.7 (Tag name should be unique) tag: {}".format(v)
74 msg = "WARNING: Violation to rule 5.7 (Tag name should be unique) tag: {}".format(v)
/Zephyr-latest/tests/posix/eventfd/
DKconfig13 upper bound because we should expect that eventfd_read() and
31 In order to get a true benchmark, there should be as few branches
38 In order to get a true benchmark, there should be as few branches
/Zephyr-latest/boards/raytac/mdbt53_db_40/
DKconfig13 image application where one or more images should be located on
26 image application where one or more images should be located on
/Zephyr-latest/boards/nordic/nrf5340_audio_dk/
DKconfig13 image application where one or more images should be located on
26 image application where one or more images should be located on
/Zephyr-latest/boards/nordic/nrf5340dk/
DKconfig13 image application where one or more images should be located on
25 image application where one or more images should be located on
/Zephyr-latest/boards/raytac/mdbt53v_db_40/
DKconfig13 image application where one or more images should be located on
26 image application where one or more images should be located on
/Zephyr-latest/doc/connectivity/networking/conn_mgr/
Dimplementation.rst24 …a reference to the passed in :c:struct:`conn_mgr_conn_api` struct (which should be populated with …
39 As such, these functions should be called sparingly, due to their relatively high search cost.
172 * the name used should match with the above
203 Each :c:struct:`implementation API function <conn_mgr_conn_api>` you implement should behave as-des…
205 For example, your implementation of :c:member:`conn_mgr_conn_api.connect` should conform to the beh…
212 Connectivity implementations should provide means for applications to pre-configure all necessary c…
213 …should not be necessary to provide this information as part of, or following the :c:func:`conn_mgr…
220 …tion parameters, or did not configure connection parameters at all, this should be treated as a ne…
222 In other words, the connectivity implementation should not give up on the connection attempt, even …
224 Instead, the connectivity implementation should asynchronously wait for valid connection parameters…
[all …]
/Zephyr-latest/doc/build/dts/
Ddt-vs-kconfig.rst8 sometimes be confusing. This section should help you decide which one to use.
41 * Devicetree should be used to describe the presence of the radio **hardware**,
43 * **Boot-time configuration** for the radio, such as TX power in dBm, should
45 * Kconfig should determine which **software features** should be built for the
60 properties should be prefixed with ``zephyr,``,
/Zephyr-latest/snippets/cdc-acm-console/
DREADME.rst14 which should be used is configured using :ref:`devicetree`.
28 device node with driver support. This should look roughly like this in
/Zephyr-latest/drivers/gpio/
DKconfig.rt1718s19 RT1718S device driver initialization priority. The priority should be
26 RT1718S GPIO driver initialization priority. The priority should be lower
/Zephyr-latest/drivers/i2c/
DKconfig.mcux28 0 means that the driver should use the K_FOREVER value,
29 i.e. it should wait as long as necessary.
/Zephyr-latest/cmake/linker/ld/gcc/
Dlinker_flags.cmake5 # All flags should be described, and the caller should know the flag name to use.
/Zephyr-latest/boards/ezurio/bl5340_dvk/
DKconfig14 image application where one or more images should be located on
27 image application where one or more images should be located on
/Zephyr-latest/drivers/mdio/
DKconfig.nxp_enet_qos17 Number of times that the driver should recheck the status
26 The amount of time in microseconds that the driver should
/Zephyr-latest/tests/cmake/snippets/
DKconfig46 This option's value should be overridden by the 'foo' snippet config
52 This option's value should be overridden by the 'foo' snippet config
58 This option's value should be overridden by the snippet config

12345678910>>...51