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.
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.infocenter.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. [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. [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? [...] Thanks again, Chris
