Hi Martin, To start with - thanks for WinARM. Certainly has got me going on my at91sam7s256 quicker than expected. Problem though - I have taken the syscalls.c file from one of your examples and changed the write function from supporting the usart0 to supporting my lcd. i.e. I have a lcdputchar function which prints a character on the lcd. If I call iprintf with a \n at the end of the format string, iprintf works, if I remove the \n, I get no output. The same applies for printf etc. My lcdputchar function is extremely simply - it just outputs the received character to the lcd. Any ideas anybody? Thanks Mike
Mike Betz wrote: > Hi Martin, > > To start with - thanks for WinARM. Certainly has got me going on my > at91sam7s256 quicker than expected. > > Problem though - I have taken the syscalls.c file from one of your > examples and changed the write function from supporting the usart0 to > supporting my lcd. i.e. I have a lcdputchar function which prints a > character on the lcd. If I call iprintf with a \n at the end of the > format string, iprintf works, if I remove the \n, I get no output. The > same applies for printf etc. > > My lcdputchar function is extremely simply - it just outputs the > received character to the lcd. > > Any ideas anybody? > > Thanks > Mike Problem solved. 'setvbuf' is the answer. TTFN Mike
Guest
#1170988
Mike Betz wrote: > Problem solved. 'setvbuf' is the answer. Yes, as far as I know the output for the newlib's (i)printf is buffered by default. IRC I once used fflush(stdout) to work around this but setvbuf seems to be a better solution. I usualy use a smaller but not very universal "rprintf" for my projects, so I can not say too much about the newlib's implementation. If you are interested: I have included this small version in the efsl-ARM-interfaces (efsl_dbg_printf_arm.c in the zip-archive from http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/efsl_arm/index.html ) Thanks for the information. Martin Thomas