From add0254b7d6c95a90f0d01ec68df2c0159c66f40 Mon Sep 17 00:00:00 2001 From: Matthias Ringwald Date: Thu, 21 Jan 2016 12:21:03 +0100 Subject: [PATCH] drop _internal from doc and remaining places --- doc/manual/Makefile | 3 ++- doc/manual/docs/appendix/events_errors.md | 6 ++--- doc/manual/docs/how_to.md | 10 +++---- doc/manual/docs/profiles.md | 4 +-- doc/manual/docs/protocols.md | 32 +++++++++++------------ doc/notes/SDP.txt | 2 +- src/l2cap.c | 2 +- test/pts/classic_test.c | 4 +-- 8 files changed, 32 insertions(+), 31 deletions(-) diff --git a/doc/manual/Makefile b/doc/manual/Makefile index 751fa3219..4afa8189e 100644 --- a/doc/manual/Makefile +++ b/doc/manual/Makefile @@ -19,6 +19,7 @@ all: mv latex/btstack_gettingstarted.pdf btstack.pdf rm -rf latex tmp - +clean: + rm -rf docs_final btstack diff --git a/doc/manual/docs/appendix/events_errors.md b/doc/manual/docs/appendix/events_errors.md index ec03d63fe..3f9ee1e87 100644 --- a/doc/manual/docs/appendix/events_errors.md +++ b/doc/manual/docs/appendix/events_errors.md @@ -3,7 +3,7 @@ L2CAP events and data packets are delivered to the packet handler specified by *l2cap_register_service* resp. -*l2cap_create_channel_internal*. Data packets have the +*l2cap_create_channel*. Data packets have the L2CAP_DATA_PACKET packet type. L2CAP provides the following events: - L2CAP_EVENT_CHANNEL_OPENED - sent if channel establishment is @@ -17,7 +17,7 @@ L2CAP_DATA_PACKET packet type. L2CAP provides the following events: - L2CAP_EVENT_INCOMING_CONNECTION - received when the connection is requested by remote. Connection accept and decline are performed with *l2cap_accept_connection* and - *l2cap_decline_connecti-on_internal* respectively. + *l2cap_decline_connecti-on* respectively. - L2CAP_EVENT_CREDITS - emitted when there is a chance to send a new L2CAP packet. BTstack does not buffer packets. Instead, it requires @@ -65,7 +65,7 @@ by RFCOMM: - RFCOMM_EVENT_INCOMING_CONNECTION - received when the connection is requested by remote. Connection accept and decline are performed with *rfcomm_accept_connection* and - *rfcomm_decline_con-nection_internal* respectively. + *rfcomm_decline_connection* respectively. - RFCOMM_EVENT_CHANNEL_CLOSED - emitted when channel is closed. No status information is provided. diff --git a/doc/manual/docs/how_to.md b/doc/manual/docs/how_to.md index 522a0a8c8..5ab220d9d 100644 --- a/doc/manual/docs/how_to.md +++ b/doc/manual/docs/how_to.md @@ -242,8 +242,8 @@ These handlers are registered with the functions listed in Table Packet Handler Registering Function HCI packet handler *hci_register_packet_handler* L2CAP packet handler *l2cap_register_packet_handler* - L2CAP service packet handler *l2cap_register_service_internal* - L2CAP channel packet handler *l2cap_create_channel_internal* + L2CAP service packet handler *l2cap_register_service* + L2CAP channel packet handler *l2cap_create_channel* RFCOMM packet handler *rfcomm_register_packet_handler* ------------------------------ -------------------------------------- @@ -257,7 +257,7 @@ data packets are delivered to different packet handlers. Outgoing connections are used access remote services, incoming connections are used to provide services. For incoming connections, the packet handler specified by *l2cap_register_service* is used. For outgoing -connections, the handler provided by *l2cap_create_channel_internal* +connections, the handler provided by *l2cap_create_channel* is used. Currently, RFCOMM provides only a single packet handler specified by *rfcomm_register_packet_handler* for all RFCOMM connections, but this will be fixed in the next API overhaul. @@ -273,10 +273,10 @@ application could use three packet handlers: one to handle HCI events during discovery of a keyboard registered by *l2cap_register_packet_handler*; one that will be registered to an outgoing L2CAP channel to connect to keyboard and to receive keyboard -data registered by *l2cap_create_channel_internal*; after that +data registered by *l2cap_create_channel*; after that keyboard can reconnect by itself. For this, you need to register L2CAP services for the HID Control and HID Interrupt PSMs using -*l2cap_register_service_internal*. In this call, you’ll also specify +*l2cap_register_service*. In this call, you’ll also specify a packet handler to accept and receive keyboard data. diff --git a/doc/manual/docs/profiles.md b/doc/manual/docs/profiles.md index dc5706b79..a66429018 100644 --- a/doc/manual/docs/profiles.md +++ b/doc/manual/docs/profiles.md @@ -193,7 +193,7 @@ To provide an SPP Server, you need to provide an RFCOMM service with a specific RFCOMM channel number as explained in section on [RFCOMM service](protocols/#sec:rfcommServiceProtocols). Then, you need to create an SDP record for it and publish it with the SDP server by calling -*sdp_register_service_internal*. BTstack provides the +*sdp_register_service*. BTstack provides the *sdp_create_spp_service* function in that requires an empty buffer of approximately 200 bytes, the service channel number, and a service name. Have a look at the [SPP Counter example](examples/generated/#sec:sppcounterExample]. @@ -243,7 +243,7 @@ To provide a PANU service, you need to provide a BNEP service with the service UUID, e.g. the PANU UUID, and a a maximal ethernet frame size, as explained in Section [on BNEP service](protocols/#sec:bnepServiceProtocols). Then, you need to create an SDP record for it and publish it with the SDP server by -calling *sdp_register_service_internal*. BTstack provides the +calling *sdp_register_service*. BTstack provides the *pan_create_panu_service* function in *src/pan.c* that requires an empty buffer of approximately 200 bytes, a description, and a security description. diff --git a/doc/manual/docs/protocols.md b/doc/manual/docs/protocols.md index bdaccad23..ccc8d5994 100644 --- a/doc/manual/docs/protocols.md +++ b/doc/manual/docs/protocols.md @@ -185,8 +185,8 @@ protocols. Multiple channels can share the same baseband connection. To communicate with an L2CAP service on a remote device, the application on a local Bluetooth device initiates the L2CAP layer using the *l2cap_init* function, and then creates an outgoing L2CAP channel to -the PSM of a remote device using the *l2cap_create_channel_internal* -function. The *l2cap_create_channel_internal* function will initiate +the PSM of a remote device using the *l2cap_create_channel* +function. The *l2cap_create_channel* function will initiate a new baseband connection if it does not already exist. The packet handler that is given as an input parameter of the L2CAP create channel function will be assigned to the new outgoing L2CAP channel. This @@ -205,7 +205,7 @@ in Listing [below](#lst:L2CAPremoteService). } void create_outgoing_l2cap_channel(bd_addr_t address, uint16_t psm, uint16_t mtu){ - l2cap_create_channel_internal(NULL, l2cap_packet_handler, remote_bd_addr, psm, mtu); + l2cap_create_channel(NULL, l2cap_packet_handler, remote_bd_addr, psm, mtu); } void l2cap_packet_handler(uint8_t packet_type, uint16_t channel, uint8_t *packet, uint16_t size){ @@ -228,10 +228,10 @@ in Listing [below](#lst:L2CAPremoteService). To provide an L2CAP service, the application on a local Bluetooth device must init the L2CAP layer and register the service with -*l2cap_register_service_internal*. From there on, it can wait for +*l2cap_register_service*. From there on, it can wait for incoming L2CAP connections. The application can accept or deny an incoming connection by calling the *l2cap_accept_connection* -and *l2cap_deny_connection_internal* functions respectively. If a +and *l2cap_deny_connection* functions respectively. If a connection is accepted and the incoming L2CAP channel gets successfully opened, the L2CAP service can send L2CAP data packets to the connected device with *l2cap_send*. @@ -252,7 +252,7 @@ provides L2CAP service example code. void btstack_setup(){ ... l2cap_init(); - l2cap_register_service_internal(NULL, packet_handler, 0x11,100); + l2cap_register_service(NULL, packet_handler, 0x11,100); } void packet_handler (uint8_t packet_type, uint16_t channel, uint8_t *packet, uint16_t size){ @@ -334,12 +334,12 @@ To communicate with an RFCOMM service on a remote device, the application on a local Bluetooth device initiates the RFCOMM layer using the *rfcomm_init* function, and then creates an outgoing RFCOMM channel to a given server channel on a remote device using the -*rfcomm_create_channel_internal* function. The -*rfcomm_create_channel_internal* function will initiate a new L2CAP +*rfcomm_create_channel* function. The +*rfcomm_create_channel* function will initiate a new L2CAP connection for the RFCOMM multiplexer, if it does not already exist. The channel will automatically provide enough credits to the remote side. To provide credits manually, you have to create the RFCOMM connection by -calling *rfcomm_create_channel_with_initial_credits_internal* - +calling *rfcomm_create_channel_with_initial_credits* - see Section [on manual credit assignement](#sec:manualCreditsProtocols). The packet handler that is given as an input parameter of the RFCOMM @@ -358,7 +358,7 @@ Listing [below](#lst:RFCOMMremoteService). } void create_rfcomm_channel(uint8_t packet_type, uint8_t *packet, uint16_t size){ - rfcomm_create_channel_internal(connection, addr, rfcomm_channel); + rfcomm_create_channel(connection, addr, rfcomm_channel); } void rfcomm_packet_handler(uint8_t packet_type, uint16_t channel, uint8_t *packet, uint16_t size){ @@ -381,15 +381,15 @@ Listing [below](#lst:RFCOMMremoteService). To provide an RFCOMM service, the application on a local Bluetooth device must first init the L2CAP and RFCOMM layers and then register the -service with *rfcomm_register_service_internal*. From there on, it +service with *rfcomm_register_service*. From there on, it can wait for incoming RFCOMM connections. The application can accept or deny an incoming connection by calling the *rfcomm_accept_connection* and -*rfcomm_deny_connection_internal* functions respectively. If a +*rfcomm_deny_connection* functions respectively. If a connection is accepted and the incoming RFCOMM channel gets successfully opened, the RFCOMM service can send RFCOMM data packets to the connected device with *rfcomm_send* and receive data packets by the -packet handler provided by the *rfcomm_register_service_internal* +packet handler provided by the *rfcomm_register_service* call. Sending of RFCOMM data packets may fail due to a full internal BTstack @@ -408,7 +408,7 @@ provides the RFCOMM service example code. void btstack_setup(){ ... rfcomm_init(); - rfcomm_register_service_internal(NULL, rfcomm_channel_nr, mtu); + rfcomm_register_service(NULL, rfcomm_channel_nr, mtu); } void packet_handler(uint8_t packet_type, uint8_t *packet, uint16_t size){ @@ -534,7 +534,7 @@ Listing [below](#lst:explicitFlowControl). rfcomm_init(); rfcomm_register_packet_handler(packet_handler); // reserved channel, mtu=100, 1 credit - rfcomm_register_service_with_initial_credits_internal(NULL, rfcomm_channel_nr, 100, 1); + rfcomm_register_service_with_initial_credits(NULL, rfcomm_channel_nr, 100, 1); } ~~~~ @@ -578,7 +578,7 @@ connection is used. See Listing [below](#lst:automaticFlowControl). // init RFCOMM rfcomm_init(); rfcomm_register_packet_handler(packet_handler); - rfcomm_register_service_internal(NULL, rfcomm_channel_nr, 100); + rfcomm_register_service(NULL, rfcomm_channel_nr, 100); } ~~~~ diff --git a/doc/notes/SDP.txt b/doc/notes/SDP.txt index b7b9e47a7..dba07a513 100644 --- a/doc/notes/SDP.txt +++ b/doc/notes/SDP.txt @@ -44,7 +44,7 @@ Implementation: * call handler on every element: int handle_element(uint8_t element, void *context) - done? * Dispatch packets for protocols implemented by BTdaemon * add packet_handler to l2cap_service_t and l2cap_channel_t - * pass acl/event handler to l2cap_register_service_internal + * pass acl/event handler to l2cap_register_service * copy acl/event handler to l2cap_channel_t * if specified, call custom packet_handler instead of general one * acl -> l2cap -> l2cap_channel -> acl/event handler OR daemon diff --git a/src/l2cap.c b/src/l2cap.c index c68cdb94e..e7d9162cb 100644 --- a/src/l2cap.c +++ b/src/l2cap.c @@ -756,7 +756,7 @@ uint8_t l2cap_create_channel(btstack_packet_handler_t channel_packet_handler, bd // check if hci connection is already usable hci_connection_t * conn = hci_connection_for_bd_addr_and_type(address, BD_ADDR_TYPE_CLASSIC); if (conn){ - log_info("l2cap_create_channel_internal, hci connection already exists"); + log_info("l2cap_create_channel, hci connection already exists"); l2cap_handle_connection_complete(conn->con_handle, chan); // check if remote supported fearures are already received if (conn->bonding_flags & BONDING_RECEIVED_REMOTE_FEATURES) { diff --git a/test/pts/classic_test.c b/test/pts/classic_test.c index 32936a3b5..65a3132ac 100644 --- a/test/pts/classic_test.c +++ b/test/pts/classic_test.c @@ -608,11 +608,11 @@ static int stdin_process(struct btstack_data_source *ds){ hci_send_cmd(&hci_create_connection, remote, hci_usable_acl_packet_types(), 0, 0, 0, 1); break; // printf("Creating L2CAP Connection to %s, PSM SDP\n", bd_addr_to_str(remote)); - // l2cap_create_channel_internal(NULL, packet_handler, remote, PSM_SDP, 100); + // l2cap_create_channel(packet_handler, remote, PSM_SDP, 100); // break; // case 'u': // printf("Creating L2CAP Connection to %s, PSM 3\n", bd_addr_to_str(remote)); - // l2cap_create_channel_internal(NULL, packet_handler, remote, 3, 100); + // l2cap_create_channel(packet_handler, remote, 3, 100); // break; case 'q': printf("Send L2CAP Data\n");