Michael Trimarchi wrote:
> Hi,
> > Thanks. Actually, I have simillar problems (buffer
> > overrun) when working
> > with serial port (at91sam9260-ek based board). But,
> > I haven't inspected the
> > problem more than that. I'll do that next week.
> >
> > On Feb 8, 2008 8:36 PM, Gilles Chanteperdrix
> > <[EMAIL PROTECTED]>
> > wrote:
> >
> > >
> > > I received a mail from Michael recently telling me
> > that he observes the
> > > same behaviour with the PREEMPT_RT patch, so the
> > I-pipe patch is
> > > probably out of cause. He now suspects a hardware
> > issue (one serial port
> > > pin seems to be shared with another peripheral, as
> > I think I understood).
> > >
> > >
> >
> I finish my investigation, and I think that depens
> only
> in some overhead. In linux is present using hrtimer
> and doesn't depends on NO_HZ options. If some hrtimer
> is executed with the interrupts disabled and the
> serial
> must receive a single char, you receive and overrun.
> I suppose that the NO_HZ option can be a solution
> (less interrupt) but an the end, doesn't change. The
> dma
> patch on serial device resolve the problem. I think
> that for adeos is the same. I try to investigate, how
> long is the max blocking time in hrtimer interrupt.
>
> Using TC timer is ok. David and Gilles, you are right
> but I want to know how in linux-rt and adeos, I can
> reduce the latency to support this interrupts
> frquency.
If I were you, if this serial driver was used only for debugging, I
would tolerate overruns. And if my application relied on the correct
working of a serial driver, I would use another driver, because you can
not base a system on a driver needing 10000 interrupts by second without
loss. This is not reasonable, especially on ARM. Or use a lower baud
rate.
--
Gilles Chanteperdrix.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
