Re: Linux serial port dropping bytes



CBFalconer wrote:
I'm trying to receive bytes over the built-in RS-422 serial port
at 921.6 kbps. The received packets are 1500 bytes long. The
UART is a 16C2850 (dual port version of the 16C850 with 128 byte
FIFO).

This means you have 1.388 mS to fill the FIFO - plenty of time to
process it.

Oh? The unit fills up, with 1500 bytes, and interrupts. Bytes can
be coming in at one per microsec (roughly) until you get at least
some out.

Oops, sorry, I have taken the 1500 for FIFO depth, not the 128, hence
the wrong result.
This means he will have (1388/1500)*128 uS to fill the FIFO, or about
118 uS.
Still plenty of time to empty a FIFO into memory on most if not all
todays
CPUs which would have a 128 byte deep FIFO on the UART.
But latency is bound to creep in as an issue in this context given
that under
linux other IRQ handlers will not unmask early (I am relying on Grants
word for
that), so there is probably no working linux option - which is I
believe what
you suggested initially.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/




CBFalconer wrote:
Didi wrote:
Derek Young wrote:
...
I'm trying to receive bytes over the built-in RS-422 serial port
at 921.6 kbps. The received packets are 1500 bytes long. The
UART is a 16C2850 (dual port version of the 16C850 with 128 byte
FIFO).

This means you have 1.388 mS to fill the FIFO - plenty of time to
process it.

Oh? The unit fills up, with 1500 bytes, and interrupts. Bytes can
be coming in at one per microsec (roughly) until you get at least
some out. That doesn't happen until the interrupt is serviced, and
control is transferred to the unloading code, after doing all the
checks (for error, etc.) So that must have all happened in about
one microsec, to avoid rejecting further input. Now the discharge
loop has to remove items in less that 1 microsec per byte, just to
keep up with the input line. I have doubts that you can even talk
to the UART that fast.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com
.