printf requires string to end with \n - is there a workaround?

Asked by ilovefpv

I'm retargeting my printf to a UART, however this is only processed when the string ends in \n.

Is there a way to print something which doesn't end in \n?

Thanks,

Steve
www.ilovefpv.com

Using newlib-nano with the 2013q2 release.

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
ilovefpv
Solved:
Last query:
Last reply:
Revision history for this message
chengbin (can-finner) said :
#1

Hi,
Which version of library are you linking against, newlib or newlib-nano?

Thanks.

Revision history for this message
ilovefpv (ilovefpv) said :
#2

Using newlib-nano with the 2013q2 release

Revision history for this message
chengbin (can-finner) said :
#3

Could you please try it out with newlib?
Since I have no environment to reproduce the problem, I have to ask you for help.

Thanks.

Revision history for this message
ilovefpv (ilovefpv) said :
#4

Ok how do I specify to have it compile with newlib over newlib-nano?

Revision history for this message
chengbin (can-finner) said :
#5

It's documented in readme.txt.

Revision history for this message
ilovefpv (ilovefpv) said :
#6

Ok, I can try, but I do know this works with Code Red's Redlib...

Revision history for this message
ilovefpv (ilovefpv) said :
#7

While I'm doing this - can you check with the developer to see if this is a limitation of newlib-nano? It seems there are other implementations of printf to STDOUT require a "\n" to flush the buffer..

See. http://stackoverflow.com/questions/1716296/why-does-printf-not-flush-after-the-call-unless-a-newline-is-in-the-format-strin

I tried:

    fflush(stdout);

But, this doesn't do the trick either..

Is there any testcase in your development environment which exercises the printf without a newline?

Revision history for this message
chengbin (can-finner) said :
#8

Hi,
I think this is because stdout is buffered by default.
Take below program as an example:
#include <stdio.h>

int main (void)
{
    fprintf (stdout, "hello");
    fprintf (stderr, "world");

    return 0;
}

If I build and run it with below command lines:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -O2 test.c -o test.axf --specs=rdimon.specs -lc -lrdimon -lc
qemu-system-arm -nographic -serial null -monitor null -semihosting -kernel test.axf -cpu cortex-m3

The output is "worldhello" because stdout is buffered and stderr is not.

If I change the program into :
#include <stdio.h>

int main (void)
{
    fprintf (stdout, "hello");
    fflush (stdout);
    fprintf (stderr, "world");

    return 0;
}
With same command lines the output is "helloworld".

I think this can illustrate the buffer strategy well.

Still I am not sure why fflush does not work in your case, which works fine for me.

As for the redlib, I think they might have the buffer facility optimized out, but this is just a guess without access to the source code.

Thanks.

Revision history for this message
ilovefpv (ilovefpv) said :
#9

Thanks - I'll try this...

Is there a way to turn the buffering off? Not sure why I'd want this because my UART driver requires as driver anyways..

Revision history for this message
ilovefpv (ilovefpv) said :
#10

Answered my own question, but figured I'd share with others (and confirm with the developers)...

setvbuf(stdout, NULL, _IONBF, 0);