For Codewarrior V10.5 with EWL, I have been having problems getting
printf to process the argument list correctly. As an example, for two
test variables:
unsigned short locTestNum = 5;
float locTestFloat = 1.234;
When I execute:
printf("{Float=%8.3f} {Int= %hu}\n",locTestFloat,locTestNum);
The result is:
{Float=0.000} {Int= 5}
I realize that there are library build options (such as
_EWL_FLOATING_POINT_PRINTF_SCANF) that may cause such a problem, but I have used sprintf
in the past with floats with no problems.
As a sidenote: I found that I had to initialize the stdout file handle
to get printf to work via WriteUARTN. The following are the settings I used:
stdout->mode.open_mode = __create_if_necessary;
stdout->mode.buffer_mode = _IONBF;
stdout->mode.io_mode = __write_mode;
stdout->mode.file_kind = __console_file;
stdout->state.error = 0;
stdout->state.io_state = __writing;
stdout->write_proc = __write_console; //located in /src/sys/uart_console_io.c calls WriteUARTN directly
stdout->read_proc = __read_console;
stdout->buffer = stdout_buff;
stdout->buffer_ptr = stdout_buff;
stdout->buffer_size = sizeof(stdout_buff);
stdout->buffer_len = sizeof(stdout_buff);
Solved! Go to Solution.
It looks like my problem was that printf was called before the UART (and the processor itself) was properly initialized. I added a test to make sure the UART interrupt was installed and the receiver and transmitter was initialized and to problem went away.
This was a good exercise since we discovered that the EWL libraries use RAM-based file handles (stdout which equals struct _FILE _files[1]) to store the UART accessor function pointers (ReadUARTN, WriteUARTN). Using a ram-based function pointer that is never refreshed is unacceptable to us. We will be making our own printf-equivalent that calls our UART routines directly.
We are working in a bareboard project with the MK60FX512. We have only used Codewarrior V10.5 for this processor.
Hi Tho,
You've always used CW for MCU v10.5 ?
What does this means "I have used sprintf in the past with floats with no problems." ?
By default when you create a project with the wizard you can select 2 options:
-> I/O support
-> ARM Build Tools
Depending of the options selected this could have an impact of your project - libraries included.
Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
What I mean by "I have used sprintf in the past with floats with no problem" is that it has worked in the past on other projects
with no problems. Now it does not seem to work correctly. I setup the project with hard float, the UART box checked as you show in your screenshot along with the GCC option.
I also have the librarian setup for model ewl and print formats "int_FP" as shown below:
It looks like my problem was that printf was called before the UART (and the processor itself) was properly initialized. I added a test to make sure the UART interrupt was installed and the receiver and transmitter was initialized and to problem went away.
This was a good exercise since we discovered that the EWL libraries use RAM-based file handles (stdout which equals struct _FILE _files[1]) to store the UART accessor function pointers (ReadUARTN, WriteUARTN). Using a ram-based function pointer that is never refreshed is unacceptable to us. We will be making our own printf-equivalent that calls our UART routines directly.
Hi Tho,
what is the architecture used ?
It seems you used the printf functions without problem with older version.
What was this version ?
Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------