Contents.Introduction General This content is part of the book. It covers the programming of Hayes and Hayes-compatible telephone modems. Such types of modems are the norm in consumer applications, as well as many professional applications - basically, wherever modems are still used.Modem programming is slowly becoming a lost art, particularly with the widespread migration of users from dial-up lines to DSL for very obvious performance reasons. Nevertheless, modems are used for many applications. In recent times, modems can be found in new areas where they were previously not seen. For example, embedded modems in machines are used to automatically 'call home' to the manufacturer in case the machine is in need of some service. Often this is done via a wireless phone system, where the wireless module still provides a Hayes-compatible interface for dialing and data transmission.The original Hayes modem command set is exclusively used as a reference in this module.

1. Serial Port Programming Linux Pdf Tutorial Windows 10
2. The Serial Programming Guide For Posix Operating Systems
3. Serial Port Programming

Vendor specific extensions are not covered, and do not belong into this module. The module explains the origin of the term Hayes, and the related AT commands. It also includes some principal information about what a modem is, and how the signaling with a modem happens. The module then continues with a description of the basics of modem programming, including the set-up of a development environment.Further, the module provides detailed (but incomplete) programming information, and an incomplete reference of the original Hayes command set and registers.Administrative Information This section particularly addresses potential authors. Please note:. This module is not a dumping ground for random modem programming information and folklore. This module is operating-system–agnostic.

The book provides other modules for such information. This module deals with generic Hayes modems, not with any vendor-specific extensions. If you really want to see your particular love-child covered, provide an Appendix with that vendor-/brand-specific information. Do not assume that just because something works on your particular modem it is the standard and other modems do it the same way. If you have no firsthand experience that something is done the same way on 'almost' all Hayes-compatible modems, then leave it out, or mark it at least as doubtful.The reason why this module sticks with the original Hayes command set is to have a defined boundary.

This module is not intended as a reference manual. Once someone has mastered the basic set, and implemented the code, it is rather straightforward to deal with vendor-specific extensions. Other extensions, e.g.

The very rough and basic FAX extensions, require some deep insight into the involved protocols (e.g. In the case of FAX the detailed encoding, compression and timing of fax data on the phone line). This is out of the scope of this book. If you know how to handle the FAX extensions, write your own book.What is Hayes? Hayes Microcomputer Products, Inc.

Was a modem manufacturer from the beginning of the 1980s until the end of the 1990s, with its heyday in the early '90s. The name Hayes still exists as a brand name, owned by Zoom Telephonics, Inc. (as of Fall 2004).In 1981, Hayes developed the Hayes Smartmodem.

This was a unique product at the time, because this modem was no longer simply a 'dumb' device blindly converting serial data to and from audio tones, but contained some 'intelligence'. It was possible to send commands to the modem to configure it, to execute certain operations (such as dialling a number, quieting the speaker, hanging up, etc.), and to read the current status of the connection. Hayes developed and published a command set to control the modem over a serial line. This command set became popular among consumer modem manufacturers, and was cloned by many different manufacturers. Known as both the 'Hayes command set' and the 'AT command set', it has long been the de-facto standard for controlling consumer modems and also many professional modems. Modems which support this command set are called Hayes-compatible.The commands were standardised at some point in time, however, as it is typical with standards, there are several standards.

Plus, of course, there are still vendor-specific extensions and implementations in different modems vary slightly. Some of these enhancements were required to support at that time emerging features, such as data compression and FAX support.

As a result, the command sets of modern modems are not fully compatible with each other. The original Hayes commands, however, should still work, and still form the core of almost all consumer modem command sets.The basic set of commands was at some point in time standardised as and the syntax as EIA/TIA-615. But as already mentioned, modem manufacturers added their extensions. A larger extended set, particular under the pressure from cell phone manufacturers, was standardised as (old name V.25ter). That one usually forms the base for professional Hayes-compatible modems, and cell phones with build in data modems.

ITU V.250 further referes to a bunch of other standards (e.g. V.251, V.252, V.253) for particular applications and extensions, and also has some supplements. Plus, of course there are the many standards defining other aspects of a modem, like compression and transmission.See Also:.What are AT Commands? Almost all of the Hayes modem commands start with the two letter sequence AT - for getting the modem's attention.

Because of this, modem commands are often called AT Commands. This still holds for many of the manufacturer specific command set extensions. Most of them also start with AT, and are called AT Commands, too. Please note, that just because an AT command contains a & does not make it an extensions. & commands were already part of the original Hayes command set.The exact usage of the term AT command set slightly varies from manufacturer to manufacturer, often subject to marketing blurbs. In general, it can be assumed that a modem with an AT command set.

uses commands mostly starting with AT,. uses the original Hayes way of separating data and commands, and. supports the original Hayes commands and register settings as a subset.What is a Modem? has related information atA modem in the classic sense is a modulator/ demodulator for transmitting digital information over analog wires, such as the analog telephone system's two-wire or four-wire lines. The term has come to be used as acceptable slang for many communication devices used to link a computer to either another computer, or a wide-area network. For example, the Ricochet radio data transceivers were commonly known as 'Ricochet modems'.This module deals with the classic type of smart modems, designed to convert data from/to a serial interface to/from an analog line. The module also applies to modems which provide the classic serial interface but connect over a different physical layer, such as a digital line, as well as devices providing a serial modem-like interface for other purposes.

For our purpose, the modem is a classic DCE (data communications equipment) device, controlled via serial line by a classic DTE (data terminal equipment) device (such as a computer).Depending on the type of modem, the modem can use a number of different technologies and speeds to transmit the data over the analog line. The details of these technologies are of no particular interest here, other than to note that it is possible with most modems to specify these communication parameters (for example, to disable compression, or to change modulation techniques). The data this module deals with is not the data on the analog line, but the data as it appears on the serial interface between the DTE and DCE. The data as read and written by a device like a computer.( Smart) Modems also provide auxiliary services, such as dialling a particular number to set up a connection. As a consequence, a modem can be in a number of different states and modes, which are not always orthogonal. It is possible, for example, for a modem to be in the command mode while still keeping a connection (see the sequence for details).Non-smart modems had to rely on other equipment like an ACU (automatic call unit) to provide these auxiliary services, but they are practically extinct today.Inband Signalling The original RS232C/V.24 specification contained a TX wire for transmitting data and a RX wire for receiving data, and other completely separate wires for transmitting control information between the DTE and DCE, the idea being to separate data and control information.

In telecommunication jargon this is called outband signalling.Hayes-compatible modems use almost none of these RS232C/V.24 features. Instead, communication with the modem is done almost exclusively via the same RX/TX lines which are used for transferring the data.

This mechanism is called inband signalling.Inband signalling has significant disadvantages. At any point in time, both the DTE and DCE must know if information sent or received via the TX and RX lines is for signalling purposes, or if it is data, which should be handled transparently. Therefore, the DTE and DCE must operate in sync. If they get out of sync, either data will be lost, data will be incorrectly interpreted as commands, or signalling information will be interpreted as data, effectively destroying the original data.Inband signalling has the advantage that the wiring between the DTE and DCE is simpler, and also that, at least at first glance, the communication software in the DTE is simpler.As it has been said, Hayes-compatible modems use almost none of the RS232 control lines. But only almost. For example, they often drive DCD (data carrier detect). This, however creates the situation that modem-driving software now has to take care not only of the inband, but also the outband signalling with a modem.

This slightly complicates the communication software's.Further, especially with the rise of cell phone modems, manufacturers have again started to introduce more outband signaling. Such modems provide multiple virtual serial interfaces. Some of these interfaces are exclusively dedicated to data transport, controlled by another serial interface which is either used exclusively for signalling (i.e. Outband signalling) or can still also be used in the more conventional inband signalling scenario. In such cases the communication software needs to manage even more complex states.Command State / On-line State With respect of controlling the modem a Hayes-compatible modem is in one of two main states:Command State The modem interprets data from the DTE as modem commands. The modem can be in command state while still keeping a connection with a remote party.

Serial Port Programming Linux Pdf Tutorial Windows 10

On-line State The modem interprets data from the DTE as payload and transmits it to the other party. This state requires that a connection to the remote site has been established.Inside these main states are a number of sub states. Also, with respect to other issues a modem has a number of communication states, e.g.

If a remote carrier has been detected or not.Originating Mode / Answer Mode Originating mode A modem in originating mode is a modem which is setting up a connection, e.g., by dialing the number of a remote station and initiating the negotiation of protocols. Answer Mode A modem in answer mode is a modem waiting to be contacted and ready to 'answer the phone'. Command Responses A modem is supposed to send a response for almost all commands it receives. These responses can either be in the form of ASCII strings, or numeric values. The response type can be switched with a command, but it is typical to use the ASCII responses.Responses need to be tracked by the DTE with great care. Among other things they inform the DTE if the dialling of the remote site was successful or not, and if the modem switches from command state to on-line state or not.Unfortunately, the set of response messages has been greatly enhanced since the original Hayes modems and are often configurable via additional AT commands. It is suggested to not strictly parse response messages but to forgivingly check if they contain interesting keywords, like CONNECT.

It is also suggested to study the manual of a particular modem very carefully.S-Registers The so called S-registers are also a Hayes heritage which all Hayes-compatible modems support. They are registers in the modem which contain various settings.

And like the AT commands, they have been extensively enhanced by different modem manufacturers.The reason why they are called S-Registers is a little bit unclear. Some say the S stands for modem settings. Some say they are just called like this, because they are set and read with ATS. In the common vernacular they were usually termed storage registers because they permanently stored the values even through power-off.Several of the other AT commands also change values of particular S-Registers. There is usually no difference in setting a value directly via an S-Register or via another AT command.

It depends on the particular situation which way of setting a register is better.Modem Programming Basics Command Reference In order to program for an actual modem it is a rather good idea to obtain the command reference for that particular modem. Unfortunately, it has become quite common for no-name modems to ship without any kind of usable command reference. Thanks to Windows' Plug & Play feature it is no longer necessary on Windows to know the individual commands. Instead, all that is needed for a modem to run on Windows is to be shipped with the necessary.inf files (often hidden inside some 'installer' software, and called a 'driver' which is technically not the case, Windows already contains the necessary drivers).If the modem doesn't come with a command reference the next logical step is to search the web. However, unfortunately, a lot of modem information has vanished from the surface of the earth and the web in recent years.

With the rise of broadband Internet connections, modems have become old fashioned devices and many sources are no longer available. It has become more and more difficult to find basic information about particular modem types. Even for modern modems like cell phone modems it can be difficult to find the necessary information.There are a number of alternatives to obtain a command reference if one doesn't come with the modem:. Maybe the distributor provides one on its website.

Maybe the OEM manufacturer provides one.This requires to identify the OEM manufacturer. A possible way is to use the FCC number of the device, and then looking the original manufacturer up on the FCC web site. Maybe the chipset manufacturer provides one.Consumer modems are often just build around 'off-the-shelf' modem chipsets from larger hardware manufacturers.

The cheaper the modem, the more likely it is that the modem manufacturer didn't change anything in the firmware and is using the original example software from the chipset manufacturer. Some chipset vendors provide command references for their modems. By looking into the corresponding Windows.inf files it is possible to at least obtain the basic commands. By using the generic Hayes command reference in this Wikibook module. Obtaining the previously mentioned standard documents if there is an indication a particular modem complies to such a command standard.

Using some kind of sniffer program to monitor the communication between the modem and the DTE and reverse engineering the commands using the obtained information. This requires that (a) reverse engineering is legal in your jurisdiction and (b) that there is some DTE communication software available that handles the particular modem so there is some valid communication to sniff.Setting up a Development Environment It is highly recommended to spend some preparation time setting up a suitable development environment before starting to write drivers or software for a modem.

Most of this consists of hardware set-up.It is suggested to set up a small network with a 'remote' computer and a second modem in answer mode. 'Remote' computer in this case means a computer sitting right next to the development machine, but connected via the modems.

If a terminal program is being developed, the 'remote' computer should run some small BBS software (for example), so there is always someone ready to answer, and/or protocol analysis/data dump software. Developing modem software without such a setup can be extremely frustrating. Such a set-up pays off a hundred times in reduced development time and lower stress. Likewise, the modems used should have real speakers, and support ATM n commands well enough that you can leave the speaker on for the entire connection process (and ideally have the option to leave it on, period).

The Serial Programming Guide For Posix Operating Systems

'Debugging by ear' can be a reality with modems, particularly during compatibility testing.If possible, a hardware protocol analyser, or at least an, should be obtained. These can be placed between the computers and modems, if needed, to troubleshoot the serial link and ensure that data is, in fact, being transferred between the modem and the computer - a sanity check which comes in handy far more often than you might expect. Actual hardware protocol analysers are surprisingly expensive, however; old Wyse terminals are not, and are almost as useful for this purpose. If you find one, pick it up. Terminals that support automatic baud-rate detection are particularly useful.If dialing with the modem also needs to be tested, a small analog PABX for home usage is needed. These PABX units are dirt cheap; an analog PABX for four internal lines and one external line should cost no more than US$50.

Flow Control A slow device needs a way to tell its peer that currently, it is busy, so further incoming data must be stopped until this slow device tells otherwise. This mechanism is provided by flow control.There are two ways of doing flow control: by hardware or software.Hardware Flow Control Hardware flow control is usually implemented using the CTS and RTS lines, which needs separate hardware data lines between devices. This is allocated in the RS-232 cable specification.Hardware flow control based on DSR and DTR is uncommon, particular for modems. It can usually be found at serial printers. Again, DSR/DTR hardware flow control requires additional hardware data lines between devices.From a programming point of view there is usually not much difference in programming CTS/RTS or DSR/DTR hardware flow control. The hardware has to provide means to drive/read the corresponding signals in the serial interface.

If the hardware supports both, CTS/RTS and DSR/DTR flow control, then it is recommended to support both and provide the user with a configuration option.It should be noted that some hardware or operating system drivers do not provide means to drive/read the less common DSR/DTR combination. If the remote device insists on DTR/DSR flow control a common workaround is to use CTS/RTS in the software, but rewire the cabling so the CTS/RTS wires are in fact connected to DSR/DTR.Software Flow Control This kind of flow control doesn't need extra signal line(s) like hardware flow control, but instead uses special control characters within the data content. To stop further incoming data, the receiving device sends the XOFF character. To enable more data, an XON character will be sent.However, since the data being sent cannot contain these characters (unless you know that the receiving device ignores such information), binary (non-ASCII) data cannot be transmitted this way.

Serial Port Programming

Software flow control is typically used for communications to terminals and other character-based devices. Binary data should not be sent this way as it could, randomly, contain these characters. Hardware flow control using RTS/CTS is usually used.Helpful Hint: Realizing that the Control Key is a special 'shift' key that chops off the 100 bit (octal), it is easy to remember that the ASCII character used for sending XOFF is a Control-S (23 Octal) while the character for XON is a Control-Q (21 Octal). Think of 'S' for Stop and 'Q' for Qontinue. Don't you spell it that way?Changing State General Changing the state from command state to on-line state or vice versa is either straightforward or a great mystery.

This module covers the more obscure ways.On-line State to Command State It is of course possible to switch from on-line state to command state by dropping the connection (going on-hook in modem terminology). It is also possible to temporarily switch into command state while keeping the connection.Going on-hook programmatically (and not via dropping a modem control line) requires to first switch into command state while keeping the connection, too.Switching into command state, while in fact in the middle of transferring data (nothing else is meant with on-line state) requires to send a certain escape sequence as part of the data.

This escape sequence is detected by the modem and the modem changes state. Since this character sequence might also be part of the normal data, an additional mechanism is needed to separate the escape sequence from normal data. This is the curse of inband signalling.The separation of the escape sequence is done by using a so called guard time, which was once patented by Hayes.

As a result, some modem manufacturers eliminated the guard time using an alternate escape sequence called the Time Independent Escape Sequence. Anyway, the escape sequence is only recognized by the modem when there was no other data from the DTE (terminal) for at least the duration of the guard time, and when there was no other data from the terminal after the escape sequence for at least the duration of the guard time, too.An escape sequence consists of three times the same particular character. The character, as well as the guard time is configurable. By default, the character is +, and the guard time is one second. So, with the default configuration, a change to command state requires If the connection should be dropped, this escape sequence should be followed by the AT command to go on-hook, which is ATH0: ATH0 Command State to On-line State The usual way to go from command state to on-line state is via dialing the remote site (see D command). But if the connection already exists, and the modem has been switched to command mode via the escape sequence, the way is different.If the connection should not be dropped, but instead data transmission should be continued, the ATO0 (letter o, digit zero) command is needed: send a few more modem commands, then go back on-lineATO0 Sync.

Interface. This page or section is an undeveloped draft or outline.You can help to, or you can ask for assistance in the.AT Command Format Here is a summary of the format and syntax of AT commands. Please note that most of the control characters are configurable, and the summary only uses the default control characters. AT commands are accepted by the modem only when in command mode.

The modem can be forced into command mode with the. Commands are grouped in command lines.

Each command line must start with the and terminated with. The only exception is the command. The body of a command line consists of visible ASCII characters (ASCII code 32 to 126). Space (ASCII code 32) and ASCII control characters (ASCII code 0 to 31) are ignored, with the exception of, and. All characters preceding the are ignored. Interpretation / execution of the command line starts with the reception of the first (and also command-line terminating).

Characters after the initial and before the are interpreted as commands. With some exceptions, there can be many commands in one command line. Each of the basic commands consists of a single ASCII letter, or a single ASCII letter with a &prefix, followed by a numeric value. Missing numeric values are interpreted as 0 (zero). The following commands can't be followed by more commands on the command line.

They must always be the last commands in a command line. If they are followed by other commands, these other commands are ignored.

However, some of these commands take command modifiers and it is possible that a following command is accidentally interpreted as a command modifier. Therefore, care should be taken to not follow these commands with any more commands on the same command line. Instead, they should be placed in an own command line. A command line can be edited if the terminating has not ben entered, using the to delete one command line character at a time.

The initial can't be edited/deleted (it has already been processed, because upon reception of the the modem immediately starts command line parsing and editing, but not execution). The modem echoes command lines and edits when is on (surprise, surprise:-)). When echo is on, are echoed with a sequence of (backspace, space, backspace) to erase the last character in e.g.

A terminal program on the DTE. A command line can be cancelled at any time before the terminating by sending the. No command in the command line is executed in this case. The and can also be cancelled as long as the handshake with the remote site has not been completed.

Cancellation is done by sending an additional character. In theory, it doesn't matter which character.

But care has to be taken that cancellation is not attempted when the handshake has already completed. In this case the modem has switched to on-line state and the character will be send to the remote side.

A save way to avoid this problem is to always use the followed by going on-hock with the. If the modem is already in the on-line state, this will drop the connection. If the modem is still in the handshake phase the first character of the will cancel the command (and the rest will be interpreted as a normal command line, doing no harm).

Command line execution stops when the first command in the command line fails, or the whole command line has been executed. Every command before the failed command has been executed. Every command after the failed command and the failed command in the command line has not been executed.

There is no particular indication which command in a command line failed, only that one failed. It is best to repeat the complete command line, or to first reset the modem to a defined state before recovering from a failure.

A modem only accepts a new command line when the previous command line has been executed (half-duplex communication).

Contents.The Classic Unix C APIs for Serial Communication Introduction Scope 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. 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 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/tty xxx Normal, generic access to the device. Used for terminal and other serial communication (originally for tele types). More recently, they are also used in modem communication, for example, whereas the /dev/cua xxx was used on older systems. See the following module on how terminal I/O and serial I/O relate on Unix. /dev/cua xxx Legacy device driver with special DCD handling.

Typically this was used for accessing a modem on old Unix systems, such as running the 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/com xxx. Linux system generally call serial ports /dev/ttyS xxx 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/pty xxx 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 Basics 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,.

An old one called. A newer one (although still already a few decades old), which is called (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 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 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. This section is a stub.You can help Wikibooks by.Just some hints:A Linux-specific way of configuring serial devices using the setserial program.tty 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.echo -e 'Enter serial device name: c'read devif tty -s.