Use BLE driver and stack outside nRF Connect SDK

[Georgi Valkov]

I created a new RTOS called nano RTOS. I would like to add support for the BLE hardware in nRF52840.

How are the BLE driver and stack organised in the build system? My goal would be to find all related files, and copy them outside the SDK. Then I can provide all the necessary API which Zephyr provides and build a library using arm-none-eabi-gcc and make. What is the entry point to initialise BLE?

Any help would be very helpful. Thanks in advance!

[Edvin]

Hello,

This is far from a trivial question, and unfortunately not something that I can assist a lot with. But I can tell you what I know. 

I see that you are talking about Zephyr, but I think I should mention that it is a lot harder to pull out the softdevice controller (Bluetooth Low Energy Stack) from NCS/Zephyr, to use as a standalone component, than it is to use the SoftDevice from our non-Zephyr nRF5 SDK. The reason is that the softdevice from nRF5 SDK is a standalone .hex file, with some header files, where the SoftDevice Controller from NCS is a lot more nested into the nRF Connect SDK. That being said, in theory, it is possible to try to hack into the HCI layer (Host Controller Interface), which is more or less a standard Bluetooth interface, used by e.g. Bluetooth Dongles for computers. 

For the nRF5 SDK, the softdevice is located in SDK\components\softdevice\s140\hex\, and it is a standalone .hex file. In that SDK, most examples are "bare metal" approaches, but there are also some freertos examples that use the SoftDevice. If you are familliar with FreeRTOS, perhaps you can even use that as inspiration on how to integrate the SoftDevice into your own RTOS. 

Best regards,

Edvin

[Georgi Valkov]

Edvin 

Hello Edvin and thank you very much for this important clue. I finally found time and it's been a wild ride during the past two months, but I got it working under nanoRTOS and it works well. I integrated it as a preboot UART driver which can be attached to stdin/stdout for use with printf, read and write. I made a simple 3-way bridge app. Performance, latency and power consumption are better than the Connectivity Bridge from NCS/Zephyr. But when it comes to complexity, the difference is night and day: each task reads one stream and writes the other two. Three lines of code guaranteed to never drop any data. As simple as using synchronous API, yet with the performance of background simultaneous read and write.

I understand that Nordic's primary focus is Zephyr, yet I wonder if Nordic would be interested to look into my work? There are some fresh ideas to greatly speed-up project development.
I can share some samples if you or any of your colleagues show interest: BLE-UART bridge for nRF52840dk, nRF9160dk, Thingy:91 and also the Thingy sensors.

Cheers!

[Edvin]

Thank you for the update!

I am glad to hear that you got it working! What did you end up using? Did you base it off the nRF5 SDK? Or did you manage to pull out the softdevice controller from NCS? And how about support for LTE on the nRF91 parts? Did you manage to use that from NCS without using Zephyr?

Best regards,

Edvin

[Georgi Valkov]

Hi Edvin,

I used SoftDevice and sources from nRF5 SDK. `examples/ble_peripheral/ble_app_uart` is a good starting point. I wrote an article about the Integration of Nordic SoftDevice into a BLE UART driver for nanoRTOS.
https://nanortos.com/nordic/softdevice.md?view

I haven't tried to pull the SoftDevice controller from NCS, not yet. But I will be more than happy to do it. Especially if you can find someone from Nordic to assist. The same applies to LTE on nRF91. nanoRTOS already has support for nRF52840 and nRF9160, with BLE UART, UART, SPI, I2C, I2S, FLASH, GPIO, RTC, TIMER and all Thingy:91 sensors. You can find more info and sample apps from this link:
https://nanortos.com/nordic/