Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF_LOG_PROCESS() defined as NRF_LOG_INTERNAL_PROCESS() which in turn in defined as nrf_log_frontend_dequeue(). Why?

In the nRF SDK 15.2, I am using the function idle_state_handle() which has a macro NRF_LOG_PROCESS() which is defined in another header file as NRF_LOG_INTERNAL_PROCESS() which in turn is defined as nrf_log_frontend_dequeue(). Why did we have to redefine NRF_LOG_PROCESS(). Is it just to avoid using too many header files in the main application or to give structure to the code?

Thank you so much. I would highly appreciate the clarification.

Parents
  • Hi,

    Guess it is done for both reasons you have mentioned. But I would assume it is mainly to have everything collected as one interface/header file. Unfortunately it can be a bit cumbersome if you want to look into the under laying code, but the assumption is that most customers benefit from having a clear interface, while the once that wants to investigate more have the patience to drill down into the details.

Reply
  • Hi,

    Guess it is done for both reasons you have mentioned. But I would assume it is mainly to have everything collected as one interface/header file. Unfortunately it can be a bit cumbersome if you want to look into the under laying code, but the assumption is that most customers benefit from having a clear interface, while the once that wants to investigate more have the patience to drill down into the details.

Children
Related