[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: serial ports on devboard_lx
----- Original Message -----
From: "Amit Kucheria" <firstname.lastname@example.org>
To: "Mikael Starvik" <email@example.com>
Cc: "Johan Adolfsson" <firstname.lastname@example.org>
Sent: Thursday, March 20, 2003 20:42
Subject: RE: serial ports on devboard_lx
> Thanks for your reply.
> I tried out option 2 and it brings the performance to acceptable levels
> (roughly 5ms greater than PC-to-PC results for 115200 baud).
> A quick look at the code tells me that CONFIG_ETRAX_FAST_TIMER seems to
> be a way of achieving better timer resolution not unlike "highres
> timers" from MonteVista and KURT's UTIME approach
> (www.ittc.ku.edu/kurt/). Is that understanding right?
Yes, that's correct although the ETRAX fast timer is handled
independently from the ordinary timers and uses a second hardware timer
instead of reprogramming the timer used to generate the normal "jiffies"
I beleive that is the best way to do it to avoid "loosing time" which
could happen when reprogramming the tick timer. (
> What is the
> processing penalty in this case (in terms of CPU usage)?
Sorry, don't have any numbers on that.
> Besides reducing interrupt processing, is there any other reason to make
> the driver timer-driver instead of interrupt-driven?
Well, the timer approach is needed if we use DMA, since there are no
automatic flushing of the DMA when the line has been idle for a while.
If the data over the serial port is streaming data with high throughput,
DMA is more efficient, but for short packet based data, interrupt-driven
could give you lower latency and the extra interrupt processing wouldn't
It's on our todo list to add support for doing interrupt-driven transfers
without DMA, can't give you any date though.
> What is the size of the serial FIFO buffers?
The fifos (that belongs to the DMA channel - not really the serial port)
are 64 byte fifos.
> On Wed, 2003-03-19 at 22:17, Mikael Starvik wrote:
> > Hi,
> > With ETRAX it is a bit difficult to detect that a small
> > number of characters has been received (and there won't
> > be any more characters). We have three different
> > implementations that solves this in software (you can only
> > enable one of them at any time):
> > 1. CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS. Set this to 0 for
> > minimum latency
> > 2. Enable CONFIG_ETRAX_SERIAL_FAST_TIMER (requires
> > CONFIG_ETRAX_FAST_TIMER)
> > 3. CONFIG_ETRAX_SERIAL_FLUSH_DMA_FAST gives minimum latency
> > but impacts performance severely.
> > Can you try if any of these improves the numbers?
> > Another not yet implemented approach would be to make the
> > driver interrupt driven.
> > /Mikael