This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, 23 Oct 2003 12:52:21 +0200
Thomas Koeller <thomas.koeller@baslerweb.com> wrote:

> Laurent GONZALEZ wrote:
> > On Thu, 23 Oct 2003 11:31:15 +0200
> >
> > There is no doubt that your driver is better than the old one. But I
> > noticed that you did not use the double buffer swapping trick, that
> > has been discussed here several time.
> >
> > The DMA capability of the AT91 is only used to continue receiving
> > chars during the execution of ISR and DSR. It's a good idea, but you
> > still needs two buffers and another swapping method. The major
> > drawback of your code is that it does not change the interrupt rate
> > enough. So under heavy load, I wonder if your driver will be
> > reliable enough.
> >
> > Have you ever tried to pass the serial test serial3 ? And with long
> > packets (see line 121) ?
> >
> > If someone interrested, i will contribute my idea of the reliable
> > driver for at91, using two buffer for direct PDC usage. I already
> > tested networking load (ftp server) over serial lines at 115200 and
> > more, without any packet loose.
> 
> Strange - I thought I used double-buffering...
> 

oh yes, you did, I never say anything else.

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:

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.

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.

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.

Have you tried to pass the eCos serial tests ?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]