Hi Chris,
> -----Original Message----- > From: Christopher Collins [mailto:[email protected]] > Sent: Friday, June 24, 2016 18:21 > To: [email protected] > Subject: Re: Re: Proposed nimble host API changes > > Hi Carles, > > Thanks for clarifying the soft device API, and sorry for misrepresenting > some aspects of it; it was certainly not intentional. It is really > helpful to hear from someone who is familiar with it. I acknowledge and > appreciate all of your comments, but I am only responding to those which > elicited follow-up questions. Sure, I'm happy that someone might be able to learn from our mistakes and shortcomings. We have had to break the API several times because of both the nature of BLE as a moving target and also some oversights that we incurred in during our initial API design. > > On Fri, Jun 24, 2016 at 11:29:17AM +0000, Cufi, Carles wrote: > > I think this is a great idea, but you should probably use the latest > SoftDevice API version 2.0.0 instead: > > > > http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocen > > ter.s132.api.v2.0.0%2Findex.html&cp=2_3_0_1_0 > > Indeed! > > [callbacks vs. queued events] > > Have you thought about a mailbox/queue mechanism of some sort to > > isolate tasks perhaps? Since, in contrast with the SD, you control the > > userspace, this would be acceptable. > > The Nimble host doesn't have a task of its own; it "piggybacks" on an > application task. I think callbacks and events both have pros and cons. > The main benefit of using callbacks in our case is that it allows for a > simple means of blocking while waiting for feedback from the application > (e.g., whether to proceed with a GATT procedure). Blocking has its own > issues, but it simplifies the code and reduces the code size. Since > nothing in the host is particularly time-critical, this was seen as an > acceptable tradeoff. That is perfectly acceptable in your case, since you essentially provide both the stack and the userspace runtime as a package. In the case of the SoftDevice things look quite differently if one wants to maintain the OS-neutral aspect of it and at the same time be able to protect the memory used by the SD from application access. The only thing that I dislike about a callback-based approach is that if your stack is single-threaded (i.e. the callback is invoked from the stack thread) and you block for authorization then things like asking the user for acknowledgement on a screen for a GATT request coming over one of the links will block all other link procedures while the user reads the prompt and responds with a Yes/No authorization reply. > > [GATT server: characteristic values] > > We sort of support both: if you enable authorization you get > > essentially the nimble approach and, if you have a constant attribute > > that is not gonna change then the app doesn't need to worry about > > incoming reads at all, which can be handy. That said, I think the > > nimble approach is more than reasonable. > > That sounds interesting. I didn't see anything about special handling > of characteristics that require authorization in the API reference. If > this is documented in the API, could you please point me in the right > direction? I am just curious how the soft device exposes this > functionality. Sure, here it is: http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v2.0.0%2Fgroup___b_l_e___g_a_t_t_s___r_e_a_d___r_e_q___a_u_t_h___m_s_c.html&cp=2_3_0_1_0_2_4_3_12 http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v2.0.0%2Fgroup___b_l_e___g_a_t_t_s___w_r_i_t_e___r_e_q___a_u_t_h___m_s_c.html&cp=2_3_0_1_0_2_4_3_19 http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v2.0.0%2Fstructble__gatts__attr__md__t.html&anchor=a0d2f2743a556d382513a43607a08c057 http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v2.0.0%2Fstructble__gatts__attr__md__t.html&anchor=affcd971025cbaa9525c2ed9ff95d913c > > [notifications] > > We have both approaches when it comes to data: you can either pass a > > NULL pointer to sd_ble_gatts_hvx() and the data that is currently > > present in the buffer will be sent, or you can pass a valid pointer > > and the stack will atomically set the data in the buffer and send the > > notification. > > OK, good to know. > > > Allowing notifications without the CCCD being set goes against the BLE > > spec and in general Nordic has always tried to enforce conformance. > > I didn't see anything in the spec prohibiting a device from sending a > notification without the CCCD being written. Do you know where this is > specified? This is my own interpretation of the spec: In Vol 3, Part G, 3.3.1.1, the characteristic properties table, "Notify" row: "If set, permits notifications of a Characteristic Value without acknowledgement using the procedure defined in Section 4.10. If set, the Client Characteristic Configuration Descriptor shall exist." I read that as "if the characteristic is notifiable, then a CCCD must exist. Then in Vol 3, Part G, 3.3.3.3: " The characteristic descriptor value is a bit field. When a bit is set, that action shall be enabled, otherwise it will not be used." I interpret that as "for notifications to be enabled the bit needs to be set". Thanks, Carles
