Re: [ECOS] DSR latency

[Roland Caßebohm <roland dot cassebohm at visionsystems dot de>]

On Montag, 10. February 2003 20:21, Nick Garnett wrote:
> Roland Caßebohm <roland.cassebohm@visionsystems.de> writes:
> > Hello,
> >
> > I'm using an ARM7TDMI system (Samsung S3C4510A).
> > My problem is that sometimes the time between an ISR and a DSR is very
> > long. I'm using external UARTs (16550) and with higher baudrates I lose
> > characters. There characters are read in the DSR routine of the serial
> > driver (generic 16x5x). So if DSR latency is to long, the FIFO of the
> > UART overruns. I have seen DSR latency of more than 1ms sometimes (with
> > oscilloscope). With help of the kernel instrumentation I have found out,
> > that such long delays happen if the UART interrupt comes in concurens
> > with the system clock DSR and this calls some alarm calls.
>
> The trace you supplied shows the UART DSR is delayed by about 200?s,
> which is still less than one character time at 38400bps. The 16x5x
> FIFO should be able to absorb this slight jitter with no
> problem. Normally we only see things like this in FIFO-less UARTs.

Yes with 38400bps I have no problems, but I want up to 460800bps. It works 
till 115200bps, if I have a low trigger level. With trigger level 8 the UART 
starts to lose characters.

>
> Do you have any alarm functions that may take up to a millisecond to
> run? If so consider moving that function to a thread and just kicking
> the thread from the alarm function.

I don't have any extra alarm function in my application or maybe I don't know 
it. I use the OpenBSD stack, pthreads, signals.

The following alarm is the one for the OpenBSD stack and comes every tick. 
This seems to take 50 µs. The other two alarm calls I don't know jet, because 
the test was made without debug information.
I have to try the same with debug information, so I can search for symbol 
corresponding to arg2 of ALARM_CALL. But it is difficult to catch such a 
situation with the instrumentation.

>
> > Is there any option to give the UART DSR a higher priority as the system
> > clock DSR?
>
> No, DSRs shouldn't need prioritizing like that. They should be short.

Yes I understand, but if there are many short alarm, the clock DSR will be 
long.

>
> > Otherwise I think about changing the serial driver to read the character
> > in the ISR and working in block transfer mode.
>
> We have in the past put a software FIFO between the ISR and DSR, but
> only for FIFO-less devices. The 16x5x should never need it.

I was thinking about before getting any data, using data_rcv_req() to get a 
peace of the buffer and writing in the ISR direct in this buffer. In the DSR 
I call then data_rcv_done() and get with data_rcv_req() a new peace of the 
buffer.

>
>
> The 1ms DSR latency you have seen is worrying, there's nothing is eCos
> that should be absorbing all that time. There must be something else
> going on. Either there is some software in a DSR which should not be
> there, or interrupts are being missed in the hardware, or maybe
> something is disabling interrupts for a long time. 

I think I have to search for the reason more.

> Are you sure that
> the 16x5x FIFOs are actually working?
Yes, I am sure.

Roland

--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss