I don't understand the uuid parameter used in the service definition of the peripheral sample #28541
-
Hi, I am trying to understand bluetooth custom service definition, so I have been exploring the peripheral sample code. There is one use of the uuid parameter I cannot understand and it would be great if someone could explain what is going on. /* Vendor Primary Service Declaration */
BT_GATT_SERVICE_DEFINE(vnd_svc,
BT_GATT_PRIMARY_SERVICE(&vnd_uuid),
BT_GATT_CHARACTERISTIC(&vnd_enc_uuid.uuid,
BT_GATT_CHRC_READ | BT_GATT_CHRC_WRITE |
BT_GATT_CHRC_INDICATE,
BT_GATT_PERM_READ_ENCRYPT |
BT_GATT_PERM_WRITE_ENCRYPT,
read_vnd, write_vnd, vnd_value), I cannot understand why &vnd_enc_uuid.uuid is used in BT_GATT_CHARACTERISTIC rather than &vnd_enc_uuid.val. As far as I can tell vnd_enc_uuid is initalised with the BT_UUID_INIT_128 macro which seems to define .uuid as the enum BT_UUID_TYPE_128. It does seem odd that .uuid isn't the actual UUID but seems to be a UUID type (i.e. 128bit in this case). But if the sample works as expected ( I haven't actually tried it on hardware) then I must not be understanding this properly because with my current understanding this shouldn't work. Any insight would be much appreciated. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
In case anyone else is confused by this, I think I understand now. &vnd_enc_uuid.uuid is correct. Even though using .val compiles and runs and allows connection to the service, the service UUID will be wrong. It appears that UUIDs are defined as an incomplete type in order to allow something like polymorphism across the different UUID types. The type field identifying the concrete type of the structure pointed too. That is probably very obvious to those with decent experience with c (which I don't have). The fact the incorrect approach compiles and runs fine didn't help!! |
Beta Was this translation helpful? Give feedback.
In case anyone else is confused by this, I think I understand now.
&vnd_enc_uuid.uuid is correct.
Even though using .val compiles and runs and allows connection to the service, the service UUID will be wrong.
It appears that UUIDs are defined as an incomplete type in order to allow something like polymorphism across the different UUID types. The type field identifying the concrete type of the structure pointed too.
That is probably very obvious to those with decent experience with c (which I don't have).
The fact the incorrect approach compiles and runs fine didn't help!!