This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: DSR latency
On Donnerstag, 13. Februar 2003 01:31, Jonathan Larmour wrote:
> Nick Garnett wrote:
> > 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.
>
> One other thought is if you are doing any diagnostic I/O using e.g.
> diag_printf, especially if it's to GDB, then interrupts are disabled for
> that time, which can reduce interrupt latency. diag output isn't intended
> for "real" applications :-).
Yes, diagnostic I/O is off and also "using rom monitor" is off.
>
> >>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.
>
> It should be alright if the buffer is large enough so that you can be
> conservative with how much you want to be able to put in at once.
>
> It's also worth making sure flow control, line status stuff and select
> support is off if you don't need them as they increase the DSR time.
I need this all too, so I can't make it off.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss