Re: [ECOS] DSR latency

[Nick Garnett <nickg at ecoscentric dot com>]

Roland Caßebohm <roland.cassebohm@visionsystems.de> writes:

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

OK. That makes things slightly different. I'm still surprised that you
have a problem with a FIFO trigger of 8. That still gives you 8
character times, nearly 700us at 115200bps, to recover. 

None of the system alarm functions do anything significant, mostly
they just wake a thread up somehow. So they should not be absorbing
enormous amounts of time.

Of course DSRs also get delayed by thread-level code when it claims
the scheduler lock, so maybe a combination of several factors is
causing problems. 

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

That's worth trying, but they only really work if you know how much
data is coming, or can detect when there is no more to come. I'm not
sure how well they would work for a normal serial device.

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

I would be very interested to find out where this time is going. 


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


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