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!
