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

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

Einar Thorsrud — Mon, 19 Sep 2016 06:21:47 GMT

@skarvone (BorkFest): You are right that the logger module in SDK 12 has less support for input than what was there in SDK 11. This thread has some more information about it.

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

Pierre Landau — Thu, 15 Sep 2016 18:58:08 GMT

Sorry about that. According to the suggested example, you can use NRF_LOG_RAW_xxx like NRF_LOG_PRINTF as long as you cast every single parameter to a (uint32_t) regardless of whether it's a pointer to char, an int, or anything else. The online docs for NRF_LOG_RAW_xxx are still somewhat lacking.

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

Pierre Landau — Thu, 15 Sep 2016 18:53:03 GMT

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.

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

BorkFest — Thu, 15 Sep 2016 06:34:59 GMT

Actually it seems it got a bit worse with reading the input. The HasInput() got dropped, now if you want to do non-blocking get input (like a terminal over RTT) you need to go around the logging API

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

Einar Thorsrud — Thu, 15 Sep 2016 06:07:01 GMT

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).

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

Keton — Wed, 14 Sep 2016 19:55:37 GMT

strange, my NRF_LOG_DEBUG happily accepts %X and prints hex and thanks to nrf_log_push() function prints strings as well. And it can handle floats via %f without pulling up a function like sprintf and its many kilobyte dependencies. So for me it's a major step forward + deferred logging which guarantees almost zero performance penalty. Just take a loot at the docs summary here: infocenter.nordicsemi.com/.../nrf_log.html and glance trough the sources.