There aer a couple of ifles in the SDK that use this weird _H compiler directive that prevents them from compiling - how do you control those? For example, NRF_SORTLIST_H, or CRC32_H? seems to be related to the NRF_MODULE_ENABLED() macro.
There aer a couple of ifles in the SDK that use this weird _H compiler directive that prevents them from compiling - how do you control those? For example, NRF_SORTLIST_H, or CRC32_H? seems to be related to the NRF_MODULE_ENABLED() macro.
Are you referring to the include guards? We use include guards like these in pretty much every header file in the SDK. E.g. like this in nrf_sortlist.h:
#ifndef NRF_SORTLIST_H #define NRF_SORTLIST_H .... #endif //NRF_SORTLIST_H
OK, I'm clearly barking up the wrong tree. How do you get crc32_compute(...) to compile? In other words, how do you get NRF_MODULE_ENABLED(CRC32) to resolve true? Or NRF_MODULE_ENABLED(NRF_SORTLIST)?
OK, I'm clearly barking up the wrong tree. How do you get crc32_compute(...) to compile? In other words, how do you get NRF_MODULE_ENABLED(CRC32) to resolve true? Or NRF_MODULE_ENABLED(NRF_SORTLIST)?
Have you enabled them in sdk_config.h?
By that you mean set CRC32_ENABLED and NRF_SORTLIST_ENABLED to 1 - yes, of course.
What example are you based off, and what do I need to add in order to reproduce your issue?
It turns out the compiler was not using the correct version of sdk_config.h. Aside from adding the correct sdk_config.h file to the includes of the offending source file, how does one force the usage of one particular sdk_config.h?
The examples in the SDK all have their own sdk_config.h who the compiler have included in their search path, I suggest you use them as a template for your development.