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
- From: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- To: "ecos-patches (E-Mail)" <ecos-patches at sources dot redhat dot com>
- Date: Wed, 22 Oct 2003 12:18:59 +0200
- Subject: RE: patch - at91 serial drivers assumed realtime response for DSR routines
I am currently working on a similar patch, which ís almost completed.
My app is running from slow flash, and I want to transfer data at
high baud rates. If possible, could you put this on hold until I
finished my work? We would then have two implementations to choose from.
tk
-----------------------------------------------
Thomas Koeller, Software Development
Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany
Tel +49 (4102) 463-390
Fax +49 (4102) 463-46390
mailto:Thomas.Koeller@baslerweb.com
http://www.baslerweb.com
> -----Original Message-----
> From: Nick Garnett [mailto:nickg@ecoscentric.com]
> Sent: Wednesday, October 22, 2003 11:03 AM
> To: Øyvind Harboe
> Cc: ecos-patches@sources.redhat.com
> Subject: Re: patch - at91 serial drivers assumed realtime response for
> DSR routines
>
>
> Øyvind Harboe <oyvind.harboe@zylin.com> writes:
>
> > > 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?
>
> As Jani noticed, Paul has an assignment for a HAL port. In theory this
> should cover any other contributions, including this patch. So it
> looks like we can use his code.
>
> >
> > > 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.
>
> Good. In addition things like the buffer sizes and the receive timeout
> should also be config options.
>
> >
> > I've got an EB40a, and I've never gotten it to work >38400,
> even when
> > I'm running everything from onchipo SRAM.
>
> I've certainly had mine running at 115200 -- as I just tried it again
> to check. However, that was only for a relatively short test. Maybe
> it's not sustainable.
>
> >
> > > 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?
> >
>
> Yep.
>
>
> > 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.
>
> I agree. Given that the contribution is usable, and that it is
> suitably configurable, I see no reason not to apply it.
>
> --
> Nick Garnett eCos Kernel Architect
> http://www.ecoscentric.com The eCos and RedBoot experts
>