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

Re: Serial Latency Issues, Baud Rate Affects Buffering



Doh.. regarding the 2.4.22 file at
http://developer.axis.com/download/linux/
it doesn't contain the CRIS specific patches.
You can find the diff file in devboard_82-R1_91.tar.gz
in
http://developer.axis.com/download/devboard_82/latest/

/Johan

----- Original Message -----
From: <johana@xxxxxxx.com>
To: "Eric Sorton" <esorton@xxxxxxx.com>;
<dev-etrax@xxxxxxx.com>
Sent: den 9 januari 2004 20:53
Subject: Re: Serial Latency Issues, Baud Rate Affects Buffering


>
> ----- Original Message -----
> From: "Eric Sorton" <esorton@xxxxxxx.org>
> To: <johana@xxxxxxx.com>
> Sent: den 9 januari 2004 20:22
> Subject: Re: Serial Latency Issues, Baud Rate Affects Buffering
>
>
> > On Friday 09 January 2004 12:31, Johan.Adolfsson@xxxxxxx.com wrote:
> > > The way CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS work
> > > is to check the port at a certain timer tick intervals to see if we
> > > should force the DMA to flush. That interval is not related to the
> > > baudrate so that's one of the reasons it affect the buffering
behaviour.
> >
> > The Configure.help states:
> >
> > Number of timer ticks between flush of receive fifo (1 tick = 10ms).
> >
> > At 4800 baud, each character is transmitted in 2.1ms.  Therefore, 7
> characters
> > are transmitted in ~15ms.  If we flush the buffer every 10ms, then we
> should
> > receive data in our read() looping every 20ms.  This does not occur, we
do
> > not receive data until the buffer is flushed when it is full at 256
bytes.
> >
> > However a comment in the code states:
> >
> > ... forces an end-of-packet for the dma input channel if no chars
> > have been received for CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS/100 s.
>
> Note the "to see if we should force DMA to flush" in the help text,
> which make it consistent with the code - "we should" is only true
> if no data has been received since the last check.
>
> > So it appears that CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS suffers from a
> similar
> > problem to CONFIG_ETRAX_SERIAL_FAST_TIMER that you describe below.
> >
> > What changes would I have to make to force the DMA buffer to flush every
> > CONFIG_ETRAX_SERIAL_RX_TIMEOUT_TICKS regardless of if data has been
> received
> > or not?
>
> You could modify force_eop_if_needed() I guess, but I wouldn't recommend
it.
>
> > > CONFIG_ETRAX_SERIAL_FAST_TIMER on the other hand should force the DMA
to
> > > flush when no new data has arrived in 4 character times.
> > > However - with 7 bytes at 50 Hz the idle time between chunks will be
> less
> > > then 4 character ((7+4)*50 = 550 which is above the throughput
provided
> > > with 4800 baud)
> > >
> > > You could try using the port in manual (interrupt driven) mode
instead,
> >
> > Based upon previous discussions in this newsgroup, I believe this would
> > involve writting a device driver as the current serial.c does not
support
> > interrupt driven operation.  Is this correct?
>
> Not any more, it's implemented in the 2.4.22 kernel along with other
> improvements.
> You can download it from http://developer.axis.com/download/linux/
> The latest version of serial.c is 1.58, but 1.57 should be fine as well
> (unless you use CMSPAR)
> (Not sure what version is in the tarball)
>
> > > or try changing the line:
> > >   info->flush_time_usec = 4*info->char_time_usec;
> > > in os/linux/arch/cris/drivers/serial.c:update_char_time()
> > > to something like:
> > >   if (info->char_time_usec > 1000)
> > >     info->flush_time_usec =
info->char_time_usec+info->char_time_usec/2;
> > >   else
> > >     info->flush_time_usec = 4*info->char_time_usec;
> > >
> > > (or change the 4)
> >
> > My version of serial.c does not have the above code.  It has a line
> similar
> > line where info->flush_time_usec is being set.  Perhaps I need a newer
> > version (version information provided below).
>
> Yes, please try a newer version, see above.
>
> > > What version of os/linux/arch/cris/drivers/serial.c are you using?
> > > See above for why things dont get flushed at 7 chars at 50Hz at 4800
> baud.
> > > Does the data arrive after 256 bytes?
> >
> > Version is "$Id: serial.c,v 1.40 2002/10/14 05:33:18 starvik Exp $".
> >
> > We are running 2.4.19 with a 2.4.19 patch acquired from the Axis
> developer's
> > website.  The date on the patch is 2002-10-24.  Is a newer (better?)
> version
> > available?
> >
> > With fast timers at 4800, we never received any data; not even in 256
byte
> > blocks.  I can rerun the tests to confirm this.
>
> If I remember correctly, I might have fixed such a problem.
> Please try 2.4.22.
>
> > Eric
>
> /Johan
>
>