Hi
Am I alone in my judgement that some of the Nordic Example code is a good example of how NOT to code? These examples should demonstrate the perfect way to utilise a given peripheral, but frequently there is stuff missing that makes the example almost unusable.
A case in point is the SPIS (SPI Slave example). It should be obvious that for example code, 100% of folks are expecting logging via the JLINK CDC to be in place and working. Unfortunately not so with this example. I define #define NRF_LOG_ENABLED 1 in sdkconfig.h only to get linker errors because nef_log_default_backends is missing. I add the backends that I require and then I get linker errors re fprintf, I add these files, and note that they are not enabled in SDKconfig.h. I hunt through SDK_Config.h, but the #define for fprintf is missing. I steal it from another sdk_config.h and plonk it in the file:
// <q> NRF_FPRINTF_ENABLED - nrf_fprintf - fprintf function.
#ifndef NRF_FPRINTF_ENABLED
#define NRF_FPRINTF_ENABLED 1
#endif
Now it builds again, but still no logging. I look through a working sdk_config.h and note that all the UART defines are missing from the SPIS example sdkconfig.h. I find these and plonk them in. The baud rate, parity settings for the UART are also missing.... I end up giving up.
All I want is for logging to work - it should work out of the box with zero effort from myself!. Whoever wrote the SPIS example went to the trouble of sticking NRF_LOG_INFO("SPIS example"); in main(), but there is no way to easily enable logging - why?
The above is true of oh so many nordic examples. poor quality code, poorly documented and poorly implemented when the examples should be detailing the best possible way of deploying a Nordic device.
If I'm honest, it winds me up, its 100% avoidable, Nordic can fix all the examples once, which then saves every single customer having to manually fix the things themselves. The poor quality of the example code will lead me to choosing a different vendor for our next BLE project.
Nigel
