Port pc-ble-driver application for nrf52840 dongle to run on the dongle

[brianreinhold]

If this has an answer, I did not look as one loses position if one checks.

IN any case, I have a working application running on the PC that uses the pc-ble-driver to access the sd_* methods on the nrf52840 dongle. I would like to port this application to run directly on the dongle. I do not want to use the BTLE nrf_SDK  but only the sd_* methods. This is necessary as I am using BTLE profiles that are in the standardization process and do not yet exist. In fact the new profile uses none of the currently existing BT SIG profiles and services (except the two required one). So there is no support for them.

In addition direct calls to the gatt and gap methods are much simpler. However, the more difficult part is all the spin up code and methods needed to 'boot' up dongle.

I am looking at a segger example project for the health thermometer which I could modify to implement this GHS (generic health system) service. It uses only one service and two characteristics and bonding is optionally supported. As stated I already have code for all of this running on the PC using sd_* calls.

Would it be possible to port this code to install directly on the dongle?

I should add that I have an nrf51288 DK which I could use as an SWD debugger.

I have looked at the tutorial. The important thing here is not using the BTLE nrfSDK APIs but direct calls into softdevice.

[awneil]

brianreinhold said:

one loses position if one checks

pardon?

brianreinhold said:

I have an nrf51288 DK which I could use as an SWD debugger.

It would probably be easier to work on an nRF52840-DK - which is the same target chip as the Dongle.

[Einar Thorsrud]

Hi,

I do not see why you want to avoid SDK libraries even though you may need to implement some services yourself (assuming you don't need similar code  on the PC side and nRF side). But if you want to avoid it, that is possible.

You can reuse most of your code, as the SoftDevice API is essentially the same on the pc-ble-driver as when using it directly. You would have to make adjustments though, as you are suddenly writing code for the nRF rather than a PC. I suggest starting of with a simple example project that use the SoftDevice, and copy in your code adapting as you go.

However, the more difficult part is all the spin up code and methods needed to 'boot' up dongle.

There is not much needed for this, and you can refer to any existing SoftDevice examples. I do not follow your reasoning for not using SDK modules on the SDK, and if you like you could use for instance the SoftDevice handler library. But if not, it is also not much work to do this yourself. Essentially the typical things you need to do is to initialize the SoftDevice, by calling sd_softdevice_enable(), passing the LF clock configuration and enable interrupts. Then enable BLE by calling sd_ble_enable(). If you for some reason want to do that without helper libraries you can still look at the implementation in <SDK>\components\softdevice\common\nrf_sdh.c and <SDK>\components\softdevice\common\nrf_sdh_ble.c to see how this is done. The rest should be more or less like you have done before using the pc-ble-driver.

[brianreinhold]

"One loses position if one checks" is another issue. But when you type in your question, you get a host of possible answers from the forum. The problem is if you look at one of the problems, you can't go back to that list. You have to restart from scratch and retype your question. So when I typed this question, I did not look at any more of the possible answers.

That being said, that may be an intermittent problem. Kind of like the fact the 'reply' option does not show up when you view this question. So you try several refreshes or hit a reply to another comment (if a reply option exists) and maybe the reply option finally displays for the comment you want to reply to. As I had to do here. There are lots of annoying issues with the web site which is too bad as it has a great deal of good information.

In the end this will be a test platform to illustrate a new BTLE standard for health devices. Dongles are cheap compared to DKs and its easy to give people pre-programmed dongles  or give them hex files which can then be used with the Nordic app to program on the dongle. We are not talking commercial here - we are developing a standard for health devices - one standard to cover ALL health devices..

[mrono]

brianreinhold said:

Kind of like the fact the 'reply' option does not show up when you view this question. So you try several refreshes or hit a reply to another comment (if a reply option exists) and maybe the reply option finally displays for the comment you want to reply to.

I can't help with your original issue, but I have figured out a way to make those 'reply' buttons reappear. At least on Chrome on Windows. Change taskbar settings. If the taskbar is set to auto-hide, disable that. If you have it disabled then enable it. And suddenly 'reply' options reappear on every post, I don't even need to refresh. Go figure. Wonders of web design.

[brianreinhold]

There are several reasons for not wanting to use the SDK. First, it is huge. The project is enormous with all these directories and methods that one wont use. Simplifying that would greatly help understanding and navigation. Second, there are no services or characteristics supported by the SDK that will be used. And third, it will maximize the portability of the code to other platforms. The more 'raw C' the easier to port.

Personally, I have always found it simpler to work with the basic GATT and GAP calls than to use any API surrounding them on all platforms I have worked on - especially on the central side. I guess it is because I know what GATT and GAP have to do, and every API has to be able to do those operations ... somehow. However, when the API takes that extra step of creating and configuring existing standards in an effort to be helpful one has to learn all the ins and outs of how that API works and is configured (the tedious part) which is completely different on every platform.

And yes, another reason - portability between the PC code and the on chip code. Right now I have a working GHS implementation on the PC and the lines of code is very small. It needs to support only characteristic writes, descriptor writes, and indications (and bonding/encryption). The standard is designed to be synchronous - including pairing. Reads are never done so the only reason one needs to create a database is for service discovery. No need to set readable characteristic values. The GHS uses one service and two characteristics in that service. That's it.

To start with I am looking at the thermometer example in the SDK in Segger Embedded Studio. The trickiest part as I see it is those first calls

    // Initialize.
    log_init();
    timers_init(); // This looks like it is only for the Battery service
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    advertising_init();
    services_init();
    sensor_simulator_init();
    conn_params_init();
    peer_manager_init();

    // Start execution.
    NRF_LOG_INFO("Health Thermometer example started.");
    application_timers_start();
    advertising_start(erase_bonds);

relative to the spin up calls I have on the PC. Clearly I will need the buttons to start the app; on the PC I can have a UI. So I am contrasting my PC-based spin up with that above. What I don't seem to have in my PC spin up is equivalents for 'gap_params_init() and gatt_init(). Probably because on the PC side there are defaults being used by the pc-ble-driver.

So if I work out those kinks then the next step is to connect my usb cable to my nrf51288 DK SWD debugger PIN 20 (easier to use) and connect the correct SWD pins to the dongle. (Softdevice already installed.)

I assume that the dongle will get its power from the USB connection - but here is where I am most uncertain.