This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: patch - at91 serial drivers assumed realtime response for DSR routines
On Thu, 23 Oct 2003 15:25:48 +0200
Thomas Koeller <thomas.koeller@baslerweb.com> wrote:
> Laurent GONZALEZ wrote:
> > > 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.
> >
>
> But that would result in arbitrary delays that are visible to the
> application. You would need to pick some delay value at random, or
> make it a configuration parameter. I find this undesirable; it is
> not the driver's business to enforce this kind of policy decision
> upon the application. If it needs to transfer data at a rate that
> significantly loads the CPU in order to serve its purpose (maybe in
> bursts only), than it must be able to do so.
>
Yes, the delay is arbitrary, and the value is choosen at random. But
most of the available high performance chip (e.g. 16x5x family)
integrate such arbitrary timeout. I work with some of them and they
provide a delay around 4 chars (40 bit). I don't think that a delay of
... 20 bit for example, is undesirable. You may at least recompute it in
function of the speed to be x microseconds.
--
GONZALEZ Laurent
Silicomp Research Institute
Tel: 04 76 41 66 98