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


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.

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

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

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

tk.

-- 
--------------------------------------------------

Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel +49 (4102) 463-162
Fax +49 (4102) 463-239

mailto:thomas.koeller@baslerweb.com
http://www.baslerweb.com

==============================


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