Design an application with or without the SDK

[obbe]

We're developing a new device for a regulated market (medical). As such, we need to have control on what third-party software we're using, and how it is working. While starting to dig into the Bluetooth aspects of our device, I've found two routes to take.

1) Develop the application using the SDK as interface for the SoftDevice. Benefits of this is out-of-the-box experience, while the downside is another third-party library (SoftDevice already being one) that we have to manage and that we don't have full control on what the SDK actually does. We (probably) won't use the other drivers from the SDK, so we're a little worried that there will be some conflicts that may be hard to discover, particularly when it comes to timers and power management, e.g. stuff that is not application specific in the sense I2C or SPI are.

2) Code directly to the SoftDevice. Benefits of this is total control (except as stated in the SD specification) of hardware with less risk of conflicts / shared usage. Downside is the increased work that needs to be done to complement the SoftDevice, where bonding and advertising seems to be the bigger tasks.

I don't have a particular question, but rather seeking input on which route to go and if any has experience with both ways and how much extra effort it was to go with option 2. Also, I'm curious on how much using the SDK locks you in design-wise? Is there a particular design paradigm that is suggested (I've seen a little about the app timer, but haven't grasped it fully)? Anyone have experience with the SDK doing "unexpected things", or the general quality of the SDK?

Any thoughts or observations on the two routes are greatly appreciated!

[Kenneth]

I recommend to use the SDK libraries, because even though it is possible to implement bonding and database discovery yourself, you will be doing work that has already much work have been put into (and considering the actual sequence of messages may also vary depending on the peer) you may spend years before you will have all combinations covered. If you still want to pursue this you can find the message sequence charts in the softdevice specification useful:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v6.0.0/s132_msc_overview.html?cp=2_3_1_1_0_1 

 

[obbe]

Thank you for your reply! I should probably have mentioned that we control the central the peripheral will communicate with. (The SoftDevice would only be needed for peripheral) Its very application specific use of BLE; it's only intended as means to transmit data wirelessly between two devices. The communication will use a single service with two characteristic (Rx and Tx).

The link was very helpful, thanks for that! Why am getting the feeling I'm fooling my self looking at it thinking it seems pretty straightforward? Why is it it "may take years" to cover the combinations? What's more specifically taking time - coding, testing, troubleshooting, analysing...?

Edit: Also, are there any security features implemented in the SDK that should be taken into considerations? I assume the data encryption is done on SoftDevice level, but thinking of paring - is that handled in the SoftDevice or the SDK/Application? I assume that for e.g. passkey there has to be some intervention from the application side.

[Kenneth]

Especially bonding and storing and retrieving keys, identifiers and system attributes is not as straight forward as it seems. A problem could be that someone bond, and for unknown reason decide to remove the batteries shortly after because it's now bonded and should be working, so you need to be able to store away data fast. 

[robert]

I just ported my RTOS to work with nRF5 SDK. Instead of integrating my RTOS into the SDK source tree, I only collect the required source files from SDK to build a library which only contains the required BLE functions. These source files are "linked" in the library project, not copied. So, now I have two libraries, one is my RTOS and the other one is a simplified SDK library. Applications will link to these two libraries. By this approach, The source tree of application, RTOS and SDK are isolated. I can easily update SDK when Nordic release a new version.

So far, I have no intention to modify the interface code to SoftDevice. But if I want, I can copy (instead of link) the source files from SDK to the library project. And then I can modify them to be my own version. So, I can create my own SoftDevice interface by starting at the point where everything is working well.

AppTimer is easy to use, but it doesn't have the mechanism of multi-threading. So, I would recommend AppTimer only for very simple project. If your application needs to handle several tasks at the same time, it would be better to use RTOS.

Btw, I use Eclipse as the IDE.