Using the SD API directly - is it straightforward, or too much hassle?

[UnicycleBloke]

I am experienced with ARM Cortex-M devices, but new to Nordic. I am using C++, and have a publisher-subcriber event driven framework of my own in place already. My own software timers are integrated with this (driven by SysTick or RTCx or whatever). My question relates to how best to integrate all this with the NRF52 SDK. I've just started working through some of the BLE examples. I'm slightly hampered by also being new to BLE...

There seems to be a huge layer of abstraction between the application and the actual SoftDevice API. I try to never use macros which generate lines of code, and the SDK appears to be riddled with them. Is it *practical* to just use the SD API directly, and where might I find examples of this? I can see the documentation online for the SD API, including a lot of useful-looking sequence charts, but no PDF. In principle, it looks like a relatively small number of API calls to set up my advertising, services and whatnot, implementing an ISR to receive events, and then pressing go. I'll need to make sure my application's vector table is at the right location, and to give the SoftDevice enough RAM, but that's about it. Is that a fair assessment?   

For context, I found it *much* simpler and cleaner to configure and operate the hardware peripherals directly through registers. I dispensed with the HAL and drivers entirely (except for the convenient definitions of bitmasks and so on). And my driver classes are integrated with my application framework...

Thanks.


Al

[natersoz]

I understand. Which is why I've chosen to remove myself from working with the SDK as much as possible. The softdevice, however, IMO is well written. I am mystified as to how Nordic can do such a good job at provisioning the softdevice and fail so hard with this SDK.

I'll keep my rants to a minimum in order to not displease the Nordic gods. They have lightning I am told. And vikings.

They also have #define MACRO_HELL()

To your specific missing linkage: UARTE0

Nordic has done something rather nasty here: It is not sufficient to include a module in the compile and link phase of your project. You have to also satisfy their #define module nonsense.

You have probably already looked into the source nrfx_arte.c ? 

#if NRFX_CHECK(NRFX_UARTE_ENABLED)

#if !(NRFX_CHECK(NRFX_UARTE0_ENABLED) || NRFX_CHECK(NRFX_UARTE1_ENABLED))
#error "No enabled UARTE instances. Check <nrfx_config.h>."
#endif

If NRFX_UARTE_ENABLED (and a few others!) are not defined then the uarte_control_block instance is not instantiated.

In Nordic' defense, when it comes to peripherals, there will have to be some macro hell in play.

They have shared UART/SPI master/slave/I2C devices which all have to share the IRQ vector and handlers.

Having looked at this, and the compromises required to deal with shared peripherals, some type of macro is required. Minimizing and isolating their dependencies did not seem important to whoever is leading the direction for Nordic's SDK. In fact, with SDK 15 compared to 14 it seems to have gotten worse  :(

[UnicycleBloke]

I did see NRFX_UARTE0_ENABLED in the config.h, but this did not fix the problem. I think I stumbled over some problem in the linker script which means that __bss_start__ is not correctly initialised. Lightning could hardly be worse than this endless yak shaving. :)

I agree that it is hard to understand how the people who created the SD also created this SDK. I have rarely been so infuriated and so depressed by a body of code.

[Nguyen Hoan Hoang]

For C++ drivers, have a look at this multi-target project.  For Nordic based code, go down into the ARM tree.  All low level drivers (SPI, I2C, UART,..) are directly written to register no SDK and independent of RTOS.  It can be used with any RTOS as well.