The ordinary personal computer makes convenient automated testing possible on an everyday budget. In general, the PC-based system is usually dedicated to testing a specific component or circuit. Large-scale automatic test equipment (ATE), on the other hand, provides tremendous flexibility by allowing complex testing of many different types of devices through software modifications. But this capability comes at a price: ATE can cost upwards of a million dollars.
One of the easiest ways to connect test equipment and the device under test (DUT) to a personal computer is through the PC's parallel port. This port serves as a convenient connection for small, cost-sensitive test applications. It also is a useful tool for quickly prototyping a circuit.
A parallel port, which is standard equipment on nearly every IBM-compatible PC, can be connected directly to TTL/CMOS circuits. The standard parallel port provides 12 logic outputs and five inputs. Furthermore, software design is simple because the PC parallel port is easy to program using either C or Basic.1
Because PCs contain the hardware necessary to operate the parallel port, there's no need to open the PC to install a card. Using the parallel port thereby eliminates the risk of electrostatic discharge damage due to improper handling procedures while the computer is open.
Engineers connect the parallel port to various types of interfaces. A parallel port often drives two-wire I2C interfaces. The I2C standard specifies that I2C transmitters provide logic signals via open-collector outputs, so the interface circuitry can be as simple as a single open-collector inverter IC, like the 74HC05. Figure 1 illustrates a parallel-port-to-I2C interface that transmits and receives data to and from a DUT.
Beware Of Parallel-Port Pitfalls
Although there are advantages to communicating via the parallel port, a number of minor pitfalls accompany its use. For example, when using programs written for Microsoft Windows, only as many as four unused parallel-port input pins can be dedicated to the application. The limitation occurs because programs written for Windows cannot reliably determine the address of the parallel port. Connecting one of the output pins of the parallel port to one of its input pins allows software to automatically determine the parallel-port address. Doing so, however, reduces the number of usable input pins to four. A more difficult problem can occur if voltages that exceed the supply rails make contact with any of the circuitry connected to the parallel port. These voltages can destroy the circuitry external to the computer, as well as the parallel port itself.
A way to guard against excessive voltage is to include a circuit-protector IC, such as the MAX367 (Fig. 1, again). When voltage applied to either side of any protector within this chip exceeds the supply rails, the resistance of the specific protector becomes very high, preventing appreciable current from flowing through it. This high resistance also acts to limit the voltage to within the supply rails. This way, it prevents any high voltages inadvertently placed on its SCL, SDA, or DUT-+5-V pins from damaging either the interface circuitry or the parallel port itself.
Other minor problems can crop up when using the PC parallel port. Because only a small amount of power can be drawn from the unused parallel-port output pins (no more than 10 mA with the output voltage perhaps dropping as low as 3 V), an external power supply might be required. However, a carefully designed micropower system may eliminate that need.
Another possible problem is variation of parallel-port logic levels from one PC to the next. Different computer manufacturers use different output drivers (i.e., S, TTL, LSTTL, CMOS) within their computers, so some drivers provide output levels close to 5 V, while others are nearer to 3 V.
Additional problems can arise when a low-budget test system shares a computer that runs other applications. For example, when a computer includes a print driver, that driver may maintain control of the parallel port, even when nothing is being printed. Because most PCs include only one parallel port, no communication with test equipment via the port is possible under these conditions. Another source of possible bus contention is software protection keys that plug into the parallel port.
Today's computers typically include enhancements that allow bidirectional communication via the parallel port. The relatively modern ECP and EPP standards permit the parallel port to automatically transfer blocks of data to and from the PC (i.e., bidirectionally). Sometimes the system BIOS disables these enhancements, and sometimes PCs that include these enhancements are incompatible with other computers.
When communication with the test system must be accomplished with precise timing, the parallel port might not be the right selection. The periodic intervals when the main processor refreshes the PC's dynamic memory often cause the waveforms synthesized by the parallel port to be "jittery." Even worse, when using Windows, the program driving the parallel port may be periodically interrupted. Although all programmed events happen in the correct order, exact timing of these events isn't assured.
The PC serial port, sometimes called the RS-232 port, provides another easy method for connecting a PC to a DUT. Like the parallel port, the serial port is available on most PCs, and an interface need not be installed. Unlike the parallel port, which uses logic-level voltages, the serial port employs signal voltages that swing both positively and negatively. The transmitter voltage levels required by the RS-232 specification are at minimum ±5 V. In reality, voltage levels can vary from ±3 to ±30 V. The logic-level variations associated with a parallel port don't occur with a serial port because, after receiving the RS-232 signals, an RS-232 receiver provides a logic-level output close to the voltage of the supply powering the receiver (provided that the output is lightly loaded).
The PC Serial Port Or RS-232
The serial port allows only one driver on each signal line, so it can connect the PC to only one device at a time. Some devices get past this restriction by using the hardware handshake lines to create a signal. (This is an unorthodox technique whose description is beyond the scope of this article.) Because PCs usually include only one or two serial ports and because each instrument requires exclusive use of a port, a test system based on the serial port has limited expansion capability.
The serial port provides even less power than the parallel port, and the voltage levels aren't regulated. With the aid of some additional circuitry, the serial port can power a micropower circuit, but most applications require an external power supply.
When using a serial port, sending and receiving data often requires a microcontroller. Some microcontrollers, such as the 68HC11, the 8051, and the PIC-16C63, include a UART. When teamed with an RS-232 transceiver like the MAX3320 and a low-cost ceramic resonator, these microcontrollers can receive commands from a user-interface program running on the PC (Fig. 2). Two options are possible for this user interface: a text-only terminal program (e.g., Hyperterminal or Procomm) or a custom graphical interface. After receiving these commands from the user interface, the microcontroller can perform relatively sophisticated control functions without the aid of the PC.
The IEEE-488 bus, which also is called the General-Purpose Instrument Bus (GPIB), is more complex but far more versatile. It allows a single PC to control multiple test instruments. For the type of test system discussed in this article, the GPIB is clearly the preferred bus.
Although the GPIB increases the price of the test system, its ability to connect more than one instrument at a time to the PC justifies the extra cost. For example, in the pressure-sensor test system of Figure 3, one PC controls an oven, a pressure source, a voltmeter, and a tester providing signal conditioning for the DUT. Here, the pressure-sensor tester calibrates and tests pressure sensors mated with signal-conditioning ICs that compensate for pressure-sensor errors.
The IEEE-488 specification allows multiple instruments to share the same bus because the bus uses a different output-driver structure than the PC serial and parallel ports. Each IEEE-488 driver includes a strong pull-down resistor and a weak pull-up resistor, allowing one or more devices connected to the bus to pull each signal wire low, or permitting the line to remain high when no devices assert a low.
Another significant advantage of the IEEE-488 interface is that it includes a hardware handshake to help prevent data loss. Yet another advantage is its popularity among the major vendors of benchtop test equipment (e.g., Agilent, Fluke, Keithley, Tektronix). Because power supplies, relay switch banks, environmental chambers, oscilloscopes, digital voltmeters, function generators, and other equipment are readily available with IEEE-488 buses, a single PC can automate virtually any benchtop test setup.
Software that controls this bus is available off-the-shelf or can be developed in-house. National Instruments' LabView and Agilent's (formerly Hewlett-Packard) Agilent-VEE are two of the most popular software packages for controlling instruments via the GPIB. As an alternative, control software can be developed using traditional C-language programming, given a certain level of expertise. Both the LabView and Agilent-VEE software, though, let a novice programmer quickly and easily design sophisticated programs. These standard packages come with software modules for driving many common instruments.
A few problems accompany the employment of the IEEE-488 bus. Because this bus isn't standard equipment on most PCs, an interface adapter card must be added, for a price of $500 or more. Interface cards are available from companies such as Agilent, IOtech, Measurement Computing, National Instruments, and Tektronix. In addition to an interface card, the GPIB also requires special cables costing about $20 each.
The IEEE-488 instruments themselves are expensive as well. If the test system requires custom instruments, significant software and hardware development time will be necessary for both a microprocessor and an IEEE-488 interface controller. Some software development can be streamlined by implementing a bus-controller IC, like National Instruments' NAT9914. Using a bus controller also frees the microprocessor from the time-consuming activity of monitoring the GPIB.
Critical system concerns such as keeping noise levels low and making measurements precise must be ad-dressed from the very beginning. Those types of performance problems become increasingly difficult to cure as the project gets older.
Following several fundamental guidelines helps to guarantee success. First of all, digital and analog grounds should be kept separate. Also, when necessary, use high-speed optocouplers to isolate microprocessor switching noise from the analog signals. Furthermore, good hardware techniques—including spending time on component placement, identifying high-impedance nodes, and accounting for voltage drops in power and ground traces—increase the chances of a successful design.
An important precaution: make sure that you identify high-impedance nodes, like those found at op-amp inputs. Because these nodes are sensitive to noise, keep them away from noisy signal lines. Noisy lines are those that carry fast rise-time and fall-time signals. Frequently, they're fed from digital or video sources. Such high-speed signals may need to be routed through a transmission line, depending on what distance they travel. Use special controlled-impedance layout techniques to incorporate these transmission lines in the printed-circuit board. These lines require precisely calculated dimensions and are typically routed without vias.
When testing numerous devices simultaneously, be certain that one failed device doesn't prevent the testing of the remaining devices. This problem can occur when a DUT's power-supply lead becomes shorted to ground. The short can sufficiently load the power supply to prevent accurate testing of the remaining devices. Ballast resistors connected in series with the power-supply lead of each DUT prevent this problem from occurring.
When gang-testing a large number of devices, it's best to use hardware that operates independently of software to identify and quickly disconnect any short-circuited DUTs to prevent further damage. The added delay that software might add could increase the damage done by excessive current. Also, if this excessive current loads the supply that powers the microprocessor, the actions ordered by the software might not occur. An example of the kind of hardware used to detect overcurrent faults is shown in Figure 4. When the control software requests the circuit's power-up flip-flop to set, the flip-flop switches on power MOSFET Q2. The MAX472 current-sensing device detects the supply current drawn through the 0.5-Ω resistor (R4) and into the DUT.
If the current through R4 exceeds 160 mA, the voltage across R11 activates one of U2's two comparators. If this overcurrent condition persists for more than approximately 30 ms, C1 charges sufficiently to trip U2's second comparator, which sets the overcurrent flip-flop and, in turn, immediately disables Q2. The control software detects the overcurrent alarm and identifies the failed device, while testing of the other devices continues. The control software must remove and then reassert the power-up signal before Q2 can power on again.
Prior to laying out the board, it's helpful to prototype the various sections of circuitry and test them manually. Doing this ensures that these circuits function properly prior to placing them together with additional circuits on a single board and under the control of the IEEE-488 bus.
When considering board layout, it's important to examine the flow of the board's ground current. Board designers sometimes err by assuming that all ground-return paths stay at 0 V. Instead, current flow through the resistance of the ground traces creates unwanted voltage drops. Particularly troublesome are the transient switching currents from digital circuits that flow through the ground-return system. The errors introduced not only by the unspecified trace resistance of the ground path but also by the trace resistance of the power path are illustrated in Figure 5. When ground-return current flows, it elevates VSS in accordance with Ohm's law (VSS equals the ground-return current multiplied by the trace resistance). Additionally, the power-supply trace suffers a voltage drop due to the DUT's load current. The op amp detects these voltage losses and adjusts the power supply to compensate for them. Note that the sense leads must connect directly at the VDD and VSS pins of the DUT. A connection of leads in this manner is commonly termed a "Kelvin connection."
Budget twice as much time for component placement as you think you will need. Perform a preliminary routing, perhaps with an auto-router, and look for congested areas. Adjust component placement to reduce the congestion. As mentioned previously, highlight all high-impedance signal lines, minimize their length, and keep them away from noisy signals. Prioritize the design constraints before starting the layout. Even the best layout designers can't feed a 100-mil trace into a 0.65-mm fine-pitch lead.
No matter what bus is used to control instruments within a test setup, the commands that initiate this control must be defined. Commands that control the parallel port send data in a "bit-banged" format. Both the RS-232 serial bus and the IEEE-488 bus transmit serial strings of character data.
The IEEE-488 standard governs the bus itself, not the kinds of messages sent over it. Despite this, there's some agreement as to what types of messages are sent. For example, modern DVMs use nearly identical command sets, which saves customers development time. But for older or nonstandard instruments, little or no agreement exists. The Standard Commands for Programmable Instruments (SCPI) is an attempt to increase the agreement within command sets. If the SCPI doesn't include suitable commands for your instrument, then you will have to invent part or all of a command language unique to that instrument. SCPI is preferred, of course, because it enables those who use the instrument to more quickly understand its operation.
It's best to develop software in small steps and in a logical progression. Make sure to partition the software so that future changes can be readily implemented. Good software development begins with the command processor, which is a collection of software routines that interpret text commands and control the hardware accordingly. One possible approach is to have the command processor initially accept commands only via the RS-232 serial port, permitting the development of low-level subroutines and the command processor itself to be used to test them. Gradually, device drivers can be added for each of the subsystems (e.g., the IEEE-488 controller, the analog-to-digital converter, and the digital I/O), always with the working code to fall back on if problems arise.
This modular approach to software design facilitates initial development as well as future software changes, especially if the person creating the changes isn't the original developer. When software is developed by organizing it into independent device drivers, new devices to test can be supported quite quickly. Changes to one part of the software don't change other unrelated parts because the modular structure partitions the code aggressively, in anticipation of future changes.
Aside from proving useful at the beginning to develop the software, the RS-232 port is a handy diagnostic tool for the final phase of the project in which the software is debugged. Even if the final design of the tester doesn't provide customer access to the RS-232 port, it can still function as an effective and inexpensive portal for status messages that are useful to a field technician.
When writing software, reserve one memory location as a diagnostic enable and another as a diagnostic status indicator. Keep these locations in the final version of the software. If a customer encounters a problem, these diagnostic tools may provide valuable information.
A watchdog timer is a useful device that resets the microprocessor if it gets stuck in an infinite loop. Software must service the watchdog timer at regular intervals to prevent its timer from expiring. When the watchdog timer does expire, indicating the microprocessor is stuck in an infinite loop, it resets the instrument's microprocessor, restoring it to a known operating state. The watchdog-timer reset can initiate the printing of the diagnostic status indicator contents, revealing which part of the software may be responsible for the crash. Only the input, output, and delay subroutines need to service the watchdog, preventing its timer from expiring. As a general rule, the software spends most of its time in its input or output subroutines. Therefore, these subroutines are the best place to service the watchdog timer.
Although it might be obvious, it's well worth noting that you have to frequently make backup copies of the source code. To save time, every time you program a new ROM image, copy only the changed files. Also, make sure that you have a way to patch ROM code. Even with a limited amount of memory available for patches, the time saved for each instance that you compose, compile, and test code is significant, particularly during marathon development sessions.
- Axelson, Jan, "Parallel Port Complete," Lakeview Research, 1999, p. 343.