mirror/btstack
1
0
Fork 0
mirror of https://github.com/bluekitchen/btstack.git synced 2025-01-01 09:08:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

initial docu for le-data-channels

Browse Source
This commit is contained in:
Matthias Ringwald 2016-10-18 15:45:20 +02:00
parent c99bb61874
commit f30489e747
2 changed files with 21 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
doc/manual/docs/protocols.md
View File

@ -303,6 +303,26 @@ as soon as possible. It might happen that the event is received via
packet handler before the *l2cap_request_can_send_now_event* function returns.
The L2CAP_EVENT_CAN_SEND_NOW indicates a channel ID on which sending is possible.
### LE Data Channels
The full title for LE Data Channels is actually LE Connection-Oriented Channels with LE Credit-Based Flow-Control Mode. In this mode, data is sent as Service Data Units (SDUs) that can be larger than an individual HCI LE ACL packet.
LE Data Channels are similar to Classic L2CAP Channels but also provide a credit-based flow control similar to RFCOMM Channels.
Unless the LE Data Packet Extension of Bluetooth Core 4.2 specification is used, the maximum packet size for LE ACL packets is 27 bytes. In order to send larger packets, each packet will be split into multiple ACL LE packets and recombined on the receiving side.
Since multiple SDUs can be transmitted at the same time and the individual ACL LE packets can be sent interleaved, BTstack requires a dedicated receive buffer per channel that has to be passed when creating the channel or accepting it. Similarly, when sending SDUs, the data provided to the *l2cap_le_send_data* must stay valid until the *L2CAP_EVENT_LE_PACKET_SENT* is received.
When creating an outgoing connection of accepting an incoming, the *initial_credits* allows to provide a fixed number of credits to the remote side. Further credits can be provided anytime with *l2cap_le_provide_credits*. If *L2CAP_LE_AUTOMATIC_CREDITS* is used, BTstack automatically provides credits as needed - effectively trading in the flow-control functionality for convenience.
The remainder of the API is similar to the one of L2CAP:
* *l2cap_le_register_service* and *l2cap_le_unregister_service* are used to manage local services.
* *l2cap_le_accept_connection* and *l2cap_le_decline_connection* are used to accept or deny an incoming connection request.
* *l2cap_le_create_channel* creates an outgoing connections.
* *l2cap_le_can_send_now* checks if a packet can be scheduled for transmission now.
* *l2cap_le_request_can_send_now_event* requests an *L2CAP_EVENT_LE_CAN_SEND_NOW* event as soon as possible.
* *l2cap_le_disconnect* closes the connection.
## RFCOMM - Radio Frequency Communication Protocol
The Radio frequency communication (RFCOMM) protocol provides emulation
@ -311,7 +331,6 @@ for the Serial Port Profile and other profiles used for
telecommunication like Head-Set Profile, Hands-Free Profile, Object
Exchange (OBEX) etc.
### RFCOMM flow control {#sec:flowControlProtocols}
RFCOMM has a mandatory credit-based flow-control. This means that two

2
src/l2cap.h
View File

@ -381,7 +381,7 @@ uint8_t l2cap_le_provide_credits(uint16_t cid, uint16_t credits);
int l2cap_le_can_send_now(uint16_t cid);
/**
* @brief Request emission of L2CAP_EVENT_CAN_SEND_NOW as soon as possible
* @brief Request emission of L2CAP_EVENT_LE_CAN_SEND_NOW as soon as possible
* @note L2CAP_EVENT_CAN_SEND_NOW might be emitted during call to this function
* so packet handler should be ready to handle it
* @param local_cid L2CAP LE Data Channel Identifier