Use BLE driver and stack outside nRF Connect SDK

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!

Parents
  • 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

  •  

    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!

  • Thank you for the update! Slight smile

    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

Reply Children
Related