How GPIB really works

In a post long ago I wrote about having built a serial ULI GPIB interface adapter, and about some of the troubles I had with the original firmware of that adapter. I meant to fix those issues in the firmware, but I've come to realize that ULI is never going to properly work over serial, and I'll need to come up with a custom solution and to re-write the firmware.

To do that, I've researched how GPIB actually works. A bit surprisingly, the resources available on the topic are pretty bad. I thought that there'd be several detail resouces on the subject. I even acquired a copy of the original IEEE-488-1978 standard, and while it helped, it is written in (IMHO) a very difficult to understand way. In the end I've tried to piece together the information from several sources and from testing with how my GPIB enabled instruments behave. This post is mainly me documenting my findings to myself for later reference.

Basic behavior

There is at most one talker on the bus at a time, while there can be several listeners. The controller determines which device is the talker and which are listeners at any given time. Almost always the controller is either the talker or a listener on the bus.

Data output by the talker on the bus is read in by all of the listeners. This would allow e.g. a measurement device to produce output as a talker and a data recording device to collect it as a listener. In my use cases, the data would be always between a single instrument and the controller. I would consider it to be very rare these days, that data would get passed directly from one instrument to another.

The controller can act as a talker and as a listener, but in addition it can send commands.

The signals

All signals, including data lines, operate with inverted logic. That is, a high level voltage is a 0 and a low level voltage is a 1. In particular, control lines are asserted when a low voltage level is present and deasserted when a high voltage level is present. The logic level voltages themselves are TTL.

When used as outputs, the signals are driven with one of two driver types. Some signals are open-collector with weak pull-ups, while others are push-pull driven. The data lines use both driver types in different conditions, while for the other lines the driving scheme is fixed. All lines are high-impedance on a device, when they are used as inputs.

Open-collector drive is used to produce a wired OR on the bus for certain lines. In this case the low level (value 1 or asserted state) is the dominant state.

ATN

Attention. Asserted by the controller to signal the sending of a command on the data lines. This line is push-pull driven by the controller and is high-impedance on the other devices.

IFC

Interface clear. Asserted by the controller to asynchronously reset the bus logic in devices. This line is push-pull driven by the controller and is high-impedance on the other devices.

REN

Remote enable. Asserted by the controller to cause addressed devices enter remote operation mode (local user interface disabled, except for go to local key). This line is push-pull driven by the controller and is high-impedance on the other devices.

SRQ

Service request. Asserted by any device requesting an interrupt from the controller. Reason is device dependent. This line is open-collector driven by every other device on the bus except for the controller. It is high-impedance on the controller.

EOI

End or Identify. This signal has two meanings.

End: Can be asserted by a talker to indicate the last byte of a data transfer.  It is push-pull driven by the talker and is high-impedance on the other devices. It appears to be talker implementation specific if it is asserted at all, as well has how it is interpreted by listeners when it is asserted. As an example, my Racal-Dana 1992 does not assert EOI when talking, but does accept EOI as an end-of-line indicator if it is asserted. However, it also accepts CRLF as an end-of-line even without EOI asserted.

Identify: Asserted by the controller to request parallel polled devices to identify if they have a service request. It is push-pull driven by the controller and is high-impedance on the other devices. Parallel poll in general seems to be very rarely used, and is up to the controller to use it anyway. So when programming a controller, the whole functionality can be omitted.

NRFD

Not ready for data. Asserted by any listener on the bus, which is not ready to receive data. This line is open collector driven by all listeners on the bus, while it is high impedance for others. Since the asserted state is dominant, the bus will show NRFD as asserted if any one listener is not ready.

DAV

Data valid. Asserted by the talker to indicate that the data lines contain valid data, which should be accepted by the listeners. The talker waits for the NRFD signal to become deasserted before asserting DAV. This line is push-pull driven be the talker while it is high impedance on other devices.

NDAC

Not data accepted. Asserted by any listener on the bus, which has not yet accepted the valid data on the bus. This line is open collector driven by all listeners on the bus, while it is high impedance for others. Since the asserted state is dominant, the bus will show NDAC as asserted if any one listener has not accepted the data. After all listeners have accepted the data, the talker knows to de-assert the DAV line and prepare the next data.

D1 through D8

Data lines. These contain the data that is being sent. It is important to note that data lines also operate with inverted logic. The lines are push-pull driven by the talker, or open collector driven by polled devices when a parallel poll identify is requested by the controller. For other devices, the lines are high impedance.

Handshaking

At the core of transmitting data and commands is the three-way handshake process. This allows the data to be transmitted asynchronously, and following the limitations of the slowest device involved with the transfer.

Handshake timing

The listeners first deassert their pull of the NRFD line when they become able to receive data. When the last of the listeners releases the line, the line goes high (deasserted). This signals the talker that they can now transmit data. Before beginning the transfer, the talker should check that NRFD and NDAC are not both high, as that would be an indication that there is no-one listening (though at least my Racal-Dana 1992 does not do such checking).

The talker then sets the data on the data lines (remembering that the logic is inverted) and asserts the DAV line to indicate valid data (note: data can be set on the data lines already before NRFD goes high, as long as data is stable when DAV is asserted). There should be a delay of at least 1.5us between setting the data on the data lines and assertion of DAV to ensure the settling of the data lines (required by the standard).

Asserting the DAV line will signal the listeners to receive the data. When a listener has accepted the data, it will again assert the NRFD line (i.e. pull it low) to indicate that they are not ready for new data and will release their pull on the NDAC line. The NRFD line on the bus will thus become again asserted as soon as the first listener has accepted the data, but the NDAC line will become deasserted only after the last listener has accepted the data.

When the NDAC line becomes deasserted, it signals the talker that all listeners have accepted the data, and the talker will deassert the DAV line. After this, when the listeners are again ready to receive more data, they will again release their pull on NRFD line and the cycle begins again.

Exactly the same handshake cycle is used for transmitting commands when the ATN line is asserted. In that case however, the talker is the controller and the listeners are all devices on the bus.

Commands

As said, the commands are sent by the controller on the data lines together with the ATN asserted. Asserting the ATN line will instantly (<200ns) cause the other devices to release the bus for the controller to talk.

The command will be transmitted on the data lines of the bus following the handshaking protocol. The controller acts as the talker, while the other devices will act as listeners. Each command that the controller sends is a single byte.

A large portion of the commands are reserved commanding specific devices to become listeners or talkers. The addressing is also used together with the addressed group of commands, which only affect devices which have been addressed. Each addressable device on the bus has a GPIB address. The GPIB address of a device is a 5 bit value between 0 and 30 (with value 31 reserved for a special purpose).

Some sources say that address 0 is often reserved for the controller itself, but this makes no sense to me. The controller is the only one addressing the other devices, so it has no need for an address. I guess it makes sense in the weird situation, where there are several possible controllers that need to address each other.

Listen - 0x20+GPIB address - MLA

A device will become a listener if it receives the listen command with its address.

In the GPIB nomenclature the value "0x20+GPIB address" is called the listen address of the device, which is a bit misleading since this is actually the full command for the device to begin listening. Upon reception of its listen address, a device will stop being a talker (if it was one) and begin acting as a listener.

To set a device as a listener, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol
3. Deassert ATN (and set proper bus directions)

The configured device will handshake data sent on the bus and interpret them in a device dependent way.

Unlisten - 0x3f - UNL

All devices currently listening will stop listening when they receive the unlisten command. The unlisten command is basically the listen command issued for address 31, which is why no device can have GPIB address 31.

Talk - 0x40+GPIB address - MTA

A device will become a talker if it receives the talk command with its address.

In the GPIB nomenclature the value "0x40+GPIB address" is called the talk address of the device. Upon reception of its talk address, a device will stop being a listener (if it was one) and begin acting as a talker. Upon reception of a talk address of any other device it will cease acting as a talker (if it was one).

To set a device as a talker, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value "0x40+GPIB address" (MTA) on the data lines using the handshake protocol
3. Deassert ATN (and set proper bus directions)

Untalk - 0x5f - UNT

The current talker will stop talking when it receives the untalk command. The untalk command is essentially just the talk command issued for address 31.

Interface clear

Asynchronously reset the GPIB interfaces of the devices on the bus. To perform the clear, the controller asserts the IFC control line for more than 150 microseconds. Devices forget their listen/talk status etc. Measurement etc. states of the instruments may be retained.

Remote control

Enabling remote control of devices uses its own REN control line. As long as the REN line is asserted, the devices which have been put into remote control stay in remote control. When the REN line is deasserted, then all devices go back to local control asynchronously.

To set a specific device to remote control, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Assert REN
3. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol
4. Deassert ATN (and set proper bus directions)

Any device addressed to listen while the REN message is asserted goes into remote control. The addressed devices will remain listeners. The controller can send the UNL command if the devices shouldn't be a listeners at this time. The device will remain in remote mode for as long as REN is asserted or a go to local command is issued (either via manual entry from keypad or through command).

Local lock out - 0x11 - LLO

Will cause the go to local (or equivalent) button to be disabled on the from front panels of all instruments. This command does not inherently take devices to remote control, and doesn't an effect if the device is not taken to remot control.

To cause a specific device to enter remote control with local lockout, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Assert REN
3. Send the value 0x11 (LLO) on the data lines using the handshake protocol
4. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol
5. Deassert ATN (and set proper bus directions)

After the LLO command has been issued with REN asserted, any following listen command will place a device into remote control with go to local disabled. The controller can send the UNL command if the device doesn't need to be a listener at this time. The device will remain in remote control as long as REN is asserted or a go to local command is issued. As long as REN is asserted, any device transitioning to remote control will have their go to local disabled. To re-enable the go to local buttons, REN needs to be deasserted.

Go to local - 0x01 - GTL

Will cause the addressed devices to go back to local control even when REN is asserted.

To send the GTL command to a specific device, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value 0x3f (UNL) on the data lines using the handshake protocol
3. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol
4. Send the value 0x14 on the data lines using the handshake protocol
5. Deassert ATN (and set proper bus directions)

Device clear - 0x14 - DCL

Will cause a power-on-reset type resetting of device functions for all devices on the bus. Racal-Dana 1992 will only perform this reset if it is under remote control, but I'm unclear if this is common (IEEE-488-1978 specifies this without remote). In any case, the devices at least don't need to be addressed to follow the command.

To clear devices on the bus, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value 0x14 (DCL) on the data lines using the handshake protocol
3. Deassert ATN (and set proper bus directions)

Selected device clear - 0x04 - SDC

Will cause a power-on-reset type resetting of device functions for the devices addressed to listen on the bus.

To clear a specific device on the bus, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value 0x3f (UNL) on the data lines using the handshake protocol
3. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol 
4. Send the value 0x04 (SDC) on the data lines using the handshake protocol
5. Deassert ATN (and set proper bus directions)

Group execute trigger - 0x08 - GET

Causes a trigger event to be issued to the devices addressed to listen on the bus. What the trigger means is device dependent. On the Racal-Dana 1992 it triggers a single shot measurement.

To issue a trigger to a specific device on the bus, the controller does the following

1. Assert ATN (and set proper bus directions)
2. Send the value 0x3f (UNL) on the data lines using the handshake protocol
3. Send the value "0x20+GPIB address" (MLA) on the data lines using the handshake protocol 
4. Send the value 0x08 (GET) on the data lines using the handshake protocol
5. Deassert ATN (and set proper bus directions)

Serial poll enable - 0x18 - SPE

Causes all devices on bus to send status messages instead of data, when commanded to talk.

This is used by the controller to determine which device asserted the SRQ line. The other mechanism for determining this is the parallel poll, but it seems rather obscure and rarely worth the effort.

To find the devices, which asserted the SRQ, the controller does the following

1. Assert ATN (and set proper bus direction)
2. Send the value 0x3f (UNL) on the data lines using the handshake protocol
3. Send the value 0x5f (UNT) on the data lines using the handshake protocol
4. Send the value 0x18 (SPE) on the data lines using the handshake protocol

To poll whether device with GPIB address X asserted SRQ:

1. Assert ATN (and set proper bus direction)
2. Send the value "0x40+X" (MTA) on the data lines using the handshake protocol
3. Deassert ATN (and set proper bus direction)
4. As a listener, receive the single byte status message from the talker using the handshake protocol

The status message byte holds the the SRQ status as bit 6. The controller polls each device, until if finds the one that asserted the SRQ. The status byte may also contain other device dependent information.

Serial poll disable - 0x19 - SPD

Causes all devices on bus to again send data instead of status messages, when commanded to talk.

Other commands

Parallel poll configure - 0x05 - PPC (Parallel poll stuff...)

Parallel poll enable - 0x6X - PPE (Parallel poll stuff...)

Parallel poll disable - 0x7X - PPD (Parallel poll stuff...)

Parallel poll unconfigure - 0x15 - PPU (Parallel poll stuff...)

Take control - 0x09 - TCT (Cause another controller to become the controller)

Interface ICs

The common interface ICs used for GPIB communications are the Texas Instruments SN75160B, SN75161B and SN75162B.

The SN75160B is an octal tranceiver, which is commonly used for the data bus signals. It allows setting the data lines into receive or transmit via the talk enable (TE) signal (TE=high, transmitting toward GPIB). When in transmit mode, the bus-side output can be set as either push-pull or open-collector via the pullup enable (PE) signal (PE=high, outputs are push-pull). The datasheet of the IC is annoyingly unclear on these aspects. It is important to note that a high value on one side of the tranceiver is transmitted as high value on the other side. That is, there are no inverters in the interface to account for the inverted logic on GPIB.

The open-collector drive capability of the data lines seems to be used only for the parallel poll feature. For the sole controller on the bus, the data lines are always either push-pull driven toward the bus or used as inputs. That is, PE can be kept constantly high.

The SN75161B and SN75162B are tranceivers for the GPIB control lines. One difference between the two is than the SN75162B includes a separate direction control for ATN/SRQ and REN/IFC, while on the SN75161B there is a single control for all four. They also seem to have different drive circuitry for some of the lines. My interface is built using an SN75162B, so I'll only cover it here.

The direction of the controller lines ATN, SRQ, REN and IFC are controlled via the DC and SC lines.

• When SC is high, REN and IFC are push-pull outputs toward the bus.
• When SC is low, REN and IFC are inputs from the bus.
• When DC is low, ATN is a push-pull output toward the bus and SRQ is an input from the bus.
• When DC is high, ATN is an input from the bus and SRQ is a open-collector output toward the bus.

For the sole controller on the bus, the SC line can be kept constantly high and the DC line can be kept constantly low.

The direction of the handshake lines NRFD, DAV and NDAC are controlled via the TE line.

• When TE is high, DAV is a push-pull output toward the bus, while NRFD and NDAC are inputs from the bus.
• When TE is low, DAV is an input from the bus, while NRFD and NDAC are open-collector outputs toward the bus.

Similar to the SN75160B, there are no inverters inside the SN75162B to account for the inverted logic of the GPIB.