Re: Linux serial port dropping bytes

On 2008-04-02, Derek Young <edu.mit.LL@xxxxxxxxxxxxx> wrote:

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

That's where a large FIFO becomes important. Using Linux on
an XScale (which, IIRC, is is what the OP is using), I've done
up to 460K baud without problems. But, that was using a UART
with a 1K byte rx FIFO. That UART also allowed 32-bit wide
accesses to the tx/rx FIFOs so that you could transfer 4 bytes
per bus cycle.

With a 128 byte FIFO and byte-wide access, the timing
constraints are quite a bit tighter, but I think it should be
doable if you carefully vet the other drivers that are running
on the system.

Unfortunately, I need to rely on drivers written by Arcom.
I've sent some questions to their tech support, but am still
waiting for a reply.

I was thinking... at 921.6 kbps (8/N/1 -> 92160 bytes/sec), if the FIFO
interrupt level is set at:

128 bytes: 720 interrupts/sec (1.4 ms/int), 10.8 us allowed for the ISR
to respond and empty the FIFO

That 10 us latency requirement is probably impossible.

64 bytes: 1440 interrupts/sec (694 us/int), ~700 us for the ISR to
respond/finish

That might be possible as long as you can make sure there
aren't any other ISRs running that take more than a a few tens
of microseconds.

(I'm still trying to look through the driver code to figure out where
the interrupt level is set.)

The XScale CPU I'm using runs at 400 MHz. (I've forgotten who
asked, but it's communicating to with a TSM320F2812 DSP.)
Hardware flow control is not an option because it's not
implemented in the Arcom hardware.

Do these interrupt frequencies sound reasonable for a
non-realtime OS, or is it hopeless as some of my coworkers
here have suggested?

It's definitely pushing the limits pretty hard. With enough
time and effort you might be able to make it work but all it
would take is one other ISR that runs for more than a few
hundred microseconds and you've lost data.

Whether the current architecture is acceptible depends on a
number of questions:

1) What are the consequences of loosing data? Does somebody
die, or is there merely a retry?

2) How much schedule risk is acceptible? Is it OK if it takes
a year of hacking on the source code for a few kernel
modules and a half-dozen different device drivers to get
the overall ISR latency down?

3) How much redesign risk is acceptible? Is it OK if you work
on it for three months before proving that it can't work
and a better UART or different interface has to be chosen?

--
Grant Edwards grante Yow! I'm having BEAUTIFUL
at THOUGHTS about the INSIPID
visi.com WIVES of smug and wealthy
CORPORATE LAWYERS ...
.

Relevant Pages

  • Re: 25 microseconds?
    ... Draining the serial FIFO in the ISR is by better ... than sipping one character at a time since each character in the FIFO is ... > Both ISR and DPC execution can kill performance. ... > ISR - 10 microseconds ...
    (microsoft.public.development.device.drivers)
  • Re: Linux serial port dropping bytes
    ... That's where a large FIFO becomes important. ... The XScale CPU I'm using runs at 400 MHz. (I've forgotten who ... hundred microseconds and you've lost data. ... I don't think I have the time to mess around any more with the Linux kernel. ...
    (comp.arch.embedded)
  • Re: 25 microseconds?
    ... Draining the serial FIFO in the ISR is by better ... than sipping one character at a time since each character in the FIFO is ... ISR - 10 microseconds ...
    (microsoft.public.development.device.drivers)
  • Re: Interrupt driven UART
    ... think I can implement the fifo with a fixed array size of n, ... The rx isr ... when the buffer is non-empty and when the buffer is full. ... I'm wondering how the retransmission will occur. ...
    (comp.arch.embedded)
  • Re: Linux serial port dropping bytes
    ... With a 128 byte FIFO and byte-wide access, ... (I'm still trying to look through the driver code to figure out where the interrupt level is set.) ... The XScale CPU I'm using runs at 400 MHz. Hardware flow control is not an option because it's not implemented in the Arcom hardware. ...
    (comp.arch.embedded)