[leon_sparc] Re: CRLF vs (just) LF

[Jarl Friis]

Ralf Corsepius <corsepiu at faw.uni-ulm.de> writes:

> Am Don, 2002-01-17 um 13.27 schrieb Jarl Friis:
> > Ralf Corsepius <corsepiu at faw.uni-ulm.de> writes:
> > 
> > > Am Don, 2002-01-17 um 12.48 schrieb Jarl Friis:
> > > > I just installed and ran the rtems-hello.c program.
> > > > 
> > > > One thing that I find annoying is that the "\n" character in the
> > > > printf string translates to CR LF (two bytes). I expected that it
> > > > would as on any other relevant OS generate only LF. I doubt this is an
> > > > RTEMS issue but related to the sparc-rtems-gcc version found on
> > > > www.gaisler.com.
> > > > 
> > > > Can someone direct of where to start to look to resolve this problem?
> > > * termios, c.f. [I|O]CRNL, [I|O]NLCR etc.
> > 
> > eh?, I think I kind of wanted a path to a file in the srouce tree?
> > What are you trying to say here. I assume that we agree to LF==NL.
> OK, apparently, I was too brief.
> 
> With termios-supported console-drivers, automatic LF->CR-LF conversion
> is a setable attribute of termios (cf. man tcgetattr, man tcsetattr).
> 
> Therefore, you might want to read man termios (rsp. man termio on some
> hosts), read RTEMS's termios.h, and check for the flags ICRNL, OCRNL,
> INLCR, ONLCR, which are involved into processing of CR/LFs.

Oh yes... Things are clearing up now ;-) rtems is a posix kernel
right? I'll have a look at the use of termios.

Thanks, so my rtsem hello world Version 2 will probably be one that
prints the termnal settings :-)

> > > * console-drivers: AFAIK, some (non-termios-based) console drivers apply
> > > LF->CRLF conversion (Note: These are console-drivers, not serial
> > > drivers, being applicable for general serial IO purposes.)
> > > 
> > > * Check the settings of your terminal.
> > 
> > My terminal does not do that. it is an issue of the compiled
> > rtems-hello program. the (rest) of tsim does not generate CRLF (only
> > in one line (using perf), which I consider a bug. Any other app
> > behaves as expected as well
> This normally is a customizable option of terminal programs, similar to
> baud-rates, parity-checking etc.
> 
> [I haven't seen any terminal emulator which doesn't have this options.]
> 

I guess we are now talking about the terminal I run tsim from (on the
host coputer), right?
Assuming I pipe the output to a file I can be sure no interpretation
by any terminal is done to the output from UART1 on LEON (i.e. tsim)
or the messages generated by tsim itself.

That makes me wonder where the implementation of printf when making
boot prom programs.

I was even wrong on my state on the hello-world program as boot prom,
for each "\n" printf emits "\n\r" (note the non-standard order of the two
bytes), further printf does not emit the two last bytes of a
string. Issuing printf("Hello") just gives you a "Hel" on the
output. Normally you don't notice since "\n" will be exactly the two
("\n\r") last bytes that are not emitted.

Well, where ever that printf-implementation comes from I gotta have a
look on that, actually I should not, making a boot prom I probably
should implement my own.

> Ralf.

Thanks.

Jarl