[buug] serial ports, etc. (Re: [Balug-talk] Anyone good with minicom and serial ports?)
mp at rawbw.com
Fri Jul 23 06:05:09 PDT 2004
Well, I'll mention a few things, as folks might find it useful (even if
the original "problem" has already been solved).
Much of this works relatively the same across various "Unix" flavors
(UNIX, LINUX, ...).
First of all, many flavors have different devices for modem control, and
non-modem control use of any given serial port. Some flavors will even
have more than two devices (each with a unique major and minor) for a
single serial port.
It's usually easiest to start with the non-modem control port and at
least make sure you're talking to the port you expect and can get some
data in and out of the port.
If you know you've already got a simple working serial device and proper
cabling (such as terminal and cable), you may want to jump to connecting
that, and see if you can get any input or output.
For input and output, I typically start quite simple.
You might want to start, by using fuser, to see that nothing else has
any of the devices associated with your target port open - one might
encounter problems or surprises if something else is concurrently trying
to access the port.
The communication parameters may be quite unsuitable. Sure, ... you can
change them with stty, ... but often these will be reset (depending on
your OS flavor, configuration, other factors, etc.) once the device is
closed again, ... so I'll typically redirect from a subshell to do some
basic tests, e.g.:
#and a slight bit of preliminary work ...
if echo '\043' | >>/dev/null 2>&1 fgrep '#'; then
elif echo -e '\043' | >>/dev/null 2>&1 fgrep '#'; then
1>&2 echo don\'t know how to use this echo
#and finally ...
<"$device" (stty sane
stty 9600 additional_settings_to_be_sane_and_disable_hardware_handshaking
>>"$device" echo $e "\r\n\r\n$device\007\r\n\r"
If you get the output on your terminal (or other device you're
monitoring), you're fairly well along the way - you know it's the
correct port and data at least goes out. You can use cat, or something
else to read data - but it may be buffered and/or in "cooked" mode ...
or it might be in raw mode, depending how things have been set. Try
sending some data to the port, be sure to include some control-J
characters and an EOF (typically control-D) ... if it's in raw mode, you
may need to send a fair bit of input before cat will write it to it's
output. Some flavors of cat have an unbuffered (typically -u) option,
which can be useful.
If that stuff didn't work at all, you can step back a bit - perhaps also
you don't know if your test device (e.g. terminal and cable) are working
and correct, or if the port hardware itself actually works. You can
make a loopback plug - or at least connect the data transmit and receive
lines together (e.g. 2 and 3 on RS-232-C DB25). If stuff you squirt out
the port comes back at you with that connection in place (and you have
local echo off), then at least the sending and receiving is okay. You
can also confirm by removing the connection and putting it back, to be
sure it's going through, and it's not local echo or something else
faking you out. Anyway, if that works, then you can proceed to sort out
cable/device issues, hardware handshaking and/or modem control (if
desired/needed/applicable), software configuration for however one plans
to use it, checking other signal lines (if applicable), etc. If the
very basic stuff isn't working, perhaps there's a hardware issue, or
it's not the port/device you think it is, etc., or there's something odd
in software/driver/hardware state.
Also, if one has some suitable bits of electronic test equipment, one
can monitor the signals on the pins. I don't recall what the absolute
max is for RS-232-C (I think it's at/under +-24VDC relative to signal
ground), but they're most typically powered with +-12VDC, and if I
recall correctly, the signal threshold is +-3VDC (0 to +-3VDC is
undefined logic state) ... so, if there's some
data flowing through (or being presented), it should be reasonably
measurable, ... also, break signal can be useful, as it typically should
send a signal of at least 300ms on the data line.
Another nice thing about RS-232-C. At least in *theory*, if one is
strictly inter-connecting RS-232-C signals (and hopefully at least has
signal ground properly interconnected), the circuits are supposed to be
sufficiently tolerant that connecting them incorrectly won't cause the
electronics to fail. In practice I've generally seen this to be the
case (I personally recall only one incident where (presumably) incorrect
wiring caused one of the driver chips to fail). Of course if the
circuits aren't RS-232-C, things will generally fry quite easily (like
an Apple DB25 SCSI or a DB25 "printer" (TTL) port, or a DE9 MDA TTL
Note also that many/most vendors "bend" the RS-232-C specifications. Ye
olde specification says that DTE is always male - in practice that's
relatively rare on electronics devices (my theory is they don't want the
pins to get bent, so they make it female - that way when pins get bent,
it's on the cable, rather than the device), and it's always DB25 (DE9
"IBM AT" "standard" is the other highly prevalent pinout, there are also
many others). Also, even if it's an "RS-232-C" device/port and DB25,
there may yet be additional surprises (like UPS devices that also
include non-RS-232-C signal/alarm pins on same DB25 as the serial data
lines, or vendors that put 2* or 3 sets of serial lines on a single
And just because the vendor's hardware documentation says it's a
"general purpose serial port" doesn't mean it is. <sigh> I dealt with
case very recently where the documentation said that, ... and after
support call with vendor and a fair bit of time (was dealing with over 4
of these units and couldn't get diddlely in or out of those ports), got
answer back that basically said, "no, that port is only for the vendor's
internal use and is not accessible by the operating system".
*It's possible this might (mostly) be to specification, as the full
RS-232-C specification does have a full set of secondary data and
control lines (use same pins for grounds) ... in practice that's very
rarely seen ... well, ... up until perhaps relatively recently anyway,
... if one vendor might actually be (mostly) following the specification
on that (of course they still have their DTE as female, which isn't to
specification) - of course if they have 3 sets of signals on a DB25, it
can't match the RS-232-C pinout specifications.
(okay, it's +-25VDC max, not 24, but I was correct on the 3VDC)
(the Operating System stuff tends to be quite LINUX specific, but lots
of good serial electronics/pinnouts/cabling/signals/etc. details):
No, they don't publish the spec. on the web, but for ~$10.00 USD:
stty(1), sh(1), various kernel/vendor/distribution's documentation on
device assignment/convention/configuration/naming, various vendor's
hardware documentation (including their many varied pinouts, and
occasionally correct documentation on which are "general purpose serial
ports" vs. only for vendor's own "internal use only").
Quoting Bill Moseley <moseley at hank.org>:
> I posted this question to debian-user yesterday, but no joy yet.
> Thought I'd try here (sorry for the dups to you d-u subscribers).
> The short description is this:
> I can talk to the serial port on an Access Point using Windows
> and Hyperterminal, but I can't get minicom to talk to the AP or
> talk to the Windows machine with a null modem cable.
> I'm trying to use ttyS1 to connect to the AP (although I also tried
> ttyS0 just in case).
More information about the buug