nRFSDK v17 libuarte cli example and logging float numbers

[Franz]

Dear all,

The forum is full of questions around printing floating point numbers, however, I have a rather strange issue where maybe someone can help.

I have a project based on the libuarte cli example (set up in VisualGDB using v17 of the SDK). cli with libuarte was chosen because the forum suggests that libuarte is the proper choice for exchanging rather big amounts of data.

I do some code profiling and for this, I have to print out floating point numbers (with as many digits "as possible") via the uart.

Since the logging backend uses libuarte cli as setup in the example, i have to send floats as strings, because sending "raw" data via cli is not possible. I could use a second UART to do so, but it is much easier to control the program and get debug data over the same interface.

Now, since NRF_LOG_FLOAT with the respective float markers is very limited in the number of digits, i use an approach like:

void write_out(float* float_array_p)
{
	char floatchar[15];
	
	for (int ii = 0; ii < 1024; ii++)
	{
		memset(floatchar, 0, sizeof(floatchar));
		sprintf(floatchar, "%14.9f", (float_array_p[ii]));
		NRF_LOG_RAW_INFO("%s,", NRF_LOG_PUSH(floatchar));
		while(NRF_LOG_PROCESS());
		cli_process();
	}
}

The code runs in the main context. While not elegant, it should work fine.

Now, I trigger the function and receive the data on the PC side where i interpret the numbers as floats again. This essentially works, but not all numbers receive with the specified number of digits. It seems that NRF_LOG_RAW_INFO does not always dela correctly with the (as it seems correct) string provided by sprintf.

For example, I receive something like

['0.261669427', '0.25', '0.251542121', '0.247047648', '0.242788866', '0.238817886', '0.235065147', '0.231475547', '0.228071377', '0.224838212', '0.22', '0.208597437', '0.199891493', '0.193471178', '0.188196659', '0.183472663']

 You can see the second number and in this case the 11th one just show 2 digits after the comma.

As far as I can tell (it is hard to debug, because even using the very same numbers as input, not always the same numbers are truncated in the received data!), the strings passed to the NRF_LOG_RAW functions are correct.

Any idea?

[Krzysztof Chruscinski]

Hi Franz,

you can delay NRF_LOG_PROCESS() by adding a delay or sleep to while loop. When NRF_LOG_PROCESS() is called it takes one message from the queue and passes it to all active backends. CLI is one of the active backends. CLI takes this message and queues. When cli_process() is called it handles cli pending actions, it will find pending log message and will process it.

Logger passes whole message to the cli, cli is the one who formats the string and sends it to transport layer (uart, rtt).

Regarding 3.1 one call to LOG_PROCESS() and one to nrf_cli_process() will process (print) one log message.

3.2 Logger passes the message to all backends. It is up to the backend to react. Simple backend like uart may print immediately but more complex may require more operations. CLI is that example, logger only enqueues the message so cli process must be explicitly called by the user.