In BLE there are concepts of profile, service, characteristic, and description.
A profile consists of multiple services,
A Service consists of multiple characteristics,
And each characteristic has some information and descriptions
According to the official examples; (https://github.com/espressif/esp-idf/bl ... through.md and others), there is `esp_gatts_attr_db_t`, and `application id`. What it seems like the application id is meant to allow multiple "profiles" in a device. I got it.
However, what about `esp_gatts_attr_db_t`? Is this meant to represent a service? of a profile?. It seems it could be used to represent a profile since it could have multiple service handles. But is this idiomatic usage? In this case, what order does the list of `esp_gatts_attr_db_t` should be consisted of? Or should one make a list of `esp_gatts_attr_db_t` to represent "a" service, and make a list of list of `esp_gatts_attr_db_t` to represent a profile?
In this case, what is the unit that calls back should be associated with? It seems after the registration, creation, and start of services, the r/w event is dispatched based on the handles. So I guess it could be either per attribute (not likely) or per service (in case attr_db represents profile, multiple services and call back will handle all the tasks related to underlying handles.) or per application or profile?
Is an application meant to represent a profile?
I am so confused about these relationships Please enlighten me.
BLE implementation and BLE concept relation.
-
- Posts: 1708
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: BLE implementation and BLE concept relation.
As the name suggests, the "esp_gatts_attr_db_t" is the "database" of all of the device's "attributes". In BLE terminology, services, characteristics and descriptors are all "attributes".
The esp_gatts_attr_db_t is basically just the list of all the services, characteristics and descriptors your device makes available as a peripheral (plus some configuration for each of the attributes for Bluedroid to know how to handle it.)
As this is a "flat" list, the relations between services, characteristics and descriptors are determined by the order of the entries in the list: All entries (characteristics) after a service entry S (but before any other service T) are considered to be part of that service S, all descriptors after a characteristic C (but before any other service or characteristic) are considered to belong to that characteristic C.
Ex: The List [S1,C1,D1,D2,C2,D3,S2] declares two services; Service S1 with characteristics C1 and C2; C1 has descriptors D1 and D2, C2 has descriptor D3; and Service S2 with no characteristics or descriptors.
The esp_gatts_attr_db_t is basically just the list of all the services, characteristics and descriptors your device makes available as a peripheral (plus some configuration for each of the attributes for Bluedroid to know how to handle it.)
As this is a "flat" list, the relations between services, characteristics and descriptors are determined by the order of the entries in the list: All entries (characteristics) after a service entry S (but before any other service T) are considered to be part of that service S, all descriptors after a characteristic C (but before any other service or characteristic) are considered to belong to that characteristic C.
Ex: The List [S1,C1,D1,D2,C2,D3,S2] declares two services; Service S1 with characteristics C1 and C2; C1 has descriptors D1 and D2, C2 has descriptor D3; and Service S2 with no characteristics or descriptors.
Who is online
Users browsing this forum: Corand and 120 guests