termios is the newer (now already a few decades old) Unix API for terminal I/O. The anatomy of a program performing serial I/O with the help of termios is as follows:

Open serial device with standard Unix system call open(2)

Configure communication parameters and other interface properties (line discipline, etc.) with the help of specific termios functions and data structures.

Use standard Unix system calls read(2) and write(2) for reading from, and writing to the serial interface. Related system calls like readv(2) and writev(2) can be used, too. Multiple I/O techniques, like blocking, non-blocking, asynchronous I/O (select(2) or poll(2), or signal-driven I/O (SIGIO signal)) are also possible. The selection of the I/O technique is an important part of the application's design. The serial I/O needs to work well with other kinds of I/O performed by the application, like networking, and must not waste CPU cycles.

Close device with the standard Unix system call close(2) when done.

An important part when starting a program for serial I/I is to decide on the I/O technique to deploy.

The necessary declarations and constants for termios can be found in the header file <termios.h>. So code for serial or terminal I/O will usually start with

#include <termios.h>

Some additional functions and declarations can also be found in the <stdio.h>, <fcntl.h>, and <unistd.h> header files.

The termios I/O API supports two different modes: doesn't old termio do this too? if yes, move paragraphs up to the general section about serial and terminal I/O in Unix).

1. Canonical mode.
This is most useful when dealing with real terminals, or devices that provide line-by-line communication. The terminal driver returns data line-by-line.

2. Non-canonical mode.
In this mode, no special processing is done, and the terminal driver returns individual characters.

On BSD-like systems, there are three modes:

1. Cooked Mode.
Input is assembled into lines and special characters are processed.

2. Raw mode.
Input is not assembled into lines and special characters are not processed.

3. Cbreak mode.
Input is not assembled into lines but some special characters are processed.

Unless set otherwise, canonical (or cooked mode under BSD) is the default. The special characters processed in the corresponding modes are control characters, such as end-of-line or backspace. The full list for a particular Unix flavor can be found in the corresponding termios man page. For serial communication it is often advisable to use non-canonical, (raw or cbreak mode under BSD) to ensure that transmitted data is not interpreted by the terminal driver. Therefore, when setting up the communication parameters, the device should also configured for raw/non-canonical mode by setting/clearing the corresponding termios flags. It is also possible to enable or disable the processing of the special characters on an individual basis.

This configuration is done by using the struct termios data structure, defined in the termios.h header. This structure is central to both the configuration of a serial device and querying its setup. It contains a minimum of the following fields:

It should be noted that real struct termios declarations are often much more complicated. This stems from the fact that Unix vendors implement termios so that it is backward compatible with termio and integrate termio and termios behavior in the same data structure so they can avoid to have to implement the same code twice. In such a case, an application programmer may be able to intermix termio and termios code.

There are more than 45 different flags that can be set (via tcsetattr()) or got (via tcgetattr()) with the help of the struct termios. The large number of flags, and their sometimes esoteric and pathologic meaning and behavior, is one of the reasons why serial programming under Unix can be hard. In the device configuration, one must be careful not to make a mistake.

A few decisions have to be made when opening a serial device. Should the device be opened for reading only, writing only, or both reading and writing? Should the device be opened for blocking or non-blocking I/O (non-blocking is recommended)? While open(2) can be called with quite a number of different flags controlling these and other properties, the following as a typical example:

After a serial device has been opened, it is typical that its default configuration, like baud rate or line discipline need to be override with the desired parameters. This is done with a rather complex data structure, and the tcgetattr(3) and tcsetattr(3) functions. Before that is done, however, it is a good idea to check if the opened device is indeed a serial device (aka tty).

The following is an example of such a configuration. The details are explained later in this module.

termios contains a number of line-control functions. These allow a more fine-grained control over the serial line in certain special situations. They all work on a file descriptor fildes, returned by an open(2) call to open the serial device. In the case of an error, the detailed cause can be found in the global errno variable (see errno(2)).

Wait until all data previously written to the serial line indicated by fildes has been sent. This means, the function will return when the UART's send buffer has cleared.
If successful, the function returns 0. Otherwise it returns -1, and the global variable errno contains the exact reason for the error.

Todays computer are fast, have more cores and a lot of optimization inside. That can cause strange results because it result depends on circumstances the programmer may not aware of. See the example below:

without tcdrain()

set_rts();
write();
clr_rts();

With that code you would expect a signal going up, the write and a signal going down. But that is wrong. Perhaps optimization causes the kernel to report success to write before the data are really written.

Now the same code using tcdrain()

with tcdrain()

set_rts();
write();
tcdrain();
clr_rts();

Suddenly the code behaves as expected, because the clr_rts(); is executed only when data really is written. Several programmers solve the problem by using sleep()/usleep() what may be not exactly what you want.

This function suspends/restarts transmission and/or reception of data on the serial device indicated by fildes. The exact function is controlled by the action argument. action should be one of the following constants:

TCOOFF

Suspend output.

TCOON

Restarts previously suspended output.

TCIOFF

Transmit a STOP (xoff) character. Remote devices are supposed to stop transmitting data if they receive this character. This requires the remote device on the other end of the serial line to support this software flow-control.

TCION

Transmit a START (xon) character. Remote devices should restart transmitting data if they receive this character. This requires the remote device on the other end of the serial line to support this software flow-control.

If successful, the function returns 0. Otherwise it returns -1, and the global variable errno contains the exact reason for the error.

Sends a break for a certain duration. The duration_flag controls the duration of the break signal:

0

Send a break of at least 0.25 seconds, and not more than 0.5 seconds.

any other value

For other values than 0, the behavior is implementation defined. Some implementations interpret the value as some time specifications, others just let the function behave like tcdrain().

A break is a deliberately generated framing (timing) error of the serial data – the signal's timing is violated by sending a series of zero bits, which also encompasses the start/stop bits, so the framing is explicitly gone.

If successful, the function returns 0. Otherwise it returns -1, and the global variable errno contains the exact reason for the error.

There are more than 60 parameters a serial interface in Unix can have, assuming of course the underlying hardware supports every possible parameter - which many serial devices in professional workstations and Unix servers indeed do. This plethora of parameters and the resulting different interface configuration is what make serial programming in Unix and Linux challenging. Not only are there so many parameters, but their meanings are often rather unknown to contemporary hackers, because they originated at the dawn of computing, where things were done differently and are no longer known or taught in Little-Hacker School.

Nevertheless, most of the parameters of a serial interface in Unix are just controlled via two functions:

tcgetattr()

For reading the current attributes.

and

tcsetattr()

For setting serial interface attributes.

All information about the configuration of a serial interface is stored in an instance of the struct termios data type. tcgetattr() requires a pointer to a pre-allocated struct termios where it reads the values from. tcsetattr() requires a pointer to a pre-allocated and initialized struct termios where the function writes to.

Further, speed parameters are set via a separate set of functions:

cfgetispeed()

Get line-in speed.

cfgetospeed()

Get line-out speed.

cfsetispeed()

Set line-in speed.

cfsetospeed()

Set line-out speed.

The following sub-section explain the mentioned functions in more detail.

50+ attributes of a serial interface in Unix can be read with a single function: tcgetattr(). Among these parameters are all the option flags and, for example, information about which special character handling is applied. The signature of that function is as it follows:

#include <termios.h>
int tcgetattr(int fd, struct termios *attribs);

Where the arguments are:

fd

A file handle pointing to an opened terminal device. The device has typically be opened via the open(2) system call. However, there are several more mechanisms in Unix to obtain a legitimate file handle (e.g. by inheriting it over a fork(2)/exec(2) combo). As long as the handle points to an opened terminal device things are fine.

*attribs

A pointer to a pre-allocated struct termios, where tcgetattr() will write to.

tcgetattr() returns an integer that either indicates success or failure in the way typical for Unix system calls:

0

Indicates successful completion

-1

Indicates failure. Further information about the problem can be found in the global (or thread-local) errno variable. See the errno(2), intro(2), and/or perror(3C) man page for information about the meaning of the errno values.

Note; it is a typical beginner and hacker error to not check the return value and assume everything will always work.

The following is a simple example demonstrating the use of tcgetattr(). It assumes that standard input has been redirected to a terminal device:

Reading and setting the baud rates (the line speeds) can be done via the tcgetattr() and tcsetattr() function. This can be done by reading or writing the necessary data into the struct termios. However, this is a mess. The previous example for tcgetattr() demonstrates this.

Instead of accessing the data manually, it is highly recommended to use one of the following functions:

If the speed could not be set (e.g. if it is not a valid or supported speed value).

Note:
If you wonder why the function names don't start with the tc but with a cf prefix, then you see one of the many idiosyncrasies of the Unix API. Someone apparently wanted to be clever and thought that since the functions need to deal with the c_flags member of struct termios, they should start with cf. Thereby totally ignoring that the whole idea of these functions is to hide an implementation detail (c_flags) - not exposing it. Talk about the wrong level of focus.

Here is a simple example for cfgetispeed(). cfgetospeed() works very similar:

cfsetispeed() and cfsetospeed() work straight-forward, too. The following example sets the input speed of stdin to 9600 baud. Note, the setting will not be permanent, since the device might be reset at the end of the program:

This mode will handle a fixed number of characters and allows for a character timer.In this mode input is not assembled into lines and input processing does not occur.Here we have to set two parameters time and minimum number of characters to be received before read is satisfied and these are set by setting VTIME and VMIN characters for example if we have to set Minimum number of characters as 4 and we don't want to use any timer then we can do so as follows-:

There are a few C functions that can be useful for terminal and serial I/O programming and are not part of the terminal I/O API. These are

#include <stdio.h>
char *ctermid(char *s);

This function returns the device name of the current controlling terminal of the process as a string (e.g. "/dev/tty01"). This is useful for programs who want to open that terminal device directly in order to communicate with it, even if the controlling terminal association is removed later (because, for example, the process forks/execs to become a daemon process).*s can either be NULL or should point to a character array of at least L_ctermid bytes (the constant is also defined in stdio.h). If *s is NULL, then some internal static char array is used, otherwise the provided array is used. In both cases, a pointer to the first element of the char array is returned

#include <unistd.h>
int isatty(int fildes)

Checks if the provided file descriptor represents a terminal device. This can e.g. be used to figure out if a device will understand the commands send via the terminal I/O API.

#include <unistd.h>
char *ttyname (int fildes);

This function returns the device name of a terminal device represented by a file descriptor as a string.

These I/O controls allow to get and set the window size of a terminal emulation, e.g. an xterm in pixel and character sizes. Typically the get variant (TIOCGWINSZ) is used in combination with a SIGWINCH signal handler. The signal handler gets called when the size has changed (e.g. because the user has resized the terminal emulation window), and the application uses the I/O control to get the new size.

Warning: In this program the VMIN and VTIME flags are ignored because the O_NONBLOCK flag is set.

#include <stdlib.h>#include <stdio.h>#include <unistd.h>#include <fcntl.h>#include <termios.h>#include <string.h> // needed for memsetintmain(intargc,char**argv){structtermiostio;structtermiosstdio;inttty_fd;fd_setrdset;unsignedcharc='D';printf("Please start with %s /dev/ttyS1 (for example)\n",argv[0]);memset(&stdio,0,sizeof(stdio));stdio.c_iflag=0;stdio.c_oflag=0;stdio.c_cflag=0;stdio.c_lflag=0;stdio.c_cc[VMIN]=1;stdio.c_cc[VTIME]=0;tcsetattr(STDOUT_FILENO,TCSANOW,&stdio);tcsetattr(STDOUT_FILENO,TCSAFLUSH,&stdio);fcntl(STDIN_FILENO,F_SETFL,O_NONBLOCK);// make the reads non-blockingmemset(&tio,0,sizeof(tio));tio.c_iflag=0;tio.c_oflag=0;tio.c_cflag=CS8|CREAD|CLOCAL;// 8n1, see termios.h for more informationtio.c_lflag=0;tio.c_cc[VMIN]=1;tio.c_cc[VTIME]=5;tty_fd=open(argv[1],O_RDWR|O_NONBLOCK);cfsetospeed(&tio,B115200);// 115200 baudcfsetispeed(&tio,B115200);// 115200 baudtcsetattr(tty_fd,TCSANOW,&tio);while(c!='q'){if(read(tty_fd,&c,1)>0)write(STDOUT_FILENO,&c,1);// if new data is available on the serial port, print it outif(read(STDIN_FILENO,&c,1)>0)write(tty_fd,&c,1);// if new data is available on the console, send it to the serial port}close(tty_fd);}