During read/write operation on a serial port (/dev/ser1…5), sometimes the
hardware connected to it is cut off. This, by design, is legal according to
the hardware specifications. The problem is, sometimes when this occurs,
the “+ohpaged” flag becomes set…found out by using "stty <
/dev/ser(1…5). When this happens, our program cannot communicate/initialize
the serial port when restarted. Obviously we are not doing something
incorrectly during initialization of the serial port…
…the qnx documentation indicated that it (+ohpaged) is “the output is
paged by hardware flow control”
…The current settings before this happens is the following:
When the hang up occurs, these exact settings remain with the exception of
the ‘+ohpaged’ flag appearing on the 5th line from the top.
First question is, what does that mean exactly. Does the serial port have a
page of data waiting to transfer out? If so, what is the correct way to
clear this flag. Right now I am using…
tcflow(filedes, TCOONHW); where TCOONHW is defined as “will cause output to
be resumed on the device associated with ‘filedes’ using hardware flow
control”
…Once I call that function with the TCOONHW argument, the +ohpaged
flag/bit is reset to 0, hence everything communicated OK again… The second
and main question is; Is this the correct way to clear this, why would it be
left un-cleared and should I even be trying to clear it rather then deal
with it properly?..
… Any help on this matter would be greatly appreciated!
Because ohflow is set, ohpaged is legal. Ohflow means that when the far
end sends a “shut up” by dropping its DTR, your end becomes paged while
waiting for DTR to be raised, or for you to override the condition, such
as by the tcflow() call or stty < -ohpaged.
Similar deal with ihflow going the other way.
I’m not sure why DTR isn’t put back when the connection is re-made,
unless there really is no wire to be raised and lowered, in which case
you ought to turn off ohflow (and ihflow perhaps).
Richard
TGF wrote:
During read/write operation on a serial port (/dev/ser1…5), sometimes the
hardware connected to it is cut off. This, by design, is legal according to
the hardware specifications. The problem is, sometimes when this occurs,
the “+ohpaged” flag becomes set…found out by using "stty
/dev/ser(1…5). When this happens, our program cannot communicate/initialize
the serial port when restarted. Obviously we are not doing something
incorrectly during initialization of the serial port…
…the qnx documentation indicated that it (+ohpaged) is “the output is
paged by hardware flow control”
…The current settings before this happens is the following:
When the hang up occurs, these exact settings remain with the exception of
the ‘+ohpaged’ flag appearing on the 5th line from the top.
First question is, what does that mean exactly. Does the serial port have a
page of data waiting to transfer out? If so, what is the correct way to
clear this flag. Right now I am using…
tcflow(filedes, TCOONHW); where TCOONHW is defined as “will cause output to
be resumed on the device associated with ‘filedes’ using hardware flow
control”
…Once I call that function with the TCOONHW argument, the +ohpaged
flag/bit is reset to 0, hence everything communicated OK again… The second
and main question is; Is this the correct way to clear this, why would it be
left un-cleared and should I even be trying to clear it rather then deal
with it properly?..
… Any help on this matter would be greatly appreciated!