Re: Linux serial port dropping bytes


You need to handle an *average* of 1 character per 10 us. But
the cost of handling each character is peanuts - even if the
UART is on a slow bus, you should be able to read out
characters at something like 20 per us. The cost is in the
handling of the interrupt itself - context switches, cache
misses, etc. That's why you use a UART with a buffer - it
takes virtually the same time to read 128 bytes out the buffer
during one interrupt, as to read 1 byte from the buffer during
the interrupt. So if you've set your UART to give an interrupt
every 100 characters, you get an interrupt every ms and read
out a block of 100 characters at a time.

That depends on your CPU speed.

True. The OP is running an XScale with Linux, so I'd guess he's
running at a couple hundred MHz.

Within the interrupt, you have to
handle something like:

REPEAT
test for more in FIFO
take one, stuff in buffer, while checking for buffer full.
test for overflow or other errors.
if any, call appropriate handler
UNTIL FIFO empty
clear interrupt system
rearm interrupt
exit

Note that some operations will require several accesses to the
UART. Those will eat up time. They will be much slower than
on-chip memory access.

People have been supporting 921K bps serial links for ages. You
do have to pay attention to what you're doing, but it's really
not that hard with a sufficiently large FIFO. However, IMO a
128 FIFO is getting close to being insufficiently large. I
wouldn't want to try to support it on a Linux system with
interrupt latencies imposed by a bunch of randomly chosen
device drivers. If it's an embedded system and you've got
control over what other ISRs are running, it should be doable.

--

DMA is way superior to FIFO, since you dump to memory in the background.
The AT91 (and AVR32 implementation) support a Timeout interrupt
which is triggered if NO characters arrive in a certain number of bit
periods.

What really limits the speed in Linux is the error handling.
If you want to to proper error handling, you typically have
to handle the error before the next character arrives, and this
is pretty difficult in Linux, and will severly limit the speed.





--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB


.

Relevant Pages

  • Re: Linux serial port dropping bytes
    ... UART is on a slow bus, you should be able to read out characters ... interrupt itself - context switches, cache misses, etc. That's ... why you use a UART with a buffer - it takes virtually the same ...
    (comp.arch.embedded)
  • Re: Linux serial port dropping bytes
    ... UART is on a slow bus, you should be able to read out characters ... interrupt itself - context switches, cache misses, etc. That's ... why you use a UART with a buffer - it takes virtually the same ...
    (comp.arch.embedded)
  • Re: Linux serial port dropping bytes
    ... The cost is in the handling of the interrupt itself - context switches, cache misses, etc. That's why you use a UART with a buffer - it takes virtually the same time to read 128 bytes out the buffer during one interrupt, as to read 1 byte from the buffer during the interrupt. ... So if you've set your UART to give an interrupt every 100 characters, you get an interrupt every ms and read out a block of 100 characters at a time. ...
    (comp.arch.embedded)
  • Re: ntp server error
    ... STTY attributes for LOGIN ... EXCESSIVE LOAD ON PROCESSOR ... The processor is too busy to pull the characters out of the UART as fast as they are arriving. ... If your UART is so equipped, that says that for something like 16 milliseconds the processor has not read a character from the UART. ...
    (comp.protocols.time.ntp)
  • Re: Linux serial port dropping bytes
    ... characters at something like 20 per us. ... takes virtually the same time to read 128 bytes out the buffer ... during one interrupt, as to read 1 byte from the buffer during ... test for more in FIFO ...
    (comp.arch.embedded)