Hi
For a serial network i need to know when the bytes from a ‘write’ to the
serial port are actually transmitted.
(the send FIFO is empty ).
I think the write returns but there are still bytes in the UART’s FIFO to
be transmitted.
Can someone clear this out to me ?
Johan
Sagaert Johan <sagaert.j@belgacom.net> wrote:
Hi
For a serial network i need to know when the bytes from a ‘write’ to the
serial port are actually transmitted.
(the send FIFO is empty ).
write() will generally return when the data has been buffered in the serial
port’s outgoing data buffer.
I think the write returns but there are still bytes in the UART’s FIFO to
be transmitted.Can someone clear this out to me ?
I was going to suggest tcdrain(), but it looks like it will return when
all the data has been written to the uart. It doesn’t look like it will
wait until the FIFO on the uart has drained.
So… I don’t think there is any standard notification process back to an
application for when the UART has drained the FIFO.
Unless I’m wrong – you may need to take the driver source, and customise
it to detect that condition on your hardware, and notify when it happens.
I’d suggest using an ionotify() for that condition, with it being an
“Out of bound” condition if you want to keep it resmgr-ish, or just register
an event with a devctl() and MsgDeliverEvent() in the driver when the
condition is satisfied. Or, even, make it a blocking devctl(), that is
only replied to when the condition is satisfied.
QNX Training Services
http://www.qnx.com/services/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote:
DG > Sagaert Johan <sagaert.j@belgacom.net> wrote:
Hi
For a serial network i need to know when the bytes from a ‘write’ to the
serial port are actually transmitted.
(the send FIFO is empty ).
DG > write() will generally return when the data has been buffered in the serial
DG > port’s outgoing data buffer.
I think the write returns but there are still bytes in the UART’s FIFO to
be transmitted.Can someone clear this out to me ?
DG > I was going to suggest tcdrain(), but it looks like it will return when
DG > all the data has been written to the uart. It doesn’t look like it will
DG > wait until the FIFO on the uart has drained.
DG > So… I don’t think there is any standard notification process back to an
DG > application for when the UART has drained the FIFO.
DG > Unless I’m wrong – you may need to take the driver source, and customise
DG > it to detect that condition on your hardware, and notify when it happens.
DG > I’d suggest using an ionotify() for that condition, with it being an
DG > “Out of bound” condition if you want to keep it resmgr-ish, or just register
DG > an event with a devctl() and MsgDeliverEvent() in the driver when the
DG > condition is satisfied. Or, even, make it a blocking devctl(), that is
DG > only replied to when the condition is satisfied.
IF it is harmless to transmit some extra characters, like maybe NULLs, and
IF you know how many characters the UART can buffer, then
transmit that number of extra characters after your data message, then
you can use txdrain() and know when all of YOUR data has left the UART.
If you have Rx and Tx tied together then reading back the data stream to
verify that all data has been sent instead of just flushing the receive
buffer should work.