Zephyr API Documentation 4.2.99
A Scalable Open Source RTOS
Loading...
Searching...
No Matches
bt_l2cap_le_chan Struct Reference

LE L2CAP Channel structure. More...

#include <zephyr/bluetooth/l2cap.h>

Data Fields

struct bt_l2cap_chan chan
 Common L2CAP channel reference object.
struct bt_l2cap_le_endpoint rx
 Channel Receiving Endpoint.
uint16_t pending_rx_mtu
 Pending RX MTU on ECFC reconfigure, used internally by stack.
struct bt_l2cap_le_endpoint tx
 Channel Transmission Endpoint.
struct k_fifo tx_queue
 Channel Transmission queue.

Detailed Description

LE L2CAP Channel structure.

Field Documentation

◆ chan

struct bt_l2cap_chan bt_l2cap_le_chan::chan

Common L2CAP channel reference object.

◆ pending_rx_mtu

uint16_t bt_l2cap_le_chan::pending_rx_mtu

Pending RX MTU on ECFC reconfigure, used internally by stack.

◆ rx

struct bt_l2cap_le_endpoint bt_l2cap_le_chan::rx

Channel Receiving Endpoint.

If the application has set an alloc_buf channel callback for the channel to support receiving segmented L2CAP SDUs the application should initialize the MTU of the Receiving Endpoint. Otherwise the MTU of the receiving endpoint will be initialized to BT_L2CAP_SDU_RX_MTU by the stack.

This is the source of the MTU, MPS and credit values when sending L2CAP_LE_CREDIT_BASED_CONNECTION_REQ/RSP and L2CAP_CONFIGURATION_REQ.

◆ tx

struct bt_l2cap_le_endpoint bt_l2cap_le_chan::tx

Channel Transmission Endpoint.

This is an image of the remote's rx.

The MTU and MPS is controlled by the remote by L2CAP_LE_CREDIT_BASED_CONNECTION_REQ/RSP or L2CAP_CONFIGURATION_REQ.

◆ tx_queue

struct k_fifo bt_l2cap_le_chan::tx_queue

Channel Transmission queue.

Internal

SDUs/PDUs given to bt_l2cap_chan_send and bt_l2cap_send_pdu are stored here until they are sent to the Controller.

The SDU header is prepended to SDUs before they are stored here. The head of this list (the next data to be sent) may be just the remaining part of an already partially transmitted SDU/PDU due to L2CAP segmentation and fragmentation.

This is the outbox for a single channel. Channels may be serviced in any order. The transmission order does not follow the sequence of bt_l2cap_chan_send calls across channels.

There may be more data here than the channel currently has credits for. The transmission will wait until credits are available.

Callbacks given to bt_l2cap_chan_send are stored in the user_data of the buffer. These callbacks must be invoked when the Controller gives a Number of Buffers Complete Event for the last L2CAP PDU of the buffer or when the channel is disconnected.


The documentation for this struct was generated from the following file: