TINI Serial and Parallel I/O
The TINI microcontroller is equipped for many forms of I/O. The simpler two of these are the serial and parallel ports. The TINI CPU can directly support two serial ports and many others can be added as memory-mapped peripherals. TINI’s parallel I/O ports are simply 8-bit wide, memory-mapped I/O busses for general-purpose control. We will examine each of these two I/O devices in detail and provide some example circuits and programs.
Some have called the RS-232/EIA-232 serial port the most popular interface standard in the world1. It was first introduced in 1962 and has been widely used throughout the industry on computers, computer terminals, and many different types of devices from modems to multimeters. It was developed for single-ended data transmission at relatively slow data rates (20 kbps) over short distances (typically up to 50 feet) but is often used for faster data rates and much longer cable lengths. Almost all personal computers currently made have at least one serial port. The serial port converts data from internal parallel data to a serial data stream and changes the electrical representation of the data so it can be transmitted over distance without data loss. The serial port is defined by the RS-232-C (RS for Recommended Standard) or the EIA-232-D (EIA for Electronics Industry Association) specifications. The RS specification is now obsolete but still widely used. The TINI microcontroller has two serial ports on the SIMM and more can be added as memory-mapped devices. We have already used the primary serial port in earlier chapters for communicating with TINI to load and configure the firmware.
Figure 9-1: Connecting to the TINI serial port
A few serial port details
You don’t have to fully understand the details of RS-232-C to use a serial port, but a familiarization with the basics makes working with the TINI serial ports much simpler and certainly helps if you run into any problems along the way.
The UART (Universal Asynchronous Receiver/Transmitter) is the integrated circuit that controls the serial port. It basically does everything for the computer in the way of managing the transmission and receipt of data. Specifically, the UART:
• converts bytes from parallel data to a serial data stream when transmitting data.
• converts the received serial data stream back into parallel data for the com-puter when receiving data.
• deals with the parity bit on both outgoing and incoming transmissions.
• manages the serial port flow control lines.
• Some UARTS also provide buffering (like 16 bytes or so).
The UART works with parallel-to-serial (and flow control) signals at the same voltage levels as the computer or device; in the case of TINI this is 5 volts. A serial line driver, discussed in a few paragraphs, will then shift these voltages to serial line voltages.
Flow control, parity, stop bits, data format
The serial port is said to be asynchronous, meaning that there is no clock transmitted with the data to identify to the receiving end when each bit should be valid. A trans- mitted sequence of all 1’s or all 0’s would be hard for the receiver to identify the individual bits (or just how many bits there are, for that matter) without some sort of timing information. Since this timing information is not in the data stream, the UART provides this. The transmitting UART frames each byte sent by placing a start bit at the beginning of the serial data and a stop bit at the end. The receiving UART listens to the serial line for a start bit and when it detects one it starts a clock running. It uses this clock to determine the amount of time needed for each bit in the serial data stream. In this way, asynchronous data is actually synchronized as it is received. In serial transmission of data by RS-232/EIA-232 ports the low-order bit is always sent first.
Figure 9-2: Serial data
The transmitting and receiving UARTs also need a way to communicate with each other so that the transmitter does not send too much data for the receiver, and the receiver can tell the transmitter if it’s ready for more data or not. This flow control prevents data from being lost. Flow control can be implemented in either hardware or software. Software flow control for serial ports is called XON/XOFF. With XON/XOFF flow control, the receiving device tells the computer when to pause by sending it an XOFF character (control-S) and when to resume transmission by sending the computer the XON character (control-Q). The advantage of using software flow control is that you can implement a serial port with only three wires (transmit, receive, common). Hardware flow control is accomplished by using additional wires for signaling between the transmitting device and the receiving device. Hardware flow control is managed by the UART. It controls four additional lines for this (but some devices will only implement two of these lines):
• RTS – Ready To Send
• CTS – Clear To Send
• DSR – Data Set Ready
• DTR – Data Terminal Ready
Here is how this works. When a computer wants to stop the flow of data on the serial line, it negates the RTS line. Negated RTS (-12 volts) means “request NOT to send” or stop sending data. When the computer is ready for more bytes it asserts RTS (back to +12 volts) and the flow of data resumes. Flow control signals are always sent in a direction opposite to the flow of data that is being controlled. Serial devices (not computers) work the same way but they send the stop signal to the computer via the CTS pin. This is called RTS/CTS flow control. In addition to RTS/CTS flow control; a device can implement DTR/DSR control. The normal use of DTR and DSR like this: A device asserting DTR (+12 volts) says that it is powered on and ready to communicate (data terminal is ready). Some modems interpret the DTR signal from the computer as a “hang up” signal (hang up when DTR is negative) but not always. In fact some devices require that DTR be high before they will communicate. Readers should note that in the case of TINI and Serial0, taking the DTR line to a non-HIGH (0 or negative) will cause a hardware reset.
Characters are normally transmitted serially as either 7 or 8 bits of data. An addi- tional parity bit may (or may not) be appended to this, resulting in a byte length of 7, 8 or 9 bits. The parity may be set to odd, even, or none. With odd parity, the parity bit is determined so that the number of 1’s in a byte, including the parity bit, is odd. If a byte gets corrupted in transmission by a bit being flipped, the result is an invalid byte of even parity (the wrong parity). Even parity works the same way but with all valid bytes including the parity bit having an even number of 1’s. The UART will detect a parity error and this allows the software application to detect (if the software is properly written) the errors and request retransmission of the appropriate information. Figure 9-2 shows 8 data bits, no parity, 1 stop bit. This is often abbreviated as 8N1. It is important that you know what format your serial device and computer is expecting and set the software settings for them both to the same parameters.