I building a simple project to develop some interface code. I'm using printf to send data to the debug console for verification of operation/calculations. In the course of troubleshooting I discovered that printf is not honoring my format specifications.
If I add the following line of code:
PRINTF("This is a test: %d, 0x%04X\n", -219, 0x242);
I get the following output:
This is a test: 219, 0x 242
Notice that the sign is not output for "%d" and zero-padding is not honored for "%04X". I have tried both redlib and newlib and it behaves the same. Is there something obvious that I'm missing?
This is using KSDK 2.8.2 (manifest 3.6.0) for an MK66FX1M0VMD18.
MCUxpresso version 11.2.0
Solved! Go to Solution.
Thanks for the pointer Erich, I will check it out.
For those that might run into this behavior when using PRINTF directed to the DebugConsole, defining PRINTF_ADVANCED_ENABLE did in fact produce the expected output.
Thanks for the pointer Erich, I will check it out.
For those that might run into this behavior when using PRINTF directed to the DebugConsole, defining PRINTF_ADVANCED_ENABLE did in fact produce the expected output.
I don't use semihosting (because my hardware is Teensy and... you know)
PRINTF -> DebugConsole_Printf and it looks like DebugConsole_Printf -> StrFormatPrintf (in fsl_str.c)
There seems to be a lot of code disabled because I don't have the macro PRINTF_ADVANCED_ENABLE defined. I'm calling it a night, but I'll see if defining that fixes the issue and report back tomorrow. I should have looked deeper before I posted - I assumed it was using the library implementation of printf (sprintf), but I guess I was wrong
I did a quick test (IDE 11.3.0, SDK 2.9, newlib-nano), and I get what I expect:
This is a test: -219, 0x0242
I did not use that PRINTF macro because not sure what you have behind it, I did use printf directly with semihosting.
I tried the same with newlib (semihosting) and had the same:
This is a test: -219, 0x0242
The difference between 11.2.0 and 11.3.0 is the GNU toolchain with the standard library, but I doubt it was a bug in the GNU libs for printf. So not sure why you have something different.
Can you check what your PRINTF does?
I hope this helps,
Erich
In that case you have a lot of different layers in between. Anyway as you probably know I avoid for this (and many other reasons) printf. I'm using XFormat (https://mcuoneclipse.com/2014/08/17/xformat-a-lightweight-printf-and-sprintf-alternative/ ) which might not be perfect for any use case, but a least I have full control over it. The McuLib implementation of it is here in case you are interested:
https://github.com/ErichStyger/McuOnEclipseLibrary/blob/master/lib/src/McuXFormat.c
Erich