O ports

O ports

IEEE-488 interface using parallel I / 0 ports Many of the commercially available standard interfaces available are too powerful and expensive for the ...

441KB Sizes 0 Downloads 44 Views

IEEE-488 interface using parallel I / 0 ports Many of the commercially available standard interfaces available are too powerful and expensive for the majority of control applications. Bruce Campbell and Philip Robertson have developed a cheap interface between IEEE-488 devices and an $100 microcomputer system which becomes cost-effective when used in a number of different applications

A single-board computer system and a selfdesigned interface card are used along with a monitor in ROM to interface a frequency spectrum ana/yser and a remote computer system using an IEEE-488 interface. Various settings on the analyser can be controlled as well as the collection o f data. The monitor also has the ability to act as a terminal on a remote computer system and to transfer spectra between the microsystern and the remote host, microprocessors interface IEEE-488

The potential for using micro-based systems in experimental control and data collection is well recognized. In many cases, the main problem to be overcome is the interface between the experimental apparatus and the microcomputer. Nonstandard buses at either or both ends are often the root of difficulties requiring one-off solutions. Therefore the emergence of standard interfaces is welcomed as it allows an approach which is of general use and therefore more costeffective. Predominant among the standard interfaces currently available is the IEEE-4881 which was developed from the general-purpose interface bus (GPIB) from HewlettPackard. Commercial interfaces are available from several sources for interfacing I EEE-488 devices and computer systems. For those with limited funds available, the cost of such devices is prohibitive. In addition, some of the interfaces are designed for use wi[h microcomputers with floppy disc facilities. Such systems are likely to be much more powerful (and expensive) than is needed for a control application. Designing and building your own interface, if you can, is more viable especially where not only the financial cost but also time and effort can be offset by using the product in more than one situation. For this to be feasible, some thought has to be given to portability so that the minimum of changes are required for different machines. The microcomputer in this interface uses the $1002 as its system bus. This is an increasingly popular system bus for microcomputers for which a large variety of peripheral cards are available. Initially its description was ill-defined but an official specification from the I EEE Computer Society is imminent. This standardization should reduce compatibility problems. It should be noted, however, that the general concept of the interface is equally applicable to other internal microcomputer buses. Computing Laboratory, University of St Andrews, North Haugh, St Andrews, Fife KY16 9SX, UK

vol 6 no 6july/august 1982

In our case, the device to be interfaced was a Bruel and Kjaer 2033 high resolution analyser 3. This machine is designed to allow access to its controls and stored data via the IEEE-488 interface. The object of this exercise was to implement a single-board microcomputer system to use this access mode and to communicate with a remote computer system. A series of digitized acoustic signals were obtained from the investigation of the characteristics of sounds from stringed instruments; these were recorded by the frequency analyser which can be regarded as a transient recorder coupled with a Fourier analyser. The data was held as a 400 line spectrum over a specified frequency range. Each of the spectra was recorded previously and then copied to a digital cassette which was then itself transferred to the local mainframe for further processing.The microcomputer system was seen as a means of making this data transfer procedure more efficient. However, the use of an intelligent controller opened up other possibilities to exploit the two-way communication available over the IEEE-488 bus. The design was intended to cope with a single device on the bus and those aspects concerned with multidevice buses have been omitted. However, the design has recognized the potential need for this at some time in the future. IEEE-488 INTERFACE

The IEEE-488 interface and the closely related IEC 625 interface 4 provide a parallel connection between devices using a 25-way cable of which 16 are signal lines and nine are for signal return and ground. The protocol was developed as an electronic interface bus and has found use in some microcomputers e.g. in the Commodore PET. It is an asynchronous bit-parallel byte-serial bus. The interface uses TTL logic levels and is negative true, i.e. the higher (positive) TTL level represents false. The lines are active true, i.e. they are false by default and must be actively set to represent true. In addition, where several devices are connected to the bus, the logical value of a line is the logical OR of the values from all the devices connected on that line. Several instruments can be connected to the bus at the same time and the bus is flexible in that it does not operate at some predetermined transfer rate but at the rate which can be accommodated by the slowest device in the system. The bus is shown schematically in Figure 1. Devices can be classified in three ways: talkers (e.g. tape readers and digital meters) which send data; listeners (e.g. pulse generators and

0141-9331/82/060281-05 $03.00 © 1982 Butterworth & Co (Publishers) Ltd

281

EOl Generol Interface Mono|lement

REN

SRQ ATN

IFC Doto byte tronefet

NRFO

l Tolker

IIIll

].

Illll

I1

Li |tener

0101... e

]

control

Controller

~ e-bit dotobue

Figure I./EEE-488 bus structure

line printers) which receive data; and controllers which organize the traffic on the bus. Devices may operate in more than one mode although, at any given time, there can only be one controller. On the bus itself are eight data lines DI01-DI08. The lines DAV, NRFD and NDAC control the handshake protocol for passing bytes of information using the source and accepter handshake routines. There are five bus management lines. •

IFC - used to clear the interface and put all devices in their default state • ATN - used by the controller to denote the nature of the information on the data lines • R E N - determines whether a device is to be controlled by its front panel switches or remotely using the IEEE-488 bus • SRQ - a line used by devices on the bus to indicate that they wish to attract the attention of the controller • EOI - can be used to terminate a string of data When a talker and a listener transfer data, they coordinate their activities using a protocol which consists essentially of four elements. The talker or source generates new data and then the data lines of the bus settle. The listener or accepter then accepts the data and finally the listener becomes ready to accept the next data byte. The characteristics of the source, transmission lines and accepter will determine the times for each of these activities and the slowest of these will determine the overall transfer speed available. HARDWARE

SOLUTION

An outline of the hardware configuration is given in Figure 2. The heart of the system was a Cromemco SCC singleboard computer s which, in common with many small systems now available, includes a Z80A processor, 1 kbyte of RAM, one serial port, 24 bits of parallel I/O and four slots which can accommodate up to 8k of ROM. In fact, only one slot, i.e. 2k of ROM on a 2716 EPROM, was required while two of the other slots were used to provide another 4k of RAM using Mostek 4802 chips. The SCC, which has a 4 MHz processor, uses the Sl00 bus for system communication. A Cromemco Tuart board was also required to provide another serial line. The choice of this particular brand of equipment was made for historical reasons rather than for any overwhelming technical arguments. We were equipped with good development facilities for this kit and had experience of using it previously. A VDU was used for communication between the user and the system.

282

The hardware interface design could have been approached using one of three options: • an interface to the $100 bus • an interface to the internal microcomputer bus • an interface to the general-purpose I/O ports As the single-board microcomputer already provided 24 bits of general-purpose parallel I/O, in the form of three 8-bit I/O ports, it was considered appropriate to design the IEEE-488 hardware interface using the third option, thus making effective use of the existing hardware. The first two options involving interfaces directly to the S] 00 or internal microcomputer bus would typically have used the Intel 8291/92 chip set, making the parallel I/O facilities redundant. The three SCC 8-bit parallel ports, in common with the S-I 00 bus, support positive true logic, i.e. a named signal is true at its high level, while the IEEE-488 bus has a negative logic convention. The I EEE-488 bus signals consist of an eight-line control bus and an eight-line data I/O bus. The data I/O bus is bidirectional, while the control bus can be split into a four-line bidirectional bus (NDAC, NRFD, DAV and EOI), three unidirectional SCC output signals IIFC, ATN and REN) and one unidirectional SCC input signal (SRQ). The circuit of the I EEE-488 interface hardware is shown in Figure 3. The necessary inversion of all signals was incorporated in the hardware interface by the use of inverting three-state TTL gates for the data I/O bus and inverting TTL gates in the case of the control bus. Open collector TTL gates were used for all control output lines (NDAC, NRFD, DAV, EOI, IFC, ATN and REN). The choice of open collector gates for these control lines is necessary because more than one device can alter the lines. However, with a single device, the data lines are only affected by one device at any time thus allowing the use of three-state gates which have a lower current drain at high impedance. (If more than one device were connected to the bus and parallel polling were required, the data lines would also have to be open-collector gates.) The nature of the I/O ports was used in the data transfer. The READ STB (read strobe) line on the port pulses low when the processor is reading a port indicating an input function while the DATA VALID line pulses low when the data byte is filled on output. The READ STB and DATA VALID I/O port signals were used with further TTL circuitry to provide software control over data transfer direction. The execution of OUT or IN instructions automatically sets the transfer direction. The cost of the components for the interface board was less than £.50. For the serial connections, the RS232 standard was used. The hardware used allows a fair degree of flexibility in

SlO0

IEEE-488

cord

computer

kfferfoce

~Usef Figure 2. Experimental hardware configuration

microprocessors and microsystems

DIo I

2

18 16

DIO 2

14

DIO 3

DI ;B

SRQ

CI2

NDAC

CI5

DI I

DI 2 5

NRFD 12

DIO '

9

DIO 5

DIO 6

6

CI6 C17

I

DI 3

DAM

8

9

EOI

I0

II

DI 4

7

Ol 5

).5

DI6

liP-.---

2,1

IP'--

3

COOl

DI7

C07

74 LS74 STB Q CLRI -I -Read 61r'~ __ 14 Dotovalid

C06

DOe DOI DO2

IFC

6

C05

IO

co4.

IIo~

co3

ATN

DO3 DO4

REN

1 : 5 0 ~ 12

COl

DO5 Legend

DO6 DO7

74LS24~ 7496 74LS~5

Figure 3. IEEE-488 interface

defining the characteristics of the serEal line which enhances the portability of the system.

SOFTWARE SOLUTION The monitor was designed as an easy-to-use system which is selfstarting on power-on or reset. The user requires only simple commands to perform various functions and should be able to extricate himself relatively easily after a mistake in commands. The software can be regarded as being in four parts. The first is a simple monitor to get the system started and read in commands. The second comprises the general

vol 6 no 6july/august 1982

I EEE-488 interface routines such as source handshake while the third contains the functions specific to the frequency analyser. The fourth section is concerned with communication with the remote computer system and the transfer of data between it and the local micro system. The programs are written in Z80 assembler and the final code can be accommodated on a single 2716 EPROM, i.e. in less than 2 kbyte. Three of the four sections of software were designed to be general purpose and can be used with other devices. This is an important aspect of the design of individual systems where the cost of developing software, because it involves

283

no purchases, is often underestimated. It is worthwhile to produce slightly longer but more general software which can be used in other applications with the minimum of modifications. The monitor section is entered at switch-on or after a reset. It is designed to recognize a series of one-letter commands, in either upper or lower case. The list of user commands is summarized in Table 1. In the initialization section, the stack is set up and the various ports and their characteristics are defined. The monitor recognizes an escape character viz controI-C which causes a warm restart of the system. This can be typed in at any time the system is waiting for input. The monitor checks the status register for the terminal input port until the data available bit is set. It then reads a character from the terminal. On reading a command, program control is switched to the appropriate section of code. At present, only nine letters of the alphabet are used which leaves plenty of scope for expansion and modification. If the monitor receives a command which it does not recognize, it reprompts the user for a valid input. The second section contains a series of functions which carry out tasks defined by the I EEE-488 specification, e.g. source and acceptor handshake. All the routines here are designed to be general in nature and do not contain names or addresses which are device-specific. On entry the control lines are initialized and the program then waits for further input from the user. The microsystem begins with the ATN line true thereby setting itself up as the controller on the bus. A storage location has to be set aside to hold the last byte asserted by the microcomputer on the I EEE-488 bus. This may be required for reference and it is not possible to check by simply sensing the lines on the bus because of the open-collector wired-OR nature of the bus. The source and acceptor handshakes include time-out routines to cope with a serious breakdown occurring during transfer. They also include a delay to allow the data to settle on the data lines. This resulted in a maximum transfer rate of slightly less than 10 kbyte/s. The monitor also detects the absence of listeners on the bus when the con-

Command

Function

troller is trying to initiate a transfer. Routines are included to manage the important lines on the control bus, e.g. IFC (interface clear), REN (remote enable), ATN (attention flag), SRQ (service request), as well as setting devices up as listeners or talkers. The next section complements the previous one and is used for communication specifically with the spectrum analyser. At the beginning of this section, the device address is defined which is used by the general routines when they are called. Various codes which are sent as ASCII strings on the data lines are used to control the functions or alter the settings of the analyser. Data transfer can be in both directions, e.g. a previously collected spectrum can be returned to the memory of the analyser for further inspection. The system can collect a record of the switch settings on the analyser by a single-letter command which is held in 232 byte of RAM or a 1000-line spectrum (3240 byte of RAM) again using only a single-letter command. A command is included to allow the user to inspect the spectrum and associated settings which are held in the microsystem memory. Commands to be sent to the analyser are read as strings from the user terminal which are then transmitted to the device. The final section offers virtual terminal support on the remote computer and commands to transfer data to and from the remote machine as well. The former uses interrupts for which the Z80 processor is well equipped and allows the VDU to behave as if it were directly connected to the remote host with the exception of one escape character which is used to disengage the user from the remote machine. In this case, the remote machines used were a DEC VAX 11/780 running VAX/VMS and a Cromemco System 3 running Cromix. This section of code is general purpose and will work with any remote computer since all it does is transmit the dialogue between the user at the terminal and the remote host. The transfer routines send data in 64 byte blocks and use a simple protocol to prevent overflowing of buffers where data is being sent faster than the receiver can cope with it. These routines are more specific in nature since they make use of the file system on the remote machine. In addition, a receiver/sender program is required at the remote end to handle the blocking and checking. To retain a degree of portability, this program was written in FORTRAN which is available on most machines.

B

Automatically scan a single spectrum as a series of time windows, collect the data from these spectra and transfer it to the remote computer

EXPERIENCE

E

Exits from the I EEE-488 routines

I

Enters the I EEE-488 routines and initializes the frequency analyser

K

Allows user to record or alter the pushkey settings on the frequency analyser

L

Lists the spectrum currently held in memory by the microsystem

P

Connects the system to a remote computer

Table 1. Summary of monitor commands

R

Restarts the system

S

Allows the user to either record or to deposit a spectrum in the analyser

T

Sets up transfer of spectra to and from the remote computer

284

The true test of the usefulness of such a project is in its application. The IEEE-488 interface is now in use and is working satisfactorily. In addition to its obvious advantages, e.g. in the speed with which it can record the instrument's key settings compared with the old method of noting them manually, the interface has been able to automate some of the repetitive aspects of the analyser's use. We summarize one application to illustrate the time-saving nature of the micro-based interface. The frequency analyser has a facility for performing a 'scan' analysis in which a single time record is collected and then restricted window samples of the complete spectrum are examined. The spectrum is broken down into about 20 samples which are all recorded. Previously the procedure to collect the data would involve the following six steps.

microprocessors and microsystems

collect the original spectrum set up cassette recorder set the keys to display the first window sample record the spectrum on digital cassette repeat the third and fourth steps for the 20 time windows • take the digital cassette to the remote computer to be read in

the reverse is true if the design which is developed can now be used in other situations. The production of second and subsequent boards has proved to be a simple and therefore cheap procedure. The IEEE-488 software has been designed with expansion in mind and can be modified to cope with multidevice configurations without any radical rewriting of the core software.

With the microsystem, the user has again to collect the original data, set up a receiver program for the data on the remote computer, then type in the command B for the microsystem and enter the starting point and step width for the scan. The microsystem will then carry out the complete spectrum scan and data transfer without further user intervention.

REFERENCES 1 'Digital interface for programmable instrumentation' IEEE Standard 488-19 78 I EEE, New York, USA (1978)

• • • • •

CONCLUSIONS The aim of providing a single card system to interface a $100 system with an I EEE-488 system has been achieved. The performance of the microsystem has proved satisfactory both in providing a more efficient means of data transfer and in allowing other functions to be controlled during experiments. On a one-off basis, the cost of doing this is probably more expensive than an off-the-shelf solution but

vol 6 no 6july/august 1982

2 Elmquist, K A, Fullmner, H, Gustavsen, D B and Morrow G, 'Standard specification for S-100 bus interface drivers' Comput. Vol 12 No 7 pp 28-51 3 2033 high resolution signal analyser technical manual Bruel and Kjaer, Naerum, Denmark 4 'Interface for programmable measuring apparatus byteserial bit-parallel' IEC 625-1 International Electrotechnical Commission, Geneva, Switzerland 5 SCC single card computer instruction manual Cromemco

Inc., California, USA

285