Bluetooth driver and Profile

I took a look at the Bluetooth protocol document yesterday. Today, I simply checked the code in the kernel (bluez). Here I take some notes, but I still inherited the old problem. I only paid attention to the overall process and ignored the details, first, let's take a look at it and analyze it carefully when necessary.

Net/hci_core.c

The driver of HCI on the host is mainly to provide a unified interface for the upper layer, so that the upper layer protocol does not depend on the implementation of specific hardware. The firmware of HCI in the hardware communicates with the driver of HCI on the host, such as UART, USB, and PC Card. Hci_core.c is equivalent to a framework used to bond various communication methods and provide implementation of some common functions.

Hci_cmd_task is the task responsible for sending cmd. It obtains cmd from the hdev-> cmd_q queue and then calls hci_send_frame to send cmd, hci_send_frame then calls the actual HCI-driven send function to send data.

Hci_rx_task is a task that receives data. It retrieves data from the hdev-> rx_q queue and then calls the upper-layer function for processing based on the data type. There are three types of data packets:

1. hci_event_pkt: used to handle communication events, such as connection establishment, connection disconnection, authentication, and encryption events. These events control protocol status changes.
2. hci_acldata_pkt: asynchronous non-connected data packet, which is submitted to the upper layer through hci_acldata_packet for L2CAP processing (hci_proto [hci_proto_l2cap]).
3. hci_scodata_pkt: synchronizes connection-oriented data packets and provides SCO protocol processing (hci_proto [hci_proto_sco]) to the upper layer through hci_scodata_packet.

Hci_tx_task is the task responsible for sending data, sending all the ACL and SCO data in the connection, as well as data packets in hdev-> raw_q.

HCI provides the following interfaces for the upper layer:

1. hci_send_sco: Send SCO data packets, put the data packets to be sent into the connection sending queue, and schedule the sending task to send the data packets.
2. hci_send_acl: Send an ACL packet, put the packet to be sent into the connection sending queue, and schedule the sending task to send the packet.
3. hci_send_cmd: send command data, put the data packet to be sent into the hdev-> pai_q queue, and then dispatch the command to send the task.
4. hci_register_proto/hci_unregister_proto: Register/cancel the upper-layer protocol. HCI forwards the received data to these upper-layer protocols.
5. hci_register_dev/hci_unregister_dev: Register/deregister the device. HCI will send the data to be sent through these devices.
6. Other common functions.

Net/hci_conn.c
Provides some connection management, demonstration and encryption functions.

Net/hci_event.c
Event Handlers are responsible for maintaining state machines. These events usually convert connections from one state to another.

1. hci_si_event: used to send events.
2. hci_event_packet: used to handle underlying reported events and called from hci_rx_task.

Net/hci_sock.c
A socket interface is provided for the upper layer. Applications can access HCI through socket.

1. The btproto_hci family is registered in hci_sock_init.
2. hci_sock_create: Create a sock function. Its sock ops points to hci_sock_ops.
3. hci_sock_setsockopt/hci_sock_getsockopt: Set/obtain some sock options.
4. hci_sock_sendmsg: Send a message and place the message in the appropriate Queue according to the Message type.
5. hci_sock_recvmsg: receives a message and obtains the message from the receiving queue.
6. hci_sock_recvmsg: ioctl function.

Net/hci_sysfs.c
Provides some sysfs file system interfaces.

Net/L2CAP. c
L2CAP is a protocol over HCI that provides functions such as QoS, grouping, multiplexing, segmentation, and assembly.

Bt_sock_register provides a sock interface for the upper layer:

1. l2cap_sock_create: Create a sock function. Its sock ops points to l2cap_sock_ops.
2. l2cap_sock_setsockopt/l2cap_sock_getsockopt set/obtain some sock options.
3. l2cap_sock_sendmsg: sends a message. The hci_send_acl function is provided by HCI to transmit the message to the underlying device.
4. bt_sock_recvmsg: receives a message and obtains the message from the receiving queue.

Use hci_register_proto to register the HCI protocol with it:

1. l2cap_connect_ind: Processes connection requests.
2. l2cap_connect_cfm: confirm the connection.
3. l2cap_disconn: process the disconnection request.
4. l2cap_auth_cfm: authentication confirmation.
5. l2cap_encrypt_cfm: Confirm encryption.
6. l2cap_recv_acldata: process data from HCI.

Net/sco. c
SCO is also a protocol running on HCI. It is a reliable connection-oriented transmission mode and is mainly used for audio data transmission.

Bt_sock_register provides a sock interface for the upper layer:

1. sco_sock_create: Create a sock function. Its sock ops points to sco_sock_ops.
2. sco_sock_setsockopt/sco_sock_getsockopt sets/gets some sock options.
3. sco_sock_sendmsg: sends a message. The sco_send_frame function is provided by HCI to transmit the message to the lower-layer device.
4. bt_sock_recvmsg: receives a message and obtains the message from the receiving queue.

Use hci_register_proto to register the HCI protocol with it:

1. sco_connect_ind: process connection requests.
2. sco_connect_cfm: confirm the connection.
3. sco_disconn_ind: process the disconnection request.
4. sco_recv_scodata: process data from HCI.

RFCOMM /*
RFCOMM is a protocol based on L2CAP. It encapsulates the traditional RS232 serial port over the Bluetooth protocol.

Drivers/Bluetooth
We have introduced the HCI and its upper-layer protocols. The implementation of the lower-layer HCI is the HCI driver. These drivers are used to communicate with Bluetooth hardware. Commonly used communication methods include USB, UART and PC Card. Here we will look at the USB method:

Drivers/Bluetooth/hci_usb.c

1. hci_usb_probe: Call hci_register_dev to register the hci_core HCI device.
2. hci_usb_send_frame: used to send data packets to HCI. It puts data packets in the transmission queue _ transmit_q (husb, bt_cb (SKB)-> pkt_type), and then calls hci_usb_tx_process to transmit data.
3. hci_usb_tx_process: Call hci_usb_send_ctrl/hci_usb_send_isoc/hci_usb_send_bulk Based on the Data Type to send the data to the hardware through USB.

 

 

Some time ago, I implemented three profiles: HID, dun, and SPP. In the next step, I implemented profiles such as OPP and FTP. The specific development is actually simple. I am implementing the relevant profile with reference to the a2dp code.

The implementation of Android handset/handfree is significantly different from that of a2dp/avrcp,Handset/handfree is developed directly on the RFCOMM socket of bluez, without the use of bluez's audio plugin, while a2dp/avrcp is developed based on bluez's audio plugin, therefore, the implementation difficulty is greatly reduced.. In fact, the audio plugin of bluez also has handset/handfree implementation, but I don't know why Google didn't use it. Instead, I need to implement one on RFCOMM socket, this makes the implementation of handset/handfree complex.

Hid uses bluez's input plugin, Android has compiled it into, in system/lib/bluez-plugin/input. so, and input. so together with audio. so library, which is used for a2dp/avrcp. For more information, see frameworks/base/CORE/JNI/android_server_jwtha2dpservice.cpp. CPP file, which uses callback to call input like a2dp. so library createdevice/connect/disconnect and other functions, the specific source code in external/bluez/utils/input/manager. C and external/bluez/utils/input/device. c. After that, refer to frameworks/base/CORE/Java/Android/Server/javastha2dpservice. java and frameworks/base/CORE/Java/Android/Bluetooth/javastha2dp. java and frameworks/base/CORE/Java/Android/Bluetooth/iblustmtha2dp. aidl: Write two Java classes and aidl interfaces respectively. The rest is the modification of each file in the packages/apps/settings/src/COM/Android/settings/Bluetooth directory, the easy way is to search for a2dp, as long as it is the place where a2dp is to be modified.

Dun/spp uses bluez's serial plugin. Because Android is not compiled in, you need to write an android file in the external/bluez/utils/serial directory. MK, compile it to generate system/lib/bluez-plugin/serial. so library, others are similar to hid.