jimlux@earthlink.net said:

The idea was to reduce the CPU load processing interrupts by batching things
up.

Some of those chips generate an interrupt when the see a return or line-feed
character.

Most of them have an option to disable that batching.  On Linux the setserial
command has a low_latency option.  I haven't measured the difference.  It
would be a fun experiment.

--
These are my opinions.  I hate spam.

I can't speak for linux, but I have been bitten by FIFO watermark
interrupts on micros before. If you set an interrupt for a 3/4 full FIFO,
the last one or two characters will sit in the receive buffer and never
trigger the RX interrupt. For a command -> response device which doesn't
have a constant data-stream, It isn't until a PC application resends the
command sequence that enough characters are in the FIFO to trigger the
watermark interrupt. The easy fix was to interrupt on any single character
being available, but would have been nice to have a timeout interrupt on a
partially full FIFO.

On Mon, Jul 18, 2016 at 9:59 PM, Hal Murray hmurray@megapathdsl.net wrote:

The aged 16550 has various timeouts so an interrupt is triggered with
a partially full buffer even if it is below the interrupt threshold.
For implementations which do not do that, I assume they intend for the
UART to be polled regularly.

On Mon, 18 Jul 2016 23:42:34 -0400, you wrote:

Long ago I measured the impact of the linux low_latency flag on a 16550 UART.  I don't know where that data is sitting now, but I remember that it made a significant difference.

On 7/18/16 9:44 PM, David wrote:

exactly... you have some sort of blocking read that waits either for an
interrupt or for time to expire

John Ackermann N8UR wrote:

AFAIK the low_latency flag just sets the UART's FIFO threshold to 1,
i.e. the UART generates an IRQ when the 1st character came in. If you
don't set this flag then the FIFO threshold is set to something different.

A very quick search on the Linux source code seems to indicate the
default threshold is 16 in current kernels, but if I remember correctly
then it was 4 or 8 in earlier kernel versions.

If you need to timestamp the 1st character of the serial time string
then things are easy. For example, for Meinberg time strings the
on-rtime character is the 1st character, STX (0x02), and subsequent
characters are sent without gap. So it doesn't matter much if you get an
IRQ after the 1st character, and compensate for 1 character only, or the
IRQ occurs after the 8th character, and you compensate for 8 characters.
But of course you need to know the current FIFO threshold.

I think if you need to timestamp e.g. the CR of LF at the end of a
string which eventually has even variable length then the timing may
vary depending on the actual string length.

E.g., with a FIFO threshold of 16 the first IRQ is generated when 16
characters have been received, but if the whole string is e.g. only 30
characters then only 14 characters follow after the first part, and the
FIFO threshold (16) is never reached by that single string. I'm not sure
if the UART then generates an IRQ anyway after some kind of timeout, but
this seems to make exact timing quite a bit more tricky.

Martin

On Tue, 19 Jul 2016 06:16:16 -0700, you wrote:

Oh, from the application program interface?  Ya, that would be a
problem if it lacks a non-blocking read.  The UART itself has a status
flag which says if there is data available to be read but if you
cannot access that, then you have to wait for the UART's interrupt
timeout assuming it has one.

I seem to recall this issue coming up long ago in connection with
dodgy 16550 implementations where data was getting stuck below the
interrupt threshold but I never encountered it myself.  For the lower
level programming I have done, it was never an issue since I had
direct access to the hardware and could check the flags anytime I
wanted.