Re: patch - at91 serial drivers assumed realtime response for DSRroutines

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

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

I seem to recall that Paul Sheer no longer was into eCos(did he have his
own real-time os?). 

Is it realistic to get an assignment?

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

That shouldn't be hard.

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

I've got an EB40a, and I've never gotten it to work >38400, even when
I'm running everything from onchipo 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

Are the other parts "flash-cheap-sram-expensive" as well?

> interrupt vectors, VSR table and virtual vector table.

The eb40a does appear to be the most popular, at least here in the eCos
mailing lists. If the PDC stuff was made configurable, these other parts
would be no worse off than today.

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

Thats one *big* patch.

It would be a shame to ditch a partial intermediate solution to the
problem, in anticipation of a complete and correct solution that may
take a long time to materialise. 

Ãyvind