| /Zephyr-Core-3.6.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.6.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.6.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
|
| /Zephyr-Core-3.6.0/dts/bindings/bluetooth/ |
| D | ambiq,bt-hci-spi.yaml | 30 controller. The host needs to enable XO32MHz when receiving low to high
31 edge interrupts and disable XO32MHz when receiving high to low edge
|
| /Zephyr-Core-3.6.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.6.0/subsys/mgmt/ec_host_cmd/backends/ |
| D | ec_host_cmd_backend_uart.c | 36 * After first byte is received the current state is moved to receiving
103 /* Timeout after receiving first byte */
123 /* If state is receiving then timeout was hit due to underrun */ in rx_timeout()
197 /* Disable receiving to prevent overwriting the rx buffer while in uart_callback()
198 * processing. Enabling receiving to a temporary buffer to detect in uart_callback()
222 /* Receiving is already enabled in the send function. */ in uart_callback()
226 LOG_ERR("UART HOST CMD ERROR: Receiving data stopped"); in uart_callback()
283 * Enable receiving to be ready to get a new command right after sending the response. in ec_host_cmd_uart_send()
|
| /Zephyr-Core-3.6.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.6.0/dts/bindings/spi/ |
| D | espressif,esp32-spi.yaml | 22 Transmit data before receiving it, instead of simultaneously
33 Use MOSI for both sending and receiving data
|
| /Zephyr-Core-3.6.0/samples/subsys/canbus/isotp/ |
| D | prj.conf | 7 # We have two receiving contexts that are bound to a single address.
|
| /Zephyr-Core-3.6.0/include/zephyr/drivers/ |
| D | lora.h | 85 /** Set to true for transmission, false for receiving */
117 * @brief Callback API for receiving data asynchronously
154 * @brief Callback API for receiving data over LoRa
164 * @brief Callback API for receiving data asynchronously over LoRa
167 * @param cb Callback to run on receiving data.
285 * @param cb Callback to run on receiving data. If NULL, any pending
|
| /Zephyr-Core-3.6.0/include/zephyr/bluetooth/audio/ |
| D | gmap.h | 70 * @brief Support for receiving at least two channels of audio, each in a separate CIS
105 * @brief Support for receiving multiple LC3 codec frames per block in an SDU
111 * @brief Support for receiving at least two audio channels, each in a separate CIS
136 * @brief Support for receiving at least two audio channels, each in a separate BIS
141 /** @brief Support for receiving multiple LC3 codec frames per block in an SDU */
|
| /Zephyr-Core-3.6.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.6.0/samples/bluetooth/observer/ |
| D | prj_extended.conf | 9 # Advertising Report for receiving the complete 1650 bytes of data
|
| /Zephyr-Core-3.6.0/dts/bindings/shi/ |
| D | shi-device.yaml | 14 Size of the internal buffer used for receiving data on the bus.
|
| /Zephyr-Core-3.6.0/tests/subsys/ipc/ipc_service/src/ |
| D | main.c | 41 * receiving callback (10 + 10 == 20) in ZTEST()
57 * 20 in the receiving callback (10 + 20 == 30) in ZTEST()
|
| /Zephyr-Core-3.6.0/drivers/sensor/grow_r502a/ |
| D | grow_r502a.c | 123 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_led_control()
154 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_verify_password()
182 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_get_template_count()
215 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_read_template_table()
267 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_get_image()
299 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_image_to_char()
327 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_create_model()
363 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_store_model()
397 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_delete_model()
428 LOG_ERR("Error receiving ack packet 0x%X", rx_packet.pid); in fps_empty_db()
[all …]
|
| /Zephyr-Core-3.6.0/drivers/bluetooth/hci/ |
| D | apollox_blue.h | 93 * @brief Check if vendor specific receiving handling is ongoing.
97 * @return true indicates if vendor specific receiving handling is ongoing.
|
| /Zephyr-Core-3.6.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.6.0/include/zephyr/drivers/serial/ |
| D | uart_altera.h | 15 * Driver will trigger interrupt upon receiving end of package character.
|
| /Zephyr-Core-3.6.0/dts/bindings/dma/ |
| D | nxp,lpc-dma.yaml | 30 description: DMA Channel Selection Address used for receiving signals
|
| /Zephyr-Core-3.6.0/subsys/bluetooth/ |
| D | Kconfig.iso | 138 used for either transmitting or receiving.
149 used for either transmitting or receiving, but not at the same time.
|
| /Zephyr-Core-3.6.0/subsys/bluetooth/controller/ll_sw/nordic/lll/ |
| D | lll_vendor.h | 22 * PHY, scheduling and receiving auxiliary PDUs.
27 * scheduling and receiving auxiliary PDUs.
|
| /Zephyr-Core-3.6.0/subsys/net/l2/ethernet/gptp/ |
| D | Kconfig | 140 The VLAN tag to use when sending and receiving gPTP messages.
182 Defines the number of sync intervals to wait without receiving
190 Defines the number of announce intervals to wait without receiving
|
| /Zephyr-Core-3.6.0/include/zephyr/bluetooth/ |
| D | l2cap.h | 70 * an alloc_buf callback for the channel in order to support receiving
170 /** @brief Channel Receiving Endpoint.
173 * channel to support receiving segmented L2CAP SDUs the application
174 * should inititalize the MTU of the Receiving Endpoint. Otherwise the
175 * MTU of the receiving endpoint will be initialized to
248 /** Channel Receiving Endpoint */
334 * @param chan The channel receiving data.
412 * @param chan The receiving channel.
630 /** @brief Complete receiving L2CAP channel data
|
