Using nRF SDK with S112 and BitFields only?

[FI]

Hello,

I would like to get some input on general framework options for development.

I am starting by strictly following the SDK framework, trying to use its drivers, translations, configs and so on. But found there is some learning curve, the configs are quite comprehensive, and I am not handling Legacy -> NRFX translation well yet.

The end App will have BLE peripheral function, so it needs S112.

I prefer to think and work with Register and BitFields and bounded references to Spec sheet and Errata, and wonder whether the SDK or Softdevice framework would encourage and support such use, bypassing the middle layers and config framework.

Please feel free to advise.  Thanks

[Einar Thorsrud]

Hi,

I would like to advise against using registers directly since that would essentially mean that you would duplicate work that we have already done for you. In most cases, it will increase the amount of work, and decrease the quality of the end application, since we have put a lot of effort into testing and verifying the SDK drivers and libraries.

That said, there is nothing preventing you from using the SoftDevice API's only, and implementing the rest yourself. In that case, you can use the MDK files from the SDK, or use the MDK distribution separately. This has register definitions, startup file, etc, but no drivers or libraries etc.

[FI]

Hello Einar,

Thanks for your reply. Doing feasibility and evaluating options and want to further confirm,

1) the SD does not have any dependencies on the drivers and data structures/defines in both legacy and nrfx, and sdk_config

2) BLE functionalities are all inclusive in the SD and

3) All data structures and macros for SD BLE integration are included in the /component/ble/ directory

4) core and peripheral can be done with Reg and BitField through HAL and MDK and standard interrupt vector tables.

Currently still exclusively using drivers, though can't help to do something like NRF_ADDR->REG etc in reference to only HW data sheet (it is quick), then I understand this defeat the disciplines governed by the sdk_config and the driver framework, so plan not to mix and stick with a selected approach.

Is there also a consolidated document for SD (or even the drivers/modules, e.g app_timer) on required/reserved HW resource (matrix)? That is super useful for early stage resource and architecture planning, derisking, making sure correct assumptions can be made to speed up a board build while FW is rolling in pipeline.

Thanks

[Einar Thorsrud]

Hi,

I saw your later post, and it seems very sensible to me. I will answer the questions in the previous post anyway, in case it is useful for someone.

FI said:

1) the SD does not have any dependencies on the drivers and data structures/defines in both legacy and nrfx, and sdk_config

The SoftDevice can be used stand-alone. It does not have any dependencies on the SDK.

FI said:

2) BLE functionalities are all inclusive in the SD and

The SD is the BLE stack, but important higher-level Bluetooth functionality is implemented by the SDK and not the SoftDevice. This includes implementations of BLE services and handling bonding information.

FI said:

3) All data structures and macros for SD BLE integration are included in the /component/ble/ directory

No. What you find under <SDK>/components/ble/ is SDK Bluetooth stuff. This has dependencies on the SoftDevice, but not the other way around. The SoftDevice is distributed as a .hex file with some header files describing the API. Those are distributed with the SoftDevice, and cand be found in the SDK under <SDK>/components/softdevice/.

FI said:

4) core and peripheral can be done with Reg and BitField through HAL and MDK and standard interrupt vector tables.

Yes.