Hi,<br><br>I have checked the termios configuration again, it seems ok. No software flow control, no canonical mode. Also the same configuration works fine on a x86.<br><br>I'm using gaisler's console driver and when i opened the rtems driver file it said this:<br>
<br> *  WARNING:  In sis 1.6, it did not appear that the UART interrupts<br> *            worked in a desirable fashion.  Immediately upon writing<br> *            a character into the TX buffer, an interrupt was generated.<br>
 *            This did not allow enough time for the program to put more<br> *            characters in the buffer.  So every character resulted in<br> *            "priming" the transmitter.   This effectively results in <br>
 *            in a polled console with a useless interrupt per character<br> *            on output.  It is reasonable to assume that input does not<br> *            share this problem although it was not investigated.<br>
<br>So, can it be that some bytes are lost / not written to the hardware buffer because each byte causes an interrupt?<br><br><br>Best,<br>JM<br><br><br><div class="gmail_quote">On Fri, Sep 24, 2010 at 3:04 AM, Eric Norum <span dir="ltr"><<a href="mailto:wenorum@lbl.gov">wenorum@lbl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Sep 23, 2010, at 6:29 PM, Chris Johns wrote:<br>
<br>
> On 23/09/10 7:52 PM, Joćo Rasta wrote:<br>
>> Thanks Chris, there are still two things i don't understand:<br>
>><br>
>> 1) When transmitting, the behaviour i expect from the rtems software<br>
>> buffer is that bytes are read from it one by one and passed to the uart<br>
>> hardware buffer and then serialized to the serial line. This software<br>
>> buffer is the raw_output buffer and the cooked buffer will not be used<br>
>> in this case. Is this correct?<br>
><br>
> It depends on the termios configuration you use. This link may help:<br>
><br>
> <a href="http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_01_03" target="_blank">http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html#tag_11_01_03</a><br>
><br>
> The section "Non-Canonical Mode Input Processing" is important for you. It is sometimes referred to as 'raw-mode'.<br>
><br>
> Some drivers can take more than one character at a time. If you have the output cooked it will be buffered into the cooked buffer and transferred to the output buffer when a LF or flush happens.<br>
<br>
</div>AFAIK the cooked buffer is for input only.  It's size determines the maximum line length that can be handled.  The raw input buffer holds characters directly from the seial port.  The cooked buffer holds the characters after erase/kill processing.<br>

><br>
<font color="#888888"><br>
--<br>
Eric Norum<br>
<a href="mailto:wenorum@lbl.gov">wenorum@lbl.gov</a><br>
<br>
<br>
<br>
</font></blockquote></div><br>