Date: Mon, 07 Feb 2000 12:24:10 +0000
From: Dr Jaime V Miro <[EMAIL PROTECTED]>
This is the situation: I've got 1 thread reading and another writing
writing over a serial port (16550). It's configured without Flow Control
(TX/RX/GND lines, that's all there is). I'm receving packets at 9600
bauds every 40ms, and get them all, no probs. But sending is more
problematic. I'd like to send packets continuosly, in a while(true)
loop. But if I don't pause and wait for the packet to be fully
transmitted from the buffer, it obviously overruns the buffer and I send
rubbish. I can slow things down with SW waits, and it kind of works, but
it is not the solution I am after. The question is probably quite clear
by now: is there a way I can grab some sort of indication the TX buffer
is empty and ready to send again?
If what you say is true, there's a bug somewhere; either in the serial
driver, in your sending hardware, or in the receiving hardware that is
reporting garbage when you are transmitting at full speed.
The way the serial driver works is that it knows how big the TX FIFO is,
and it fills it, and then waits for a transmit interrupt. The transmit
interrupt is spec'ed to come when the FIFO is empty (although the
transmitter will still be shifting the last character out the shift
register). When the serial driver gets this interrupt, the TX FIFO is
empty, and then serial driver loads up the FIFO with enough bytes to
completely fill the TX FIFO. So the serial driver is already doing what
you're trying to ask it to do, only automatically and at interrupt time.
I have in the past done tests where two ports are connectted together
with a null modem, and then bytes are blasted across the null modem at
115200 bps, and there has been no problems with the data transfer. This
is why I'm reasonably certain there isn't a bug in the serial driver in
this area, and the bug is probably either in your transmitting UART, or
that your receiver isn't able to keep up receiving all of the characters
(presumably plus whatever else it has to do).
You might want to try disabling using the transmit FIFO altogether, by
using the command "setserial /dev/ttySx uart 16450". (You can re-enable
it by setting the uart type back to 16550a). If that fixes it, then you
have a buggy uart, and you should either replace it, or live with the
workaround of forcing Linux to treat it as a FIFO-less UART, which will
increase the interrupt load on your machine.)
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]
