Hi All
I have a project that uses some middle-ware code with
#include <inttypes.h>
which doesn't build with MCUXpresso since this header is not found. Previously with KDS there was no problem.
Also, I can build the project from a make file with the same compiler as used by MCUXpresso.
In the same file there are other such headers, such as
#include <string.h>
which cause no problems.
In fact, when I search for inttypes.h on the PC I find it in the same folder as string.h.
"MCUXpressoIDE_10.2.1_795\ide\tools\arm-none-eabi\include"
How can one header be found but the other not? Are specific include paths needed, and where are they located in MCUXpresso?
Thanks in advance!
Regards
Mark
Solved! Go to Solution.
Hi Mark,
It seems to me that you are using RedLib?
In that library the inttypes are not supported as it is a reduced set of library functions.
Instead, use the newlib or newlib nano:
I hope this helps,
Erich
Hi Mark,
It seems to me that you are using RedLib?
In that library the inttypes are not supported as it is a reduced set of library functions.
Instead, use the newlib or newlib nano:
I hope this helps,
Erich
Eric
Yes, I have always used REDLIB setting although I don't think that I really use anything from it.
In fact the only thing needed was a typedef for uint_32t so I changed to NewlibNano (none) and now it finds the header.
The binary generated is identical in both cases so I'll stick with NewlibNano (none) for the moment so that this header is not missing.
Thanks since I would have had no idea what could have led to this.
When I build from a make file (the usual method since opening MCUXpresso to build is excruciatingly slow) I don't specify any particular library so it must be using a default one. It's binary is in fact a few bytes larger in size but this may also be due to it linking files in a different sequence any leaving some holes when aligning (or similar).
Regards
Mark
Hi Mark,
a better and more portable way is to use
#include <stdint.h>
I hope this helps,
Erich
I know this is a bit old, but including <stdint.h> doesn't get the macros in inttypes.h (or doesn't seem to).
Eric
The include is in some standard mbed TLS code so I don't want to change things there otherwise it will be overwritten when updating libraries in the future (and the fix will need to be made again - but no one will remember what was done anymore this post was found again....;-). Library change is probably more future-proof.
Regards
Mark