Hello all,

Long after most people has thought serial ports are dead, I have a problem.

I am running Fedora Core 4, on a Toshiba PM-2.0GHz Laptop.

My application is collecting video data (via coriander on Firewire) and GPS + inertial data on a serial port, via a custom application.

Each program on their own works well.

However, when we start streaming images, we are losing data on the serial port. Interestingly, we are NOT getting the same problem on the USB port.

This is what I have gathered so far:
- From /proc/tty/driver/serial, there are quite a few overrun errors, and data is being lost. Port is set to the usual /dev/ttyS0 parameters automatically, including IRQ.

Given that the USB-serial convert works in the same instance, it is almost certian that the 16-byte FIFO on the 16550A uart is being overrun, since it is not getting serviced fast enough.

From a couple of days of googling, it looks like a receive interrupt is generated after 14 bytes, meaning at the decent data rates (well, relative to serial ) we are using, the 2 bytes could be easily overrun. It's like this to minimise the number of rx interrupts the CUP has to service.

The problem is, neither setserial, stty, ioctrl or termios allow the receive interrupt trigger to be easly changed. Ironically, you can acutally change this quite easily in windows...

I have also investigated changing the IRQ priority, which seemed to have some success for PPP irqtune utility.

Unfortunantly, it refuses to install under FC4. See linuxforums.org/forum/peripherals-hardware/31952-i-thought-ext-usr-modem-would-work-umm-no.html[/url] to see what the problem there is (and yes, I tried all what was said there, and more).

Hence, I'd love if somone has information on the following
- Setting the Recieve interrupt trigger level on the 16550A UART
- Changing the priorities of IRQs under a 2.6 kernel.

Thanks,
Damien Dusha.

This might not really be the best suggestion, but if you can't find anything else to help, you may as well try.

Don't use interrupts. Write a program that uses a thread to poll the receiver. Set this thread to be time critical. In the thread's main loop it will sleep for maybe the duration of two-four bytes being sent (ie with 9600 BAUD 8bits 1stopbit 1startbit, receiving 2 bytes will take approx 2 milliseconds). Then check if any bytes are available, read them and place them in some buffer which will be much larger than the 16byte buffer, and restart the the loop.

Since the operation this thread will need to do is not very complex, it will finish a run very quickly. And if you are using a rather low BAUD rate (below 115200 BAUD), it wouldn't need to run too often. Thus polling shouldn't have too dramatic an effect on overall system performance.

But still, I myself would only use polling as a last resort.