Re: Linux serial port dropping bytes

Grant Edwards wrote:
CBFalconer <cbfalconer@xxxxxxxxx> wrote:
Grant Edwards wrote:
CBFalconer <cbfalconer@xxxxxxxxx> wrote:
Derek Young wrote:

I'm using an Arcom Viper PXA255 single board computer running
Linux, and 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).

Everything works fine at low speeds, but if the packet rate
increases, I start to lose bytes.

Your numbers indicate that you would need an interrupt roughly
every 1 microsec. Not a chance.

Huh?

If he sets the FIFO threshold to 64, then the interrupt
frequency is 921600.0/10/64 == 1440Hz.

If he sets it FIFO threshold to 96, then the interrupt
frequency is 921600.0/10/96 == 960Hz. 960Hz should be no
problem at all unless some of the other ISRs are running too
long.

I know of UARTs that can hold 64, or even 128, results. I gather
that that one has a 128 byte storage. Okay, now consider how long
it takes to empty that buffer, when full. That has to be done at
least every 921600/128 (I don't know where you got /10/96)

You divide by 10 bits/byte to convert from bits/sec to
bytes/sec. Then you divide by the interrupt threshold to
convert from bytes/sec to interrupts/sec.

or roughly 10 khz, for about 100 uS between interrupts.

It's 921600 _bits_ per second (including start and stop).
That's 92160 bytes per second. If he configures the FIFO
threshold to be 96, then the _fastest_ he'll get interrupts is
one interrupt every 96 bytes. That means 92160/96 interrupts
per second.

Now you don't know how many items are stored, so that implies
a one by one discharge loop. Nobody has mentioned the CPU
speed, but I still have grave doubts. Don't forget that
during the discharge the FIFO is still filling up, at roughly
1 item per microsec.

You seem to be confusing bits and bytes.

I would guess you are assuming the speed mentioned is a bit
speed,

It is.

not a per byte port speed, and the '10' is the length of the
character, in bits. Nobody computes serial port speeds that
way.

Yes they do. They always do.

I left the whole thing unsnipped. The time has come for me to
crave forgiveness. I think I have been afflicted with age or
something. The bits/persec crowd are absolutely correct, and I am
wrong.

So that leaves the real problem handling throughput of
approximately 1 char each 10 microsec.

--
[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

.

Relevant Pages

  • Re: Linux serial port dropping bytes
    ... Your numbers indicate that you would need an interrupt roughly ... If he sets the FIFO threshold to 64, ... Nobody computes serial port speeds that way. ...
    (comp.arch.embedded)
  • Re: Linux serial port dropping bytes
    ... serial port at 921.6 kbps. ... Your numbers indicate that you would need an interrupt roughly ... If he sets the FIFO threshold to 64, ...
    (comp.arch.embedded)
  • [PATCH] zs: Move to the serial subsystem
    ... This is a reimplementation of the zs driver for the serial subsystem. ... to use a console on a serial port, say Y. Otherwise, say N. ... * This is the Z85C30 driver's generic interrupt routine. ...
    (Linux-Kernel)
  • [PATCH 03/76] coldfire: scheduled SERIAL_COLDFIRE removal
    ... bool "Support RTS/CTS on 68328 serial port" ... deleted file mode 100644 ... * Here starts the interrupt handling routines. ... * This routine is called from the scheduler tqueue when the interrupt ...
    (Linux-Kernel)
  • [PATCH 03/27] coldfire: scheduled SERIAL_COLDFIRE removal
    ... bool "Support RTS/CTS on 68328 serial port" ... deleted file mode 100644 ... * Here starts the interrupt handling routines. ... * This routine is called from the scheduler tqueue when the interrupt ...
    (Linux-Kernel)