Taking advantage of present and future capabilities of the General Purpose Interface Bus (GPIB) - Embedded.com

Taking advantage of present and future capabilities of the General Purpose Interface Bus (GPIB)

The IEEE 488 standard, better known as the General Purpose InterfaceBus (GPIB), is a popular interface that connects instrumentsto computers to form ATE. GPIB was developed initially byHewlett-Packard and was recognized as an IEEE standard in 1978.

Since then, the IEEE has released IEEE 488.1 (1978) to define theGPIB hardware specifications, including its electrical, mechanical andbasic protocol parameters, and IEEE 488.2 (1987) to define relatedsoftware specifications.

Revolutionary changes being applied to the PCI I/O bus, such ashigher throughput and smaller mechanical footprint, have increased thepopularity of legacy ISA bus and more mature PCI bus standards. Thesestandards have significantly surpassed the RS-232 in speed. On top ofthese are the USB and LAN interfaces, which are proven to be faster,better performing, and more versatile.

Due to cost-effectiveness and easy connectivity, current PCs areequipped with both USB and LAN interfaces. Meanwhile, after more thanthree decades of enhancements and wide ranging development, countlesstraditional GPIB devices now support hot-plug functionality and remoteaccess to keep in pace with IP-based instruments that test engineersare more familiar with.

Table1. A comparison between the various standards based on keyspecifications.

Because of these parallel GPIB innovations, it will be difficult fornewer and faster I/O interfaces – USB or LAN – to completely replacethe standard in the ATE industry.

Bridge to USB or LAN
Realizing the GPIB's strong position in this market, major instrumentmakers have implemented a bridge communication protocol from GPIB toUSB or LAN. This move takes advantage of the flexibility and high datathroughput of USB and LAN while maintaining GPIB-based instrumentinvestments in full operation.

The bridge communication protocol comes in the form of aGPIB-USB/LAN adapter, GPIB-LAN gateway and converters. This and similartechnological trends indicate that GPIB is here to stay.

For hardware, GPIB's interconnectivity with USB and LAN deliversfaster integration and more convenient maintenance, as it is no longernecessary to physically install an ISA/GPIB card into an availableexpansion slot. The collaboration thus lowers the cost and complexityof test systems.

For software, combining GPIB with USB/LAN is similarly advantageousas most mainstream operating systems are capable of monitoring the LANor USB port status so that any newly-connected instruments areautomatically detected and recognized.

Highly integrated environments automatically recognize connectedinstruments and dispatch dedicated software resources for it, thuseliminating the need to manually search, identify and initializeconnected devices.

Adopting GPIB
Before implementing ATE, the following questions need to be addressed:

1) What is your preferredphysical interface connectivity solution within your instrument: GPIB,USB or LAN?

2) What are the softwarerequirements, specifications, capability and performance of yourinstrument?

3) Based on the selectedsoftware application, what software development environment will youuse to control and communicate with the instrument?

Figure1. After deciding on the software I/O layer, the next considerationwould be the most appropriate ADE.

If you decide to adopt GPIB as the interface to control instruments,the next step is to determine the I/O software kits for instrumentcommunication.

These I/O software kits are regarded as a software layer positionedbetween the integrated application designs and the physical interfaceto instruments. There are two ways to create an automated testapplication: perform native driver API or via high-level instrumentdrivers.

Native vs VISA vs IVI-COM
The first method involves native driver API conventions, which areusually provided by most adapter vendors and come in the form of ANSI Cfunctions. For users requiring a more detailed instrument control andmaximum system throughput, using a driver API with SCPI string commandsis highly-recommended.

For users who want to avoid complicated instrument commands,high-level instrument drivers such as VISA or IVI-COMare a suitable solution. High-level instrument libraries providetransparent software compatibility with all types of connectioninterfaces and come with functions that are mostly independent from thedevice interface used.

Whether you intend to access measurement instruments through RS-232,GPIB, USB or LAN, high-level instrument drivers do not give you theadditional burden of modifying software codes when you change thecommunication bus type. Lastly, high-level instrument drivers give youmore time to focus on software development and make user programs morescalable for later reintegration.

After deciding on the software I/O layer, the next considerationwould be the most appropriate Application Development Environment(ADE). The ADE and software tool kit combination is crucial, and maydirectly impact the total cost of development and the applicationcompletion time.

Thus, serious considerations must be made in software price and timeto learn or training. You may also consider using available softwaredevelopment kits that accelerate test system development. Softwaredevelopments may be divided into two groups: graphical and textual.

Many graphical programming environments currently cater to test andmeasurement engineering. An easy-to-learn graphical programmingenvironment allows rapid creation of prototype test systems and enablesthe user to efficiently handle the data flow between several concurrentactivities.

The straightforward programming offered by graphical environments iseasier compared with creating a program using textual programming. Inaddition, you do not need to learn complex syntax as it allows you tolearn and share predefined codes easily.

Textual ADE programming is suitable for large-scale applications andfor improving system throughput. However, this type requires anexperienced programmer. The good news is that the runtime performancedifference between graphical and textual programming has beenshrinking.

FPGA alternative
Fast and reliable connectivity is the most important concern forinstrument vendors and users. With the ever-increasing performance ofcommercial desktop and notebook computers comes an evolution ofcommunication fundamentals between PCs and instruments.

Despite the facts that GPIB is the de facto standard for connectinginstruments and the PCI bus is the standard I/O interface forindustrial control and measurement, new generation USB and Ethernet arecrossing the line and venturing into instrument control. It istherefore relevant to compare these standards.

Selecting which I/O interface to use is the first task in buildingyour ATE. You may use a legacy instrument with a pure GPIBimplementation or adopt a modern instrument with LAN or USB. Acombination of GPIB and USB/LAN offers a comprehensive solution to meetall kinds of requirements.

The GPIB bus controller – a key GPIB component – is an ASIC. Sincevery few suppliers produce this component, the cost of ASIC-based GPIBis expensive. Even though there are assurances from component vendorsthat ASIC-based GPIB has better performance, adopting ASIC based GPIBhas not become a cost-effective solution vs. FPGA implementation,especially for prototype verification or smallscale production.

With advancements in EDA tools, the FPGA offers an alternativesolution to expensive ASIC implementations. In the meantime, as moreand more FPGA standards emerge and as verified IP cores become readilyavailable from the Internet, building the GPIB protocol into FPGAs isalready on the horizon and opens a promising opportunity for test andmeasurement applications.

Andre Hsieh is Senior Application Engineer at ADLINK Technology Inc.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.