< Serial Programming
- I found projects called Linux Serial Sniffer, jpnevulator, and Moni. The first two look like they do exactly what you want. The last one calls itself a monitor, but it actually looks like a standard serial communication program.
- Welcome to pySerial’s documentation¶. This module encapsulates the access for the serial port. It provides backends for Python running on Windows, OSX, Linux, BSD (possibly any POSIX compliant system) and IronPython. The module named “serial” automatically selects the appropriate backend.
- Jun 22, 2014 Traditionally in Linux, the first serial port (COM1) is assigned a name /dev/ttyS0, the second serial port (COM2) assigned /dev/ttyS1, etc. If you specify a serial port name as the first argument of the screen command, the current terminal window where you run screen will be.
- My dell dimension 8400 has a serial port on the back. I want to use minicom to interface the serial port on this computer with Ubuntu installed. The output of dmesg grep tty did not give me much useful information however. I could not find anything with the key word 'Serial'.
How to open, read, and write from serial port in C? Ask Question Asked 8 years, 1 month ago. Active 2 months ago. Viewed 362k times 127. I am a little bit confused about reading and writing to a serial port. I have a USB device in Linux that uses the FTDI USB serial device converter driver. Linux - Multiple Serial Port Communication.
Serial Programming: Introduction and OSI Network Model-- RS-232 Wiring and Connections-- Typical RS232 Hardware Configuration-- 8250 UART-- DOS-- MAX232 Driver/Receiver Family-- TAPI Communications In Windows-- Linux and Unix-- Java-- Hayes-compatible Modems and AT Commands-- Universal Serial Bus (USB)-- Forming Data Packets-- Error Correction Methods-- Two Way Communication-- Packet Recovery Methods-- Serial Data Networks-- Practical Application Development-- IP Over Serial Connections
- 1The Classic Unix C APIs for Serial Communication
- 1.1Introduction
- 1.2Serial I/O via Terminal I/O
- 2Serial I/O on the Shell Command Line
- 2.3Permanent Configuration
- 2.6uucp
The Classic Unix C APIs for Serial Communication[edit]
Introduction[edit]
Scope[edit]
This page is about the classic Unix C APIs for controlling serial devices. Languages other than C might provide appropriate wrappers to these APIs which look similar, or come with their own abstraction (e.g. Java). Nevertheless, these APIs are the lowest level of abstraction one can find for serial I/O in Unix. And, in fact they are also the highest abstraction in C on standard Unix. Some Unix versions ship additional vendor-specific proprietary high-level APIs. These APIs are not discussed here.
Actual implementations of classic Unix serial APIs do vary in practice, due to the different versions of Unix and its clones, like Linux. Therefore, this module just provides a general outline. It is highly recommended that you study a particular Unixversion's manual (man pages) when programming for a serial device in Unix. The relevant man pages are not too great a read, but they are usually complete in their listing of options and parameters. Together with this overview it should be possible to implement programs doing serial I/O under Unix.
Basics[edit]
Linux, or any Unix, is a multi-user, multi-tasking operating system. As such, programs usually don't, and are usually not allowed to, access hardware resources like serial UARTs directly. Instead, the operating system provides
- low-level drivers for mapping the device into the file system (/dev and/or /device/ file system entries),
- the standard system calls for opening, reading, writing, and closing the device, and
- the standard system call for controlling a device, and/or
- high-level C libraries for controlling the device.
The low-level driver not only maps the device into the file system with the help of the kernel, it also encapsulates the particular hardware. The user often does not even know or care what type of UART is in use.
Classic Unix systems often provide two different device nodes (or minor numbers) for serial I/O hardware. These provide access to the same physical device via two different names in the /dev hierarchy. Which node is used affects how certain serial control signals, such as DCD (data carrier detect), are handled when the device is opened. In some cases this can be changed programmatically, making the difference largely irrelevant. As a consequence, Linux only provides the different devices for legacy programs.
Device names in the file system can vary, even on the same Unix system, as they are simply aliases. The important parts of a device name (such as in /dev) are the major and minor numbers. The major number distinguishes a serial port, for example, from a keyboard driver, and is used to select the correct driver in the kernel. Note that the major number differs between different Unix systems. The minor number is interpreted by the device driver itself. For serial device drivers, it is typically used to detect which physical interface to use. Sometimes, the minor number will also be used by the device driver to determine the DCD behavior or the hardware flow control signals to be used.
The typical (but not standardized, see above) device names under Unix for serial interfaces are:
- /dev/ttyxxx
- Normal, generic access to the device. Used for terminal and other serial communication (originally for teletypes). More recently, they are also used in modem communication, for example, whereas the /dev/cuaxxx was used on older systems.
- See the following module on how terminal I/O and serial I/O relate on Unix.
- /dev/cuaxxx
- Legacy device driver with special DCD handling. Typically this was used for accessing a modem on old Unix systems, such as running the UUCP communication protocol over the serial line and the modem. The cu in the name stands for the [[#cu]] program. The a for ACU (automatic call unit).
The xxx part in the names above is typically a one or two digit number, or a lowercase letter, starting at 'a' for the first interface.
PC-based Unix systems often mimic the DOS/Windows naming for the devices and call them /dev/comxxx. Linux system generally call serial ports /dev/ttySxxx instead.
To summarize, when programming for the serial interface of a Unix system it is highly advisable to provide complete configuration for the device name. Not even the typical /dev path should be hard coded.
Note, devices with the name /dev/ptyxxx are pseudo terminal devices, typically used by a graphical user interface to provide a terminal emulator like xterm or dtterm with a 'terminal' device, and to provide a terminal device for network logins. There is no serial hardware behind these device drivers.
Serial I/O via Terminal I/O [edit]
Basics[edit]
Serial I/O under Unix is implemented as part of the terminal I/O capabilities of Unix. And the terminal I/O capabilities of Unix were originally the typewriter/teletype capabilities. Terminal I/O is not limited to terminals, though. The terminal I/O API is used for communication with many serial devices other than terminals, such as modems and printers.
The terminal API itself has evolved over time. These days three terminal APIs are still used in Unix programs and can be found in recent Unix implementations. A fourth one, the very old one from Unix Version 6 exists, but is quite rare these days.
The three common ones are:
- V7, 4BSD, XENIX style device-specific ioctl-based API,
- An old one called termio
- A newer one (although still already a few decades old), which is called termios (note the additional 's').
The newer termios API is based on the older termio API, and so the two termio... APIs share a lot of similarities. The termios API has also undergone changes since inception. For example, the method of specifying the baud rate has changed from using pre-defined constants to a more relaxed schema (the constants can still be used as well on most implementations).
Systems that support the newer termios often also support the older termio API, either by providing it in addition, or by providing a termios implementation with data structures which can be used in place of the termio data structures and work as termio. These systems also often just provide one man page under the older name termio(7) which is then in fact the termios man page, too.
In addition, some systems provide other, similar APIs, either in addition or as a replacement. termiox is such an API, which is largely compatible with termio and adds some extensions to it taken from termios. So termiox can logically be seen as an intermediate step between termio and termios.
The terminal I/O APIs rely on the standard system calls for reading and writing data. They don't provide their own reading/writing functions. Reading and writing data is done via the read(2) and write(2) system calls. The terminal I/O APIs just add functions for controlling and configuring the device. Most of this happens via the ioctl(2) system call.
Unfortunately, whichever of the standard APIs is used, one fact holds for all of them: They are a slight mess. Well, not really. Communication with terminals was and is a difficult issue, and the APIs reflect these difficulties. But due to the fact that one can do 'everything' with the APIs, it is overwhelming when one 'just' wants to do some serial communication. So why is there no separate serial-I/O-only API in Unix? There are probably two reasons for this:
- Terminals/teletypes were the first, and apparently very important, serial devices which were connected to Unix. So that API was created first.
- Once the API was there, there was no need to create a separate one for serial I/O only, since a large part of terminal I/O is serial I/O, and all needed features were already there in the terminal I/O API.
So which API should one use? There is one good reason to use the old V7 API. It is the simplest among the APIs - after going through some initialization woes on modern Unix systems. In general, however, the newer termios API makes the most sense, although it is the most complex one.
Line Discipline[edit]
When programming serial interfaces on Unix, there is one phrase - line discipline - which can drive programmers crazy. The line discipline provides the hardware-independent interface for the communication between the computer and the terminal device. It handles such things as editing, job control, and special character interpretation, and performs transformations on the incoming and outgoing data.
This is useful for terminal communication (e.g. when a backspace character should erase the latest character from the send buffer before it goes over the wire, or when different end-of-line character sequences between the terminal and the computer need to be converted). These features are, however, hardly useful when communicating with the plethora of other serial devices, where unaltered data communication is desired.
Much of the serial programming in Unix is hitting the line discipline which is in use over the head so it doesn't touch the data. Monitoring what actually goes over the wire is a good idea.
Unix V6/PWB[edit]
Unix Bell Version 6 with the programmer's workbench (PWB) was released in 1975 to universities. It was the first Unix with an audience outside AT&T. It already had a terminal programming API. Actually, at that point it was the typewriter API. That API is not described here in depth.
The usage of this API can in theory be identified by the presence of the following signature in some source code:
In theory, because at that time the C language was still a little bit different.
data
is supposed to point to a structure. That structure later became
struct sgttyb
in Unix V7. Finding the V6 API in source code should be rare. Anyhow, recent Unix versions and clones typically don't support this API any more.Unix V7[edit]
See Serial Programming:Unix/V7
termios[edit]
termios
is the API that is in general recommended for serial I/O in Unix. A simple terminal program with termios
can look like it follows. Please note this program is not intended as a general framework for own programs. It lacks error handling, doesn't buffer data, and uses very inefficient polling, wasting lot of CPU cycles. The program just demonstrates some basics for serial I/O:See Serial_Programming:Unix/termios
termio / ioctl(2) [edit]
See Serial Programming:Unix/termio
Serial I/O on the Shell Command Line [edit]
Introduction[edit]
It is possible to do serial I/O on the Unix command line. However, the available control is limited. Reading and writing data can be done with the shell I/O redirections like <, >, and |. Setting basic configuration, like the baud rate, can be done with the stty (set terminal type) command.
There is also libserial for Linux. It's a simple C++ class whichhides some of the complexity of termios.
Configuration with stty[edit]
The Unix command stty allows one to configure a 'terminal'. Since all serial I/O under Unix is done via terminal I/O, it should be no surprise that stty can also be used to configure serial lines. Indeed, the options and parameters which can be set via stty often have a 1:1 mapping to termio/termios. If the explanations regarding an option in the stty(1) man page is not sufficient, looking up the option in the termio/termios man page can often help.
On 'modern' (System V) Unix versions, stty changes the parameters of its current standard input. On older systems, stty changes the parameters of its current standard output. We assume a modern Unix is in use here. So, to change the settings of a particular serial interface, its device name must be provided to stty via an I/O redirect:
On some systems, the settings done by stty are reverted to system defaults as soon as the device is closed again. This closing is done by the shell as soon as the stty parameters < /dev/com0 command has finished. So when using the above command, the changes will only be in effect for a few milliseconds.
One way to keep the device open for the duration of the communication is to start the whole communication in a sub shell (using, for example, '( ... )'), and redirecting that input. So to send the string 'ATI0' over the serial line, one could use:
Interweaving sending and receiving data is difficult from the command line. Two processes are needed; one reading from the device, and the other writing to the device. This makes it difficult to coordinate commands sent with the responses received. Some extensive shell scripting might be needed to manage this.
A common way to organize the two processes is to put the reading process in the background, and let the writing process continue to run in the foreground. For example, the following script configures the device and starts a background process for copying all received data from the serial device to standard output. Then it starts writing commands to the device:
If there is a chance that a response to some command might never come, and if there is no other way to terminate the process, it is advisable to set up a timeout by using the alarm signal and
trap
that signal (signal 14), or simply kill the process:or
Permanent Configuration[edit]
Overview[edit]
C++ Serial Port Communication Linux Example
It is possible to provide a serial line with a default configuration. On classic Unix this is done with entries in the /etc/ttytab configuration file, on newer (System V R4) systems with /etc/ttydefs.
The default configurations make some sense when they are used for setting up terminal lines or dialup lines for a Unix system (and that's what they are for). However, such default configurations are not of much use when doing some serial communication with some other device. The correct function of the communication program should better not depend on some operating system configuration. Instead, the application should be self-contained and configure the device as needed by it.
/etc/ttytab[edit]
The ttytab format varies from Unix to Unix, so checking the corresponding man page is a good idea. If the device is not intended for a terminal (no login), then the getty field (sometimes also called the program field, usually the 3rd field) for the device entry should be empty. The init field (often the 4th field) can contain an initialization command. Using stty here is a good idea. So, a typical entry for a serial line might look like:
/etc/ttydefs[edit]
![Linux Linux](https://petestechprojects.files.wordpress.com/2014/11/teratermtelnetopening.jpg)
Just some hints:
/etc/ttydefs provides the configuration as used by the ttymon program. The settings are similar to the settings possible with stty.
ttymon is a program which is typically run under control of the Service Access Controller (SAC), as part of the Service Access Facility (SAF).
TODO: Provide info to set up all the sac/sacadm junk.
/etc/serial.conf[edit]
Just some hints:
A Linux-specific way of configuring serial devices using the setserial program.
tty[edit]
tty with the -s option can be used to test if a device is a terminal (supports the termio/termios ioctl()'s). Therefore it can also be used to check if a given file name is indeed a device name of a serial line.
tip[edit]
It is a simple program for establishing a terminal connection with a remote system over a serial line. tip takes the necessary communication parameters, including the parameters for the serial communication, from a tip-specific configuration file. Details can be found in the tip(1) manual page.
Example:
To start the session over the first serial interface (here ttya):
To leave the session:
uucp[edit]
Overview[edit]
Uucp (Unix-to-Unix-Copy) is a set of programs for moving data over serial lines/modems between Unix computers. Before the rise of the Internet uucp was the heart and foundation of services like e-mail and Usenet (net news) between Unix computers. Today uucp is largely insignificant. However, it is still a good choice if two or more Unix systems should be connected via serial lines/modems.
The uucp suite also contains command line tools for login over a serial line (or another UUCP bearer to a remote system. These tools are cu and ct. They are e.g. useful when trying to access a device connected via a serial line and when debugging some serial line protocol.
cu[edit]
cu 'call another UNIX system', does what the name implies. Only, that the other system does not have to be a UNIX system at all. It just sets up a serial connection, possibly by dialing via a modem.
cu is the oldest Unix program for serial communication. It's the reason why some serial devices on classic Unix systems are called something like /dev/cul0 and /dev/cua0. Where cu of course stands for the cu program supposed to use the devices, l stands for line - the communication line, and a for acu (automatic call unit).
Note: An ACU is kind of a modem. Modern modems work slightly different and don't provide separate serial interfaces for dialing and communicating with the remote side. Instead they do both over the same serial interface, using some kind of inband signaling. See Serial Programming:Modems and AT Commands. |
ct[edit]
ct is intended to spawn a login to a remote system over a modem line, serial line, or similar bearer. It uses the uucp devices list to find the necessary dialing (modem) commands, and the serial line settings.
System Configuration[edit]
inittab, ttytab, SAF configuration
Other Serial Programming Articles[edit]
Serial Programming: Introduction and OSI Network Model-- RS-232 Wiring and Connections-- Typical RS232 Hardware Configuration-- 8250 UART-- DOS-- MAX232 Driver/Receiver Family-- TAPI Communications In Windows-- Linux and Unix-- Java-- Hayes-compatible Modems and AT Commands-- Universal Serial Bus (USB)-- Forming Data Packets-- Error Correction Methods-- Two Way Communication-- Packet Recovery Methods-- Serial Data Networks-- Practical Application Development-- IP Over Serial Connections
Linux Serial Port Communication C++
External links[edit]
- pySerial helps Python programmers use the serial port.
Retrieved from 'https://en.wikibooks.org/w/index.php?title=Serial_Programming/Serial_Linux&oldid=3421161'
5th Edition
Michael R. Sweet
Copyright 1994-1999, All Rights Reserved.
Introduction
Chapter 1, Basics of Serial CommunicationsChapter 2, Configuring the Serial PortChapter 3, MODEM CommunicationsChapter 4, Advanced Serial ProgrammingAppendix A, PinoutsAppendix B, ASCII Control Codes
The Serial Programming Guide for POSIX Operating Systems will teach you how to successfully, efficiently, and portably program the serial ports on your UNIX® workstation or PC. Each chapter provides programming examples that use the POSIX (Portable Standard for UNIX) terminal control functions and should work with very few modifications under IRIX®, HP-UX, SunOS®, Solaris®, Digital UNIX®, Linux®, and most other UNIX operating systems. The biggest difference between operating systems that you will find is the filenames used for serial port device and lock files.
This guide is organized into the following chapters and appendices:
This chapter introduces serial communications, RS-232 and other standards that are used on most computers as well as how to access a serial port from a C program.
What Are Serial Communications?
Computers transfer information (data) one or more bits at a time. Serial refers to the transfer of data one bit at a time. Serial communications include most network devices, keyboards, mice, MODEMs, and terminals.
When doing serial communications each word (i.e. byte or character) of data you send or receive is sent one bit at a time. Each bit is either on or off. The terms you'll hear sometimes are mark for the on state and space for the off state.
The speed of the serial data is most often expressed as bits-per-second ('bps') or baudot rate ('baud'). This just represents the number of ones and zeroes that can be sent in one second. Back at the dawn of the computer age, 300 baud was considered fast, but today computers can handle RS-232 speeds as high as 430,800 baud! When the baud rate exceeds 1,000, you'll usually see the rate shown in kilobaud, or kbps (e.g. 9.6k, 19.2k, etc). For rates above 1,000,000 that rate is shown in megabaud, or Mbps (e.g. 1.5Mbps).
When referring to serial devices or ports, they are either labeled as Data Communications Equipment ('DCE') or Data Terminal Equipment ('DTE'). The difference between these is simple - every signal pair, like transmit and receive, is swapped. When connecting two DTE or two DCE interfaces together, a serial null-MODEM cable or adapter is used that swaps the signal pairs.
What Is RS-232?
RS-232 is a standard electrical interface for serial communications defined by the Electronic Industries Association ('EIA'). RS-232 actually comes in 3 different flavors (A, B, and C) with each one defining a different voltage range for the on and off levels. The most commonly used variety is RS-232C, which defines a mark (on) bit as a voltage between -3V and -12V and a space (off) bit as a voltage between +3V and +12V. The RS-232C specification says these signals can go about 25 feet (8m) before they become unusable. You can usually send signals a bit farther than this as long as the baud is low enough.
Besides wires for incoming and outgoing data, there are others that provide timing, status, and handshaking:
Pin | Description | Pin | Description | Pin | Description | Pin | Description | Pin | Description |
---|---|---|---|---|---|---|---|---|---|
1 | Earth Ground | 6 | DSR - Data Set Ready | 11 | Unassigned | 16 | Secondary RXD | 21 | Signal Quality Detect |
2 | TXD - Transmitted Data | 7 | GND - Logic Ground | 12 | Secondary DCD | 17 | Receiver Clock | 22 | Ring Detect |
3 | RXD - Received Data | 8 | DCD - Data Carrier Detect | 13 | Secondary CTS | 18 | Unassigned | 23 | Data Rate Select |
4 | RTS - Request To Send | 9 | Reserved | 14 | Secondary TXD | 19 | Secondary RTS | 24 | Transmit Clock |
5 | CTS - Clear To Send | 10 | Reserved | 15 | Transmit Clock | 20 | DTR - Data Terminal Ready | 25 | Unassigned |
Two standards for serial interfaces you may also see are RS-422 and RS-574. RS-422 uses lower voltages and differential signals to allow cable lengths up to about 1000ft (300m). RS-574 defines the 9-pin PC serial connector and voltages.
Signal Definitions
The RS-232 standard defines some 18 different signals for serial communications. Of these, only six are generally available in the UNIX environment.
GND - Logic Ground
Technically the logic ground is not a signal, but without it none of the other signals will operate. Basically, the logic ground acts as a reference voltage so that the electronics know which voltages are positive or negative.
TXD - Transmitted Data
The TXD signal carries data transmitted from your workstation to the computer or device on the other end (like a MODEM). A mark voltage is interpreted as a value of 1, while a space voltage is interpreted as a value of 0.
RXD - Received Data
The RXD signal carries data transmitted from the computer or device on the other end to your workstation. Like TXD, mark and space voltages are interpreted as 1 and 0, respectively.
DCD - Data Carrier Detect
The DCD signal is received from the computer or device on the other end of your serial cable. A space voltage on this signal line indicates that the computer or device is currently connected or on line. DCD is not always used or available.
DTR - Data Terminal Ready
The DTR signal is generated by your workstation and tells the computer or device on the other end that you are ready (a space voltage) or not-ready (a mark voltage). DTR is usually enabled automatically whenever you open the serial interface on the workstation.
CTS - Clear To Send
The CTS signal is received from the other end of the serial cable. A space voltage indicates that is alright to send more serial data from your workstation.
CTS is usually used to regulate the flow of serial data from your workstation to the other end.
RTS - Request To Send
The RTS signal is set to the space voltage by your workstation to indicate that more data is ready to be sent.
Like CTS, RTS helps to regulate the flow of data between your workstation and the computer or device on the other end of the serial cable. Most workstations leave this signal set to the space voltage all the time.
Asynchronous Communications
For the computer to understand the serial data coming into it, it needs some way to determine where one character ends and the next begins. This guide deals exclusively with asynchronous serial data.
In asynchronous mode the serial data line stays in the mark (1) state until a character is transmitted. A start bit preceeds each character and is followed immediately by each bit in the character, an optional parity bit, and one or more stop bits. The start bit is always a space (0) and tells the computer that new serial data is available. Data can be sent or received at any time, thus the name asynchronous.
Figure 1 - Asynchronous Data Transmission
The optional parity bit is a simple sum of the data bits indicating whether or not the data contains an even or odd number of 1 bits. With even parity, the parity bit is 0 if there is an even number of 1's in the character. With odd parity, the parity bit is 0 if there is an odd number of 1's in the data. You may also hear the terms space parity, mark parity, and no parity. Space parity means that the parity bit is always 0, while mark parity means the bit is always 1. No parity means that no parity bit is present or transmitted.
The remaining bits are called stop bits. There can be 1, 1.5, or 2 stop bits between characters and they always have a value of 1. Stop bits traditionally were used to give the computer time to process the previous character, but now only serve to synchronize the receiving computer to the incoming characters.
Asynchronous data formats are usually expressed as '8N1', '7E1', and so forth. These stand for '8 data bits, no parity, 1 stop bit' and '7 data bits, even parity, 1 stop bit' respectively.
What Are Full Duplex and Half Duplex?
Full duplex means that the computer can send and receive data simultaneously - there are two separate data channels (one coming in, one going out).
Half duplex means that the computer cannot send or receive data at the same time. Usually this means there is only a single data channel to talk over. This does not mean that any of the RS-232 signals are not used. Rather, it usually means that the communications link uses some standard other than RS-232 that does not support full duplex operation.
Flow Control
It is often necessary to regulate the flow of data when transferring data between two serial interfaces. This can be due to limitations in an intermediate serial communications link, one of the serial interfaces, or some storage media. Two methods are commonly used for asynchronous data.
The first method is often called 'software' flow control and uses special characters to start (XON or DC1, 021 octal) or stop (XOFF or DC3, 023 octal) the flow of data. These characters are defined in the American Standard Code for Information Interchange ('ASCII'). While these codes are useful when transferring textual information, they cannot be used when transferring other types of information without special programming.
The second method is called 'hardware' flow control and uses the RS-232 CTS and RTS signals instead of special characters. The receiver sets CTS to the space voltage when it is ready to receive more data and to the mark voltage when it is not ready. Likewise, the sender sets RTS to the space voltage when it is ready to send more data. Because hardware flow control uses a separate set of signals, it is much faster than software flow control which needs to send or receive multiple bits of information to do the same thing. CTS/RTS flow control is not supported by all hardware or operating systems.
What Is a Break?
Normally a receive or transmit data signal stays at the mark voltage until a new character is transferred. If the signal is dropped to the space voltage for a long period of time, usually 1/4 to 1/2 second, then a break condition is said to exist.
A break is sometimes used to reset a communications line or change the operating mode of communications hardware like a MODEM. Chapter 3, Talking to MODEMs covers these applications in more depth.
Synchronous Communications
Unlike asynchronous data, synchronous data appears as a constant stream of bits. To read the data on the line, the computer must provide or receive a common bit clock so that both the sender and receiver are synchronized.
Even with this synchronization, the computer must mark the beginning of the data somehow. The most common way of doing this is to use a data packet protocol like Serial Data Link Control ('SDLC') or High-Speed Data Link Control ('HDLC').
Each protocol defines certain bit sequences to represent the beginning and end of a data packet. Each also defines a bit sequence that is used when there is no data. These bit sequences allow the computer see the beginning of a data packet.
Because synchronous protocols do not use per-character synchronization bits they typically provide at least a 25% improvement in performance over asynchronous communications and are suitable for remote networking and configurations with more than two serial interfaces.
Despite the speed advantages of synchronous communications, most RS-232 hardware does not support it due to the extra hardware and software required.
Accessing Serial Ports
Like all devices, UNIX provides access to serial ports via device files. To access a serial port you simply open the corresponding device file.
Serial Port Files
Each serial port on a UNIX system has one or more device files (files in the /dev directory) associated with it:
System | Port 1 | Port 2 |
---|---|---|
IRIX® | /dev/ttyf1 | /dev/ttyf2 |
HP-UX | /dev/tty1p0 | /dev/tty2p0 |
Solaris®/SunOS® | /dev/ttya | /dev/ttyb |
Linux® | /dev/ttyS0 | /dev/ttyS1 |
Digital UNIX® | /dev/tty01 | /dev/tty02 |
Opening a Serial Port
Since a serial port is a file, the open(2) function is used to access it. The one hitch with UNIX is that device files are usually not accessable by normal users. Workarounds include changing the access permissions to the file(s) in question, running your program as the super-user (root), or making your program set-userid so that it runs as the owner of the device file.
For now we'll assume that the file is accessable by all users. The code to open serial port 1 on an
sgi
® workstation running IRIX is: Listing 1 - Opening a serial port.
Other systems would require the corresponding device file name, but otherwise the code is the same.
Open Options
You'll notice that when we opened the device file we used two other flags along with the read+write mode:
The O_NOCTTY flag tells UNIX that this program doesn't want to be the 'controlling terminal' for that port. If you don't specify this then any input (such as keyboard abort signals and so forth) will affect your process. Programs like getty(1M/8) use this feature when starting the login process, but normally a user program does not want this behavior.
The O_NDELAY flag tells UNIX that this program doesn't care what state the DCD signal line is in - whether the other end of the port is up and running. If you do not specify this flag, your process will be put to sleep until the DCD signal line is the space voltage.
Writing Data to the Port
Writing data to the port is easy - just use the write(2) system call to send data it:
The write function returns the number of bytes sent or -1 if an error occurred. Usually the only error you'll run into is EIO when a MODEM or data link drops the Data Carrier Detect (DCD) line. This condition will persist until you close the port.
Reading Data from the Port
Reading data from a port is a little trickier. When you operate the port in raw data mode, each read(2) system call will return however many characters are actually available in the serial input buffers. If no characters are available, the call will block (wait) until characters come in, an interval timer expires, or an error occurs. The read function can be made to return immediately by doing the following:
The FNDELAY option causes the read function to return 0 if no characters are available on the port. To restore normal (blocking) behavior, call fcntl() without the FNDELAY option:
This is also used after opening a serial port with the O_NDELAY option.
Closing a Serial Port
To close the serial port, just use the close system call:
Closing a serial port will also usually set the DTR signal low which causes most MODEMs to hang up.
This chapter discusses how to configure a serial port from C using the POSIX termios interface.
The POSIX Terminal Interface
Most systems support the POSIX terminal (serial) interface for changing parameters such as baud rate, character size, and so on. The first thing you need to do is include the file <termios.h>; this defines the terminal control structure as well as the POSIX control functions.
The two most important POSIX functions are tcgetattr(3) and tcsetattr(3). These get and set terminal attributes, respectively; you provide a pointer to a termios structure that contains all of the serial options available:
Member | Description |
---|---|
c_cflag | Control options |
c_lflag | Line options |
c_iflag | Input options |
c_oflag | Output options |
c_cc | Control characters |
c_ispeed | Input baud (new interface) |
c_ospeed | Output baud (new interface) |
Control Options
The c_cflag member controls the baud rate, number of data bits, parity, stop bits, and hardware flow control. There are constants for all of the supported configurations.Constant | Description |
---|---|
CBAUD | Bit mask for baud rate |
B0 | 0 baud (drop DTR) |
B50 | 50 baud |
B75 | 75 baud |
B110 | 110 baud |
B134 | 134.5 baud |
B150 | 150 baud |
B200 | 200 baud |
B300 | 300 baud |
B600 | 600 baud |
B1200 | 1200 baud |
B1800 | 1800 baud |
B2400 | 2400 baud |
B4800 | 4800 baud |
B9600 | 9600 baud |
B19200 | 19200 baud |
B38400 | 38400 baud |
B57600 | 57,600 baud |
B76800 | 76,800 baud |
B115200 | 115,200 baud |
EXTA | External rate clock |
EXTB | External rate clock |
CSIZE | Bit mask for data bits |
CS5 | 5 data bits |
CS6 | 6 data bits |
CS7 | 7 data bits |
CS8 | 8 data bits |
CSTOPB | 2 stop bits (1 otherwise) |
CREAD | Enable receiver |
PARENB | Enable parity bit |
PARODD | Use odd parity instead of even |
HUPCL | Hangup (drop DTR) on last close |
CLOCAL | Local line - do not change 'owner' of port |
LOBLK | Block job control output |
CNEW_RTSCTS CRTSCTS | Enable hardware flow control (not supported on all platforms) |
The c_cflag member contains two options that should always be enabled, CLOCAL and CREAD. These will ensure that your program does not become the 'owner' of the port subject to sporatic job control and hangup signals, and also that the serial interface driver will read incoming data bytes.
The baud rate constants (CBAUD, B9600, etc.) are used for older interfaces that lack the c_ispeed and c_ospeed members. See the next section for information on the POSIX functions used to set the baud rate.
Never initialize the c_cflag (or any other flag) member directly; you should always use the bitwise AND, OR, and NOT operators to set or clear bits in the members. Different operating system versions (and even patches) can and do use the bits differently, so using the bitwise operators will prevent you from clobbering a bit flag that is needed in a newer serial driver.
Setting the Baud Rate
The baud rate is stored in different places depending on the operating system. Older interfaces store the baud rate in the c_cflag member using one of the baud rate constants in table 4, while newer implementations provide the c_ispeed and c_ospeed members that contain the actual baud rate value.
The cfsetospeed(3) and cfsetispeed(3) functions are provided to set the baud rate in the termios structure regardless of the underlying operating system interface. Typically you'd use the following code to set the baud rate:
Listing 2 - Setting the baud rate.
The tcgetattr(3) function fills the termios structure you provide with the current serial port configuration. After we set the baud rates and enable local mode and serial data receipt, we select the new configuration using tcsetattr(3). The TCSANOW constant specifies that all changes should occur immediately without waiting for output data to finish sending or input data to finish receiving. There are other constants to wait for input and output to finish or to flush the input and output buffers.
Most systems do not support different input and output speeds, so be sure to set both to the same value for maximum portability.
Constant | Description |
---|---|
TCSANOW | Make changes now without waiting for data to complete |
TCSADRAIN | Wait until everything has been transmitted |
TCSAFLUSH | Flush input and output buffers and make the change |
Setting the Character Size
Unlike the baud rate, there is no convienience function to set the character size. Instead you must do a little bitmasking to set things up. The character size is specified in bits:
Setting Parity Checking
Like the character size you must manually set the parity enable and parity type bits. UNIX serial drivers support even, odd, and no parity bit generation. Space parity can be simulated with clever coding.
- No parity (8N1):
- Even parity (7E1):
- Odd parity (7O1):
- Space parity is setup the same as no parity (7S1):
Setting Hardware Flow Control
Some versions of UNIX support hardware flow control using the CTS (Clear To Send) and RTS (Request To Send) signal lines. If the CNEW_RTSCTS or CRTSCTS constants are defined on your system then hardware flow control is probably supported. Do the following to enable hardware flow control:
Similarly, to disable hardware flow control:
Local Options
The local modes member c_lflag controls how input characters are managed by the serial driver. In general you will configure the c_lflag member for canonical or raw input.
Constant | Description |
---|---|
ISIG | Enable SIGINTR, SIGSUSP, SIGDSUSP, and SIGQUIT signals |
ICANON | Enable canonical input (else raw) |
XCASE | Map uppercase lowercase (obsolete) |
ECHO | Enable echoing of input characters |
ECHOE | Echo erase character as BS-SP-BS |
ECHOK | Echo NL after kill character |
ECHONL | Echo NL |
NOFLSH | Disable flushing of input buffers after interrupt or quit characters |
IEXTEN | Enable extended functions |
ECHOCTL | Echo control characters as ^char and delete as ~? |
ECHOPRT | Echo erased character as character erased |
ECHOKE | BS-SP-BS entire line on line kill |
FLUSHO | Output being flushed |
PENDIN | Retype pending input at next read or input char |
TOSTOP | Send SIGTTOU for background output |
Choosing Canonical Input
Canonical input is line-oriented. Input characters are put into a buffer which can be edited interactively by the user until a CR (carriage return) or LF (line feed) character is received.
When selecting this mode you normally select the ICANON, ECHO, and ECHOE options:
Choosing Raw Input
Raw input is unprocessed. Input characters are passed through exactly as they are received, when they are received. Generally you'll deselect the ICANON, ECHO, ECHOE, and ISIG options when using raw input:
A Note About Input Echo
Never enable input echo (ECHO, ECHOE) when sending commands to a MODEM or other computer that is echoing characters, as you will generate a feedback loop between the two serial interfaces!
Input Options
The input modes member c_iflag controls any input processing that is done to characters received on the port. Like the c_cflag field, the final value stored in c_iflag is the bitwise OR of the desired options.
Constant | Description |
---|---|
INPCK | Enable parity check |
IGNPAR | Ignore parity errors |
PARMRK | Mark parity errors |
ISTRIP | Strip parity bits |
IXON | Enable software flow control (outgoing) |
IXOFF | Enable software flow control (incoming) |
IXANY | Allow any character to start flow again |
IGNBRK | Ignore break condition |
BRKINT | Send a SIGINT when a break condition is detected |
INLCR | Map NL to CR |
IGNCR | Ignore CR |
ICRNL | Map CR to NL |
IUCLC | Map uppercase to lowercase |
IMAXBEL | Echo BEL on input line too long |
Setting Input Parity Options
You should enable input parity checking when you have enabled parity in the c_cflag member (PARENB). The revelant constants for input parity checking are INPCK, IGNPAR, PARMRK, and ISTRIP. Generally you will select INPCK and ISTRIP to enable checking and stripping of the parity bit:
IGNPAR is a somewhat dangerous option that tells the serial driver to ignore parity errors and pass the incoming data through as if no errors had occurred. This can be useful for testing the quality of a communications link, but in general is not used for practical reasons.
PARMRK causes parity errors to be 'marked' in the input stream using special characters. If IGNPAR is enabled, a NUL character (000 octal) is sent to your program before every character with a parity error. Otherwise, a DEL (177 octal) and NUL character is sent along with the bad character.
Setting Software Flow Control
Software flow control is enabled using the IXON, IXOFF, and IXANY constants:
To disable software flow control simply mask those bits:
The XON (start data) and XOFF (stop data) characters are defined in the c_cc array described below.
Output Options
The c_oflag member contains output filtering options. Like the input modes, you can select processed or raw data output.
Constant | Description |
---|---|
OPOST | Postprocess output (not set = raw output) |
OLCUC | Map lowercase to uppercase |
ONLCR | Map NL to CR-NL |
OCRNL | Map CR to NL |
NOCR | No CR output at column 0 |
ONLRET | NL performs CR function |
OFILL | Use fill characters for delay |
OFDEL | Fill character is DEL |
NLDLY | Mask for delay time needed between lines |
NL0 | No delay for NLs |
NL1 | Delay further output after newline for 100 milliseconds |
CRDLY | Mask for delay time needed to return carriage to left column |
CR0 | No delay for CRs |
CR1 | Delay after CRs depending on current column position |
CR2 | Delay 100 milliseconds after sending CRs |
CR3 | Delay 150 milliseconds after sending CRs |
TABDLY | Mask for delay time needed after TABs |
TAB0 | No delay for TABs |
TAB1 | Delay after TABs depending on current column position |
TAB2 | Delay 100 milliseconds after sending TABs |
TAB3 | Expand TAB characters to spaces |
BSDLY | Mask for delay time needed after BSs |
BS0 | No delay for BSs |
BS1 | Delay 50 milliseconds after sending BSs |
VTDLY | Mask for delay time needed after VTs |
VT0 | No delay for VTs |
VT1 | Delay 2 seconds after sending VTs |
FFDLY | Mask for delay time needed after FFs |
FF0 | No delay for FFs |
FF1 | Delay 2 seconds after sending FFs |
Choosing Processed Output
Processed output is selected by setting the OPOST option in the c_oflag member:
Of all the different options, you will only probably use the ONLCR option which maps newlines into CR-LF pairs. The rest of the output options are primarily historic and date back to the time when line printers and terminals could not keep up with the serial data stream!
Choosing Raw Output
Raw output is selected by resetting the OPOST option in the c_oflag member:
When the OPOST option is disabled, all other option bits in c_oflag are ignored.
Control Characters
The c_cc character array contains control character definitions as well as timeout parameters. Constants are defined for every element of this array.
Constant | Description | Key |
---|---|---|
VINTR | Interrupt | CTRL-C |
VQUIT | Quit | CTRL-Z |
VERASE | Erase | Backspace (BS) |
VKILL | Kill-line | CTRL-U |
VEOF | End-of-file | CTRL-D |
VEOL | End-of-line | Carriage return (CR) |
VEOL2 | Second end-of-line | Line feed (LF) |
VMIN | Minimum number of characters to read | |
VTIME | Time to wait for data (tenths of seconds) |
Setting Software Flow Control Characters
The VSTART and VSTOP elements of the c_cc array contain the characters used for software flow control. Normally they should be set to DC1 (021 octal) and DC3 (023 octal) which represent the ASCII standard XON and XOFF characters.
Setting Read Timeouts
UNIX serial interface drivers provide the ability to specify character and packet timeouts. Two elements of the c_cc array are used for timeouts: VMIN and VTIME. Timeouts are ignored in canonical input mode or when the NDELAY option is set on the file via open or fcntl.
VMIN specifies the minimum number of characters to read. If it is set to 0, then the VTIME value specifies the time to wait for every character read. Note that this does not mean that a read call for N bytes will wait for N characters to come in. Rather, the timeout will apply to the first character and the read call will return the number of characters immediately available (up to the number you request).
If VMIN is non-zero, VTIME specifies the time to wait for the first character read. If a character is read within the time given, any read will block (wait) until all VMIN characters are read. That is, once the first character is read, the serial interface driver expects to receive an entire packet of characters (VMIN bytes total). If no character is read within the time allowed, then the call to read returns 0. This method allows you to tell the serial driver you need exactly N bytes and any read call will return 0 or N bytes. However, the timeout only applies to the first character read, so if for some reason the driver misses one character inside the N byte packet then the read call could block forever waiting for additional input characters.
VTIME specifies the amount of time to wait for incoming characters in tenths of seconds. If VTIME is set to 0 (the default), reads will block (wait) indefinitely unless the NDELAY option is set on the port with open or fcntl.
This chapter covers the basics of dialup telephone Modulator/Demodulator (MODEM) communications. Examples are provided for MODEMs that use the defacto standard 'AT' command set.
What Is a MODEM?
MODEMs are devices that modulate serial data into frequencies that can be transferred over an analog data link such as a telephone line or cable TV connection. A standard telephone MODEM converts serial data into tones that can be passed over the phone lines; because of the speed and complexity of the conversion these tones sound more like loud screeching if you listen to them.
Telephone MODEMs are available today that can transfer data across a telephone line at nearly 53,000 bits per second, or 53kbps. In addition, most MODEMs use data compression technology that can increase the bit rate to well over 100kbps on some types of data.
Communicating With a MODEM
The first step in communicating with a MODEM is to open and configure the port for raw input:
Listing 3 - Configuring the port for raw input.
Next you need to establish communications with the MODEM. The best way to do this is by sending the 'AT' command to the MODEM. This also allows smart MODEMs to detect the baud you are using. When the MODEM is connected correctly and powered on it will respond with the response 'OK'.
Listing 4 - Initializing the MODEM.
Standard MODEM Commands
Most MODEMs support the 'AT' command set, so called because each command starts with the 'AT' characters. Each command is sent with the 'AT' characters starting in the first column followed by the specific command and a carriage return (CR, 015 octal). After processing the command the MODEM will reply with one of several textual messages depending on the command.
ATD - Dial A Number
The ATD command dials the specified number. In addition to numbers and dashes you can specify tone ('T') or pulse ('P') dialing, pause for one second (','), and wait for a dialtone ('W'):
The MODEM will reply with one of the following messages:
ATH - Hang Up
The ATH command causes the MODEM to hang up. Since the MODEM must be in 'command' mode you probably won't use it during a normal phone call.
Most MODEMs will also hang up if DTR is dropped; you can do this by setting the baud to 0 for at least 1 second. Dropping DTR also returns the MODEM to command mode.
After a successful hang up the MODEM will reply with 'NO CARRIER'. If the MODEM is still connected the 'CONNECT' or 'CONNECT baud' message will be sent.
ATZ - Reset MODEM
The ATZ command resets the MODEM. The MODEM will reply with the string 'OK'.Common MODEM Communication Problems
First and foremost, don't forget to disable input echoing. Input echoing will cause a feedback loop between the MODEM and computer.
Second, when sending MODEM commands you must terminate them with a carriage return (CR) and not a newline (NL). The C character constant for CR is 'r'.
Finally, when dealing with a MODEM make sure you use a baud that the MODEM supports. While many MODEMs do auto-baud detection, some have limits (19.2kbps is common) that you must observe.
This chapter covers advanced serial programming techniques using the ioctl(2) and select(2) system calls.
Serial Port IOCTLs
In Chapter 2, Configuring the Serial Port we used the tcgetattr and tcsetattr functions to configure the serial port. Under UNIX these functions use the ioctl(2) system call to do their magic.
The ioctl system call takes three arguments:
The fd argument specifies the serial port file descriptor. The request argument is a constant defined in the
<termios.h>
header file and is typically one of the following: Request | Description | tcgetattr | ||
---|---|---|---|---|
TCSETS | Sets the serial port settings immediately. | |||
TCSETSF | Sets the serial port settings after flushing the input and output buffers. | tcsetattr(fd, TCSANOW, &options) | ||
TCSBRK | Sends a break for the given time. | tcflow | ||
TCFLSH | Flushes the input and/or output queue. | None |
Getting the Control Signals
The
TIOCMGET
ioctl gets the current 'MODEM' status bits, which consist of all of the RS-232 signal lines except RXD and TXD: Constant | Description |
---|---|
TIOCM_LE | DSR (data set ready/line enable) |
TIOCM_DTR | DTR (data terminal ready) |
TIOCM_RTS | RTS (request to send) |
TIOCM_ST | Secondary TXD (transmit) |
TIOCM_SR | Secondary RXD (receive) |
TIOCM_CTS | CTS (clear to send) |
TIOCM_CAR | DCD (data carrier detect) |
TIOCM_CD | Synonym for TIOCM_CAR |
TIOCM_RNG | RNG (ring) |
TIOCM_RI | Synonym for TIOCM_RNG |
TIOCM_DSR | DSR (data set ready) |
To get the status bits, call ioctl with a pointer to an integer to hold the bits:
Listing 5 - Getting the MODEM status bits.
Setting the Control Signals
The
TIOCMSET
ioctl sets the 'MODEM' status bits defined above. To drop the DTR signal you can do: Listing 6 - Dropping DTR with the TIOCMSET ioctl.
The bits that can be set depend on the operating system, driver, and modes in use. Consult your operating system documentation for more information.
Getting the Number of Bytes Available
The
FIONREAD
ioctl gets the number of bytes in the serial port input buffer. As with TIOCMGET
you pass in a pointer to an integer to hold the number of bytes: Listing 7 - Getting the number of bytes in the input buffer.
This can be useful when polling a serial port for data, as your program can determine the number of bytes in the input buffer before attempting a read.
Selecting Input from a Serial Port
While simple applications can poll or wait on data coming from the serial port, most applications are not simple and need to handle input from multiple sources.
UNIX provides this capability through the select(2) system call. This system call allows your program to check for input, output, or error conditions on one or more file descriptors. The file descriptors can point to serial ports, regular files, other devices, pipes, or sockets. You can poll to check for pending input, wait for input indefinitely, or timeout after a specific amount of time, making the select system call extremely flexible.
Most GUI Toolkits provide an interface to select; we will discuss the X Intrinsics ('Xt') library later in this chapter.
The SELECT System Call
The select system call accepts 5 arguments:
The max_fd argument specifies the highest numbered file descriptor in the input, output, and error sets. The input, output, and error arguments specify sets of file descriptors for pending input, output, or error conditions; specify
NULL
to disable monitoring for the corresponding condition. These sets are initialized using three macros: The FD_ZERO macro clears the set entirely. The FD_SET and FD_CLR macros add and remove a file descriptor from the set, respectively.
The timeout argument specifies a timeout value which consists of seconds (timeout.tv_sec) and microseconds (timeout.tv_usec). To poll one or more file descriptors, set the seconds and microseconds to zero. To wait indefinitely specify
NULL
for the timeout pointer. The select system call returns the number of file descriptors that have a pending condition, or -1 if there was an error.
Using the SELECT System Call
Suppose we are reading data from a serial port and a socket. We want to check for input from either file descriptor, but want to notify the user if no data is seen within 10 seconds. To do this we'll need to use the select system call:
Listing 8 - Using SELECT to process input from more than one source.
You'll notice that we first check the return value of the select system call. Values of 0 and -1 yield the appropriate warning and error messages. Values greater than 0 mean that we have data pending on one or more file descriptors.
To determine which file descriptor(s) have pending input, we use the FD_ISSET macro to test the input set for each file descriptor. If the file descriptor flag is set then the condition exists (input pending in this case) and we need to do something.
Using SELECT with the X Intrinsics Library
The X Intrinsics library provides an interface to the select system call via the XtAppAddInput(3x) and XtAppRemoveInput(3x) functions:
The select system call is used internally to implement timeouts, work procedures, and check for input from the X server. These functions can be used with any Xt-based toolkit including Xaw, Lesstif, and Motif.
The proc argument to XtAppAddInput specifies the function to call when the selected condition (e.g. input available) exists on the file descriptor. In the previous example you could specify the process_fd or process_socket functions.
Because Xt limits your access to the select system call, you'll need to implement timeouts through another mechanism, probably via XtAppAddTimeout(3x).
This appendix provides pinout information for many of the common serial ports you will find.
RS-232 Pinouts
RS-232 comes in three flavors (A, B, C) and uses a 25-pin D-Sub connector:
Figure 2 - RS-232 Connector
Pin | Description | Pin | Description |
---|---|---|---|
1 | Earth Ground | 14 | Secondary TXD |
2 | TXD - Transmitted Data | 15 | Transmit Clock |
3 | RXD - Received Data | 16 | Secondary RXD |
4 | RTS - Request To Send | 17 | Receiver Clock |
5 | CTS - Clear To Send | 18 | Unassigned |
6 | DSR - Data Set Ready | 19 | Secondary RTS |
7 | GND - Logic Ground | 20 | DTR - Data Terminal Ready |
8 | DCD - Data Carrier Detect | 21 | Signal Quality Detect |
9 | Reserved | 22 | Ring Detect |
10 | Reserved | 23 | Data Rate Select |
11 | Unassigned | 24 | Transmit Clock |
12 | Secondary DCD | 25 | Unassigned |
13 | Secondary CTS |
RS-422 Pinouts
RS-422 also uses a 25-pin D-Sub connector, but with differential signals:
Figure 3 - RS-422 Connector
Pin | Description | Pin | Description |
---|---|---|---|
1 | Earth Ground | 14 | TXD+ |
2 | TXD- - Transmitted Data | 15 | Transmit Clock- |
3 | RXD- - Received Data | 16 | RXD+ |
4 | RTS- - Request To Send | 17 | Receiver Clock- |
5 | CTS- - Clear To Send | 18 | Unassigned |
6 | DSR - Data Set Ready | 19 | RTS+ |
7 | GND - Logic Ground | 20 | DTR- - Data Terminal Ready |
8 | DCD- - Data Carrier Detect | 21 | Signal Quality Detect |
9 | Reserved | 22 | Unassigned |
10 | Reserved | 23 | DTR+ |
11 | Unassigned | 24 | Transmit Clock+ |
12 | DCD+ | 25 | Receiver Clock+ |
13 | CTS+ |
RS-574 (IBM PC/AT) Pinouts
The RS-574 interface is used exclusively by PC manufacturers and uses a 9-pin male D-Sub connector:
Figure 4 - RS-574 Connector
Pin | Description | Pin | Description |
---|---|---|---|
1 | DCD - Data Carrier Detect | 6 | Data Set Ready |
2 | RXD - Received Data | 7 | RTS - Request To Send |
3 | TXD - Transmitted Data | 8 | CTS - Clear To Send |
4 | DTR - Data Terminal Ready | 9 | Ring Detect |
5 | GND - Logic Ground |
SGI Pinouts
Older SGI equipment uses a 9-pin female D-Sub connector. Unlike RS-574, the SGI pinouts nearly match those of RS-232:
Figure 5 - SGI 9-Pin Connector
Pin | Description | Pin | Description |
---|---|---|---|
1 | Earth Ground | 6 | DSR - Data Set Ready |
2 | TXD - Transmitted Data | 7 | GND - Logic Ground |
3 | RXD - Received Data | 8 | DCD - Data Carrier Detect |
4 | RTS - Request To Send | 9 | DTR - Data Terminal Ready |
5 | CTS - Clear To Send |
The SGI Indigo, Indigo2, and Indy workstations use the Apple 8-pin MiniDIN connector for their serial ports:
Figure 6 - SGI 8-Pin Connector
Pin | Description | Pin | Description |
---|---|---|---|
1 | DTR - Data Terminal Ready | 5 | RXD - Received Data |
2 | CTS - Clear To Send | 6 | RTS - Request To Send |
3 | TXD - Transmitted Data | 7 | DCD - Data Carrier Detect |
4 | GND - Logic Ground | 8 | GND - Logic Ground |
This chapter lists the ASCII control codes and their names.
Control Codes
The following ASCII characters are used for control purposes:Name | Binary | Octal | Decimal | Hexadecimal |
---|---|---|---|---|
NUL | 00000000 | 000 | 0 | 00 |
SOH | 00000001 | 001 | 1 | 01 |
STX | 00000010 | 002 | 2 | 02 |
ETX | 00000011 | 003 | 3 | 03 |
EOT | 00000100 | 004 | 4 | 04 |
ENQ | 00000101 | 005 | 5 | 05 |
ACK | 00000110 | 006 | 6 | 06 |
BEL | 00000111 | 007 | 7 | 07 |
BS | 00001000 | 010 | 8 | 08 |
HT | 00001001 | 011 | 9 | 09 |
NL | 00001010 | 012 | 10 | 0A |
VT | 00001011 | 013 | 11 | 0B |
NP, FF | 00001100 | 014 | 12 | 0C |
CR | 00001101 | 015 | 13 | 0D |
SO | 00001110 | 016 | 14 | 0E |
SI | 00001111 | 017 | 15 | 0F |
DLE | 00010000 | 020 | 16 | 10 |
XON, DC1 | 00010001 | 021 | 17 | 11 |
DC2 | 00010010 | 022 | 18 | 12 |
XOFF, DC3 | 00010011 | 023 | 19 | 13 |
DC4 | 00010100 | 024 | 20 | 14 |
NAK | 00010101 | 025 | 21 | 15 |
SYN | 00010110 | 026 | 22 | 16 |
ETB | 00010111 | 027 | 23 | 17 |
CAN | 00011000 | 030 | 24 | 18 |
EM | 00011001 | 031 | 25 | 19 |
SUB | 00011010 | 032 | 26 | 1A |
ESC | 00011011 | 033 | 27 | 1B |
FS | 00011100 | 034 | 28 | 1C |
GS | 00011101 | 035 | 29 | 1D |
RS | 00011110 | 036 | 30 | 1E |
US | 00011111 | 037 | 31 | 1F |