586 lines
32 KiB
HTML
586 lines
32 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE> Modem-HOWTO: Serial Port and Modem Basics </TITLE>
|
|
<LINK HREF="Modem-HOWTO-5.html" REL=next>
|
|
<LINK HREF="Modem-HOWTO-3.html" REL=previous>
|
|
<LINK HREF="Modem-HOWTO.html#toc4" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Modem-HOWTO-5.html">Next</A>
|
|
<A HREF="Modem-HOWTO-3.html">Previous</A>
|
|
<A HREF="Modem-HOWTO.html#toc4">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="basics_"></A> <A NAME="s4">4.</A> <A HREF="Modem-HOWTO.html#toc4">Serial Port and Modem Basics </A></H2>
|
|
|
|
<P> You don't have to understand the basics to use and install a
|
|
modem. But understanding it may help to determine what is wrong if
|
|
you run into problems. After reading this section, if you want to
|
|
understand it even better you may want to see
|
|
<A HREF="Modem-HOWTO-21.html#how_modems_work">How Modems Work</A> in this document (not yet
|
|
complete). More details on the serial port (including much of this
|
|
section) will be found in Serial-HOWTO.</P>
|
|
|
|
<H2><A NAME="ss4.1">4.1</A> <A HREF="Modem-HOWTO.html#toc4.1">Modem Converts Digital to Analog (and conversely)</A>
|
|
</H2>
|
|
|
|
<P> Most all telephone main lines are digital already but the lines
|
|
leading to your house (or business) are usually analog which means
|
|
that they were designed to transmit a voltage wave which is an exact
|
|
replica of the sound wave coming out of your mouth. Such a voltage
|
|
wave is called "analog". If viewed on an oscilloscope it looks like a
|
|
sine wave of varying frequency and amplitude. A digital signal is
|
|
like a square wave. For example 3 v (volts) might be a 1-bit and 0 v
|
|
could be a 0-bit. For most serial ports (used by external modems) +12
|
|
v is a 0-bit and -12 v is a 1-bit (some are + or - 5 v).</P>
|
|
<P>To send data from your computer over the phone line, the modem takes
|
|
the digital signal from your computer and converts it to "analog". It
|
|
does this by both creating an analog sine wave and then "MODulating"
|
|
it. Since the result still represents digital data, it could also be
|
|
called a digital signal instead of analog. But it looks something
|
|
like an analog signal and almost everyone calls it analog. At the
|
|
other end of the phone line another modem "DEModulates" this signal
|
|
and the pure digital signal is recovered. Put together the "mod" and
|
|
"dem" parts of the two words above and you get "modem" (if you drop
|
|
one of the two d's). A "modem" is thus a MODulator-DEModulator. Just
|
|
what modulation is may be found in the section
|
|
<A HREF="Modem-HOWTO-21.html#modulate_">Modulation Details</A>.</P>
|
|
|
|
|
|
|
|
<H2><A NAME="ss4.2">4.2</A> <A HREF="Modem-HOWTO.html#toc4.2">What is a Serial Port ?</A>
|
|
</H2>
|
|
|
|
<H3>Intro to Serial</H3>
|
|
|
|
<P> The UART serial port (or just "serial port for short" is an I/O (Input/Output) device.
|
|
Since modems have a serial port between them and the computer,
|
|
it's necessary to understand the serial port as well as the modem.</P>
|
|
<P>Most PC's have one or two serial ports. Each has a 9-pin connector
|
|
(sometimes 25-pin) on the back of the computer. Computer programs can
|
|
send data (bytes) to the transmit pin (output) and receive bytes from
|
|
the receive pin (input). The other pins are for control purposes and
|
|
ground.</P>
|
|
<P>The serial port is much more than just a connector. It converts the
|
|
data from parallel to serial and changes the electrical representation
|
|
of the data. Inside the computer, data bits flow in parallel (using
|
|
many wires at the same time). Serial flow is a stream of bits over a
|
|
single wire (such as on the transmit or receive pin of the serial
|
|
connector). For the serial port to create such a flow, it must
|
|
convert data from parallel (inside the computer) to serial on the
|
|
transmit pin (and conversely).</P>
|
|
<P>Most of the electronics of the serial port is found in a computer chip
|
|
(or a part of a chip) known as a UART. For more details on UARTs
|
|
see the section
|
|
"What are UARTS" in the Serial-HOWTO. But you may want to finish this section first so that you will
|
|
hopefully understand how the UART fits into the overall scheme of
|
|
things.</P>
|
|
|
|
<H3>Pins and Wires</H3>
|
|
|
|
<P> Old PC's used 25 pin connectors but only about 9 pins were
|
|
actually used so today most connectors are only 9-pin. Each of the 9
|
|
pins usually connects to a wire. Besides the two wires used for
|
|
transmitting and receiving data, another pin (wire) is signal ground.
|
|
The voltage on any wire is measured with respect to this ground. Thus
|
|
the minimum number of wires to use for 2-way transmission of data is
|
|
3. Except that it has been known to work with no signal ground wire
|
|
but with degraded performance and sometimes with errors.</P>
|
|
<P>There are still more wires which are for control purposes (signalling)
|
|
only and not for sending bytes. All of these signals could have been
|
|
shared on a single wire, but instead, there is a separate dedicated
|
|
wire for every type of signal. Some (or all) of these control wires
|
|
are called "modem control lines". Modem control wires are either in
|
|
the asserted state (on) of +12 volts or in the negated state (off) of
|
|
-12 volts. One of these wires is to signal the computer to stop
|
|
sending bytes out the serial port cable. Conversely, another wire
|
|
signals the device attached to the serial port to stop sending bytes
|
|
to the computer. If the attached device is a modem, other wires may
|
|
tell the modem to hang up the telephone line or tell the computer that
|
|
a connection has been made or that the telephone line is ringing
|
|
(someone is attempting to call in). See the Serial-HOWTO:
|
|
Pinout and Signals for more details.</P>
|
|
|
|
<H3>Internal Modem Contains Serial Port</H3>
|
|
|
|
<P> For an internal modem there is no 9-pin connector but the behavior
|
|
is almost exactly as if the above mentioned cable wires existed.
|
|
Instead of a a 12 volt signal in a wire giving the state of a modem
|
|
control line, the internal modem may just use a status bit in its own
|
|
memory (a register) to determine the state of this non-existent
|
|
"wire". The internal modem's serial port looks just like a real
|
|
serial port to the computer. It even includes the speed limits that
|
|
one may set at ordinary serial ports such as 115200 bits/sec.</P>
|
|
<P>Unfortunately for Linux, many internal modems today use software
|
|
(running on the CPU) to do much of the modem's work. Unfortunately,
|
|
such software may be only available for the MS Windows OS (it hasn't
|
|
been ported to Linux). Thus you can't use some of these modems with
|
|
Linux See
|
|
<A HREF="Modem-HOWTO-2.html#soft_modem">Software-based Modems (winmodems)</A>.</P>
|
|
|
|
|
|
|
|
<H2><A NAME="ss4.3">4.3</A> <A HREF="Modem-HOWTO.html#toc4.3">IO Address & IRQ</A>
|
|
</H2>
|
|
|
|
<P> Since the computer needs to communicate with each serial port, the
|
|
operating system must know that each serial port exists and where it
|
|
is (its I/O address). It also needs to know which wire (IRQ number)
|
|
the serial port must use to request service from the computer's CPU.
|
|
It requests service by sending an interrupt voltage on this wire.
|
|
Thus every serial port device must store in its non-volatile memory
|
|
both its I/O address and its Interrupt ReQuest number: IRQ. See
|
|
<A HREF="#interrupt_">Interrupts</A>. The PCI bus has its own system of
|
|
interrupts. But since the PCI-aware BIOS sets up these PCI interrupts
|
|
to map to IRQs, it seemingly behaves just as described above. Except
|
|
that sharing of PCI interrupts is allowed (2 or more devices may use
|
|
the same IRQ number).</P>
|
|
<P>I/O addresses are not the same as memory addresses. When an I/O
|
|
addresses is put onto the computer's address bus, another wire is
|
|
energized. This both tells main memory to ignore the address and
|
|
tells all devices which have I/O addresses (such as the serial port)
|
|
to listen to the address sent on the bus to see if it matches the
|
|
device's. If the address matches, then the I/O device reads the data
|
|
on the data bus.</P>
|
|
<P>The I/O address of a certain device (such as ttyS2) will actually be a
|
|
range of addresses. The lower address in this range is the base
|
|
address. "address" usually means just the "base address".</P>
|
|
|
|
<H2><A NAME="ss4.4">4.4</A> <A HREF="Modem-HOWTO.html#toc4.4">Names: ttyS0, ttyS1, etc.</A>
|
|
</H2>
|
|
|
|
<P> The serial ports are named ttyS0, ttyS1, etc. (and usually
|
|
correspond respectively to COM1, COM2, etc. in DOS/Windows). The /dev
|
|
directory has a special file for each port. Type "ls /dev/ttyS*" to
|
|
see them. Just because there may be (for example) a ttyS3 file,
|
|
doesn't necessarily mean that there exists a physical serial port
|
|
there.</P>
|
|
<P>Which one of these names (ttyS0, ttyS1, etc.) refers to which
|
|
physical serial port is determined as follows. The serial driver
|
|
(software) maintains a table showing which I/O address corresponds to
|
|
which ttyS. This mapping of names (such as ttyS1) to I/O addresses
|
|
(and IRQ's) may be both set and viewed by the "setserial" command.
|
|
See
|
|
<A HREF="Modem-HOWTO-10.html#set_serial">What is Setserial</A>. This does
|
|
<CODE>not</CODE> set the I/O address and IRQ in the hardware itself (which is
|
|
set by jumpers or by plug-and-play software). Thus which physical port
|
|
corresponds to say ttyS1 depends both on what the serial driver thinks
|
|
(per setserial) and what is set in the hardware. If a mistake has
|
|
been made, the physical port may not correspond to any name (such as
|
|
ttyS2) and thus it can't be used. See
|
|
<A HREF="Modem-HOWTO-9.html#ttySN_">Serial Port Devices /dev/ttyS2, etc.</A> for more details.</P>
|
|
|
|
<H2><A NAME="interrupt_"></A> <A NAME="ss4.5">4.5</A> <A HREF="Modem-HOWTO.html#toc4.5">Interrupts </A>
|
|
</H2>
|
|
|
|
<P>Bytes come in over the phone line to the modem, are converted from
|
|
analog to digital by the modem and passed along to the serial port on
|
|
their way to their destination inside your computer.
|
|
When the serial port receives a number of bytes (may be set to 1, 4,
|
|
8, or 14) into its FIFO buffer, it signals the CPU to fetch them by
|
|
sending an electrical signal known as an interrupt on a certain wire
|
|
normally used only by that port. Thus the FIFO waits until it has
|
|
received a number of bytes and then issues an interrupt.</P>
|
|
<P>However, this interrupt will also be sent if there is an unexpected
|
|
delay while waiting for the next byte to arrive (known as a timeout).
|
|
Thus if the bytes are being received slowly (such as from someone
|
|
typing on a terminal keyboard) there may be an interrupt issued for
|
|
every byte received. For some UART chips the rule is like this: If 4
|
|
bytes in a row could have been received in an interval of time, but
|
|
none of these 4 show up, then the port gives up waiting for more bytes
|
|
and issues an interrupt to fetch the bytes currently in the FIFO. Of
|
|
course, if the FIFO is empty, no interrupt will be issued.</P>
|
|
<P>Each interrupt conductor (inside the computer) has a number (IRQ) and
|
|
the serial port must know which conductor to use to signal on. For
|
|
example, ttyS0 normally uses IRQ number 4 known as IRQ4 (or IRQ 4). A
|
|
list of them and more will be found in "man setserial" (search for
|
|
"Configuring Serial Ports"). Interrupts are issued whenever the
|
|
serial port needs to get the CPU's attention. It's important to do
|
|
this in a timely manner since the buffer inside the serial port can
|
|
hold only 16 incoming bytes. If the CPU fails to remove such received
|
|
bytes promptly, then there will not be any space left for any more
|
|
incoming bytes and the small buffer may overflow (overrun) resulting
|
|
in a loss of data bytes.</P>
|
|
<P>For an external modem, there may be no way (such as flow control) to
|
|
stop the flow rapidly enough to prevent such an overrun. For an
|
|
internal modem, the 16-byte FIFO buffer is on the same card and most
|
|
modems will not write to it if it's full. Thus it will not overrun
|
|
the 16-byte buffers but it may need to use
|
|
<A HREF="#M-M_flow_c">Modem-to-Modem Flow Control</A> to prevent the modem itself from
|
|
being overrun. This is one advantage of internal modems over an
|
|
external. </P>
|
|
<P>Interrupts are also issued when the serial port has just sent out all
|
|
of its bytes from its small transmit FIFO buffer out the external
|
|
cable. It then has space for 16 more outgoing bytes. The interrupt
|
|
is to notify the CPU of that fact so that it may put more bytes in the
|
|
small transmit buffer to be transmitted. Also, when a modem control
|
|
line changes state, an interrupt is issued.</P>
|
|
<P>The buffers mentioned above are all hardware buffers. The serial port
|
|
also has large buffers in main memory. This will be explained later</P>
|
|
<P>Interrupts convey a lot of information but only indirectly. The
|
|
interrupt itself just tells a chip called the interrupt controller
|
|
that a certain serial port needs attention. The interrupt controller
|
|
then signals the CPU. The CPU then runs a special program to service
|
|
the serial port. That program is called an interrupt service routine
|
|
(part of the serial driver software). It tries to find out what has
|
|
happened at the serial port and then deals with the problem such a
|
|
transferring bytes from (or to) the serial port's hardware buffer.
|
|
This program can easily find out what has happened since the serial
|
|
port has registers at IO addresses known to the serial driver
|
|
software. These registers contain status information about the serial
|
|
port. The software reads these registers and by inspecting the
|
|
contents, finds out what has happened and takes appropriate action.</P>
|
|
|
|
<H2><A NAME="ss4.6">4.6</A> <A HREF="Modem-HOWTO.html#toc4.6">Data Compression (by the Modem)</A>
|
|
</H2>
|
|
|
|
<P> Before continuing with the basics of the serial port, one needs to
|
|
understand about something done by the modem: data compression. In
|
|
some cases this task is actually done by software run on the
|
|
computer's CPU but unfortunately at present, such software only works
|
|
for MS Windows. The discussion here will be for the case where the
|
|
modem itself does the compression since this is what must happen in
|
|
order for the modem to work under Linux.</P>
|
|
<P>In order to send data faster over the phone line, one may compress
|
|
(encode it) using a custom encoding scheme which itself depends on the
|
|
data. The encoded data is smaller than the original (less bytes) and
|
|
can be sent over the Internet in less time. This process is called
|
|
"data compression".</P>
|
|
<P>If you download files from the Internet, they are likely already
|
|
compressed and it is not feasible for the modem to try to compress
|
|
them further. Your modem may sense that what is passing thru has
|
|
already been compressed and refrain from trying a compress it any
|
|
more. If you are receiving data which has been compressed by the
|
|
other modem, your modem will decompress it and create many more bytes
|
|
than were sent over the phone line. Thus the flow of data from your
|
|
modem into your computer will be higher than the flow over the phone
|
|
line to you. The ratio of this flow is called the compression ratio.
|
|
Compression ratios as high as 4 are possible, but not very likely.</P>
|
|
|
|
<H2><A NAME="ss4.7">4.7</A> <A HREF="Modem-HOWTO.html#toc4.7">Error Correction</A>
|
|
</H2>
|
|
|
|
<P> Similar to data compression, modems may be set to do error
|
|
correction. While there is some overhead cost involved which slows
|
|
down the byte/sec flow rate, the fact that error correction strips off
|
|
start and stop bits actually increases the data byte/sec flow rate.</P>
|
|
<P>For the serial port's interface with the external world, each 8-bit
|
|
byte has 2 extra bits added to it: a start-bit and a stop-bit.
|
|
Without error correction, these extra start and stop bits usually go
|
|
right thru the modem and out over the phone lines. But when error
|
|
correction is enabled, these extra bits are stripped off and the 8-bit
|
|
bytes are put into packets. This is more efficient and results in
|
|
higher byte/sec flow in spite of the fact that there are a few more
|
|
bytes added for packet headers and error correction purposes.</P>
|
|
|
|
<H2><A NAME="ss4.8">4.8</A> <A HREF="Modem-HOWTO.html#toc4.8">Data Flow (Speeds)</A>
|
|
</H2>
|
|
|
|
<P> Data (bytes representing letters, pictures, etc.) flows from your
|
|
computer to your modem and then out on the telephone line (and
|
|
conversely). Flow rates (such as 56k (56000) bits/sec) are
|
|
(incorrectly) called "speed". But almost everyone says "speed"
|
|
instead of "flow rate". If there were no data compression the flow
|
|
rate from the computer to the modem would be about the same as the
|
|
flow rate over the telephone line.</P>
|
|
<P>Actually there are two different speeds to consider at your end of the
|
|
phone line:</P>
|
|
<P>
|
|
<UL>
|
|
<LI> The speed on the phone line itself (DCE speed) modem-to-modem</LI>
|
|
<LI> The speed from your computer's serial port to your modem (DTE speed)</LI>
|
|
</UL>
|
|
</P>
|
|
<P>When you dial out and connect to another modem on the other end of the
|
|
phone line, your modem often sends you a message like "CONNECT 28800"
|
|
or "CONNECT 115200". What do these mean? Well, its either the DCE
|
|
speed or the DTE speed. If it's higher than the advertised modem speed
|
|
it must be the DTE modem-to-computer speed. This is the case for the
|
|
115200 speed shown above. The 28800 must be a DCE (modem-to-modem)
|
|
speed since the serial port has no such speed. One may configure the
|
|
modem to report either speed. Some modems report both speeds and
|
|
report the modem-to-modem speed as (for example): CARRIER 28800.</P>
|
|
<P>If you have an internal modem you would not expect that there would be
|
|
any speed limit on the DTE speed from your modem to your computer
|
|
since you modem is inside your computer and is almost part of your
|
|
computer. But there usually is since the modem contains a dedicated
|
|
serial port within it. On some software modems there is no such speed
|
|
limit.</P>
|
|
<P>It's important to understand that the average speed is often less than
|
|
the specified speed, especially on the short DTE computer-to-modem
|
|
line. Waits (or idle time) result in a lower average speed. These
|
|
waits may include long waits of perhaps a second due to
|
|
<A HREF="#flow_control">Flow Control</A>. At the other extreme there
|
|
may be very short waits (idle time) of several micro-seconds
|
|
separating the end of one byte and the start of the next byte. In
|
|
addition, modems will fallback to lower speeds if the telephone line
|
|
conditions are less than pristine.</P>
|
|
<P>For a discussion of what DTE speed is best to use see section
|
|
<A HREF="Modem-HOWTO-14.html#speed_">What Speed Should I Use</A>.</P>
|
|
|
|
|
|
|
|
<H2><A NAME="flow_control"></A> <A NAME="ss4.9">4.9</A> <A HREF="Modem-HOWTO.html#toc4.9">Flow Control </A>
|
|
</H2>
|
|
|
|
<P> Flow control means the ability to slow down the flow of bytes in a
|
|
wire. For serial ports this means the ability to stop and then
|
|
restart the flow without any loss of bytes. Flow control is needed
|
|
for modems and other hardware to allow a jump in instantaneous flow rates.</P>
|
|
|
|
<H3>Example of Flow Control</H3>
|
|
|
|
<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 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
|
|
the your computer to your modem over the short cable is at 115.2k bps.
|
|
However the flow from your modem out the phone line is only 33.6k bps.
|
|
Since a faster flow (115.2k) is going into your modem than is coming
|
|
out of it, the modem is storing the excess flow (115.2k -33.6k = 81.6k
|
|
bps) in one of its buffers. This buffer would soon overrun (run out
|
|
of free storage space) unless the high 115.2k flow is stopped.</P>
|
|
<P>But now flow control comes to the rescue. When the modem's buffer is
|
|
almost full, the modem sends a stop signal to the serial port. The
|
|
serial port passes on the stop signal on to the device driver and the
|
|
115.2k bps flow is halted. Then the modem continues to send out data
|
|
at 33.6k bps drawing on the data it previous accumulated in its
|
|
buffer. Since nothing is coming into this buffer, the number of bytes
|
|
in it starts to drop. When almost no bytes are left in the buffer,
|
|
the modem sends a start signal to the serial port and the 115.2k flow
|
|
from the computer to the modem resumes. In effect, flow control
|
|
creates an average flow rate in the short cable (in this case 33.6k)
|
|
which is significantly less than the "on" flow rate of 115.2k bps.
|
|
This is "start-stop" flow control.</P>
|
|
<P>In the above simple example it was assumed that the modem did no data
|
|
compression. This could happen when the modem is sending a file
|
|
which is already compressed and can't be compressed further. Now
|
|
let's consider the opposite extreme where the modem is compressing the
|
|
data with a high compression ratio. In such a case the modem might
|
|
need an input flow rate of say 115.2k bps to provide an output (to the
|
|
phone line) of 33.6k bps (compressed data). This compression ratio is
|
|
3.43 (115.2/33.6). In this case the modem is able to compress the
|
|
115.2 bps PC-to-modem flow and send the same data (in compressed form)
|
|
out the phone line at 33.6bps. There's no need for flow control here
|
|
so long as the compression ratio remains higher than 3.43. But the
|
|
compression ratio varies from second to second and if it should drop
|
|
below 3.43, flow control will be needed </P>
|
|
<P>In the above example, the modem was an external modem. But the same
|
|
situation exists (as of early 2003) for most internal modems. There is
|
|
still a speed limit on the PC-to-modem speed even though this flow
|
|
doesn't take place over an external cable. This makes the internal
|
|
modems compatible with the external modems.</P>
|
|
<P>In the above example of flow control, the flow was from the computer to
|
|
a modem. But there is also flow control which is used for the
|
|
opposite direction of flow: from a modem (or other device) to a
|
|
computer. Each direction of flow involves 3 buffers: 1. in the modem
|
|
2. in the UART chip (called FIFOs) and 3. in main memory managed by the
|
|
serial driver. Flow control protects all buffers (except the FIFOs)
|
|
from overflowing. </P>
|
|
<P>Under Linux, the small UART FIFO buffers are not protected by flow
|
|
control but instead rely on a fast response to the interrupts they
|
|
issue. Some UART chips can be set to do hardware flow control to
|
|
protect their FIFOs but Linux (as of early 2003) doesn't seem to
|
|
support it. FIFO stand for "First In, First Out" which is the way it
|
|
handles bytes in a queue. All the 3 buffers use the FIFO rule but
|
|
only the one in the UART is named "FIFO". This is the essence of flow
|
|
control but there are still some more details.</P>
|
|
<P>If you have set the highest PC-to-modem speed, you may not need flow
|
|
control in the direction from the modem to a PC. For a complex
|
|
example of a case where it's needed see "Complex Flow Control Example"
|
|
in the Serial-HOWTO. To slow down this incoming flow, your modem must
|
|
tell the other modem to stop sending. See
|
|
<A HREF="#M-M_flow_c">M-M_flow_c</A>
|
|
|
|
name="Modem-to-Modem Flow Control">.</P>
|
|
|
|
|
|
|
|
<H3>Hardware vs. Software Flow Control</H3>
|
|
|
|
<P> If feasible, it's best to use "hardware" flow control that uses two
|
|
dedicated "modem control" wires to send the "stop" and "start"
|
|
signals. Hardware flow control at the serial port works like this:
|
|
The two pins, RTS (Request to send) and CTS (Clear to send) are used.
|
|
When the computer is ready to receive date it asserts RTS by putting a
|
|
positive voltage on the RTS pin (meaning "Request To Send to me").
|
|
When the computer is not able to receive any more bytes, it negates
|
|
RTS by putting a negative voltage on the pin saying: "stop sending to
|
|
me". The RTS pin is connected by the serial cable to another pin on
|
|
the modem, printer, terminal, etc. This other pin's only function is
|
|
to receive this signal.</P>
|
|
<P>For the case of a modem, this "other" pin will be the modem's RTS pin.
|
|
But for a printer, another PC, or a non-modem device, it's usually a
|
|
CTS pin so a "crossover" or "null modem" cable is required. This
|
|
cable connects the CTS pin at one end with the RTS pin at the other
|
|
end (two wires since each end of the cable has a CTS pin). For a
|
|
modem, a straight-thru cable is used.</P>
|
|
<P>For the opposite direction of flow a similar scheme is used. For a
|
|
modem, the CTS pin is used to send the flow control signal to the CTS
|
|
pin on the PC. For a non-modem, the RTS pin sends the signal. Thus
|
|
modems and non-modems have the roles of their RTS and CTS pins
|
|
interchanged. Some non-modems such as dumb terminals may use other
|
|
pins for flow control such as the DTR pin instead of RTS.</P>
|
|
<P>Software flow control uses the main receive and transmit data wires to
|
|
send the start and stop signals. It uses the ASCII control characters
|
|
DC1 (start) and DC3 (stop) for this purpose. They are just inserted
|
|
into the regular stream of data. Software flow control is not only
|
|
slower in reacting but also does not allow the sending of binary data
|
|
unless special precautions are taken. Since binary data will likely
|
|
contain DC1 and DC3 characters, special means must be taken to
|
|
distinguish between a DC3 that means a flow control stop and a DC3
|
|
that is part of the binary code. Likewise for DC1. To get software flow control to work for
|
|
binary data requires both modem (hardware) and software support.</P>
|
|
|
|
<H3>Symptoms of No Flow Control</H3>
|
|
|
|
<P> Understanding flow-control theory can be of practical use. For
|
|
example I used my modem to access the Internet and it seemed to work
|
|
fine. But after a few months, I tried to send out long files from my PC
|
|
and a huge amount of retries and errors resulted but it finally
|
|
succeeded. Receiving in the other direction (from my ISP to me) worked
|
|
fine. The problem turned out to be a modem with flow control disabled.
|
|
My modem's buffer was overflowing (overrunning) on long outgoing files
|
|
since no "stop" signal was ever sent to my computer to halt sending to
|
|
the modem. There was no problem in the direction from the modem to my
|
|
computer since the capacity (say 115.2 kbps) of the serial port was
|
|
always higher than the flow from the telephone line. But it was a
|
|
problem in the other direction where the PC would send at 115.2 kbps
|
|
and the modem couldn't handle this high flow resulting in overruns of
|
|
the modem's buffer. The fix was to enable flow control by putting
|
|
into the modem's init string an enable-flow-control command.</P>
|
|
|
|
<H3><A NAME="M-M_flow_c"></A> Modem-to-Modem Flow Control </H3>
|
|
|
|
<P> This is the flow control of the data sent over the telephone lines
|
|
between two modems. It works as long as error correction is enabled.
|
|
Actually, even without error correction it's possible to enable
|
|
software flow control between modems but it may interfere with sending
|
|
binary data so it's not often used. </P>
|
|
|
|
<H2><A NAME="ss4.10">4.10</A> <A HREF="Modem-HOWTO.html#toc4.10">Data Flow Path; Buffers </A>
|
|
</H2>
|
|
|
|
<P>It's been mentioned that there are 3 buffers for each direction of
|
|
flow (3 pairs altogether): 16-byte FIFO buffers (in the UART), a pair
|
|
of larger buffers inside a device connected to the serial port (such
|
|
as a modem), and a pair of buffers (say 8k) in main memory. When an
|
|
application program sends bytes to the serial port they first get
|
|
stashed in the transmit serial port buffer in main memory. The other
|
|
member of this pair consists of a receive buffer for the opposite
|
|
direction of byte-flow. Here's an example diagram for the case of
|
|
browsing the Internet with a browser. Transmit data flow is left to
|
|
right while receive flow is right to left. There is a separate buffer
|
|
for each direction of flow.</P>
|
|
<P>
|
|
<PRE>
|
|
application 8k-byte 16-byte 1k-byte tele-
|
|
BROWSER ------- MEMORY -------- FIFO --------- MODEM -------- phone
|
|
program buffer buffer buffer line
|
|
</PRE>
|
|
</P>
|
|
<P>For the transmit case, the serial device driver takes out say 15 bytes
|
|
from this transmit buffer (in main memory), one byte at a time and
|
|
puts them into the 16-byte transmit buffer in the serial UART for
|
|
transmission. Once in that transmit buffer, there is no way to stop
|
|
them from being transmitted. They are then transmitted to the
|
|
modem or (other device connected to the serial port) which also has a
|
|
fair sized (say 1k) buffer. When the device driver (on orders from
|
|
flow control sent from the modem) stops the flow of outgoing bytes
|
|
from the computer, what it actually stops is the flow of outgoing
|
|
bytes from the large transmit buffer in main memory. Even after this
|
|
has happened and the flow to the modem has stopped, an application
|
|
program may keep sending bytes to the 8k transmit buffer until it
|
|
becomes fill. At the same time, the bytes stored in the FIFO and
|
|
continue to be sent out. Bytes stored in the modem will continue to
|
|
be sent out the phone line unless the modem has gotten a
|
|
modem-to-modem flow control stop from the modem at the other end of
|
|
the phone line.</P>
|
|
<P>When the memory buffer gets fill, the application program can't send
|
|
any more bytes to it (a "write" statement in a C-program blocks) and
|
|
the application program temporarily stops running and waits until some
|
|
buffer space becomes available. Thus a flow control "stop" is
|
|
ultimately able to stop the program that is sending the bytes. Even
|
|
though this program stops, the computer does not necessarily stop
|
|
computing since it may switch to running other processes while it's
|
|
waiting at a flow control stop.</P>
|
|
<P>The above was a little oversimplified in three ways. First, some UARTs
|
|
can do automatic hardware flow control which can stop the transmission
|
|
out of the FIFO buffers if needed (not yet supported by Linux).
|
|
Second, while an application process is waiting to write to the
|
|
transmit buffer, it could possibly perform other tasks. Third, the
|
|
serial driver (located between the memory buffer and the FIFO) has
|
|
it's own small buffer (in main memory) used to process characters.</P>
|
|
|
|
<H2><A NAME="ss4.11">4.11</A> <A HREF="Modem-HOWTO.html#toc4.11">Modem Commands</A>
|
|
</H2>
|
|
|
|
<P> Commands to the modem are sent to it from the communication
|
|
software over the same conductor as used to send data. The commands
|
|
are short ASCII strings. Examples are "AT&K3" for enabling
|
|
hardware flow control (RTS/CTS) between your computer and modem; and
|
|
"ATDT5393401 for Dialing the number 5393401. Note all commands are
|
|
prefaced by "AT". Some commands such as enabling flow control help
|
|
configure the modem. Other commands such as dialing a number actually
|
|
do something. There are about a hundred or so different possible
|
|
commands. When your communication software starts running, it first
|
|
sends an "init" string of commands to the modem to configure it. All
|
|
commands are sent on the ordinary data line before the modem dials (or
|
|
receives a call).</P>
|
|
<P>Once the modem is connected to another modem (on-line mode),
|
|
everything that is sent from your computer to your modem goes directly
|
|
to the other modem and is not interpreted by the modem as a command.
|
|
There is a way to "escape" from this mode of operation and go back to
|
|
command mode where everything sent to the modem will be interpreted as
|
|
a command. The computer just sends "+++" with a specified time
|
|
spacing before and after it. If this time spacing is correct, the
|
|
modem reverts to command mode. Another way to do this is by a signal
|
|
on a certain modem control line.</P>
|
|
<P>There are a number of lists of modem commands on the Internet. The
|
|
section
|
|
<A HREF="Modem-HOWTO-20.html#web_sites">Web Sites</A> has links to a couple of
|
|
such web-sites. Different models and brands of modems do not use
|
|
exactly the same set of such commands. So what works for one modem
|
|
might not work for another. Some common commands (not guaranteed to
|
|
work on all modems) are listed in this HOWTO in the section
|
|
<A HREF="Modem-HOWTO-8.html#modem_conf">Modem Configuration</A></P>
|
|
|
|
|
|
|
|
<H2><A NAME="ss4.12">4.12</A> <A HREF="Modem-HOWTO.html#toc4.12">Serial Driver Module</A>
|
|
</H2>
|
|
|
|
<P> The device driver for the serial port is the software that
|
|
operates the serial port. It is now provided as a serial module.
|
|
From kernel 2.2 on, this module will normally get loaded automatically
|
|
if it's needed. In earlier kernels, you had to have <CODE>kerneld</CODE>
|
|
running in order to do auto-load modules on demand. Otherwise the
|
|
serial module needed to be explicitly listed in /etc/modules. Before
|
|
modules became popular with Linux, the serial driver was usually built
|
|
into the kernel (and sometimes still is). If it's built-in don't let
|
|
the serial module load or else you will have two serial drivers
|
|
running at the same time. With 2 drivers there are all sorts of
|
|
errors including a possible "I/O error" when attempting to open a
|
|
serial port. Use "lsmod" to see if the module is loaded.</P>
|
|
<P>When the serial module is loaded it displays a message on the screen
|
|
about the existing serial ports (often showing a wrong IRQ). But once
|
|
the module is used by <CODE>setserial</CODE> to tell the device driver the
|
|
(hopefully) correct IRQ then you should see a second display similar
|
|
to the first but with the correct IRQ, etc. See
|
|
"Serial Module" in the Serial-HOWTO.
|
|
See
|
|
<A HREF="Modem-HOWTO-10.html#set_serial">What is Setserial</A> for more info on
|
|
<CODE>setserial</CODE>.</P>
|
|
|
|
|
|
|
|
<HR>
|
|
<A HREF="Modem-HOWTO-5.html">Next</A>
|
|
<A HREF="Modem-HOWTO-3.html">Previous</A>
|
|
<A HREF="Modem-HOWTO.html#toc4">Contents</A>
|
|
</BODY>
|
|
</HTML>
|