After we complete the connection between ESP32 and blufi, that is, after completing the settings of the service (0xffff) and features (0xff01, 0xff02), we will start to interact (if you don’t understand, you can read the previous article).
The editor does not have a deep understanding of the Bluetooth protocol stack, and there may be more ways to solve this problem. Here I am just sharing some of my little pitfall experiences.
For the gatt interaction of ESP32, the received messages are actually processed by the unified ESP_GATTS_WRITE_EVT event interface, so we can directly get the final data and then process the data. Our main concern is how to send it. So we searched for the interface and found that there were many sending interfaces and we had no idea where to start.
Faced with so many sending interfaces, it is difficult for us to start, and then we go online to find solutions. Found these methods
- ESP32 development journey Bluetooth article - BLE (GATT), modify the device name, add characteristic, send data, receive data_esp_ble_gatts_set_attr_value-CSDN Blog
- ESP32 study notes (30) - BLE GATT server custom services and features_ble_svc_gatt_handler_Leung_ManWah's blog-CSDN blog
- ESP32-C3 learning and testing Bluetooth (7. GATT data communication - sending custom data)_esp-at implements gatt communication-CSDN blog
After reading these articles, I found that the big guys all have different opinions. Then I copied them one by one but failed to achieve the desired results.
At this time, I summarized my findings: My purpose is to send messages to the device from the mobile phone and the device to reply. However, the method mentioned by the big guys is that the mobile phone actively reads it, so it conflicts with my function. So I no longer put the reporting function in the ESP_GATTS_READ_EVT callback event, but instead put the function interface that needs to be forwarded in the ESP_GATTS_WRITE_EVT event, and reply after processing the data. At this time, it’s time for trial and error again, and several functions are put in for testing one after another. Finally, without reporting an error, I found the function interface esp_ble_gatts_send_indicate that can successfully report data without reporting an error. So the function interface was determined.
At this time, we used it to communicate with bluFi, but found that it still didn't work. The communication is open, and I can send and receive, but I still can't communicate. What should I do? We found the blufi demo and used the Bluetooth assistant to debug and compare.
After comparison, it turned out that we had one more report at the beginning. However, after studying the content of the reported message, I found that reporting this message at this location will not affect communication. But since we couldn't find any other way to solve this problem, we decided to give it a try, and we didn't expect it. (If anyone finds the reason, please post it for discussion)
At this point the communication is complete and the ACK is returned correctly, but we just got lucky and got to this point. Let’s look back at Espressif’s official documents:
At this point we found that as a device, we need to use FF01 as the receiver and FF02 as the sender. How to determine ff01 or ff02? We still need to analyze the function interface.
How to check the parameters and how to use them? Just copy them.
esp_ble_gatts_send_indicate ( gatts_if , param -> write . conn_id , gl_profile_tab [ PROFILE_A_APP_ID ]. char_handle , //Send instructions or notifications to the GATT client.
sizeof ( notify_data ), notify_data , true ); // Whether confirmation is required. false means no confirmation is required
From the above code, we can see that the last parameter is whether a reply is needed. It seems invalid for blufi, so we just fill in a false value. The next two characters are the data and data size. We can fill in the data we need. The remaining three parameters are difficult to determine. gatts_if: GATT server access interface is the server access interface and is associated with the service. Because each service corresponds to the same callback function, we do not need to modify gatts_if in a function. Next is the connection id: param -> write . conn_id . Each connection will establish a connection id, so we just plug the received connection id back. There is one last parameter left, which is the most important one: attr_handle attribute handle. This attribute handle is related to FF01 and FF02. If we only use one service, we will use that service to complete sending and receiving, so we will return the message sent to which one, so we can fill in: param - > write . handle . However, this obviously does not meet our needs, because we received the handle message of FF01 and we need to reply to ff02. At this time, we thought that the handle of FF02 was also written by us, so it was easier to determine. Because ff02 is defined after ff01, the char_handle in the array is the attribute handle of FF02 at this moment, which is much easier to handle, gl_profile_tab [ PROFILE_A_APP_ID] .char_handle . (Other attribute replies are also set according to this method).
So how do we make sure that the attributes we send are indeed successful? We only need to limit the ability of the attribute characteristic value, that is, let it only support reading or writing. In this case, an error will be reported if the wrong handle is written.
At this point, the interaction design of blufi and gatts services DEMO is completed.