LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2001-11-16 21:45:51 +00:00
parent 103c6e8617
commit 30891fd1da
1 changed files with 112 additions and 61 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

173
LDP/howto/linuxdoc/Serial-HOWTO.sgml
View File

@ -4,9 +4,11 @@
<author>David S.Lawyer
<tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt>
original by Greg Hankins
<date> v2.14 August 2001
<date> v2.15 November 2001
<!-- Change log:
v2.15 November 2001: mention of MIDI ports, problems with lockfiles
for devfs
v2.14 August 2001: major revision of Configuring the Serial Port
Now it's: Locating ...
v2.13 August 2001: fixed typos: done->down and "is is", USRT chip,
@ -33,7 +35,10 @@ v2.00 May 1999 holding reg. to shift reg.
only about the serial port.
v1.12 July 1998: reissue of old doc (v1.11). Added more info on Winmodems.
v1.11 15 November 1997 by Greg Hankins
v1.7 29 Oct. 1994
(Prior to this, a number of versions are not listed and it would take
some research to determine them)
v1.8.1: 9 Oct. 1995
v1.7: 29 Oct. 1994
v1.0 6 Jan. 1994: first Serial-HOWTO by Greg Hankins
v1.0 June 1993: was called Serial FAQ, by Greg Hankins
-->
@ -126,7 +131,9 @@ sites see: <url url="http://metalab.unc.edu/LDP/mirrors.html">.
Various formats are available. If you only want to quickly check the
date of the latest version look at <url
url="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"> and compare
it to this version: v2.14 August 2001 . New in recent versions:<newline>
it to this version: v2.15 November 2001 . New in recent versions:<newline>
v2.15 November 2001: mention of MIDI ports, problems with lockfiles
for devfs
v2.14 August 2001: major revision of Configuring the Serial Port
v2.13 August 2001: fixed typos: done->down and "is is", USRT chip,
synchronous defined better
@ -560,9 +567,9 @@ restart the flow without any loss of bytes. Flow control is needed
for modems to allow a jump in instantaneous flow rates.
<sect2> Example of Flow Control
<p> For example, consider the case where you connect a 36.6k external
<p> For example, consider the case where you connect a 33.6k external
modem via a short cable to your serial port. The modem sends and
receives bytes over the phone line at 36.6k bits per second (bps).
receives bytes over the phone line at 33.6k bits per second (bps).
Assume it's not doing any data compression or error correction. You
have set the serial port speed to 115,200 bits/sec (bps), and you are
sending data from your computer to the phone line. Then the flow from
@ -931,15 +938,14 @@ supplied as a module. Support for dumb boards is likely to the built
into the kernel while smart boards usually need a module.
<sect2> Driver is built into the kernel (mostly dumb boards)
<p>A pre-compiled kernel is not likely to have multiport support
built in (especially after kernel 2.4). So you probably need to compile
it yourself. In kernel 2.4 you should select "CONFIG_SERIAL_EXTENDED
when configuring the kernel (just before you compile). If you select
this there will be still more choices presented to you. Even after
you do this you may need to edit the resulting source code a
little (depending on the card).
<p>A pre-compiled kernel is not likely to have multiport support built
in. So you probably need to compile it yourself. In kernel 2.4 you
should select "CONFIG_SERIAL_EXTENDED when configuring the kernel
(just before you compile). If you select this there will be still
more choices presented to you. Even after you do this you may need to
edit the resulting source code a little (depending on the card).
<sect2> Modules (mostly for smart boards)
<sect2> Modules (mostly for smart boards) <label id="modules_">
<p>A pre-compiled kernel may come with a pre-compiled module for the
board so that you don't need to recompile the kernel. This module
must be loaded in order to use it, but the kernel may automatically do
@ -1081,16 +1087,16 @@ COM8=0x268.
<p>
Make sure that a Linux-compatible driver is available and read the
information that comes with it. These boards use special devices (in
the /dev directory), and not the standard ones. This information
the /dev directory), and not the standard ttyS ones. This information
varies depending on your hardware. If you have updated info which
should be shown here please email it to me.
Names of Linux driver modules are *.o but these may not work for all
models shown. Also, parameters (such as the io and irq often need to
models shown. See <ref id="modules_" name="Modules (mostly for smart
boards)"> The needed module may have been supplied with your Linux
distribution. Also, parameters (such as the io and irq often need to
be given to the module so you need to find instructions on this
(possibly in the source code tree). To check on the latest serial
driver go to <url url="http://serial.sourceforge.net/" name="Linux
Serial Driver home page">
(possibly in the source code tree).
There are many different brands, each of which often offers many
different cards. No attempt is currently being made to list all the
@ -1127,7 +1133,7 @@ driver status: for 2.2 kernel. Supported by Chase.
note: Old ATvantage and Intelliport cards are not supported by Computone
<item> Connecttech<newline>
website: <tt><url url="http://www.connecttech.com/porducts/products.html"></tt><newline>
website: <tt><url url="http://www.connecttech.com/products/products.html"></tt><newline>
driver location: <url url="ftp://ftp.connecttech.com/pub/linux/">
<item>Cyclades<newline>
@ -1504,7 +1510,7 @@ examples shown here). These BIOS messages may be frozen by pressing
the Pause key. Use Shift-PageUp to scroll back to the messages after
they have flashed by. Shift-PageDown will scroll in the opposite
direction. The <tt/dmesg/ command (or looking at logs in /var/log)
wil show some of the messages but they seem to miss important ones
will show some of the messages but they seem to miss important ones
from setserial. Here's an example of the start-up messages (as of mid
1999). Note that ttyS00 is the same as /dev/ttyS0.
@ -2175,12 +2181,12 @@ are some minor differences, depending on which HOWTO it appears in.
read <ref id="laptops_" name="Laptops: PCMCIA">. <tt/setserial/ is a
program which allows you to tell the device driver software the I/O
address of the serial port, which interrupt (IRQ) is set in the port's
hardware, what type of UART you have, etc. Since theres a good chance
that the serial ports will be automatically detected and set, many
people never need to use <tt/setserial/. In any case setserial will
not work without either serial support built into the kernel or loaded
as a module. The module may get loaded automatically if you (or a
script) tries to use setserial.
hardware, what type of UART you have, etc. Since there's a good
chance that the serial ports will be automatically detected and set,
many people never need to use <tt/setserial/. In any case setserial
will not work without either serial support built into the kernel or
loaded as a module. The module may get loaded automatically if you
(or a script) tries to use setserial.
Setserial can also show how the driver is currently set. In addition,
it can be made to probe the hardware I0 port addresses to try to
@ -2316,7 +2322,7 @@ the hardware. Of course this is not permitted but it sometimes
happens anyway. Probing detects one serial port when actually there
are two. However if they have different IRQs, then the probe for IRQs
may show IRQ = 0. For me it only did this if I first used
<tt/setserial/ to give the IRQ a ficticious value.
<tt/setserial/ to give the IRQ a fictitious value.
<sect2> Boot-time Configuration <label id="sets_boot_time">
@ -2518,11 +2524,11 @@ configuration. For serial ports on the motherboard, setserial is used
just like it is for a desktop. But for PCMCIA cards (such as a modem)
it's a different story. The configuring of the PCMCIA system should
automatically run setserial so you shouldn't need to run it. If you
you do run it (by a script file or by /etc/serial.conf) it might
be different and cause trouble. The autosave feature for serial.conf
shouldn't save anything for PCMCIA cards (but Debian did until 2.15-7).
Of course, it's always OK to use setserial to find out how the driver
is configured for PCMCIA cards.
do run it (by a script file or by /etc/serial.conf) it might be
different and cause trouble. The autosave feature for serial.conf
shouldn't save anything for PCMCIA cards (but Debian did until
2.15-7). Of course, it's always OK to use setserial to find out how
the driver is configured for PCMCIA cards.
<!-- setserial.H end -->
@ -2533,7 +2539,7 @@ In Serial and Text-Terminal -->
<sect2> Introduction
<p> <tt/stty/ does much of the configuration of the serial port but
since application programs (and the getty program) often handle it,
you may not need to use it much. It's handy if your having problems
you may not need to use it much. It's handy if you're having problems
or want to see how the port is set up. Try typing ``stty -a'' at your
terminal/console to see how it's now set. Also try typing it without
the -a (all) for a short listing which shows how it's set different
@ -2559,13 +2565,14 @@ tasks to write to terminal?, define special (control) characters (such
as what key to press for interrupt). See the <tt/stty/ man or info
page for more details. Also see the man page: <tt/termios/ which
covers the same options set by stty but (as of mid 1999) covers
features which the stty man page fails to mention.
features which the stty man page fails to mention.
With some implementations of getty (getty_ps package), the commands
that one would normally give to stty are typed into a getty
configuration file: /etc/gettydefs. Even without this configuration
file, the getty command line may be sufficient to set things up so
that you don't need stty."')
that you don't need stty.
One may write C programs which change the stty configuration, etc.
Looking at some of the documentation for this may help one better
@ -2794,16 +2801,20 @@ speed).
There are exceptions to the above since for certain serial port
hardware, speeds above 115.2k are set by using a very high divisor.
Bear that exception in mind as you read the rest of this section.
Normally, if you specify a speed of 115.2k (in your communication
program or by stty) then the serial driver sets the port hardware to
divisor 1 which sets the highest speed. If you happen to have
hardware with a maximum speed of say 230.4k (and the 230.4k speed has
been enabled), then specifying 115.2k will result in divisor 1. For
some hardware this will actually give you 230.4k. This is double the
speed that you set. In fact, for any speed you set, the actual speed
will be double. If you had hardware that could run at 460.8k then the
actual speed would be quadruple what you set. All the above assumes
that you don't use "setserial" to modify things.
divisor 1 which sets the highest speed.
Besides using a very high divisor to set high speed the conventional
way to do it is as follows: If you happen to have hardware with a
maximum speed of say 230.4k (and the 230.4k speed has been enabled),
then specifying 115.2k will result in divisor 1. For some hardware
this will actually give you 230.4k. This is double the speed that you
set. In fact, for any speed you set, the actual speed will be double.
If you had hardware that could run at 460.8k then the actual speed
would be quadruple what you set. All the above assumes that you don't
use "setserial" to modify things.
<sect2> Setting the divisor, speed accounting
<p> To correct this accounting (but not always fix the problem) you
@ -2826,11 +2837,16 @@ UART.
<sect2> Crystal frequency is higher than baud_base
<p> Note that the baud_base setting is usually much lower than the
frequency of the crystal oscillator in the hardware since the crystal
frequency is often divided by 16 in the hardware to get the actual top
speed. The reason the crystal frequency needs to be higher is so that
this high crystal speed can generate clock ticks to take a number of
samples of each bit to determine if it's a 1 or a 0.
frequency of the crystal oscillator since the crystal frequency of say
1.8432 MHz is divided by 16 in the hardware to get the actual top
speed of 115.2k. The reason the crystal frequency needs to be higher
is so that this high crystal speed can generate clock ticks to take a
number of samples of each bit to determine if it's a 1 or a 0.
Actually, the 1.8432 MHz "crystal frequency" is obtained from a 18.432
MHz crystal oscillator by dividing by 10 before being fed to the UART.
Other schemes are also possible as long as the UART performs properly.
<!-- high_speed.H end -->
@ -2877,7 +2893,8 @@ is to:
</enum>
<sect1>Lock-Files <label id="lockfiles_">
<p>
<p> If you use the new device-filesystem (devfs) then see the next
section.
A lock-file is simply a file created to mean that a particular device is
in use. They are kept in <tt>/var/lock</tt>. Formerly they were in
<tt>/usr/spool/uucp</tt>. Linux lock-files are usually named
@ -2902,7 +2919,7 @@ up by telling you that a device is already in use when it really isn't.
When there were only lockfiles with device names, the following
problem could arise: If the same device has two different
names then two different processes could each use a differnet name for
names then two different processes could each use a different name for
the same device. This results in lockfiles with different names that
actually are the same device. Formerly each physical serial port was
known by two different device names: ttyS0 and cua0. To solve this
@ -2921,6 +2938,18 @@ problems with older versions. For dumb terminals, lockfiles are not
used since this would not permit someone else to send a message to
your terminal using the write or talk program.
<sect1>Lock-Files and devfs Problems
<p> The new device-filesystem (devfs) has the /dev directory with
subdirectories. As of late 2001, there were problems with lockfiles.
For example, the lockfile mechanism considers /dev/usb/tts/0 and
/dev/tts/0 to be the same device with name "0". Ditto for all other
devices that have the same "leaf" name.
Also, if some applications use the old name for a device and other
applications use the new name (devfs) for the same device, then the
lockfiles will have different names. But the serial driver should
know they are the same.
<sect1> Change Owners, Groups, and/or Permissions of Device Files
<p> In order to use a device, you (or the program you run if you have
"set user id") needs to have permission to read and write the device
@ -3019,8 +3048,9 @@ Other distributions may do something similar.
One may modify the serial driver by editing the source code. Much of
the serial driver is found in the file serial.c. For info
regarding writing of programs for the serial port see
Serial-Programming-HOWTO (revised in 1999 by Vern Hoxie but not at
LDP. Get it from <url url="scicom.alphacdc.com/pub/linux">)
Serial-Programming-HOWTO. It was revised in 1999 by Vern Hoxie but
it's not at LDP. Get it from <url
url="scicom.alphacdc.com/pub/linux">
<sect1> Serial Console (console on the serial port)
<p> See the kernel documentation in: Documentation/serial-console.txt.
@ -3101,13 +3131,16 @@ LED lamps which light when certain modem control lines are asserted
signal (positive or negative voltage). Still others have jumpers so
that you can connect any wire to any wire. Some have switches.
Radio Shack sells (in 1998) a "RS-232 Troubleshooter" or "RS-232 Line
Tester" which checks TD, RD, CD, RTS, CTS, DTR, and DSR. A green
light means on (+12 v) while red means off (-12 v). They also sell a
"RS-232 Serial Jumper Box" which permits connecting the pins anyway
you choose.
Radio Shack sells (in 2001) a "RS-232 Troubleshooter" (formerly called
"RS-232 Line Tester") which checks TD, RD, CD, RTS, CTS, DTR, and DSR.
A green light means on (+12 v) while red means off (-12 v). They also
sell a "RS-232 Serial Jumper Box" which permits connecting the pins
anyway you choose. You will likely need to order them from the catalog
where you may find them by checking the Index under "Tools, D-Sub
Connection Pin ...". The two items mentioned are not "tools" but
they appear on a page with tools.
<sect2> Measuring Voltages
<sect2> Measuring voltages
<p> Any voltmeter or multimeter, even the cheapest that sells for
about $10, should work fine. Trying to use other methods for
checking voltage is tricky. Don't use a LED unless it has a series
@ -3127,7 +3160,7 @@ larger than the pins so that it doesn't damage the contact. Clip
an alligator clip (or the like) to the paper clip to connect up. Take
care not to touch two pins at the same time with any metal object.
<sect2> Taste Voltage
<sect2> Taste voltage
<p> As a last resort, if you have no test equipment and are willing to
risk getting shocked (or even electrocuted) you can always taste the
voltage. Before touching one of the test leads with your tongue, test
@ -3142,6 +3175,8 @@ Put the other test lead on your tongue. If the lead on your tongue is
positive, there will be a noticeable taste. You might try this with
flashlight batteries first so you will know what taste to expect.
<sect1> Serial Monitoring/Diagnostics
<p> A few Linux programs will monitor the modem control lines and
indicate if they are positive (1) or negative (0). See section <ref
@ -3234,7 +3269,11 @@ set. For PnP run either "pnpdump --dumpregs" (if ISA bus) or run
thinks the hardware is set.
<sect1> Somewhat Slow: I expected it to be a few times faster
<p> One reason may be that whatever is on the serial port (such as a
<p> An obvious reason is that the baud rate is actually set too slow.
It's claimed that this happened by trying to set the baud rate to a speed
higher than the hardware can support (such as 230400).
Another reason may be that whatever is on the serial port (such as a
modem, terminal, printer) doesn't work as fast as you thought it did.
@ -3373,7 +3412,7 @@ check that any suspicious IRQs shown here (and by "setserial") are
correct (the same as set in the hardware). A way to test whether or
not it's a potential interrupt conflict is to set the IRQ to 0
(polling) using "setserial". Then if the busy message goes away, it
was likely a potential interrupt conflcit. It's not a good idea to
was likely a potential interrupt conflict. It's not a good idea to
leave it permanently set at 0 since it will make the CPU work too
hard.
@ -4181,6 +4220,18 @@ power conductors (6 conductors in all). A variants uses only 4
conductors. You may compile firewire support into the Linux kernel.
Like USB, it's also limited to short distances.
<sect1> MIDI
<p>Sound cards often have a 15-pin MIDI connector. There are also
such connectors not associated with a sound card. They are for
connecting a musical keyboard to a PC so that you can create musical
recordings. You could also connect a MIDI sound system. The MIDI
standard uses 31250 baud (1M/32) which is not available on an ordinary
serial port. Some MIDI devices are designed so that they can be
connected directly to an ordinary serial port.
Besides the 15-pin connector, many use a 5-pin DIN connector.
The /dev/midi00 is for MIDI.
<sect1> Synchronization & Synchronous <label id="sync">
<p> Beside the asynchronous EIA-232 (and others) there are a number of
synchronous serial port standards. In fact EIA-232 includes