Issues writing float data to UART

[JayDev]

Hello everyone!

Ran into some issues writing float data to the UART. I know with Nordic, there was some weird workaround that had to be used to convert it that looked something like this:

 NRF_LOG_INFO("MLX90393 X = " NRF_LOG_FLOAT_MARKER "\r", NRF_LOG_FLOAT(*x));

I wasn't sure if there was some other trick for this, if there's a project related setting that is required to make use of floating point (in case it's disabled by default or something to that effect, etc). I tried finding one but didn't seem to find one in the project options.

Anyway, this is my current attempt at resolving the issue:

void write_mlx90393_to_uart(float x, float y, float z)
{
	x = 250.3;
	y = -112.3;
	z = 15.214;
 
	char x_str[30];
	char y_str[30];
	char z_str[30];
 
	sprintf(x_str, "X: %f", x);
	sprintf(y_str, "Y: %05.2f \n", y);
	sprintf(z_str, "Z: %05.2f \n", z);
 
	debugPrintln(&huart1, x_str);
	debugPrintln(&huart1, y_str);
	debugPrintln(&huart1, z_str);
}

I expected it would convert it but the output for x_str is:

"X: \0\230\0\0 \224\0\0 \204\001\a\030N\0\002\0>\a\0\030\022ÿÿÿÿÿ"
 
or 
 
0x2002ffa8

Had to hardcode the values in this function to even test this as the values aren't being passed to the function as I would've expected. One problem at a time though! Heh . . .

Any suggestions you guys can point me towards would be greatly appreciated. Thanks!

[Tesla DeLorean]

What tools are you using?

Things using GNU/GCC like CubeIDE might need you to explicitly enable, have float libraries, and full C libraries for printf/scanf, not lite ones.

Source for debugPrintln() not shown, sure that's viable?

Smarter tools might scan the source to see "%f" and "%lf" usage, and suggest/implement better settings.

[TDK · Accepted solution]

In STM32CubeIDE, there is a checkbox to enable support for floats within printf. If "\0" is a null character, looks like your current implementation simply ignores the "%f" specifier.

[JayDev]

Heh, yeah, I actually stumbled across that and enabled it and was poking around at it. Tried moving from sprintf to printf (since the prompt mentioned printf) but that didn't work. Went back to sprintf and it started working for y. Which is when things get odd (and kind of explain why I was getting some odd results) . . .

So, this is the code I am currently using:

void write_mlx90393_to_uart(float x, float y, float z)
{
	x = 250.3;
	y = -112.3;
	z = 15.214;
 
	char x_str[10];
	char y_str[10];
	char z_str[10];
 
	sprintf(x_str, "X: %5.2f \n", x);
	sprintf(y_str, "Y: %5.2f \n", y);
	sprintf(z_str, "Z: %5.2f \n", z);
 
	debugPrintln(&huart1, x_str);
	debugPrintln(&huart1, y_str);
	debugPrintln(&huart1, z_str);
}

So, turns out that it prints Y and Z correctly. X, however, it seems to be interpreting the X incorrectly using sprintf (or I have another issues). Below is what the watch looks like:

I'm not sure if it's just interpreting the X incorrectly, if it's a bug, or what the deal is. I'll have to look into this a bit further. But if I was having issues with X specifically earlier, might've masked the issue at least a bit (since I wasn't looking at y and z at that time).

Overall, a step forward though! Thanks for your help!

[JayDev]

Sorry about that, I just realized I left out a lot of details!

I'm using STM32CubeIDE with a STM32WB55 Nucleo board. I believe you might be right about the full C library though, I'm going to check that next. Ran into that float option in the settings, so that was a good catch. I'm not familiar with %lf, is that referring to a line feed?

Thanks for your help!

[TDK]

> Below is what the watch looks like:

Nothing came through.

I assume the checkbox includes sprintf as well as printf. Obviously printf won't work unless you've explicitly rerouted printf output somewhere.

[TDK]

> char x_str[10];

> char y_str[10];

> char z_str[10];

Why did you change those from 30 characters to 10? Writing "X: %5.2f \n" needs more than 10 characters.

[JayDev]

Sorry, meant to come back here and completely forgot once I got it working . . . You are 100% correct on this and that seemed to be the root of the issue. Oddly enough, it worked fine for getting the Y and the Z but not for the X. I had reduced it to get rid of the additional garbage output . . completely forgetting that it didn't matter as the line was getting terminated at the /n anyway (so none of that garbage data mattered).

Just wanted to pop in and say thanks again for your help! Sorry for the delay!

[Piranha]

sprintf() is dangerous, better use snprintf().

[PRout.1]

Hi JayDev,

Would you like to share I2C or SPI code for MLX90393? I believe you were able to implement ML90393 interfacing.

Thannks..