Problems with printf variable argument parsing

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Problems with printf variable argument parsing

跳至解决方案
3,143 次查看
thoborawski
Contributor II

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);


标签 (1)
0 项奖励
回复
1 解答
2,945 次查看
thoborawski
Contributor II

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.

在原帖中查看解决方案

0 项奖励
回复
5 回复数
2,945 次查看
thoborawski
Contributor II

We are working in a bareboard project with the MK60FX512. We have only used Codewarrior V10.5  for this processor.


0 项奖励
回复
2,945 次查看
trytohelp
NXP Employee
NXP Employee

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.

pastedImage_2.png


Have a great day,
Pascal
Freescale Technical Support
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 项奖励
回复
2,945 次查看
thoborawski
Contributor II

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:

x.png (2).png

0 项奖励
回复
2,946 次查看
thoborawski
Contributor II

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.

0 项奖励
回复
2,945 次查看
trytohelp
NXP Employee
NXP Employee

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!
-----------------------------------------------------------------------------------------------------------------------

0 项奖励
回复