Any reason to support older library versions?

[brianreinhold]

This maybe a stupid question but is there any reason to include support for older versions of the SDKs? I am using the pc-ble-driver approach and the example is full of if-defs on the version. If one does NOT have to worry about backward  compatibility (this is a brand new start and first time use of Nordic products) should I just use the latest version (6 as of this time)? My concern is that the latest version may not work with some older versions/platforms of Android or other existing BLE peers.

[Edvin]

Hello,

No, as you say, this is for backward compatibility. 

I don't see any reason not to start with the latest API version. It is the softdevice (the Bluetooth Low Energy stack) that handles all BLE things. I would say that it is safer to use the latest version. Everything in BLE should be backwards compatible, so it is no risk that something shouldn't work with older versions. 

[brianreinhold]

OKay thanks. I will go with that. Now along those lines I just built and ran the pc-ble-driver demo heart rate monitor on the nRF52840 dongle from a PC-application. I downloaded the nrf5 SDK and that has several examples. I grabbed the BloodPressure example and tried to build that. However, the set of include files is entirely different than that of the pc-ble-driver. I thought the idea of the driver was that you could build an application that runs on the PC that accesses the BLE functionality through the serial port. But I guess not. The API appears to be completely different.

I even replaced the h-files in the example with those in the driver. No better. That means I can never migrate my app onto the dongle should I so desire; the entire source code would have to be re-written.

Am I doing something wrong? Otherwise its a major misunderstanding on my part and a HUGE disappointment. I feel I must be doing something wrong as to create two different APIs makes no sense...

[Edvin]

The API is similar (if not identical), but the SDK structure vs the pc-ble-driver structure is different. So it is possible to use some libraries, but they are not directly plug in compatible. Remember that the 2 systems (SDK and pc-ble-driver) use different languages, C and C++. 

In addition, the transport layer is different on the serialized example in the SDK and the pc-ble-driver, because it is a transport layer between computer -> USB -> DK instead of "other microcontroller -> UART -> DK.

I don't think this really answered your question, but the point is that the softdevice api, that is, all the function calls starting with "sd_" should be similar, but they are not equal. In general, there are more sd_ calls in pc-ble-driver, because you have an API to setting up and maintaining the adapter.

But I believe most of the API from the SDK is similar, except that they also take in a handle to the adapter. 

[brianreinhold]

I saw things like ieee_float16_t which had no matching definition for in the h-files defined for pc-ble-driver. That is one I can solve myself since I know what that is but there are countless others. I guess the big question is are there things that one cannot do in the pc-ble-driver APIs that are used in these nRF5SDK examples? 

I worked on a Renesas BLE chip where there was a serial port as well and the great convenience was that one could develop and run the code on the PC (easy) and then migrate the code to the MTU. But there were ble issues on the chip.

Also, the examples I have in both cases are both written in C.

[Edvin]

Where did you find the ieee_float16_t missing definition? That is, where in the project was ieee_float16_t used?

 

brianreinhold said:

I worked on a Renesas BLE chip where there was a serial port as well and the great convenience was that one could develop and run the code on the PC (easy) and then migrate the code to the MTU. But there were ble issues on the chip.

 This sounds like something called a HCI application running on the ble chip on the serial port. 

HCI stands for Host Controller Interface. This is a bluetooth standarized serial port interface, and this is not what the pc-ble-driver uses. The HCI layer is hidden away in the softdevice, and it is not accessible. If that is what you want to use, then Zephyr has a project for the nRF series, but it is not maintained and supported by us. Please check out Zephyr's homepage if that is what you are looking for. 

[brianreinhold]

No it is not. It was not an HCI; it was an interface that allowed you to access the BLE methods from any mcu like you were on the chip itself. So you could develop, run, and test your app on a PC then take that code and compile it for another mcu.

IN any case, I do not want an HCI; the BLE GAP and GATT levels are exactly what I want.