• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 22 subscribers
  • Views 6781 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Printf redirect to STDOUT

Viral Purohit

I have a real STM32F103ZE hardware which i program simple test printf redirect to STDOUT UART.

If i put printf("Test"); then it does not output anything until to UART until it reaches 64 bytes and then outputs.

If I put printf("Test\n"); then it instantly transmits to UART.

It seems adding the new line \n character seems to change the printf behavior.

I saw the ARM Compiler documents but it does not seems to be mentioned anywhere.

Can anyone comment on this?

Parents
  • 0 in reply to Viral Purohit

    "It was nothing to do with PC buffer."

    Notice that I talk about generic printf() output and buffering. So nothing PC-specific, but something that exists outside of the embedded world. setbuf() and setvbuf() are part of the C standard, and controls buffering of FILE-based stream output which includes printf(), fprintf(), ...

    When in full-buffer mode, you get data emitted when the buffer is full.
    In line-buffer mode, you get data emitted at end of strings.
    In unbuffered mode, every single character gets emitted.

    Not sure what bug you think you found in Keils fputc function - it's quite common to have support for auto-translation of '\n' into "\r\n" line breaks, since that's the standard on the Windows platform. While the C language considers the single character '\n' to represent a line break.

    The only thing is that most implementations who have such logic makes use of a stream-specific flag to check if fopen() did open the stream in binary or text mode. But in this specific case, the logic is hard-coded for stdout and stderr which are quite logical to be operating in text mode.

Reply
  • 0 in reply to Viral Purohit

    "It was nothing to do with PC buffer."

    Notice that I talk about generic printf() output and buffering. So nothing PC-specific, but something that exists outside of the embedded world. setbuf() and setvbuf() are part of the C standard, and controls buffering of FILE-based stream output which includes printf(), fprintf(), ...

    When in full-buffer mode, you get data emitted when the buffer is full.
    In line-buffer mode, you get data emitted at end of strings.
    In unbuffered mode, every single character gets emitted.

    Not sure what bug you think you found in Keils fputc function - it's quite common to have support for auto-translation of '\n' into "\r\n" line breaks, since that's the standard on the Windows platform. While the C language considers the single character '\n' to represent a line break.

    The only thing is that most implementations who have such logic makes use of a stream-specific flag to check if fopen() did open the stream in binary or text mode. But in this specific case, the logic is hard-coded for stdout and stderr which are quite logical to be operating in text mode.

Children