Blocking write on serial port

[Norman Weiss]

Hi,

I have a problem with programming the serial ports on Linux: I need a
blocking write. Whereas blocking reads seem to be no problem, I haven't
found a way to block my program as long as not all of the characters
sent to the serial port have been really sent to the communication
partner. I need this for a half duplex radio module, after sending data
I have to switch it back to receive mode, if this is done to early the
data sent will be corrupted.
So: I need either an option to make the call to write() blocking, or a
way to find out the fill state of the transmit buffer. (Any other ways
also appreciated ;-)

Thanks,
Norman Weiss

--
**********************************************
* Norman Weiss * http://www.normanweiss.de *
* * newsreply(at)normanweiss.de *
**********************************************

[Pete Zaitcev]

> So: I need either an option to make the call to write() blocking, or a
> way to find out the fill state of the transmit buffer. (Any other ways
> also appreciated ;-)
>
> Thanks,
> Norman Weiss

There's an ioctl for that, check termios(3) and the serial.c.
Write blocks if you write too much, and sits blocked until
there's space in the output buffer. Then it returns before
all data were transmitted, as you observed. The idea behind
it is that close(2) will wait until it is all transmitted,
but I think you have to use ioclts, because close will mess with
your modem control lines.

Supporting TNC is a little tricky, but not a rocket science.
I think a better way would be to find an existing package that
deals with AX.25 or something, and reuse that code.

-- Pete

[Grant Edwards]

In article <3C869504...@normanweiss.de>, Norman Weiss wrote:

> I have a problem with programming the serial ports on Linux: I need a
> blocking write. Whereas blocking reads seem to be no problem, I haven't
> found a way to block my program as long as not all of the characters
> sent to the serial port have been really sent to the communication
> partner.

man tcdrain

--
Grant Edwards grante Yow! Did an Italian CRANE
at OPERATOR just experience
visi.com uninhibited sensations in
a MALIBU HOT TUB?

[Markus Mohr]

> man tcdrain

tcdrain() waits until all output written to the object
referred to by fd has been transmitted.

Is that the buffer in system memory or that on the UART?
And as an additional question: is there a way to find out how many
bytes are still in the UARTs output buffer?
Or better: is there a signal/interrupt when the output buffer runs
dry? (as is the case under DOS)

thanks for your help
marksu

[Grant Edwards]

In article <ffa6bccc.02030...@posting.google.com>, Markus Mohr wrote:
>> man tcdrain
>
> tcdrain() waits until all output written to the object
> referred to by fd has been transmitted.
>
> Is that the buffer in system memory or that on the UART?

It returns when the system tx buffer, the UART tx FIFO, the
UART tx holding register and the UART tx shift register are all
empty. At least that's what the standard 16x50 driver does.
If you're using a different type of serial port, you'd have to
look at the appropriate sources to find out for sure.

> And as an additional question: is there a way to find out how many
> bytes are still in the UARTs output buffer?

No.

> Or better: is there a signal/interrupt when the output buffer runs
> dry? (as is the case under DOS)

No.

BTW, the was no such thing under DOS. The serial support
provided by DOS was strictly a dumb polling scheme.

--
Grant Edwards grante Yow! I need "RONDO".
at
visi.com