Re: AT91 serial driver

["Gary Thomas" <gary at mlbassoc dot com>]

Øyvind Harboe said:
> So far I've run my patch through stress tests(lots of serial
> communication + a soft 16x5x implemented in a FPGA), and it seems to
> work fine @ 38400. My primary concern is not to loose chars and not to
> introduce too long a delay from a char arrives until my app sees it.
>
> I haven't tested or looked very carefully at the other two patches.
>
> It doesn't matter to me whether my patch(reformulated existing work)
> gets comitted or not, but I'll be sure to take whatever gets committed
> for a spin to see if it performs well enough for my app.
>
> Here is a thought: there is no way I can use eCos in its committed state
> for my application, hence I've made moficiations that are part patches
> that have not been committed(and they may never be) and part highly
> application specific tweaks. This means that the eCos source code itself
> is a second level of configuration, where ecos.ecc is the primary.
>

Why is this the case?  We make every effort to keep the "core" sources
in such a state that they are usable by everyone and the design is _supposed_
to be such that extraordinary circumstances can be handled outside of the
kernel - in other words, we try to not ever have it be the case that changes
need to be made to the kernel proper which can't be used, or at least present
if not enabled, by everyone.

If you can explain why this doesn't work for you, we'd (at least me) would
like to understand your situation.

> IMHO, the most important thing right now, is not the exact form or final
> details of the serial driver patch, but to converge our efforts such
> that we can yet again share work and experiences.
>
> The patch to choose to commit, would be the one that can most easily be
> tweaked through .ecc options and source code changes into whatever each
> of need.
>
> Ã?yvind
>
>
>