Re: patch - at91 serial drivers assumed realtime response for DSR routines

[Laurent GONZALEZ <laurent dot gonzalez at silicomp dot fr>]

On Thu, 23 Oct 2003 14:40:36 +0200
Thomas Koeller <thomas.koeller@baslerweb.com> wrote:

> Laurent GONZALEZ wrote:
> >
> > The DMA capability is only used to handle the latency, the time from
> > the Rx interrupt to the scheduling of the DSR. I guess your buffer
> > will not fill more than 2 or 3 chars (and only under heavy load).
> > Moreover, your code only requires the use of one buffer, not two:
> 
> I didn't really investigate this, but I suspect that the buffer can
> fill much more than that. After all, execution of the DSR can be
> delayed by other DSRs (the system timer, for instance, which may call
> user-supplied handler functions). In any case, it's preferable to
> always have some leeway.

I agree for that.

> 
> >
> > rcv_buffer[cb] liveness is restricted to the execution of ISR,
> > followed by its corresponding DSR, and at the end of DSR, the data
> > may be safely ignored.
> > The second buffer is useless, because no new ISR will happen until
> > the current DSR ends. In other words, both rx buffers will never
> > been accessed simultaneously.
> 
> This is not true. If I first processed all characters received and
> then re-enabled the interrupt just before exiting from the DSR, I
> would create a time window during which data might be lost. I have to
> redirect any input data to the second buffer _before_ processing the
> data just received. Therefore, the second buffer is absolutly
> required.

Sorry I did not notice that the interrupt were reenabled before
unloading the current buffer. 

> 
> >
> > The major drawback of your solution is that the IT rate is still
> > high under heavy load, the continuous cycle ISR-DSR during a receive
> > burst, will completely hangs other running thread, and you will
> > loose real-time performance.
> >
> 
> This cannot be avoided. The driver must be able to respond to any
> single character received, because an application might want to
> receive characters sent one by one.

And that is the major point. Carefully reading the at91 manual, it is to
notice that at91 provide a powerfull timeout mechanism, to raise an
interrupt if the line is idle after the last receive character. Using
this, the driver will respond to a single char under ligth load, and
will use full buffering capability under heavy load.

> 
> > I do not say that your driver is not good, I say IT IS GOOD and
> > reliable enough for the mostly application. But, we can do much
> > better.
> 
> O.k., do it better, then.

Yes i will contribute my code until the end of the day. I'am running
eCos tests to provide source code and benchmark.

> >
> > Have you tried to pass the eCos serial tests ?
> 
> I'll do, as soon as I get some time to spend on this. However, the
> tests I performed have been quite exhaustive. I even tested the
> polling mode.
> 

-- 
GONZALEZ Laurent
Silicomp Research Institute
Tel: 04 76 41 66 98