A versatile interface bus

9 downloads 0 Views 374KB Size Report
use only. Any other use requires prior permission of the author and the American Institute of Physics. ... all the measuring instruments in a given experiment connected to a ... design of a versatile interface bus (hereafter VIB) that attempts to ...
A versatile interface bus R. Labb´e1, a) Departamento de F´ısica, Facultad de Ciencia, Universidad de Santiago de Chile, Casilla 307, Santiago, Chile (Dated: Received 28 January 1993; accepted for publication 10 October 1995)

A versatile interface bus was designed. It allows the control of up to 16 instruments using an IBM XT/AT—or compatible—personal computer. Its main features are simplicity and flexibility to connect it with instruments not necessarily designed to be controlled by a computer, greatly improving their performance. c ⃝1996 American Institute of Physics. This article may be downloaded for personal use only. Any other use requires prior permission of the author and the American Institute of Physics. This article appeared in Rev. Sci. Instr. 67, 328 (1996) and may be found at http://scitation.aip.org/content/aip/journal/rsi/67/1/10.1063/1.1146591 I.

INTRODUCTION

The automatic systems for control of experiments and data acquisition are now almost essential tools in the laboratory. In fact, it is in general desirable to have all the measuring instruments in a given experiment connected to a computer, to allow automated reading and storage (or, eventually, real time processing) of the quantities being measured and, on the other hand, to control the parameters governing the system under study. Although there is an enormous variety of commercial instruments conceived to reach this goal using, for example, the IEEE-488 (GPIB) or RS-232 interfaces, sometimes a more simple and manageable interface is desirable to adapt to instruments that may have not necessarily been designed to be controlled by a computer. This may also be the case with ”homemade instruments like, for example, amplifiers, relay arrays or motor controllers, where adding the possibility of computer interfacing remarkably increases their interest and usefulness. One way to fulfill this need of computer control is to use a commercial card,1 based on the GPIB standard or another commonly used interface for instrument communication and control. Another one is to design a customized interface, including only the features commonly required in applications like the ones in the few examples given above. This last approach allows for great simplification in the communication protocol, making the implementation of particular solutions notably less difficult. This note describes the design of a versatile interface bus (hereafter VIB) that attempts to reach the goal of simplicity in both hardware and software implementations, but at the price of a complete dependence of the instrument on the controller, in contrast with commercial instruments, which generally show a tendency to the autonomy. However, this drawback seems of minor importance if we keep in mind that the objective here is to allow the realization of particular—often very specialized—applications rather than generate multipurpose or general solutions.

´ address: Ecole Normale Sup´ erieure de Lyon, CNRS URA 1325, 69364 Lyon, France. a) Present

The VIB uses one card plugged in a slot of the controller—an IBM XT/AT or compatible computer— and one remote card in each instrument connected to the bus, being the design of these cards very simple. In fact, one of the objectives of the whole VIB design was to avoid the utilization of microprocessors to control the operation of remote cards, which is almost invariably the case in instruments using the GPIB or RS-232 standards. This avoids the necessity of software development for their operation. In fact, the only programming required here may be carried out using C, BASIC, PASCAL, ASSEMBLY or any other language featuring INP and OUTor equivalentinstructions, which means no need of software development packages other than the ones belonging to the PC itself. Also, as the only program related with the bus runs on the PC, it can be modified at any time, in order to meet new requirements. But, of course, the VIB is not intended to replace commercial standards. A typical GPIB implementation may be capable of data transfers at rates up to 1 MB/s, using direct memory access. As DMA is not included in the VIB design, the transfer rate will be limited by the CPU speed and the programming strategy, and will be far slower than the GPIB. So, the VIB is very appropriate to be used when commercial standards are not easily applicable, specially in those cases in which an evolving experimental set-up involving customized devices imposes frequent changes in the hardware and software interfacing.

II.

VIB DESCRIPTION

The VIB consists in two sets of eight lines: one to send commands and the other to send addresses or data and to receive data or status information from instruments. For the VIB purposes, an instrument is seen as a set of registers to write or read data. Because it is not possible to read back from some physical registers used to write, a memory was included on the remote card design, in which a copy of the bytes written on such registers is put automatically. Thus the control software does not need to hold an image of the written registers. However, it is possible to write on this memory without change in the associated register, to take advantage of the 128 bytes

2

FIG. 1. Schematic diagram of the VIB controller card. The thick lines represent internal or external buses. The boxed terminals on the left and right sides are connections to the external world.

available. The following are the lines of the command set: -SRQ: Service Request RDY: Data Valid (in Command Code Lines) ACK: Service Request Acknowledge H/L: High/Low Select for 16 bit words C0..3: Command Code Lines The available commands are: 0: RST -To reset all interfaces on the bus 1: WRITE -Register and Memory Write, if bit 7 in the Register Address Latch is 0. Otherwise, Memory Write only. 2: READ REG -Read Register 3: READ MEM -Read Memory 4: READ STAT -Read Status (of an instrument) 5: WRITE RAL -Write on Register Address Latch 6: RESET SRQ -Reset Service Request 7: START -Begin a process (A/D or D/A conversion, etc.) 8...14: -Defined by the User (via hardware) 15: ENABLE -Enables the interface of the addressed instrument and disables the previously addressed one, if it is the case. The second set of eight lines is the following: A0..3/D0..3: -Address [Instrument or Register]/Data (low nibble) S0..3/D4..7: -Status/Data (high nibble). The management of communications between a remote card and its associated instrument is done through 15 command lines plus two groups of write and read data lines, each being eight bit wide. There are, in addition, lines for status, service request, reset and so on, making a total of 50 lines for this purpose. Each device on the bus has a unique address in the range from 0 to 15. The controller can use these addresses to establish communication with the desired

FIG. 2. Schematic diagram of a remote card. Arrow tips and tails represents internal connections between components. (a) Diagram relating the different registers and decoders. (b) Card control logic.

device, accordingly to the control program. Also, when a Service Request Acknowledge occurs, the requesting device put its address on the low nibble of the data bus. So, the controller can identify it, performing then the appropriate actions. This feature can be used for vectorized interrupt handling with priorities established by software. Figure 1 shows a schematic diagram of the controller card. This card is mapped on the CPU I/O space and its address is set up by the DIP switch DSW1. U1 compares this data with the address A2..9 set on the XT/AT bus and, if they are equal and Address Enable is active, a Chip Select signal is sent to U2, a Programmable Peripheral Interface. This enables a read or write operation on the data lines of this IC. U3 is a bus transceiver used to increase the current management capability on the VIB data bus and should be disabled when there are no transactions on the bus. Note that special attention must be paid to the management of the DIR line of U3, because errors in the control program could generate a conflict in the data bus, resulting in

3 the destruction of U3 and/or U5 in the remote card if these two transceivers are driving the bus simultaneously. U4 is a buffer for the command bus. One of its gates A8,Y8! is used to drive the Interrupt Request line selected on the I/O slot of the computer. There is some additional logic, accomplished by U5, allowing for software enabling/disabling of the interrupt linked to the VIBs SRQ line. The interrupt level is selected between IRQ2 to IRQ7 by means of a jumper provided for that purpose. As can be seen, this hardware represent a very simple way to the implementation of the controller card. For the same reason, all the functions defined for the VIB must be implemented by software. Figure 2(a) shows the schematic diagram of a remote card, the control logic being displayed in Fig. 2(b). During power up, a reset circuitry leaves the card in a determined state. When disconnected from the bus, the outputs of the buffer U1 [see Fig. 2(a)] are disabled and forced to the Low state. This avoid that noise picked at the high impedance inputs of this IC be accidentally interpreted as commands. In this way, the associated instrument can be used in a manual mode if that is possible. The card address is set up by DSW1 (Fig. 2(b)), a four bit DIP switch. When the ENABLE command is decoded by U12a, the address set on the low nibble of the data lines is compared with the card address by U7, a magnitude comparator. If these data are not equal, the card is disabled if it was previously enabled. On the other hand, if the address on the bus equals the card address, the communication between this card and the controller is established. As an example, the controller can now write on a low byte of a register, using the WRITE command. The events take place in the following sequence: first, the controller put the register

address on the low nibble (D3...D0) of the data bus, with D7=0. Then, the command code WRITE RAL is sent through the command code lines (C3...C050101 in this case) and a READY signal is put on the RDY line after a short time interval. This stores the desired register address on the Register Address Latch. Lastly, the datum to be write is put on the data lines and a WRITE command is sent by the controller, with the H/L line set to the low state. As bit 7 in the RAL is 0, the datum is written simultaneously on the same address of U8, the on-card memory. Note that the usage given here for some of the lines, like H/L, is not mandatory. For example, when only a word of 16 bit is required for, say, a digital to analog converter, the RAL byte S0..7 can be used in conjunction with DO0..7, and the H/L (or RDY) line to latch these two bytes simultaneously in the DAC register.

ACKNOWLEDGMENTS

This work was partially supported by FONDECYT under Grant No. 778-90 and DICYT-USACH under Project No. 8831. 1 For

example, the IEEE-488 to BINARY/BCD interface from ICS Electronics Corporation (473 Los Coches Street, Milpitas, CA 95035-5422). Roughly speaking, this card provides up to 80 signals for interfacing with BCD/HEX or binary signals to the instrument side, and a GPIB interface to the controller (computer) side. The operation of this card is controlled by an on-board microprocessor running a program stored in a plug-in EPROM. Another example may be the Digital488/32/OEM card, from IOtech, Inc. (25971 Cannon Road, Cleveland, OH 44146). This one provides 32 digital I/O lines programmable as input or output in groups of 8 bits. A microprocessor controls the operation of the GPIB interface and the digital I/O ports. Of course, more complex possibilities are offered by these and other companies.