Hi, I have been working on porting code for communicating with a device over
a serial interface to qnx 6. My program usually works fine. However, on
rare occasions, when I write to the fd for the serial connection, my message
isn’t actually transmitted over the serial line for several seconds. I know
this because I call tcdrain (), which causes the process to wait until any
data sent to the specified fd has been transmitted. Does anyone know why
this problem may be occurring and whether there is any way of ensuring that
data sent to a serial device will be transmitted immediately? Please email
me at whomever23@aol.com if you have any ideas.
Thanks,
Andrew
Andrew Lovett <whomever23@aol.com> wrote:
Hi, I have been working on porting code for communicating with a device over
a serial interface to qnx 6. My program usually works fine. However, on
rare occasions, when I write to the fd for the serial connection, my message
isn’t actually transmitted over the serial line for several seconds. I know
this because I call tcdrain (), which causes the process to wait until any
data sent to the specified fd has been transmitted. Does anyone know why
this problem may be occurring and whether there is any way of ensuring that
data sent to a serial device will be transmitted immediately? Please email
me at > whomever23@aol.com > if you have any ideas.
What’s happening on the other end? Has the device been flow-controlled,
either hardware or software?
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:adg1l2$8o7$1@nntp.qnx.com…
Andrew Lovett <> whomever23@aol.com> > wrote:
Hi, I have been working on porting code for communicating with a device
over
a serial interface to qnx 6. My program usually works fine. However,
on
rare occasions, when I write to the fd for the serial connection, my
message
isn’t actually transmitted over the serial line for several seconds. I
know
this because I call tcdrain (), which causes the process to wait until
any
data sent to the specified fd has been transmitted. Does anyone know why
this problem may be occurring and whether there is any way of ensuring
that
data sent to a serial device will be transmitted immediately? Please
me at > whomever23@aol.com > if you have any ideas.What’s happening on the other end? Has the device been flow-controlled,
either hardware or software?-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
I have not been using any flow control. Is it possible that the default
flow control (hardware flow control, right?) could be causing the
communication to suspend. Now that I’ve had more time to work on the
problem, I can describe it in greater detail. When I am rapidly
communicating with a device over the serial port, the serial will, on very
rare occasions, pause several seconds before transmitting data which I have
placed in the serial’s output buffer. I have tried both tcflush-ing the
buffer and filling the output buffer up with 0’s, but even after I do either
of these and retransmit the message, thedelay continues for its duration.
This duration is relatively consistent, also. Depending on where it occurs
in the code it tends to be either a little over 8 seconds or a little over
12 seconds (on the other hand, if I put a tcdrain() immediately after
writing to the serial, the program will sometimes pause forever). I am
sending the messages with a simple write() command. Any ideas what my
problem might be?
Thanks,
Andrew
PS: A couple of people have suggested that some other device may be using
the same interrupts as the serial. I can see how this might be a problem,
but I have no idea how to check it.
Andrew Lovett <whomever23@aol.com> wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:adg1l2$8o7$> 1@nntp.qnx.com> …
Andrew Lovett <> whomever23@aol.com> > wrote:
Hi, I have been working on porting code for communicating with a device
over
a serial interface to qnx 6. My program usually works fine. However,
on
rare occasions, when I write to the fd for the serial connection, my
message
isn’t actually transmitted over the serial line for several seconds. I
know
this because I call tcdrain (), which causes the process to wait until
any
data sent to the specified fd has been transmitted. Does anyone know why
this problem may be occurring and whether there is any way of ensuring
that
data sent to a serial device will be transmitted immediately? Please
me at > whomever23@aol.com > if you have any ideas.What’s happening on the other end? Has the device been flow-controlled,
either hardware or software?-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.I have not been using any flow control. Is it possible that the default
flow control (hardware flow control, right?) could be causing the
communication to suspend. Now that I’ve had more time to work on the
problem, I can describe it in greater detail. When I am rapidly
communicating with a device over the serial port, the serial will, on very
rare occasions, pause several seconds before transmitting data which I have
placed in the serial’s output buffer. I have tried both tcflush-ing the
buffer and filling the output buffer up with 0’s, but even after I do either
of these and retransmit the message, thedelay continues for its duration.
This duration is relatively consistent, also. Depending on where it occurs
in the code it tends to be either a little over 8 seconds or a little over
12 seconds (on the other hand, if I put a tcdrain() immediately after
writing to the serial, the program will sometimes pause forever). I am
sending the messages with a simple write() command. Any ideas what my
problem might be?
You wouldn’t be using flow control – but the device you are taking
to might be.
Can you use stty to check for +ohpaged or +ospaged when the output
is stopped?
This would indicate if the device you are talking to has flow-controlled
you.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:adit8u$ejs$1@nntp.qnx.com…
Andrew Lovett <> whomever23@aol.com> > wrote:
“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:adg1l2$8o7$> 1@nntp.qnx.com> …
Andrew Lovett <> whomever23@aol.com> > wrote:
Hi, I have been working on porting code for communicating with a
device
over
a serial interface to qnx 6. My program usually works fine.
However,
on
rare occasions, when I write to the fd for the serial connection, my
message
isn’t actually transmitted over the serial line for several seconds.
I
know
this because I call tcdrain (), which causes the process to wait
until
any
data sent to the specified fd has been transmitted. Does anyone know
why
this problem may be occurring and whether there is any way of
ensuring
that
data sent to a serial device will be transmitted immediately? Please
me at > whomever23@aol.com > if you have any ideas.What’s happening on the other end? Has the device been
flow-controlled,
either hardware or software?-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.I have not been using any flow control. Is it possible that the default
flow control (hardware flow control, right?) could be causing the
communication to suspend. Now that I’ve had more time to work on the
problem, I can describe it in greater detail. When I am rapidly
communicating with a device over the serial port, the serial will, on
very
rare occasions, pause several seconds before transmitting data which I
have
placed in the serial’s output buffer. I have tried both tcflush-ing the
buffer and filling the output buffer up with 0’s, but even after I do
either
of these and retransmit the message, thedelay continues for its
duration.
This duration is relatively consistent, also. Depending on where it
occurs
in the code it tends to be either a little over 8 seconds or a little
over
12 seconds (on the other hand, if I put a tcdrain() immediately after
writing to the serial, the program will sometimes pause forever). I am
sending the messages with a simple write() command. Any ideas what my
problem might be?You wouldn’t be using flow control – but the device you are taking
to might be.Can you use stty to check for +ohpaged or +ospaged when the output
is stopped?This would indicate if the device you are talking to has flow-controlled
you.-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
No, neither of them was set. stty returned the same output it returns
normally. Could anything else be causing the problem?
Thanks,
Andrew
Andrew Lovett <whomever23@aol.com> wrote:
No, neither of them was set. stty returned the same output it returns
normally. Could anything else be causing the problem?
Hm…something else must be causing the problem…but what is
the tricky bit.
Probably not the problem, but…what baud rate are you using, and how
fast are you writing data? The driver will buffer up to a point, then
stop accepting data until it has drained.
Beyond that, I’m out of ideas.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
The baud rate is 115k, and the program is sending messages rapidly.
However, the serial output buffer isn’t filling up. At times when the pause
occurs, the only data in the buffer is the data just passed to it (generally
around 4 bytes). Also, the input buffer is always empty at the time.
Thanks for the help. I’ll keep searching.
–Andrew
“David Gibbs” <dagibbs@qnx.com> wrote in message
news:adl70p$8i1$1@nntp.qnx.com…
Andrew Lovett <> whomever23@aol.com> > wrote:
No, neither of them was set. stty returned the same output it returns
normally. Could anything else be causing the problem?Hm…something else must be causing the problem…but what is
the tricky bit.Probably not the problem, but…what baud rate are you using, and how
fast are you writing data? The driver will buffer up to a point, then
stop accepting data until it has drained.Beyond that, I’m out of ideas.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
Andrew Lovett <whomever23@aol.com> wrote:
The baud rate is 115k, and the program is sending messages rapidly.
However, the serial output buffer isn’t filling up. At times when the pause
occurs, the only data in the buffer is the data just passed to it (generally
around 4 bytes). Also, the input buffer is always empty at the time.
Thanks for the help. I’ll keep searching.
This might be pretty simple, but are you check the return value from write to
make sure all of you characters are making it to the output buffer?
Tom