UNDERSTANDING THE GPIB
The general-purpose instrumentation bus has a wide range of applications
Don Morgan
Don is a consulting engineer in the area of embedded systems and automation and can be contacted care of Don Morgan Electronics, 2669 N. Wanda, Simi Valley, CA 93065.
The general-purpose instrumentation bus (GPIB), or IEEE 488 Bus, is a high-speed communications bus widely used in engineering and scientific applications. It was originated in the mid-'60s as the HP-IB by Hewlett-Packard to ease the integration of computers and instrumentation. Today, the GPIB is used in scientific workstations and computer-based systems where the instrumentation involved--oscilloscopes, meters, and equipment such as lasers and plotters--needs to exchange information.
The reason for the GPIB's popularity is manifest in the objectives of its creators: 1. To define a general-purpose system for use in small or limited distance applications; 2. to develop common mechanical, electrical, and functional interface requirements that would be simple, easy to use, and inexpensive to implement; 3. to permit instrumentation from a wide range of capabilities to be connected simultaneously; 4. to allow direct connection between devices so that no intermediary (central point through which all messages had to be routed) was needed; 5. to require a minimum of restrictions on the performance characteristics of any device connected; and 6. to create a system that permitted asynchronous communications over a wide range of data rates.
It was the mid-70's before the official IEEE 488 standard was set. This standard described the functional description and electrical characteristics of the bus, along with the connector and related mechanical data. These standards were echoed in ANSI MC1.1, and, except for the connector proposed, in the international IEC 625-1 and British B.S. 6146.
Then, in 1987, after more than 15 years of use, IEEE 488 was revised and expanded. At that time, the original standard was renamed IEEE 488.1 and the revision was given the name IEEE 488.2. The new standard does not change the basic functionality described in the original but goes further, describing basic sets of abilities necessary in a conforming device. It prescribes new codes and data formats, protocols, and commands.
The extensions presented by the IEEE 488.2 are wide ranging, but meaningless without a good understanding of the IEEE 488.1. In fact, unless a device complies with IEEE 488.1, it can not comply with the new standard. The focus of this article is to provide an understanding of the basic functionality described by 488.1 through description and example, from the viewpoints of both the host PC and the microprocessor/embedded system. I'll deal mainly with IEEE 488.1, alluding to 488.2 when its extensions or amendments bear on what we are doing.
Overview
The IEEE 488.1 describes an 8-bit parallel, byte serial interface that, under proper circumstances, can communicate at speeds up to 1 MHz. It employs a patented three-wire handshake and does not require that all devices involved handle data at the same speed, but it guarantees that the flow of data is accepted by all devices before continuing. In addition, it specifies five command lines that are used singly and together to issue certain commands, request service for individual devices, and distinguish data from commands. Certain hardware and electrical characteristics, such as the connector, the length of the bus and the number of contiguous devices are also prescribed.
In its simplest form, a GPIB bus may consist of only two devices: one that transmits data and one that receives it. These two devices are known, respectively, as a talker and a listener. An example of this sort of bus might be an oscilloscope connected to a printer/plotter; the oscilloscope is a permanent talker and the printer/plotter is a permanent listener. In such a case, data might be printed upon a trigger or the press of a button.
Most of the time, there are more than two devices connected to the bus, and more often than not, these devices will need to receive information as well as transmit it. To accomplish this, we add one more element, a controller.
Now, the bus may be composed of as many as 15 devices, including the controller, all with the ability to become talkers or listeners as the need arises. There can, however, be only one controller at a time on the bus, and no device may send or receive device-dependent data unless addressed to do so. This arrangement provides for each of the 15 devices on the bus, a My Listen Address, and a My Talk Address. To obtain a listen address from the primary address, this address is ORed with 20h; to obtain a talk address, it is ORed with 40h. In most implementations of the interface, this address manipulation is done by the hardware, and the primary address of any one node is set locally with a switch, or remotely with bus commands.
On a small scale, this bus may be composed of a computer, acting as controller, the oscilloscope as a talker and listener, and the printer/plotter as a listener. Here, the oscilloscope will need to receive data from the computer setting parameters for data collection. When it gets the data it is meant to capture, it must become a talker and transfer that information to the printer/plotter.
There are really three kinds of communication involved in any bus transaction. One, which might be considered interface maintenance, comprises that state of the control lines and commands, which tell the interface how to behave and what to do. These commands are not device dependent; they are specified in detail beginning with IEEE 488.1 and in a good deal more detail in IEEE 488.2. Examples of these commands might be DCL (Device Clear), IFC (Interface Clear), or LLO (Local Lockout).
The next type of communication that occurs is device dependent and consists of the actual commands transferred over the bus to the instruments connected. These data relate to information to or from the device, as well as the commands designed by the manufacturer of the device to set parameters. These data are in the language of the device and are not part of the interface. Before IEEE 488.2, there were no guidelines for the type of data transmitted over the bus, but with the new specification, some protocol has been established. Data, for example, are to be transferred as 7-bit ASCII, because binary data sometimes mimicked interface commands and caused communication problems. There are set ways to end a message, so that there is no mistaking the intention of the device. There are many more additions, far too many to go into in the framework of this article.
The third sort of communication that exists on the bus is between the interface hardware and the instrument itself. This communication is in the form of logic signals that handle the hardware as well as the device-dependent data that must pass through it. There a number of chip manufacturers that provide hardware for this purpose, among them NEC, TI, and National Instruments, with its IEEE 488.2 compatible device. In my follow-up article, "Implementing GPIB in an Embedded System," I'll describe the interface from the viewpoint of an embedded system using the TMS9914A.
An Implementation
To illustrate some of the features of a system using the GPIB, I've chosen a simple laboratory experiment in which a computer, an oscilloscope, and a printer/plotter are used to capture data for study. The system would be designed to set the oscilloscope for a series of trigger levels, and, as each is met, transmit the information to the plotter for plotting.
We want the system to maintain itself: The program would run on the host, a PC, which in turn would configure the oscilloscope and printer/plotter. The oscilloscope would be set-up to wait for a trigger from the subject of the test, collect the data and inform the host that it has done so. The host would then arrange for the oscilloscope to transmit the data to the printer/plotter. As soon as the oscilloscope had done its job it could be told to wait for another trigger, and the printer could be told to print. This loop could then continue until other conditions were met.
For this example, our host is the PC, and as such it is the controller as well, with the GPIB cables connecting the oscilloscope and printer in either a daisy chain or star pattern. The manner isn't important because essentially they are all parallel, each having it's own unique address: The controller address is 0, the scope address 7, and the printer/plotter address 1.
To simplify the illustration, I'll use the pseudocode commands OUT and IN in place of language- or driver-specific commands to highlight the IEEE 488 command structure itself. Where possible, I will use the ASCII representations of the Multiline Interface Messages needed. For a sample of code using C and driver, see Scope.c (Listing One, page 92), in which I use a library and driver supplied by National Instruments to accomplish a task similar to the one I will now describe.
When the system starts up, the controller asserts an active low on the Interface Clear (IFC) command line; see Example 1(a). Upon receiving the IFC, all devices on the bus cease Talking (transmitting) or Listening (receiving) and return to an idle state. This command does not affect the state of the instruments involved, only the interface. The controller now asserts the Remote Enable (REN) command line. This will permit the host to program the other instruments on the bus, as shown in Example 1(b). A Device Clear is sent. This multiline interface message returns all receiving devices to a default state defined by the manufacturer, which may be a full reset; see Example 1(c).
Example 1: Implementing the IEEE 488 command structure
(a) OUT "IFC" /*Interface Clear*/
OUT "REN" /*Remote Enable*/
(b) OUT '?_@'\0X14"; /*? = Unlisten (UNL), _ = Utalk (UNT), @ = My Talk
Address of controller (MTA), ' = My Listen address
of scope (MLA), 0X14 = Device clear*/
(c) OUT '?_@'"; /*UNL, UNT, MTA of controller, ML; of scope*/
OUT ":ACQUIRE:TYPE NORMAL";
; /*Now the device dependent configuration data*/
;
OUT ":TRIGGER:SOURCE CHANNEL1";
OUT ":SRQ 1"; /*Enable SRQ on trigger, bit 1 of SRQ mask
register*/
OUT "?_"; /*UNL, UNT*/
(d) OUT "?_\X18G "; /*UNL, UNT, Serial Poll Enable (SPE), Talk
Address (TAD) of scope, MLA of controller*/
IN & BUFFER; /*Program puts Serial Poll Byte in a buffer*/
OUT "\0X19"; /*Issue Serial Poll Disable (SPD)*/
(e) OU' "?_@'"a /*UNL" UNT" MT; of controller" ML; of scope*/
OUT "PRINT"; /*Tell scope to print*/
OUT "?_@!G"; /*UNL, UNT, MTA of controller, ML; of
printer/plotter, MTA of scope*/
OU' "DATA"a /*Controller takes its own attention (ATN(c) line
low to allow scope to talk to printer/plotter*/
WAI' "END"a /*Controller watches command lines for end or
identify (EOI), which means that the transfer is
complete*/
The next step is to configure the instruments involved in the procedure. First, the controller makes the oscilloscope a listener by sending its My Listen Address. After the oscilloscope is made a Listener, the controller becomes a Talker and sends data over the bus in the language (command set) of the oscilloscope. For the purpose of this experiment, the commands sent set a sweep rate, gain, and trigger level, and enable the instrument to issue an SRQ when it is triggered.
The oscilloscope now goes into a ready state, waiting for a trigger from the subject of the test. Having configured the oscilloscope, the host again becomes a controller and tells the oscilloscope to unlisten with the Unlisten command (UNL). At this time, the host may go on to other duties, maintaining other instruments or messaging data; see Example 1(d).
When the oscilloscope is finally triggered and the data captured, it asserts a negative true on the bus's SRQ command line. The controller responds to this signal by polling all the devices on the bus to find out which one issued the command. This is done by issuing a Serial Poll Enable (SPE), which tells each device on the bus that when it is made a talker, it should put the Serial Poll Byte on the bus. The controller then issues the MTA for each device on the bus, reads its Serial Poll Byte in and determines which device or devices require service. When the serial poll is complete on all devices on the bus, the controller issues a Serial Poll Disable (SPD). The Serial Poll Byte sent by the oscilloscope indicates that it is requesting service and that it has been triggered; see Example 1(e).
The controller now configures the oscilloscope to transmit the data it has collected. It makes the plotter a listener and the oscilloscope a talker with its MLA and MTA commands, respectively, and goes off line lowering the ATN command line. The oscilloscope will now transmit its data to the plotter. The controller monitors the bus when it is off line, but the software may be written so that the controller reasserts ATN when transmission between the oscilloscope and printer/plotter is complete, and returns to being the controller.
When the scope has completed this transfer, the controller can issue an IFC to return both scope and printer to an idle state. The controller might then make the printer a listener with the appropriate MLA command and tell the device to print using the command structure of the particular device, followed by an UNL command.
It may take time for the plotter/printer to print the data. What happens next depends on the devices used and the programmer. If the printer has an appropriately sized buffer, the oscilloscope may be freed up almost immediately, whereupon it can be set to trigger again. If not, the next trigger will have to wait until the printer/plotter is finished.
There are a number of ways to implement this procedure. Besides using the SRQ, you might choose to poll the oscilloscope, waiting for a trigger before turning it into a talker and the printer/plotter into a listener. Depending on the device, it might be possible to set the parameters necessary for a trigger and immediately make the oscilloscope a talker and the printer/plotter a listener.
The Host PC
To complete the host side of the discussion, I'm providing a small program (see Listing One) to acquire data using an HP oscilloscope and to print it with an HP ThinkJet printer. The program is written in C using a library and driver provided with the PCIIA GPIB card from National Instruments.
This code is an approximation of the example that we have been working with. The PCIIA resides in an AT and performs the functions of controller, talker, and listener on the bus. The oscilloscope is an HP 54502A and the printer/plotter is an HP ThinkJet. The program is a short example, using real hardware, of actual code written using the lower-level functions provided with the National Instruments' card to emphasize the functionality and flexibility of the interface itself.
Conclusion
The purpose of this article was to present the GPIB as an understandable and useful interface. Once the protocol is understood, IEEE 488 is not difficult to use, and its speed, commonality of interface, and range of data rates offer many opportunities to the designers of instrumentation and systems. In my next article, I'll examine the interface from the viewpoint of the embedded system.
Bibliography
Caristi, Anthony J. IEEE-488 General Purpose Instrumentation Bus Manual. San Diego, Calif.: Academic Press, 1989.
Tutorial Description of the Hewlett-Packard Interface Bus. Hewlett-Packard, 1980.
HP 54502A 400MHz Digitizing Oscilloscope Programming Reference. First Edition. Hewlett-Packard, 1989.
IEEE Standard Digital Interface for Programmable Instrumentation. New York, N.Y.: The Institute of Electrical and Electronics Engineers, 1987.
IEEE Standard Codes, Formats, Protocols, and Common Commands For Use with ANSI/IEEE Std 488.1-1987. New York, N.Y.: The Institute of Electrical and Electronics Engineers, 1987.
IEEE Standard Digital Interface for Programmable Instrumentation. New York, N.Y.: The Institute of Electrical and Electronics Engineers, 1987.
NI-488 MS-DOS Software Reference Manual. Austin, Tex.: National Instruments Corporation, 1990.
The Three-Wire Handshake
The three wire handshake used by the designers of the bus was a means to provide reliable communication across a wide range of devices, from the very slow to the very fast. Because the bus transfer isn't considered complete until each device listening acknowledges that it has received the data, no device will miss any data. This also means that in any particular transfer, the slowest device addressed controls the speed of transfer.
It is important to remember that these command lines are in parallel and negative true, so that a line will remain true until all devices release it.
The following terminology is associated with this function:
- NFRD (not ready for data). The devices on the bus use this line to indicate readiness to accept a data transfer. If a device is not ready, for whatever reason, it will pull the line low, inhibiting the talker from transmitting. All devices must release the line before a transfer can occur.
- DAV (data valid). The talker asserts this line when the data lines have settled and are valid. This line will not go true until all devices have released the NFRD.
- NDAC (no data accepted). Listeners pull this line low to indicate that the data has not yet been accepted. When the slowest listener releases the line, it will finally go high.
T-1 At the end of a successful transfer, each listener releases the NFRD line as it becomes ready for the next byte. The source of communication (current talker) checks the NRFD\ and NDAC\ command lines to see that there are listeners on the bus. If both are high, there are no listeners. If all is okay, the current talker places a byte on the data lines.
T0 The source tells the listeners that the data is stable on the data lines by pulling the Data Valid (DAV) line low.
T1 The first to accept the data pulls the NFRD line low, inhibiting any further transmissions.
T2 The slowest device on the bus accepts the data and releases the No Data Accepted (NDAC) line, indicating that all listeners have received and accepted the data.
T3 The source allows the DAV line to go high, telling the listeners that the data is no longer valid. Another data byte may now be placed on the bus.
T4 The fastest device sets the NDAC line low, ready for the next byte.
T5 The slowest listener finally releases NFRD allowing the next transfer to occur.
_UNDERSTANDING THE GPIB_ by Don Morgan[LISTING ONE]
<a name="00eb_000d">
/* Scope.c */
#include <stdio.h>
#include "decl.h" /* a header file containing declares pertinent to the
National Instruments library*/
/* Application program variables passed to GPIB functions */
char rd[512]; /* read data buffer*/
int bd; /* board number, in this case that representing controller */
main()
{
/* Assign unique identifier to board 0 and store in variable bd. Check for
error.*/
if ((bd = ibfind ("GPIB0")) < 0) error();
printf("\ninitializing controller");
getch();
/* Send the Interface Clear (IFC). */
if (ibsic (bd) & ERR) error();
/* Turn on Remote Enable (REN) signal so instrument can be programmed. */
if (ibsre (bd,1) & ERR) error();
/* Put scope in remote mode by addressing it to listen, send Device Clear
(DCL) message to clear internal device functions, and address GPIB board to
talk. */
ibcmd (bd,"?_@' ",4);
if (ibsta & ERR) error();
/* Write the function, range, and trigger source instructions to scope. */
ibwrt (bd,":bnc probe",10);
if (ibsta & ERR) error();
ibwrt (bd,":acquire:type normal",20);
if (ibsta & ERR) error();
ibwrt (bd,":timebase:range 5e-4",20);
if (ibsta & ERR) error();
ibwrt (bd,":timebase:delay 0",17);
if (ibsta & ERR) error();
ibwrt (bd,":timebase:reference center",26);
if (ibsta & ERR) error();
ibwrt (bd,":timebase:mode triggered",24);
if (ibsta & ERR) error();
ibwrt (bd,":channel1:probe 10",18);
if (ibsta & ERR) error();
ibwrt (bd,":channel:range 1.2",18);
if (ibsta & ERR) error();
ibwrt (bd,":trigger:mode edge",18);
if (ibsta & ERR) error();
ibwrt (bd,":trigger:slope positive",23);
if (ibsta & ERR) error();
ibwrt (bd,":trigger:level 300mv",20);
if (ibsta & ERR) error();
ibwrt (bd,":trigger:source channel1",24 );
if (ibsta & ERR) error();
/* Scope is now ready to go. Set up SRQ by first clearing internal
data structures. */
ibwrt (bd,"*cls",4);
if (ibsta & ERR) error();
/* Clear the trigger by issuing the command to return the bit. */
ibwrt (bd,":ter?",5);
if (ibsta & ERR) error();
/* Then make the scope a talker. */
ibcmd (bd,"?_ G",4);
/* And become a listener. Read three bytes or stop when an EOI is received. */
ibrd(bd,rd,3);
if (ibsta & ERR) error();
/* When the data is in buffer issue an untalk and unlisten, then make the
controller a talker again and scope a listener. */
ibcmd (bd,"?_@'",4);
/* Enable the SRQ bit within scope that will case an RQS on next trigger. */
ibwrt (bd,"*sre 1",6);
if (ibsta & ERR) error();
/* Now wait for the trigger. */
if (ibwait (bd,SRQI) & (ERR)) error();
/* If we are here, scope must have been triggered and must have asserted SRQ
command line. Do a serial poll. First unaddress bus devices and and send
Serial Poll Enable (SPE) command, followed by scope's talk address, and GPIB
board's listen address. */
ibcmd (bd,"?_\x18G ",5); /*UNL UNT SPE TAD MLA*/
if (ibsta & ERR) error();
/* Now read status byte. If it is 0x41, the scope has valid data to send;
otherwise it has a fault condition to report. */
ibrd (bd,rd,1);
if (ibsta & ERR) error();
if ((rd[0] & 0xFF) != 0x41) error();
/* Note that if more than one device is attached to bus, each device must be
checked to see which issued the SRQ. */
/* Complete serial poll by sending the Serial Poll Disable (SPD) message. */
if (ibcmd (bd,"\x19",1) & ERR) error();
/*Send scope untalk and unlisten; make controller talker and scope listener*/
ibcmd (bd,"?_@'");
/*Tell the scope to print the screen and associated data*/
ibwrt(bd,":hardcopy:page automatic",24);
ibwrt(bd,":print?",7);
/*Make scope a talker and printer a listener; have controller get out of
the way for the transfer*/
ibcmd(bd,"?_@!G",5);
ibgts(bd,1);
/*Wait for the transfer to complete and reassert control over the bus*/
ibwait(END);
/*The program terminates with an interface clear*/
ibsic (bd);
}
/* Simple error routine that reads system variables and returns them. */
error()
{
printf("\nGPIB function call error:");
printf("\nibsta=0x%x, iberr=0x%x,",ibsta,iberr);
printf("\nibcnt=0x%x\n",ibcnt);
}
Example 1:
(a)
OUT "IFC"; /*Interface Clear*/
(b)
OUT "REN"; /*Remote Enable*/
(c)
OUT "?_@'\0X14"; /*? = Unlisten (UNL), _ = Utalk (UNT), @ = My Talk Address
of controller (MTA), ' = My Listen address of scope (MLA),
0X14 = Device clear*/
(d)
OUT "?_@'"; /*UNL, UNT, MTA of controller, MLA of scope*/
OUT ":ACQUIRE:TYPE NORMAL";
; /*Now the device dependent configuration data*/
;
OUT ":TRIGGER:SOURCE CHANNEL1";
OUT ":SRQ 1"; /*Enable SRQ on trigger, bit 1 of SRQ mask register*/
OUT "?_"; /*UNL, UNT*/
(e)
OUT "?_\X18G "; /*UNL, UNT, Serial Poll Enable (SPE), Talk Address (TAD)
of scope, MLA of controller*/
IN &BUFFER; /*Program puts Serial Poll Byte in a buffer*/
OUT "\0X19"; /*Issue Serial Poll Disable (SPD)*/
(f)
OUT "?_@'"; /*UNL, UNT, MTA of controller, MLA of scope*/
OUT "PRINT"; /*Tell scope to print*/
OUT "?_@!G"; /*UNL, UNT, MTA of controller, MLA of printer/plotter,
MTA of scope*/
OUT "DATA"; /*Controller takes its own attention (ATN) line low to allow
scope to talk to printer/plotter*/
WAIT "END"; /*Controller watches command lines for end or identify (EOI),
which means that the transfer is complete*/
Copyright © 1991, Dr. Dobb's Journal
