Configuring (Set-Up) involves both storing a configuration in the non-volatile memory of the terminal, and putting commands in start-up files (on you hard disk) that will run each time the computer is powered on (or possibly only when the run-level changes). This section gives an overview of configuring and covers the configuring of the essential communication options for both the terminal and the computer. The next two major sections cover in detail the configuration of the terminal (see Terminal Set-Up and the computer (see Computer Set-Up (Configure) Details.
When a terminal is installed it's necessary to configure the physical terminal by saving (in its non-volatile memory which is not lost when the terminal is powered off) the characteristics it will have when it is powered on. You might be lucky and have a terminal that has already been set-up correctly for your installation so that little or no terminal configuration is required.
There are two basic ways of configuring a terminal. One is to sit at the terminal and go thru a series of set-up menus. Another is to send escape sequences to it from the host computer. Before you can send anything to the terminal (such as the above escape sequences), its Communication Interface) options such as the baud rate must be set up to match those of the computer. This can only be done by sitting at the terminal since the communications must be set up right before the computer and the terminal can "talk" to each other. See Terminal Set-Up.
Besides possibly sending escape sequences from the computer to configure the terminal, there is the configuring of the computer itself to handle the terminal. If your lucky, all you need to do is to put a "getty" command in the /etc/inittab file so that a "login:" prompt will be sent to the terminal when the computer starts up. See Getty (in /etc/inittab) for details. this for the computer.
The computer communicates with the terminal using the device driver software (part of the kernel). The serial device driver has a default configuration and is also partly (sometimes fully) configured by the getty program before running "login" at each terminal. However, additional configuration is sometimes needed using programs named "stty" and "setserial". These programs (if needed) must be run each time the computer starts up since this configuration is lost each time the computer powers down. See Computer Set-Up (Configure) Details.
There are a great many configuration options for you to choose from. The communication options must be set right or the terminal will not work at all. Other options may be set wrong, but will cause no problem since the features they set may not be used. For example, if you don't have a printer connected to the terminal it makes no difference how the printer configuration parameters are set inside the terminal. This last statement is not 100% correct. Suppose that you have no printer but the compute (by mistake) sends the terminal a command to redirect all characters (data) from the computer to the printer only. Then nothing will display on the screen and your terminal will be dead. Some terminals have a configuration option to inform the terminal that no printer is attached. In this case the terminal will ignore any command to redirect output to the "printer" and the above problem will never happen. However, this doesn't help much since there are many other erroneous commands that can be sent to your terminal that will really foul things up. This is likely to happen if you send the terminal a binary file by accident.
In some cases a wrong setting will not cause any problem until you happen to run a rare application program that expects the terminal to be set a certain way. Other options govern only the appearance of the display and the terminal will work fine if they are set wrong but may not be as pleasant to look at.
Some options concern only the terminal and do not need to be set at the computer. For example: Do you want black letters on a light background? This is easier on the eyes than a black background. Should a key repeat when held down? Should the screen wrap when a line runs off the right end of the screen? Should keys click?
Some of these communication settings (options) are for both the terminal and the computer and they must be set exactly the same for both: speed, parity, bits/character, and flow control. Other communication options are only set at the terminal (and only a couple of these are essential to establish communications). Still others such as the address and interrupt (IRQ) of the physical port ttyS2 are set only at the computer using the "setserial" command. Until all of the above essential options are compatibly set up there can be no satisfactory serial communication (and likely no communication at all) between the terminal and the computer. For the terminal, one must set these options manually by menus at each terminal (or by using some sort of special cartridge at each terminal). The host computer is configured by running commands each time the computer is powered up (or when people log in). Sometimes the getty program (found in the /etc/inittab file) which starts the login process will take care of this for the computer. See Getty (in /etc/inittab)
The settings for both the computer and the terminal are:
Some essential settings for the terminal alone are:
If the Getty (in /etc/inittab) program can't set up the computer side the way you want, then you may need to use one (or both) of the Stty & Setserial commands.
These must be set the same on both the terminal and the computer. The speed is the bits/sec (bps or baud rate). Use the highest speed that works without errors. Enabling flow control may make higher speeds possible. There may be two speeds to set at the terminal: Transmit and Receive, sometimes abbreviated T and R. Usually they are both set the same since stty in Linux doesn't seem to have the option yet of setting them differently. (There is an option to do this with the "stty" command but it seems to actually set them both the same.) Common speeds are 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, ... The slower speeds (like 600) are for printers and hard-copy terminals.
For a definition see Parity Explained. Parity-disabled is often the default. To enable parity, you must both enable it and then select either even or odd parity. It probably makes no difference if it's odd or even. For terminals there are sometimes settings for both transmit and receive parity. You should set both of these the same since stty at the computer doesn't permit setting them differently. The PC serial port usually can't support different parities either. Some terminal are unable to set receive parity and will simply always ignore received parity bits. On some older terminals if you use 8-data-bits per byte then parity will not work since there is no room in the hardware for the extra parity bit.
Should you use parity at all? Parity, while not really necessary, is nice to have. If you don't have parity, then you may get an incorrect letter here and there and wind up trying to correct spelling errors that don't really exist. However parity comes at a cost. First, it's more complicated to set up since the default is usually no parity. Secondly, parity will slow down the speed with which bytes travel over the serial cable since there will be one more bit per byte. This may or may not slow down the effective speed.
For example, a hard-copy terminal is usually limited by the mechanics of the printing process. Increasing the bytes/sec when the computer (its UART chip) is transmitting only results in more flow-control "halt" signals to allow the mechanical printing to catch up. Due to more flow-control waits the effective speed is no better without parity than with it. The situation is similar for some terminals: After you implement parity there may be fewer flow-control waits per unit time resulting in more bits/sec (average). However, due to the added parity bits the bytes/sec (average) stays the same.
One option is to install terminals with no parity. Then if parity errors are noticed, it can be implemented later. To spot possible errors with no parity, look for any spelling errors you don't think you made. If you spot such an error, refresh the screen (retransmit from the computer). If the error goes away, then it's likely a parity error. If too many such errors happen (such as more than one every few hundred screens) then corrective action is needed such as: Enable parity and/or reduce speed, and/or use a shorter/better cable. Enabling parity will not reduce the number of errors but it will tell you when an error has happened.
Just the opposite policy is to initially enable parity. Then if no parity errors (error symbols on the CRT) are ever seen (over a reasonable period of time, say a month or two) it may be safely disabled.
This is the character size (the number of data bits per character excluding any parity bit). To use international character sets you need 8 bits. But it's not of much use unless your terminal has the fonts for them. See Character-Sets If you are only going to use ASCII characters, then select 7-bits since it's faster to transmit 7 bits than 8. Some very old terminals only support 7-bit characters.
The choice is between "hardware" (for example dtr/cts) or "software" (Xon/Xoff) flow control. (The Adds terminal menu incorrectly use "Xon/Xoff" to mean any kind of flow control.) While hardware flow control may be faster (if the one or two extra wires for it are available in the cable and if the terminal supports it) in most cases Xon/Xoff should work OK. Some people report that they solved disturbing problems (see below) by converting to hardware flow control but software flow control has worked fine at other installations (and for me personally).
If you use software (Xon/Xoff) flow control and have users who don't know about it, then they may accidentally send an Xoff to the host and lock up their terminal. While it's locked, they may type frantically in a vain attempt to unlock it. Then when Xon is finally sent to restore communication, all that was typed in haste gets executed, perhaps with unexpected results. They can't do this with hardware flow control. See Flow Control for an explanation of flow control.
Since most terminals have two or more connectors on the back, it is usually possible to assign one of these connecters to connect to the host computer and assign another connector to be the printer port. The connector may have a name next to it (inspect it) and this name (such as Aux, Serial 2, or Modem) may be assigned to either be the main host connection or the printer connection (or the like).
While all the above may seem overly complex, to get a terminal working is often fairly simple. The Quick Install section describes a simple way to try to do this. But if that doesn't work or if you want to make the display look better and perform better, more reading will be needed.