| /Zephyr-Core-3.7.0/subsys/net/l2/ieee802154/ |
| D | ieee802154_radio_csma_ca.c | 32 uint8_t be = CONFIG_NET_L2_IEEE802154_RADIO_CSMA_CA_MIN_BE; in unslotted_csma_ca_channel_access() local
44 if (be) { in unslotted_csma_ca_channel_access()
45 uint8_t bo_n = sys_rand32_get() & ((1 << be) - 1); in unslotted_csma_ca_channel_access()
64 be = MIN(be + 1, CONFIG_NET_L2_IEEE802154_RADIO_CSMA_CA_MAX_BE); in unslotted_csma_ca_channel_access()
|
| /Zephyr-Core-3.7.0/samples/drivers/led_lp5562/ |
| D | README.rst | 13 1. turn on LEDs to be red
14 2. turn on LEDs to be green
15 3. turn on LEDs to be blue
16 4. turn on LEDs to be white
17 5. turn on LEDs to be yellow
18 6. turn on LEDs to be purple
19 7. turn on LEDs to be cyan
20 8. turn on LEDs to be orange
|
| /Zephyr-Core-3.7.0/doc/develop/api/ |
| D | design_guidelines.rst | 8 be followed when developing a new capability or interface.
14 configuration structure. The following policies should be followed when
17 * The first parameter should be a pointer to the object most closely
19 would be ``const struct device *dev``. For library functions it may be a
23 * The next parameter(s) should be additional information specific to the
27 * The final parameter should be a ``void *user_data`` pointer carrying
31 An exception to providing ``user_data`` as the last parameter may be
33 will be embedded in another structure. An example of such a case is
64 occurred, as well as user context which may or may not be the
72 code size but are optional in the sense that some applications can be
[all …]
|
| D | api_lifecycle.rst | 8 maintaining and extending Zephyr's APIs need to be able to introduce
20 An up-to-date table of all APIs and their maturity level can be found in the
30 or be removed in future versions. Try it out and provide feedback
36 explaining its design and assumptions, how it is to be used, current
38 - The API introduction should be accompanied by at least one implementation
53 The API shall be promoted to ``unstable`` when it has at least two
62 testing to be considered stable. The API is considered generic in nature and can
63 be used on different hardware platforms.
71 Changes will not be announced.
76 The API shall be promoted from ``experimental`` to ``unstable`` when it has at
[all …]
|
| /Zephyr-Core-3.7.0/doc/connectivity/bluetooth/api/ |
| D | gatt.rst | 10 Services can be registered using :c:func:`bt_gatt_service_register` API
13 can be used to declare a service.
15 Attributes can be declared using the :c:struct:`bt_gatt_attr` struct or using
47 callbacks can be set to NULL if the attribute permission don't allow their
51 32-bit UUIDs are not supported in GATT. All 32-bit UUIDs shall be converted
58 Attribute value changes can be notified using :c:func:`bt_gatt_notify` API,
60 pass a callback to be called when it is necessary to know the exact instant when
64 Client procedures can be enabled with the configuration option:
67 Discover procedures can be initiated with the use of
71 field only attributes which matches will be discovered, in contrast setting it
[all …]
|
| /Zephyr-Core-3.7.0/doc/services/device_mgmt/ |
| D | mcumgr_callbacks.rst | 12 that provides control over if the action should be allowed or not. An example
13 of this is with the fs_mgmt group, whereby file access can be gated, the
24 The base callback/notification system can be enabled using
28 be selected by enabling the Kconfig's for the required callbacks (see
30 :c:type:`mgmt_cb` type definition can then be declared and registered by
35 With the system enabled, a basic handler can be set up and defined in
66 event, which will be called after a MCUmgr command has been processed and
68 :kconfig:option:`CONFIG_MCUMGR_SMP_COMMAND_STATUS_HOOKS` be enabled to receive
71 Multiple callbacks can be setup to use a single function as a common callback,
72 and many different functions can be used for each event by registering each
[all …]
|
| /Zephyr-Core-3.7.0/arch/x86/zefi/ |
| D | efi.ld | 19 /* Must be a separately visible section to the EFI loader, doesn't
20 * need to be page-aligned and can be immediately after text/rodata */
23 /* Must be page-aligned or EFI balks */
30 *(.runtime_data_end) /* Must be last. Obviously. */
|
| /Zephyr-Core-3.7.0/samples/boards/stm32/power_mgmt/serial_wakeup/ |
| D | README.rst | 18 it should support a clock source alternative to Cortex Systick that can be used
21 2. The serial port used by the shell should be configured, using device tree, to
22 be a functional wakeup source:
25 that can be requested dynamically by device on activity detection (HSI on STM32WB).
26 - Matching oscillator sources should be enabled
28 should be adapted (9600 bauds)
29 - Port should be set as "wakeup-source"
37 configured to be compatible with this sample.
57 :kconfig:option:`CONFIG_DEBUG` could be enabled to allow debug. Note that debug mode prevents
59 Also note that after debug mode has been disabled, target should also be powered off in order
[all …]
|
| /Zephyr-Core-3.7.0/doc/security/ |
| D | sensor-threat.rst | 8 be used to help prioritize these efforts as well.
15 images. A general diagram can be seen in Figure 1:
24 model in unexpected ways, and variants on this will need to be
29 as this seems to be in wide use [1]_.
40 a root of trust, this image must be immutable. This model assumes
42 from future writes, and that this will be done after this image is
47 is made because this part of the image will need to be updated
51 a. The image shall only be replaced with an authorized image
55 shall be done in a timely manner [th-timely-update]_.
57 c. The image update shall be seen as atomic, meaning that when the
[all …]
|
| D | security-overview.rst | 13 to be created. After the process is implemented and all supporting
35 Finally, a process shall be defined for reporting, classifying,
40 how these assets are protected. Certification claims shall be
60 "OPTIONAL" are to be interpreted as described in [RFC2119]_.
67 SHOULD NOT be done may be very subtle. Document authors should take the
77 changes are identified, they will be added to this document through the
80 1. Changes will be submitted from the interested party(ies) via pull
105 requires all code to be reviewed before being committed to the
178 concrete and detailed guidelines need to be developed and aligned with
199 Execution protection is supported and can be categorized into the
[all …]
|
| D | secure-coding.rst | 14 uncontrolled access can be devastating [#attackf]_.
41 should have. This knowledge will be necessary for the review process
49 Finally, the document covers how changes are to be made to this
55 Designing an open software system such as Zephyr to be secure requires
61 protection mechanisms cannot be kept secret on any system in
64 well established cryptographic libraries shall be used.
67 system shall be kept as simple and small as possible. In the context
68 of the Zephyr project, this can be realized, e.g., by modular code
72 process needs to be authenticated first. Mechanisms to store access
73 conditions shall be avoided if possible.
[all …]
|
| D | reporting.rst | 9 Vulnerabilities to the Zephyr project may be reported via email to the
10 vulnerabilities@zephyrproject.org mailing list. These reports will be
12 Each vulnerability will be entered into the Zephyr Project security
13 advisory GitHub_. The original submitter will be granted permission to
54 response to an email, the issue shall be transitioned directly to
60 issue to the Assigned state. Part of triage will be to set the
67 link will be added to a comment in the issue, and the issue moved to
73 - Public: The embargo period has ended. The issue will be made
97 need to be embargoed.
99 The guideline for embargo will be based on: 1. Severity of the issue,
[all …]
|
| /Zephyr-Core-3.7.0/doc/build/flashing/ |
| D | configuration.rst | 10 might want to only allow the ``--erase`` argument to be used once for all of the cores in the SoC
17 Flashing configuration is singular, it will only be read from a single location, this
27 child, this then contains a map of commands as they would be provided to the flash runner e.g.
32 Groups of board targets can be specified using the ``groups`` key which has a list of board
34 board targets must be in a ``qualifiers`` key (only regular expression matches for board
35 qualifiers are allowed, board names must be omitted from these entries). For ``board.yml``
36 files each set of board targets must be in a ``boards`` key, these are lists containing the
37 matches which form a singular group. A final parameter ``run`` can be set to ``first`` which
38 means that the command will be ran once with the first image flashing process per set of board
39 targets, or to ``last`` which will be ran once for the final image flash per set of board targets.
[all …]
|
| /Zephyr-Core-3.7.0/doc/connectivity/networking/api/ |
| D | websocket.rst | 14 The Websocket client API can be used directly by application to establish
15 a Websocket connection to server, or it can be used as a transport for other
28 The Websocket API allows it to be used as a transport for other high level
29 protocols like MQTT. The Zephyr MQTT client library can be configured to use
33 First a socket needs to be created and connected to the Websocket server:
48 The Websocket socket can then be used to send or receive data, and the
51 BSD socket API functions can be used to send and receive application data.
63 must be used.
65 When done, the Websocket transport socket must be closed. User should handle
|
| D | tls_credentials_shell.rst | 16 Buffer data incrementally into the credential buffer so that it can be added using the :ref:`tls_cr…
44 …"``<DATA>``", "Text data to be appended to credential buffer. It can be either text, or base64-enc…
53 Credential contents can be provided in-line with the call to ``cred add``, or will otherwise be sou…
78 "``<SECTAG>``", "The sectag to use for the new credential. Can be any non-negative integer."
80 "``<BACKEND>``", "Reserved. Must always be ``DEFAULT`` (case-insensitive)."
82 … "If provided, this argument will be used as the credential data, instead of any data in the crede…
107 "``<SECTAG>``", "The sectag of the credential to delete. Can be any non-negative integer."
133 "``<SECTAG>``", "The sectag of the credential to get. Can be any non-negative integer."
179 …with this sectag. Pass ``any`` or omit to allow any sectag. Otherwise, can be any non-negative int…
201 … to the storage backend otherwise. Lines for which status is not zero will be printed with error f…
[all …]
|
| /Zephyr-Core-3.7.0/doc/kernel/memory_management/ |
| D | sys_mem_blocks.rst | 6 The Memory Blocks Allocator allows memory blocks to be dynamically
11 * Multiple blocks can be allocated or freed at the same time.
13 * A group of blocks allocated together may not be contiguous.
18 memory regions where these can be powered down to conserve energy.
27 Any number of Memory Blocks Allocator can be defined (limited only by
33 It must be at least 4N bytes long, where N is greater than 0.
36 It must be greater than zero.
39 It must be at least "block size" times "number of blocks" bytes long.
43 The buffer must be aligned to an N-byte boundary, where N is a power of 2
46 also be a multiple of N.
[all …]
|
| D | demand_paging.rst | 17 the eviction algorithm is invoked to select a data page to be paged out,
18 thus freeing up a page frame for new data to be paged in. If this data
19 page has been modified after it is first paged in, the data will be
28 There are functions where paging in and out can be invoked manually
30 :c:func:`k_mem_page_in()` can be used to page in data pages
33 memory, and thus minimizing latency. :c:func:`k_mem_page_out()` can be
34 used to page out data pages where they are not going to be accessed for
36 page in can be executed faster as the paging code does not need to invoke
44 or be paged out to some backing store. Its location can always be looked
46 The data type will always be ``void *`` or in some cases ``uint8_t *``
[all …]
|
| /Zephyr-Core-3.7.0/soc/microchip/mec/mec172x/ |
| D | Kconfig | 30 Debug port is disabled, JTAG/SWD cannot be enabled. JTAG_RST#
31 pin is ignored. All other JTAG pins can be used as GPIOs
37 JTAG port in SWD mode. I2C09 and ADC00-03 can be used.
43 to see if ADC00-03 can be used or not.
57 I2C09 can be used, but ADC00-03 cannot.
63 I2C09 cannot be used. ADC00-03 can be used.
67 # CONFIG_KERNEL_INIT_PRIORITY_DEFAULT, so GPIO_INIT_PRIORITY needs to be
|
| /Zephyr-Core-3.7.0/samples/bluetooth/peripheral_accept_list/ |
| D | README.rst | 10 If no device is bonded to the peripheral, casual advertising will be performed.
11 Once a device is bonded, on subsequent boots, connection requests will only be
13 data will only be sent to devices that are on the accept list. As a result, some
18 to be bonded, while a read can be done immediately after a connection
30 This sample can be found under :zephyr_file:`samples/bluetooth/peripheral_accept_list` in the
|
| /Zephyr-Core-3.7.0/doc/kernel/usermode/ |
| D | kernelobjects.rst | 6 A kernel object can be one of three classes of data:
20 All kernel objects must be placed in memory that is not accessible by
36 may be called to release any runtime-allocated buffers the object was using.
39 will be freed.
45 and can be located anywhere in the binary, or even declared on stacks. However,
47 not be located in any memory that user threads have direct access to.
49 In order for a static kernel object to be usable by a user thread via system
50 call APIs, several conditions must be met on how the kernel object is declared:
52 * The object must be declared as a top-level global at build time, such that it
56 in a special table of kernel object metadata. Kernel objects may be members
[all …]
|
| /Zephyr-Core-3.7.0/doc/contribute/ |
| D | bin_blobs.rst | 7 many different IC families, some functionality may be unavailable without the
35 Blobs must be hosted on the Internet and managed by third-party infrastructure.
48 The blobs themselves must be specified in the :ref:`module.yml
52 module repository must exist first or be created as part of the submission
55 Each blob which may be fetched must be individually identified in the
61 - The blob’s :ref:`type <bin-blobs-types>`, which must be one of the allowed types
71 The :ref:`west blobs <west-blobs>` command can be used to list metadata of
75 Any accompanying code, including interface header files for the blobs, must be
84 in the context of Zephyr, a tainted image will be one that includes binary blobs
87 Tainting will be communicated to the user in the following manners:
[all …]
|
| /Zephyr-Core-3.7.0/drivers/timer/ |
| D | Kconfig.gecko | 12 If you enable this, BURTC will be used to provide hw_cycles and
14 to be able to keep track of time and wake up from EM2 & EM3 sleep
20 1. You won't be able to use the usual 0.1ms-granularity tickless
21 scheduling. Kernel tick duration should be at least 6 BURTC clock
24 2. In general, accuracy of real-time scheduling by kernel will be
28 3. hw_cycles granularity will be equal to 1 BURTC clock, that is
|
| /Zephyr-Core-3.7.0/subsys/usb/device/class/ |
| D | Kconfig.msc | 19 string "T10 assigned vendor ID for inquiry (must be 8 characters)"
23 Spaces must be added to bring the string to 8 bytes.
26 string "Product ID for inquiry (must be 16 characters)"
30 Spaces must be added to bring the string to 16 bytes.
33 string "Revision for inquiry (must be 4 characters)"
37 Spaces must be added to bring the string to 4 bytes.
|
| /Zephyr-Core-3.7.0/subsys/retention/ |
| D | Kconfig.blinfo | 23 MCUboot and the running image. This can be used by applications so
27 In order to use this, a retention area must be created and set as
29 must be built with the same "zephyr,bootloader-info" DTS node and
32 information will not be accessible.
38 Bootloader info initialization priority (must be higher than init
45 Allows bootloader settings to be fetched by calling a function which
52 Allows bootloader settings to be fetched using settings with the
|
| /Zephyr-Core-3.7.0/doc/kernel/services/other/ |
| D | thread_local_storage.rst | 6 Thread Local Storage (TLS) allows variables to be allocated on a per-thread
17 needs to be enabled. Note that this option may not be available if
23 :kconfig:option:`CONFIG_ERRNO_IN_TLS` can be enabled together with
24 :kconfig:option:`CONFIG_ERRNO` to let the variable ``errno`` be a thread local
32 The keyword ``__thread`` can be used to declare thread local variables.
46 Keyword ``static`` can also be used to limit the variable within a source file:
|
