|
|
|
|
|
Serial vs. Parallel Ports
A serial port is a physical communication interface through which information is transferred in or out one bit at a time (in contrast to a parallel port). Throughout most of the history of computers, serial ports have been used for data transfer between a computer and various peripheral devices, including computer terminals.
A parallel port is a physical communication interface which allows transfer of multiple bits simultaneously. It is also known as a printer port or Centronics port. The IEEE 1284 standard defines the bi-directional version of the port, which allows the transmission and receipt of data bits at the same time.
Common Settings for Serial Ports
Speed
Serial ports use two-level (binary) signaling, so the data rate in bits per second is equal to the symbol rate in bauds. A standard series of rates is based on multiples of the rates for electromechanical teleprinters; some serial ports allow many arbitrary rates to be selected. The port speed and device speed must match. Some serial port systems can automatically detect the bit rate. The speed includes bits for framing (stop bits, parity, etc.) and so the effective data rate is lower than the bit transmission rate. For example with 8-N-1 character framing only 80% of the bits are allocated for data (for every eight bits of data, two more framing bits are sent). Bit rates commonly supported include 75, 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200 bit/s.
Data bits
The number of data bits in each character can be 5 (for Baudot code), 6 (rarely used), 7 (for true ASCII), 8 (for any kind of data, as this matches the size of a byte), or 9 (rarely used). 8 data bits are almost universally used in newer applications. 5 or 7 bits generally only make sense with older equipment such as teleprinters.
Parity
Parity is a method for detection of errors in data transmission. When parity is used for the communication over a serial port, an extra data bit is sent with each data character, arranged so that the number of bits with value 1 in each character, including the parity bit, is always odd or always even. If a byte is received with a wrong number of 1s, then it must have been corrupted. However, an even number of errors can pass the parity check. The parity bit in each character can be set to none (N), odd (O), even (E), mark (M), or space (S). None means that no parity bit is sent at all. Mark parity means that the parity bit is always set to the mark signal condition (logical 1) and likewise Space parity always sends the parity bit in the space signal condition. Aside from uncommon applications that use the 9th (parity) bit for some form of addressing or special signaling, mark or space parity is uncommon, as it adds no error detection information. Odd parity is more useful than even parity, since it ensures that at least one state transition occurs in each character, which makes it more reliable. The most common parity setting, however, is "none", with error detection handled by a communication protocol.
Stop bits
A stop bit is sent at the end of every character to allow the hardware receiving the signal to detect the end of the character and to resynchronize with the character stream. Electronic devices usually use one stop bit. If slow electromechanical teleprinters are used, one-and-one half or two stop bits are required.
Flow control
A serial port may use signals in the interface to pause and resume the transmission of data. For example, a slow printer might need to handshake with the serial port to indicate that data should be paused while the mechanism advances a line. Common hardware handshake signals (hardware flow control) use the RS-232 RTS/CTS or DTR/DSR signal circuits. Generally, the RTS and CTS are turned on and off from alternate ends to control data flow, for instance when a buffer is almost full. According to the RS-232 standard and its successors, DTR and DSR are usually on all the time, and are used to signal from each end that the other equipment is actually present and powered-up. However, over the years manufacturers built many devices that implemented variations on the standard, for example, printers that use DTR as flow control. Another method of flow control (software flow control) uses special characters such as XON/XOFF to control the flow of data. The XON/XOFF characters are sent by the receiver to the sender to control when the sender should send data, that is, these characters go in the opposite direction to the data being sent. The circuit starts in the "sending allowed" state. When the receiver's buffers reach their capacity, the receiver sends an XOFF character to tell the sender to stop sending data. Later, after emptying its buffers, the receiver sends an XON character to tell the sender to resume the transmission. These are non-printing characters and are interpreted as handshake signals by printers, terminals, and computer systems. Thus the XON/XOFF flow control is an example of in-band signaling, i.e. control information is sent over the same channel used for the data. If the XON and XOFF characters happen to appear in the data being sent, the XON/XOFF handshaking might face difficulties, as the receiver may interpret them as flow control. To prevent this, such characters sent as part of the data stream must be encoded in escape sequences, and the receiving and sending software must generate and interpret these escape sequences. On the other hand, since no extra signal circuits are required, the XON/XOFF flow control can be implemented using a 3 wire interface.
What is RXTX?
RXTX is a Java library which provides the Java Development Toolkit (JDK) with capabilities for communication over serial and over parallel ports. It uses JNI (Java Native Interface) - an API for integration of native code with Java programs. All deliverables of the RXTX library are under the GNU LGPL license. It is based on the Oracle's specification for the Java Communications API and many of the class names are the same. Though a different package name is used here - gnu.io instead of javax.comm. The RXTX library was intended to be somewhat compatible with the Java Communications API, though this project should be considered as a fork and therefore compatible in spirit, but not in implementation.