[Gumstix-users] Please Help, Connex 400xm STUART FIFO Overrun Errors -Possible So lution?

[Gil Y. <Gil_Yetter@SensArray.com>]

We are experiencing sporadic serial port overrun errors in a real time
application currently under development running on a Connex 400xm. The
overruns have been detected by executing the line 'cat
/proc/tty/drivers/PXA\ serial' on the console which produces the following
output:

# cat /proc/tty/driver/PXA\ serial
serinfo:1.0 driver revision:
0: uart:FFUART mmio:0x40100000 irq:15 tx:532 rx:1 brk:1
RTS|CTS|DTR|DSR|CD|RI
1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0
2: uart:STUART mmio:0x40700000 irq:13 tx:22911 rx:1085173517 brk:5 oe:79
RTS|DTR
3: uart:HWUART mmio:0x41600000 irq:0 tx:0 rx:0

The current application consists of external hardware communicating
asynchronously at 57.6Kbps serially on the STUART (ttyS2). The communication
from the external hardware to the Gumstix is periodic (25Hz) and consists of
protocol packets containing 100 bytes. The application performs various
mathematical calculations on the data; writes information to a Sqlite
database; buffers 10 seconds worth of data and then generates a line chart
using gnuplot; and writes the data to a binary file in 4kbyte chunks. 
What we determined experimentally is that when the Gumstix is under file IO
load of Sqlite database inserts, gnuplot data file generation, and binary
file writing that the 64 byte STUART hardware FIFO will sporadically
overrun. 

Our hardware configuration includes Bluetooth for future applications and
the NetCF expansion board (for both Ethernet and Flash card memory). We also
use the USB port for Ethernet over USB.
We are ready to add serial flow control to our external hardware. However it
is not clear what the Gumstix side solution for flow control can be.
We would like to consider an attempt to use the HWUART with hardware flow
control enabled to alleviate or completely prevent the overrun errors, but
that does not look possible from the documentation.

1.) Is the use of the HWUART to obtain Flow control possible at all
considering our hardware set?

2.) Is the use of the NSSP port for SPI communication a viable alternative
to develop a serial interface with flow control?  SPI to serial conversion
can be done with the addition of a microcontroller chip interfacing between
the Gumstix and our external hardware, BUT programming the NSSP/SPI within
the Gumstix "build" poses its own set of difficulties. I am not sure how
applicable the example code (Direct Register Access via /dev/mem) for the
NSSP/SPI device driver with chip selects is for this purpose.  Does am SPI
kernel module or device driver exist for the Gumstix build root?

Any information or suggestions would be welcome


Gil Yetter
Director of Sensor Networks
SensArray
Austin Technology Center
1-512-795-0392 x614 
1-512-740-8448 Cell phone
1-512-372-8196 fax
gil...@se...
www.sensarray.com