Why was NRF_LOG_PRINTF and its tie-in to Segger output eliminated in SDK 12?

[Pierre Landau]

In SDK 11, there was an immensely useful function known as NRF_LOG_PRINTF. in SDK 12, this seems to have been replaced by NRF_LOG_DEBUG, NRF_LOG_INFO, NRF_LOG_ERROR. However, if you expand the macros to these functions, it becomes clear that the only value one can ever use is a uint32_t. What happened to the ability to print strings, individual hex values, etc?

One reasonably ugly workaround seems to be something like:

#include "SEGGER_RTT.h"

then global search and replace every occurrence of NRF_LOG_DEBUG(xxx) by

SEGGER_RTT_printf(0,xxx)

Seems like a major step backwards from what had been a very useful debug tool.

[Einar Thorsrud]

The logger API (which was experimental in SDK 11) has changed a bit, but the functionality should not be any worse. You can use the NRF_LOG_*() macros to format strings like you would using printf().

If you want something printf() like, which is independent of log level, you should use NRF_LOG_RAW_INFO(). You can see an example of its use in the TWI Transaction Manager Example (examples\peripheral\twi_master_using_app_twi).

[Pierre Landau]

Unfortunately, the new NRF_LOG_xxx macros, while they accept varargs, are rather limited in functionality. If you want to do something like:

char day[5] = "Tues"; NRF_LOG_DEBUG("today's date is %s\r\n", day);

which worked just fine with NRF_LOG_PRINTF, you now get some horrible error about trying to force a pointer (the pointer to the char array) into a uint32_t. Expanding the new macros shows why this is the case, since the arguments after the format string are all expected to be uint32_t.

We have many dozens of NRF_LOG_PRINTF statements sprinkled through our code, and it appears the suggestion is to replace each one by local allocation of a buffer, an sprintf, followed by an NRF_LOG_RAW_INFO(). Seems awfully clumsy, not to mention time-consuming.