[Solved] Re: USB-RS232 adapters vs. machines w/real consoles.

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

On Fri, 25 Nov 2016, Dave McGuire wrote:

>   This is odd to hear.  I use between five and ten various, random,
> cheap Chines USB-RS232 adapters with all manner of chips on a Linux Mint
> system every day.  Have for years.  No issues whatsoever.  Most (but not
> all) handle breaks without issues.

I finally got around to rigging up my RS-232 test block to use on these
adapters.  I was wondering if they were being operated in a way that
didn't assert DTR on open.  That's when the light went on (so to speak).

I've been using DB9 to 6-wire RJ11 adapters wired to provide simple 3-
wire null-modem communication with the ubiquitous 4-line modular phone
cord.  I'd always jumpered DTR to CD and DSR locally and wired the
additional pair of lines as RTS/CTS so that if I ever obtained 6-line
modular phone cord, I'd have hardware handshaking.  Somewhere in my
collection are some 4-line DB9-RJ11 adapters and they have RTS/CTS
jumpered as well as DTR/CD/DSR.

(My wiring of these adapters is a bit odd, dating from my CP/M days,
before I or most people had heard of Cisco--probably before they existed.)

A Cisco-compatible 6-line cord would use the extra pair for DTR/DSR
(IIRC, likely with DSR jumpered to CD), so the obvious completion would
be to jumper RTS/CTS together.

I reworked one of my DB9-RJ11 adapters to jumper RTS/CTS and all the
adapters were then capable of transmitting under Linux Mint 17.3.  The
Belkin/MCT adapter still does not transmit BREAK.

NetBSD's com/ucom driver always defaulted to no handshaking, so they
didn't care that RTS/CTS were not connected to anything.  (The Belkin/MCT
device, however still needs CTS active to transmit under NetBSD.  It
identifies itself as a PDA adapter, so that probably explains both its
need for RTS/CTS and inability to transmit BREAK.)

Likewise, gNewSense defaults to no handshaking, so ignores RTS/CTS.
The Belkin/MCT device transmits fine (except, of course, BREAK) under
gNewSense, so perhaps there's something amiss with NetBSD's umct(4)
driver?

So, it would be nice to tell 'cu' on Linux Mint to not use flow control.
It seems to have no equivalent to NetBSD 'cu's "-f" or "-F none".
Attempting to influence it with 'stty' seemed to have no effect.  The
default state showed "crtscts" and setting "-crtscts" had no effect when
'cu' was next run.  The state remained exactly as last set by 'stty'.

Perhaps that's a point in favor of 'minicom' on some platforms.  As I
wrote this, I installed it on the Linux Mint system and it was sane
enough to have empty modem init/hangup strings by default.  I did the
minimal config to set line, speed, and disable all flow control.  It
worked just fine (using KeySpan USA19HS and Belkin/MCT adapters with my
normal 6-line DB9-RJ11 adapter).

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645