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: AT91 serial driver


GONZALEZ Laurent wrote:
> True. My driver lacks of configuration. For your application, I suggest
> you to try to reduce the Rx_PDC buffer size from 32 to 8 for example. If
> your records are sent with some "inter-record" delay between each of
> them, I rather you to reduce the time out value programmed in the
> TIMEOUT register from 40 bits to 16 for example.
>
> > Put another way, your driver may reduce overall system load by
> > reducing the number of interrupts to process, but it also prevents me
> > from making any use of the resources thus freed - it is only the idle
> > thread that benefits. If you have to use lower baud rates for some
> > reason, it gets even worse.
>
> Is this behaviour specific to your application ? Your thread sleeps on
> reading one record at time, or several ??

Neither. It does single-character reads and tries to start to decode the
protocol header of any record as soon as the first byte is received. It
is a problem of your approach that it affects the semantics of the read
operation (as compared to existing serial driver implementations) and,
what's worse, the change depends on the way the sender works: if there
are gaps sufficiently large between any two characters received, I will
be notified of any single character, if not, I will receive the data in
chunks.
>
> > However, you do of course have a point - minimizing system load is
> > always good, and depending on the nature of the particular application
> > this advantage may outweigh the speed penalty. Is there any reason why
> > we can't (or shouldn't)
> > have two at91 serial drivers in ecos?
>
> I am not against. On the contrary, we could take advantage of the
> powerfull configuration framework of eCos to let the user choose if he
> prefers responsiveness (yours) or lowest IT rate (mine).
> We all agree on that point: the old driver should disappear !

That's for sure!

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

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]