This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Using softdevice directly without SDK libraries

I'm trying to update my project to use the latest S110 softdevice release. The trouble is that I have written many of my own hardware abstraction layers and they are conflicting with the hardware abstraction layers that have been introduced in the later SDK release. I'm finding it very difficult to resolve these conflicts, as the BLE_Modules in the SDK libraries have dependencies on the nRF_Drivers modules. If I want to use my own hardware abstraction layers, then I can't use any of the BLE_Modules libraries in my project. To be honest, I don't really have a good understanding of what these BLE_Modules libraries actually do.

I am considering not using any of the SDK libraries and instead interfacing directly with the softdevice. Before I head down this path, I was wondering if anyone else is doing the same and was it difficult? Does it require an in-depth understanding of the different layers of the BLE stack (GATT, GAP, L2CAP, etc)?

Parents
  • You can absolutely do it - I do it. What you may lose is some of the higher level abstraction modules like the bond manager and the advertising manager. Some of them only use a couple of the HAL components, like pstorage and timers so you may still be able to use them. I have my own timer implementation which stops me using many of them at all.

    You will need to know more about BLE if say you write your own device manager, that deals with bonding and persistence of bonded data etc.

    If you're just talking about the real hardware drivers, TWI, SPI, UART etc, none of those are really used in the BLE modules, so you can use your own very easily.

Reply
  • You can absolutely do it - I do it. What you may lose is some of the higher level abstraction modules like the bond manager and the advertising manager. Some of them only use a couple of the HAL components, like pstorage and timers so you may still be able to use them. I have my own timer implementation which stops me using many of them at all.

    You will need to know more about BLE if say you write your own device manager, that deals with bonding and persistence of bonded data etc.

    If you're just talking about the real hardware drivers, TWI, SPI, UART etc, none of those are really used in the BLE modules, so you can use your own very easily.

Children
  • Thanks for the response. I am also using my own app_timer module. The SDK app_timer module was hogging RTC1 and I needed to use it for multiple purposes. But I kept the .h (API) the same, so that the SDK modules can use my app_timer implementation. Not ideal, but that worked. The problem I am having now is that I created my own HAL for the GPIOTE.

Related