elua serial console CRLF strange behaviour

[Martin Guy]

Hi
   I've been getting weird behaviour from elua when using the serial
console (shell) with minicom.  If I ended a line with the 'Enter' key,
I had to hit it twice to get one end-of-line. If instead I used line
feed (control-J), I har to hit it twice, but got two line feeds each
time, in pairs.
  The cause seems to be some strange CRLF/LFCR handling code in
newlib/genstd.c which, when it sees a carriage return or a newline,
reads another character, hoping to map CRLF or LFCR to LF.  When
presented with "single" CR or LF line terminators, as generated by all
known serial terminals, the behaviour becomes bizarre.

   I note in the web instructions that it recommends setting the
terminal emulator to send CRLF when you press Enter - but I've never
seen a physical serial terminal that does this, nor a terminal
emulator that does this.

   The attached patch simply maps CR or LF to '\n', in each case
echoing CRLF to the screen.  It also fixes a bug, whereby a UART
failure (overrun, parity error etc) would have returned an entire
buffer full of junk (it returns EOF instead).

   Are there really any situations where CRLF (and LFCR!) mapping on
serial input is necessary?

       M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

On Fri, Sep 3, 2010 at 5:18 PM, Martin Guy <[hidden email]> wrote:
> Hi
>   I've been getting weird behaviour from elua when using the serial
> console (shell) with minicom.  If I ended a line with the 'Enter' key,
> I had to hit it twice to get one end-of-line. If instead I used line
> feed (control-J), I har to hit it twice, but got two line feeds each
> time, in pairs.

Do you have timers working on your platform? The idea was to have the
code in genstd.c handle all possible situations (CR+LF, LF+CR, only
CR, only LF) automatically. So, when a CR or LF is received, the code
tries to read the complementary char (LF or CR respectively) with a
small enough timeout (STD_INTER_CHAR_TIMEOUT). If it gets the
complementary char in this period of time, it simply consumes it; if
not, it assumes that the terminal emulator uses simple line endings
(CR or LF) and carries on. If this does not work for you, I suspect
there's a problem with your timers.

>   I note in the web instructions that it recommends setting the
> terminal emulator to send CRLF when you press Enter - but I've never
> seen a physical serial terminal that does this, nor a terminal
> emulator that does this.

Unfortunately there are some, this is why your patch will not work
properly. I can't tell you which ones right now, just that I found
them in Windows.

Thanks,
Bogdan
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 9/3/10, Bogdan Marinescu <[hidden email]> wrote:

>  On Fri, Sep 3, 2010 at 5:18 PM, Martin Guy <[hidden email]> wrote:
>  > Hi
>  >   I've been getting weird behaviour from elua when using the serial
>  > console (shell) with minicom.  If I ended a line with the 'Enter' key,
>  > I had to hit it twice to get one end-of-line. If instead I used line
>  > feed (control-J), I har to hit it twice, but got two line feeds each
>  > time, in pairs.
>
> Do you have timers working on your platform? The idea was to have the
>  code in genstd.c handle all possible situations (CR+LF, LF+CR, only
>  CR, only LF) automatically. So, when a CR or LF is received, the code
>  tries to read the complementary char (LF or CR respectively) with a
>  small enough timeout (STD_INTER_CHAR_TIMEOUT).

Thanks, yes, my lack-of-32kHz-timer patch had not been activated.
Seems to work ok without the patch now. Many thanks.

>  >   I note in the web instructions that it recommends setting the
>  > terminal emulator to send CRLF when you press Enter - but I've never
>  > seen a physical serial terminal that does this, nor a terminal
>  > emulator that does this.
>
>
> Unfortunately there are some, this is why your patch will not work
>  properly. I can't tell you which ones right now, just that I found
>  them in Windows.

I guessed it might be to work round something nasty in Windows

Cheers

     M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev