News Group Posts

modem dtr

From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Dropping DTR in OSR5
Date: 5 Nov 2001 01:39:05 GMT
References: <9s40rp$fdh$1@newsmaster.cc.columbia.edu>
<3be5c667$0$439$8eec23a@newsreader.tycho.net>
<20011104160917.A13779@mammoth.ca.sco.com> 

In article <20011104160917.A13779@mammoth.ca.sco.com>,
Bela Lubkin  <belal@sco.com> wrote:
: John DuBois wrote:
: > ...
: > Some problems in this area were fixed in 5.0.6a.  Please test on that
: > release and see if you still encounter this problem.
: 
: While this is true, Frank likes to support every OS ever made.  I
: believe he still builds binaries for SCO Xenix.  A solution which
: requires users to have an OS less than a year old won't satisfy him...
: 
Strange but absolutely true.  People still run old -- even ancient --
Unix OS's, including SCO Xenix.  Doctors' offices are a good place to
look for computing antiques.  I know a doctor who runs his practice from
an AT&T 3B2.  The billing package only runs there, the vendor disappeared
decades ago...

: The OpenServer "sio" driver doesn't implement ispeed and ospeed as
: separate entities.  The functions exist and the structures have all the
: necessary members, but it doesn't pay attention to the input rate, only
: the output rate.  At least, that's how it's _intended_ to work.
:
Aha, the truth comes out...  Strict POSIX on the outside, not so strict
on the inside :-)

Actually a pet peeve of mine is how latter-day SCO header files (and
most other vendors) are full of:

  #if !defined(_XOPEN_SOURCE) && !defined(_POSIX_SOURCE)

to keep you from getting at anything useful -- hardware flow control, for
example.  In many cases also high serial speeds.  But I digress...

: I vaguely remember that you can get into trouble -- confuse the driver --
: by trying to change both.  This might have been one of the things fixed in
: rs506a.  But I think the problem can be avoided on all releases, by only
: programming the output speed.  So, suppose you test with only changing
: ospeed, see whether that makes a difference?
: 
I just tried this on 5.0.2 -- no difference.  DTR and RTS go down,
but only DTR come back up.

: This also isn't a general solution.  There are third party drivers that
: slot into the same ioctls, but _do_ correctly support independent i/o
: speeds.  Does Kermit have any system-specific hint settings?  Something
: like an OpenServer-specific "set ignore-ospeed", turned on by default?
: "On" is the correct default since "sio" is the most common serial driver
: on OpenServer, and split-speed usage is rather uncommon.
: 
The third-party drivers is a land I don't have a passport for.  Device
names, lockfile conventions, who knows what else.  I have reams of
correspondence on this stuff, and the conclusion is always "don't touch
it".  I figure if Digi or Stallion or somebody wants Kermit to support
their stuff, they'll contact me about it.

: And, if I'm wrong, you might try an even kludgier workaround (which also
: might not work, but is definitely worth trying): after having performed
: all the POSIXly correct incantations, i.e. after the 2nd tcsetattr() in
: your pseudo-code above, force an extra open of the port:
: 
:   ...
:   tcsetattr()
:   if ((kludge_fd = open(the_port, O_RDONLY | O_NONBLOCK | O_NOCTTY)) >= 0)
:     close(kludge_fd);
: 
: I'm pretty sure this will cause "sio" to get its house in order and
: raise DTR (and the close shouldn't lower it, since the other open still
: exists).  For debugging purposes you might need to put in a pause before
: the close() to observe that DTR actually goes on -- I don't fully trust
: my assertion that the close() won't lower it.
: 
In fact DTR comes back on, but RTS stays down, just as without the kludge.
The kludge does make a difference in 5.0.5, however: it makes it act like
5.0.2 (without the kludge in 5.0.5, both DTR and RTS stayed down).

: One last thing.  There's a comment in the driver that implies that after
: cycling the baud rate through 0, DTR might not come back up immediately;
: might only come up when you output a character.  I'm pretty sure this is
: fixed in rs506a, but for older releases, see whether outputting a NUL
: after the 2nd tcsetattr() causes DTR to wake up.
: 
In 5.0.2 DTR came up anyway, but RTS does not come back up, even when you
send bytes.   Ditto for 5.0.5 with and without all the above tricks.

In short there seems to be no way to do this in OSR5 prior to 5.0.6a.  Hard
to believe, right?  But not surprising either since I think Kermit must be
the only program that would want to momentarily drop DTR without closing the
device (and of course the problem with closing the device is that you've
lost all the myriad setups you've done on it when you reopen it).

Thanks!

- Frank
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.