[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: serial ports on devboard_lx

----- Original Message ----- 
From: "Amit Kucheria" <akucheria@xxxxxxx.com>
To: "Mikael Starvik" <starvik@xxxxxxx.com>
Cc: "Johan Adolfsson" <johana@xxxxxxx.com>
Sent: Thursday, March 20, 2003 20:42
Subject: RE: serial ports on devboard_lx

> Hi,
> 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
really matter.
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.

> Thanks.
> Regards,
> Amit

Best regards

> 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):
> > 
> > minimum latency
> > 2. Enable CONFIG_ETRAX_SERIAL_FAST_TIMER (requires
> > 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