May
2005, Issue 178
Network
GPIB Controller
by
Ron Battles, Patrick Jackson, & Scott Shumate
SOFTWARE
DESIGN
The
GPIB bus consists of eight signals for data and eight
for handshaking. The maximum data transfer rate is specified
to be 1 MBps, but because each data byte on the bus
is acknowledged, the speed of the bus transactions actually
depends on the speed of the devices being addressed.
The eZ80 has more than enough speed to keep up with
the real-time demands of the GPIB bus.
Each
GPIB bus has one controller in charge (CIC). It’s the
function of the controller to send commands and specify
who may talk on the bus. Because our controller acts
in place of a PC and runs the client application, it
acts as the CIC for the bus.
The
handshaking signals pertinent to our design include:
Interface Clear (IFC), Attention (ATN), Service Request
(SRQ), Not Ready for Data (NRFD), Data Available (DAV),
Not Data Accepted (NDAC), and End or Identify (EOI).
The controller takes control of the bus by pulling the
IFC signal low for at least 100 µs upon initialization.
To keep the bus quiescent during periods of inactivity,
we keep ATN asserted, which forces all of the other
devices off the bus. A device can assert SRQ if it needs
service.
Addresses
in GPIB commands are 5 bits along. One bit is unused.
The other 2 bits specify whether the address is a talk
address or a listen address. The range is from one to
31 (see Table 1). But because primary
address (PAD) 31 is reserved, it leaves a total of 31
addresses for use on the bus (zero through 30). By convention,
PAD 0 is reserved for the controller, but this isn’t
mandatory.
There
are two types of data on the GPIB bus: commands and
data. Asserting ATN when you place the command data
on the bus identifies the former. The CIC is the only
device allowed to send commands and assert ATN. Commands
are individual bytes used to specify which devices should
listen and which should talk. Command bytes also exist
that “untalk” or “unlisten” all devices on the bus.
Any number of command bytes can be sent while ATN is
low. All devices on the bus must monitor these commands.
To
send data, the driver first needs to set “talk enable”
on the transceivers to ensure that you’re driving the
correct signals onto the bus. ATN is then driven low
to force all of the devices into a listen state. After
that, you can send commands to “unlisten” and “untalk”
the devices so that the bus is in a known state. The
controller then addresses itself as a talker by sending
its talk address followed by the listener address.
Handshaking
transmission data is the same for command and data bytes.
First, the driver makes sure that NRFD isn’t asserted,
indicating that all of the addressees are ready for
data. The driver then places the data on the bus and
asserts DAV. When all of the devices have accepted the
data, NDAC will go high and the driver can de-assert
DAV. This cycle is repeated for each byte sent.
There
are three different ways to terminate the transmission:
assert EOI on the last byte, send a line feed (0x0A),
or do both (see Photo 1). In order to receive data,
the driver must first address another device as a talker.
Again, the driver begins by asserting ATN, and it then
“untalks” and “unlistens” all devices on the bus. The
driver then addresses itself as the listener and addresses
the new talker. Following this, the driver can de-assert
ATN and begin to receive data from the talker.
|
(Click
here to enlarge)
|
Photo
1—Take a look at the GPIB control lines. ATN is
de-asserted so these are data cycles. EOI signals
the end of the transaction. |
Handshaking
received data takes on the opposite role from a send.
After ATN is de-asserted, the bus has been turned over
to another device as the talker, so the transceivers
must be switched out of Talk Enable mode. The driver
then raises NRFD and asserts NDAC to indicate that it’s
ready to receive data. After DAV goes low, the driver
asserts NRFD and retrieves the data from the bus. This
cycle repeats for each byte of data. Again, the transmission
is terminated by an EOI or a line feed.
The
GPIB driver provides a standard board-level interface
API to the XML-RPC server. These routines mirror those
of the well-known API used by GPIB libraries for various
platforms like Windows and Linux. The functions map
directly into the network control functions provided
by the XML-RPC server to the client software. Because
of time constraints, we implemented the functions for
demonstrating the board’s functionality (SendIFC, SendCmds,
SendDataBytes, Send, ReceiveSetup, RcvRespMsg, and Receive)
rather than the entire standard API.
