Searched refs:receiving (Results 1 – 25 of 86) sorted by relevance
1234
/Zephyr-Core-3.7.0/doc/kernel/services/data_passing/ |
D | mailboxes.rst | 32 while a thread that receives the message is known as the **receiving thread**. 45 Both the sending thread and the receiving thread supply a message descriptor 47 a message exchange between compatible sending and receiving threads. 70 by the mailbox until it is given to a receiving thread. The receiving thread 80 Likewise, a receiving thread can specify the address of the thread from which 84 and receiving thread are satisfied; such threads are said to be **compatible**. 98 has been fully processed by the receiving thread. In an asynchronous exchange, 102 *before* the message is given to a receiving thread and fully processed. 108 consumed by receiving threads. The asynchronous exchange technique provides an 155 receiving a message, set it to the maximum amount of data desired, or to [all …]
|
D | message_queues.rst | 44 The data item is copied to the area specified by the receiving thread; 45 the size of the receiving area *must* equal the message queue's data item size. 48 the receiving thread may choose to wait for a data item to be sent. 49 Any number of receiving threads may wait simultaneously when the ring buffer 51 the highest priority receiving thread that has waited the longest. 55 The data item is copied to the area specified by the receiving thread; 56 the size of the receiving area *must* equal the message queue's data item size.
|
/Zephyr-Core-3.7.0/doc/connectivity/networking/api/ |
D | net_core.rst | 13 The network subsystem contains two functions for sending and receiving 21 for sending and receiving network data.
|
/Zephyr-Core-3.7.0/doc/connectivity/bluetooth/api/mesh/ |
D | blob_srv.rst | 6 The Binary Large Object (BLOB) Transfer Server model implements reliable receiving of large binary 8 receiving other binary images. 42 A BLOB Transfer Server is capable of receiving a single BLOB transfer at a time. Before the BLOB 49 Once the transfer has been set up on the BLOB Transfer Server, it's ready for receiving the BLOB. 69 <bt_mesh_blob_srv_cb.suspended>` callback. If the BLOB Transfer Server is in the middle of receiving
|
D | sar_cfg.rst | 17 The lower transport layer on the receiving device reassembles the segments into a single Upper 19 lower transport layer of the receiving node, while an unsegmented message delivery is not 230 receiving segments of a segmented message before discarding that segmented message. Use the Kconfig 243 transmission of an acknowledgment message after receiving a new segment. The increment is measured 278 delaying the transmission of an acknowledgment message after receiving a new segment. The interval
|
/Zephyr-Core-3.7.0/drivers/mbox/ |
D | Kconfig.nrf_vevif_event | 9 Mailbox driver for receiving events triggered by VPR
|
D | Kconfig.nrf_vevif_task | 9 Mailbox driver for receiving VEVIF tasks on VPR as CLIC interrupts
|
/Zephyr-Core-3.7.0/subsys/mgmt/mcumgr/transport/ |
D | Kconfig.shell | 35 Number of buffers used for receiving SMP fragments over shell. 50 Time (in msec) after receiving a valid MCUmgr header on the serial
|
/Zephyr-Core-3.7.0/tests/bsim/bluetooth/host/privacy/device/ |
D | README.rst | 14 * After devices have exchanged IRK, they must correctly resolve RPA when receiving packets from the
|
/Zephyr-Core-3.7.0/subsys/logging/backends/ |
D | Kconfig.swo | 46 frequency to be known on the receiving side. 52 recovered automatically on the receiving side.
|
/Zephyr-Core-3.7.0/samples/bluetooth/peripheral_nus/ |
D | README.rst | 12 characteristic, it will start receiving periodic notifications with "Hello World!\n".
|
/Zephyr-Core-3.7.0/subsys/canbus/isotp/ |
D | Kconfig | 30 int "Bs timeout [ms] (timeout for receiving the frame control)" 37 int "Ar and As timeout [ms] (sending and receiving timeout)" 70 int "Number of data buffers for receiving data" 86 int "Number of SF and FF data buffers for receiving data"
|
/Zephyr-Core-3.7.0/samples/bluetooth/periodic_sync_conn/ |
D | README.rst | 12 This sample will send its address in response to the advertiser when receiving
|
/Zephyr-Core-3.7.0/subsys/dfu/ |
D | Kconfig | 70 bool "Erase flash progressively when receiving new firmware" 73 If enabled, flash is erased as necessary when receiving new firmware,
|
/Zephyr-Core-3.7.0/samples/drivers/uart/echo_bot/ |
D | README.rst | 15 for receiving, so that in theory the thread could do something else
|
/Zephyr-Core-3.7.0/doc/hardware/peripherals/ |
D | gnss.rst | 21 subsystem covers everything from sending and receiving commands
|
/Zephyr-Core-3.7.0/subsys/modem/backends/ |
D | Kconfig | 32 when receiving a byte before sending the RECEIVE_READY pipe event.
|
/Zephyr-Core-3.7.0/tests/net/ppp/driver/src/ |
D | main.c | 171 static uint8_t *receiving, *expecting; variable 229 receiving = recv; in send_iface()
|
/Zephyr-Core-3.7.0/subsys/bluetooth/audio/ |
D | Kconfig | 25 enables support for receiving of audio data.
|
/Zephyr-Core-3.7.0/modules/nanopb/ |
D | Kconfig | 52 Only to be used when the decoder on the receiving side cannot
|
/Zephyr-Core-3.7.0/subsys/bluetooth/ |
D | Kconfig.iso | 145 used for either transmitting or receiving. 156 used for either transmitting or receiving, but not at the same time.
|
/Zephyr-Core-3.7.0/samples/net/cloud/aws_iot_mqtt/ |
D | Kconfig | 56 bool "Test suite for receiving QoS 1 messages"
|
/Zephyr-Core-3.7.0/doc/services/storage/stream/ |
D | stream_flash.rst | 11 One typical use of a stream write operation is when receiving a new firmware
|
/Zephyr-Core-3.7.0/doc/connectivity/canbus/ |
D | isotp.rst | 33 The receiving peer sends back a flow-control-frame (FC) to either deny,
|
/Zephyr-Core-3.7.0/doc/connectivity/networking/ |
D | net-stack-architecture.rst | 58 receiving data to and from an actual network device. 69 physical sending or receiving of network packets. 85 Data receiving (RX)
|
1234