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


Øyvind Harboe <oyvind.harboe@zylin.com> writes:

> The at91 serial routines are broken in that they assume a very low
> latency for the DSR handler.

As it happens, I have been looking at this problem myself recently.

While Paul Sheer's patch reduced the problems with serial performance,
it did not totally fix it.

> 
> This became a problem when I added a 16x5x serial port to my system,
> which also spends a fair amount of time in the DSR handler.
> 
> My solution was to modify the work that was done to add hardware
> buffering support to the at91 serial routines, but remove the rejected
> modifications done to the interrupt routines. 
> 
> http://sources.redhat.com/ml/ecos-discuss/2002-01/msg00205.html

I believe that code was never assigned, so we cannot use it. Since
your code is based on it, we would have problems accepting it also.

If we manage to solve that, I think I would also like to see use of
the PDC made a configuration option. It adds quite a lot of code and
data and is not needed on all AT91 targets.

> 
> Although the ISR interrupt latency is still an issue, this should be a
> step forward:
> 
> - it would bring the hardware buffering code under the scruteny of the
> eCos community
> - since the code is now in "at91 speak", a bit of the tedium has now
> been removed if someone decides to do the "fast interrupt" support.
> 

My observation is that the EB40A has no problem keeping up with even
the highest baud rate. However, this board uses an AT91R40008 which
has 256k of on-chip SRAM. The other AT91 parts all have just 8k of
on-chip SRAM which eCos does not use, apart from a few words for the
interrupt vectors, VSR table and virtual vector table.

I believe the correct solution is to move the main part of the
interrupt handling code into the on-chip SRAM. However, that requires
some fundamental reorganization of the code in vectors.S, and would
have to be done in such a way to make it configurable, avoid
disturbing other platform HALs and destabilizing the ARM HAL as a
whole. Also, once this has been done, the existing serial ISR code
would work without using the PDC.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com      The eCos and RedBoot experts


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