This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CCCD and sd_ble_gatts_sys_attr_get

I need to remember the CCCD's of some service, e.g. service changed. A CCCD is according to spec 2 bytes long. The method to do this is by using sd_ble_gatts_sys_attr_get. This function returns a binary blob which is not documented. The amount of data returned is, depending of how many characteristics you use, huge. Somewhere around 100 bytes. I don't want to store all this information for actually 1 bit, the indication config bit of service changed. Is there information available how this data is formatted? Or do I have to reverse engineer it?

Why is it implemented like this. Why not a function in the SD which can get or set the client characteristic configuration per handle? Or combine client and server characteristic configuration. This only has to return a 32 bits value.

Yes, I know there is BLE_GATTS_SYS_ATTR_FLAG_SYS_SRVCS in SD v8 but going to SD v8 is not an option at the moment for my.

Parents
  • Hi there,

    The reason we don't allow individually setting the CCCD values is that per the spec you need to remember all of them for a bonded device. You're still allowed to get them one by one though.

    For the Service Changed user case as you already mentioned we have solved this in 8.0.0 by adding the new flags in the sys attr get and set functions.

    Carles

  • I understand what you mean. The system attributes API was designed to cover a few use cases and to future proof it when it was originally introduced, but as time goes by and use cases evolve we try to adapt our APIs to the current trends as to best fit the current batch of applications. You only really need to persist CCCDs according to spec, and that is all there is in the system attributes. The metadata is however necessary because between the time you call sys_attr_get() and sys_attr_set() the layout of the attribute table could have been modified (if you've for example reset the SD and populated the table with different attributes). Each CCCD is 16-bit, but we add a few other metadata fields that make the size of the sys attrs grow like you are now seeing. Allowing sd_ble_gatts_value_set() to set CCCD values would alleviate your problem considerably.

Reply
  • I understand what you mean. The system attributes API was designed to cover a few use cases and to future proof it when it was originally introduced, but as time goes by and use cases evolve we try to adapt our APIs to the current trends as to best fit the current batch of applications. You only really need to persist CCCDs according to spec, and that is all there is in the system attributes. The metadata is however necessary because between the time you call sys_attr_get() and sys_attr_set() the layout of the attribute table could have been modified (if you've for example reset the SD and populated the table with different attributes). Each CCCD is 16-bit, but we add a few other metadata fields that make the size of the sys attrs grow like you are now seeing. Allowing sd_ble_gatts_value_set() to set CCCD values would alleviate your problem considerably.

Children
No Data
Related