Use nRF5SDK examples with pc-ble-driver

[brianreinhold]

The nRF5SDK has a rich set  of examples illustrating extensive use of the BLE APIs, including full examples of the Blood Pressure profile and other health device profiles. The examples for the pc-ble-driver, by comparison, are woefully anemic. Our reasons for using the pc-ble-driver is that our test suite for health device ble centrals/clients requires interfacing to the user that cannot be sensibly loaded on the nRF5 MCU and it will require dynamic configuring at run time of numerous simulated peripherals. 

Part of the  tests will be full fledged BLE health profile peripherals which we then hoped could be downloaded and installed onto the nRF5840 without changing the source code. Let's face it, its far easier to develop and test and run apps on the PC than on an embedded platform. Thus another potential advantage of developing code using the pc-ble-driver and then build the same code for an ARM processor.Lot easier than re-writing the code.

Is this even possible? How can I use the nRF5SDK examples with the pc-ble-driver? Is there any documentation about the differences between the BLE APIs of the pc-ble-driver and those of the nRF5SDK? Its also not completely clear what is application code and what is nRF5 API  code (if any ... perhaps all C-code in the SDK is 'application' code?

[awneil]

https://devzone.nordicsemi.com/f/nordic-q-a/51245/api-usage-documentation-for-pc-ble-driver-and-pc_ble_driver_py

[brianreinhold]

I am well aware of that. But that does not help me when trying to use the examples in the HUGE nRF5SDK package. I don't even know if it can be done, but there is a plethora of examples in the nRF5SDK compared to the two in the pc-ble-driver!

[awneil]

the main point being this reply:

Einar Thorsrud said:

The API is essentially the same as you get from the underlying SoftDevice

that being the API that the SDK examples use.

And the links for Serialisation explain how it all works.

brianreinhold said:

there is a plethora of examples in the nRF5SDK compared to the two in the pc-ble-driver!

That's understandable: Nordic's business is selling chips,not developing PC apps - so the focus is very much on facilitating the embedded side.

[brianreinhold]

I can understand the business model; but there is something to be said for ease of development - write, run, and test code on PC. Then when it all works, port to the embedded platform. Renesas did this and it was really fast to make embedded apps. The problem Renesas had was with their BLE.

I kind of assumed that was one of the main motivations behind supporting the serialization library...

[Einar Thorsrud]

Hi,

I have heard about other customers doing something like this, bu tit is not the main motivation for serialization from Nordic's side. The main motivations are:

• Serialization firmware running on the nRF chip can be used when the nRF is used as a BLE connectivity chip for another host MCU.
• The pc-ble-driver is a PC side companion that can be used with serialization for:
  • Nordics developed Test tools (such as nRF Connect BLE)
  • Customer test tools or other applications (such as for instance your use case).

Regarding the original questions, the pc-ble-driver is just a host-side implementation of the SoftDevice API. We do not provide anything similar to the nRF5 SDK for any other platform then the nRF itself (so no PC side equivalent).

[brianreinhold]

I assume that everything I could do with the nRFSDK (ble-wise) I can do with the pc-ble-driver. Its just that the nRFSDK has a large set of helpers ( all the C-code is some type of helper; making calls into 'SoftDevice').

[Einar Thorsrud]

Hi,

Yes, you are correct. You can do everything, but you would have to port or implement all the higher-level functionality that is provided by the SDK yourself since pc-ble-driver only provides access to the SoftDevice API. So things like implementations for BLE service, bond management, etc. are missing.

[brianreinhold]

Thanks. I need the BLE functionality, the other things I know how to do (or at least have dome them on other platforms). So this is good (and the SDK is always a good source of references as to HOW to make the ble calls, because I do not know the SoftDevice APIs and how they work).