ESP32 Forum

When implementing a GATT server, the current handling of GATT read events seems rather convoluted and inefficient to me. In my understanding of Bluetooth LE, the value of a GATT characteristic is a value stored in the server. It only needs to change when the underlying data changes (e.g. a sensor value, status, etc.).

Currently, when a GATT client reads a characteristic, on the ESP32 GATT server, an ESP_GATTS_READ_EVT is propagated to the event handler. For the client to actually receive the characteristic value, the server needs to call esp_ble_gatts_send_response every time, even when the value did not change since the last read request.

I think an approach where the ESP API (or maybe even bluedroid already does?) provides a database for the GATT server, into which the current characteristic value is written to and read from. E.g. when the server wants to update a characteristic value, it can just call something like esp_ble_gatts_characteristic_value_update with a handle identifying the characteristic and connection and the updated value. Subsequent requests will then read the value that was last stored to the database.

In combination with the current handling of write and notify, the way read works is really odd: When a characteristic has read, write and notify permissions and notifications are enabled on the characteristic value, when the client issues a write, the written value will immediately be notified (makes sense), but an immediate subsequent read could return whatever value is being written using esp_ble_gatts_send_response.

The need to explicitly and manually send a response to a write request seems unnecessary as well, but maybe I just don't see the use case in that.

I would be really happy, if you would implement a proper characteristic data base and remove the need to explicitly send a response to read and write requests! I think having a look how e.g. the API of a Nordic Softdevice BLE stack looks may give some good ideas

Thank you for listening

Small addendum: After calling esp_ble_gatts_characteristic_value_update, further down the stack, in the consecutive functions that transfer the data from the ESP API to the underlying bluedroid stack, the function btc_to_bta_response will be called and will copy THE COMPLETE MAXIMUM supported length of 600 bytes of characteristic value to the structure to be relayed to BTA, even when the characteristic is merely 1 byte in length! The same thing seems to be done further down the stack... Seems a bit over the top to me?

I actually think we have a feature like the one you describe planned for esp-idf 2.0. It should appear in the master branch pretty soon.

That is great news to hear!

michaelwgnr wrote:Small addendum: After calling esp_ble_gatts_characteristic_value_update, further down the stack, in the consecutive functions that transfer the data from the ESP API to the underlying bluedroid stack, the function btc_to_bta_response will be called and will copy THE COMPLETE MAXIMUM supported length of 600 bytes of characteristic value to the structure to be relayed to BTA, even when the characteristic is merely 1 byte in length! The same thing seems to be done further down the stack... Seems a bit over the top to me?

I have not looked at the code as in depth as you but it does seem like there is a lot of value passing of buffer data between a bunch of handler lookup functions.

WiFive wrote:it does seem like there is a lot of value passing of buffer data between a bunch of handler lookup functions.

Yes, that is true. From what I gather, part of the btc subsystem decouples all the ESP API calls from the rest of the bluetooth stack but doesn't do much further.
So, for example when calling esp_ble_gatts_send_response, the whole esp_gatt_rsp_t structure (including the 600 byte characteristic length maximum) is copied and transferred to the btc_task. In there, the whole esp_gatt_rsp_t is copied into a tBTA_GATTS_RSP structure, which is required by the API for BTA_GATTS_SendRsp, wherein another buffer of the same type is allocated and the whole contents are copied and transferred to the btu_task. In that task, another GATT server event handler is called. Somewhere within that task, the whole buffer is copied again! (Here I'm not exactly sure anymore what exactly happens - depends on the exact GATT request sent by the client) Now, I'm not sure what happens further, the data is now pointed to from a tGATT_TCB structure which is associated with the current connection. Somehow the whole data is passed to the L2CAP layer and eventually to the controller... (I still don't work with a debugger, so I can't trace it )

So there are at least four memcpy's of the whole data buffer, each one copying more than 600 bytes, even if the characteristic value only has a length of one byte! To me, it looks like there is still a lot of work to be done on the BLE/Bluetooth stack... That is part of the reason why I asked in another thread, whether there is a roadmap laying out Espressifs future plans for BLE / Bluetooth on the ESP32.

TBH, the ESP32 looks really promising, but there are so many question marks concerning the BLE part of the SDK, that I really wonder at what point it is viable to really start working with it. Being used to the Nordic SDK, I'm probably a bit jaded, though... and I almost feel like a spammer with all the BLE posts I write here

michaelwgnr wrote:... and I almost feel like a spammer with all the BLE posts I write here

I appreciate you

It was a bit surprising to me that bluedroid was picked but I guess the other open source options like the Intel stack in zephyr and apache nimble stack are still developing.

WiFive wrote:

michaelwgnr wrote:... and I almost feel like a spammer with all the BLE posts I write here

I appreciate you

It was a bit surprising to me that bluedroid was picked but I guess the other open source options like the Intel stack in zephyr and apache nimble stack are still developing.

Thanks.

I don't know what options there are for open source bluetooth stacks. I'm sure that bluedroid can be trimmed down to embedded needs somehow. What I feel is very odd, though, is the fact that the ESP API on top of Broadcomm's Bluetooth Application Layer (BTA) adds quite a bit of overhead and - from what I see - mostly just passes the input to the corresponding BTA functions.

I'm sure they have their reasons, but with the current lack of documentation and explanations, it's just hard to figure out why it is done like that and where this whole thing is headed to...