On Mon, Nov 28, 2016 at 04:33:23PM -0500, David G. Simmons wrote:
> Thanks to both of you for hugely helpful answers!
>
> Now, the last bit ...
>
> Where is the value -- or the variable, more accurately -- associated
> with a characteristic defined? So that I know which one to update. :-)
The source of the characteristic data is determined by the GATT callback
function. In English, your app defines a variable to hold the
characteristic value, and the callback retrieves this variable when the
characteristic is read. To change the value of the characteristic,
write to the source variable that the callback reads from.
Looking at bleprph's alert notification service callback:
case GATT_SVR_CHR_NEW_ALERT:
if (ctxt->op == BLE_GATT_ACCESS_OP_WRITE_CHR) {
rc = gatt_svr_chr_write(ctxt->om, 0,
sizeof gatt_svr_new_alert_val,
gatt_svr_new_alert_val,
&gatt_svr_new_alert_val_len);
return rc;
} else if (ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR) {
rc = os_mbuf_append(ctxt->om, &gatt_svr_new_alert_val,
sizeof gatt_svr_new_alert_val);
return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES;
}
This callback uses the "gatt_svr_new_alert_val" variable to hold the
"new alert" characteristic value. So, if you wanted send a notification
with the four-byte value {10,20,30,40} to to all subscribed peers, you
might do something like this (not compiled!):
/* Update characteristic value. */
gatt_svr_new_alert_val[0] = 10;
gatt_svr_new_alert_val[1] = 20;
gatt_svr_new_alert_val[2] = 30;
gatt_svr_new_alert_val[3] = 40;
gatt_svr_new_alert_val_len = 4
/* Look up characteristic handle. */
uint16_t chr_val_handle;
rc = ble_gatts_find_chr(BLE_UUID16(GATT_SVR_SVC_ALERT_UUID),
BLE_UUID16(GATT_SVR_CHR_NEW_ALERT),
NULL, &chr_val_handle);
assert(rc == 0);
ble_gatts_chr_updated();
I hope that clears things up. If not, I probably am not explaining it
well, so please don't hesitate to ask again :).
There are a few secondary issues this email raises that I should mention
for completeness:
1. Using ble_gatts_find_chr() is not the preferred way to determine a
characteristic's attribute handle. Rather, it is better to discover
this information at registration time via the "val_handle" pointer in
the characteristic definition. For an example of how this is done, see
the New Alert characteristic definition in
net/nimble/host/services/ans/src/ble_svc_ans.c.
2. The above point leads to this one: why does bleprph re-implement the
Alert Notification Service when there is already an ANS Mynewt package?!
This is my screw-up; I merged the ANS pull request without removing the
duplicate implementation from the sample apps.
Thanks,
Chris
>
> dg
>
> > On Nov 28, 2016, at 4:30 PM, Christopher Collins <ccoll...@apache.org>
> > wrote:
> >
> > As long as you specify one of the BLE_GATT_CHR_F_NOTIFY or
> > BLE_GATT_CHR_F_INDICATE flags in the characteristic definition, the
> > characteristic will be subscribable.
> >
> > When a peer subscribes to a characteristic, the stack signals this event
> > to the application via the GAP event callback associated with the peer.
> > When a peer unsubscribes, this is signalled via the same mechanism. For
> > rationale on why the GAP event callback is used here, see this email:
> > https://lists.apache.org/thread.html/8706f7914d2b716a02c25bdfc57fe942f7c7fca82446dd3523014d43@%3Cdev.mynewt.apache.org%3E
> >
> > <https://lists.apache.org/thread.html/8706f7914d2b716a02c25bdfc57fe942f7c7fca82446dd3523014d43@%3Cdev.mynewt.apache.org%3E>
> >
> > As Mike indicated, your application tells the stack that a
> > characteristic's value has changed via the ble_gatts_chr_updated()
> > function. It is up to the application to actually change the value
> > prior to calling this function.
> >
> > If you are not sure which handle is associated with a particular
> > characteristic, you can perform a lookup by
> > service-characteristic-UUID-pair using the ble_gatts_find_chr()
> > function.
>
> --
> David G. Simmons
> (919) 534-5099
> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> •
> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter
> <http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs>
> /** Message digitally signed for security and authenticity.
> * If you cannot read the PGP.sig attachment, please go to
> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
> * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/>
> **/
> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
>
> There are only 2 hard things in computer science: Cache invalidation, naming
> things, and off-by-one errors.
>
>
