Hi Chris, One quick clarification question: after receiving a callback with any error status, do you guarantee that the callback will never be called again (including with a NULL svc param)?
On Mon, Jun 20, 2016 at 3:17 PM, chris collins <ch...@runtime.io> wrote: > I agree it would be better to pass a status of BLE_HS_EDONE rather than 0 > in this case. I will include this in the list of API-breaking changes that > I think should be made to the Nimble host. > > Thanks, > Chris > > On Mon, Jun 20, 2016 at 3:06 PM, Simon Ratner <si...@proxy.co> wrote: > > > Oh, interesting. It hadn't occurred to me to check that svc pointer is > > non-NULL. I assumed from the callback function signature that absence of > > error implies that the remainder of params hold valid data (this seems to > > be a common standard for callbacks, at least in my experience). Of > course, > > deref of NULL doesn't fail on hardware without memory protection :) > > > > Thanks for clarifying. > > > > > > On Mon, Jun 20, 2016 at 2:51 PM, chris collins <ch...@runtime.io> wrote: > > > > > Hi Simon, > > > > > > Yes, you are correct - the second callback indicates that the discovery > > > operation is complete. You can determine that the procedure has > > > successfully completed by checking the following: > > > > > > * rc == 0 > > > * service pointer is null > > > > > > If your callback only gets executed once, and the parameters are as > > defined > > > above, that means the peer device does not support the service you are > > > interested in. > > > > > > The reason for this somewhat awkward interface is that a device is > > allowed > > > to support two different services with the same UUID. To resolve this > > > ambiguity, the callback gets executed with special values indicating > > > discovery is complete. > > > > > > By the way - I hadn't noticed that jira ticket you filed a few days > ago. > > > Sorry about that. I will close it with the above explanation shortly. > > > > > > On Mon, Jun 20, 2016 at 2:34 PM, Simon Ratner <si...@proxy.co> wrote: > > > > > > > Actually I think I just realised that might be what the mystery > second > > > > callback in https://issues.apache.org/jira/browse/MYNEWT-326 is. Is > > that > > > > actually the "done" callback that just fails to set the error param > > > > correctly? > > > > > > > > > > > > > > > > On Mon, Jun 20, 2016 at 2:32 PM, Simon Ratner <si...@proxy.co> > wrote: > > > > > > > > > Hi devs, > > > > > > > > > > It appear that when I call ble_gattc_disc_svc_by_uuid with a > service > > id > > > > > that the device does not implement, I don't get any indication that > > is > > > > the > > > > > case. No callback, no error, just sits there holding up the > > connection > > > > > resources. > > > > > > > > > > Same deal with ble_gattc_read_by_uuid. > > > > > > > > > > I would've expected a callback with an error value, or some other > > > > > indication discovery was completed but the requested > > service/attribute > > > > > wasn't found. > > > > > > > > > > > > > > >
