CA1196979A - Asynchronous interface - Google Patents

Abstract

Abstract of the Invention A loop interface is presented which allows the asynchronous transfer of information between a set of devices. An asynchronous handshake is presented which allows transfer of an assortment of types of Data frames to be initiated. The types of Data frames transferred include the identity and capability of devices in the loop. A handshake is also presented which allows control of the loop to be passed from one device in the loop to another.

Description

~96~7'~i ASYNCHRONOUS INTERFACE

Background of the Invention This invention relates generally t:o interface methods and apparatus for transferring information between devices and more particularly to interface methods and apparatus for transferring information between devices coupled in a linear arrangement or in a l~op structure. Because of the decreasing cost and increasing use of microprocessors, calculators and c~mputers it is becoming increasingly attractive to combine at least one of these devices with a number of othex devices such as test instruments to form a coordinated system in which the devices are coupled ~y suitable interface apparatus. The necessary structure of the interface apparatus is strongly dependent upon the class of devices which are to be coupled to form the system. In many systems and partic-ularly in the early examples of systems, I/O signal parameters such as the protocol (i.e., rules governing ~iming and format of message exchanges) and voltages differed among devices in such systems so that an I/O circui~ card was required for every interface between a pair of devices. To avoid this need for a multiplicity of I/O circuit cards a trend has developed to ~tandardize inpu~ and output protocol and voltages. Such standard-ization enables system configuration t~ be changed simply byreconnecting cables, deleting devices and/or adding devices to ~he sy~tem. The elimination of the mul~iplicity of ~/O circuit.
cards also reduces the cost of int~rconnecting devices to IOrm a system.

6~

Unfortunately, just as one set of ~oltages and protocol is not ideally suited to all devices, a single interface is not ideally suited to all ~ystems. As a result of this, a number of interfaces have already been developed.' A discussion of several interfaces is presented in chapters 9 and 12 of khe text entitled "Computer Organization" written by Bamacher et al and published by McGraw-Hill in 1978. In general an interface should perform the following functions: ~1) provide device status to assist information transfer; (2) provide a ~ata buffer for temporarily storing input or output information; (3) recognize device addresses to enable ransfer of information between subset of de~ices in the system; and (4) provide timing and gating signals to control information transfer. In many interfaces separate lines are provided for transmitting da~a signals, address signals and control signals. The number of data lines employed by an interface is dictated largely by data transfer rate requirements. In a relatively slow interface such as that connecting a central processing unit to a teletypewriter, teleprinter, line printer or magnetic tape unit, bit-serial data transfer is adequate so that in addition to the reference voltage line only a s:Lngle data line is r2quired.
In a byte-serial interface, such as the Hewlett-Packard ~nterface Bus, 8 data lines are required.

Interfaces can be broadly classified as being either synchronous or asynchronous. In a synchronous interface all timing information is deriv d fr~m a single system clock which defines equally spaced intervals in each of which a single data ~ransfer can take place.

A major drawback to such an interface is that the clock rate must be no faster than the slowest device which might be coupled into the system thereby pro~iding low speed data transfer even between high speed devices~ Therefore~ a number of asynchronous intexfaces ha~e been developed which do not restrict da~a transfer to equally spaced intervals. These in1erfaces are well suited for systems utilizing devices having a wide range of data processing speeds. In these interfaces the system clock is replaced by a set of timing control lines over which the de~ices ~ignal one another when they have compl~ted a step or are ready to begin the next step in the data transfer process.

Interfaces can also be broadly classified according to the physical pattern of interconnection between the devices. Some common configurations are: the star configuration in which all peripheral devices are connected to a single controller such as a calculator or computer; the multipoint configuration in which all devices are connected in parallel to a single interface bus; the tree configuration in which a set of linking devices are coupled in a star configura~ion to the controller and each linking device in turn has a set of peripheral devices coupled to it; and the loop configuration in which the output port of each device is connected to the input port of another device.

The ~ewlett-Packard Interface Bus (HP-IB) is n example of a byt -serial asynchxonous interface. IThis in~er~ace utilizes a pro~ocol which has ~een adopted as IEE~ Standard 48~ 75)~ In ~ 3 -this interface the devices are connected in a multipoint configuration by a 16 wire bus. Eight of the sixteen wires are data lines enabling this interface to transmit data in the by~e-serial format.
The xemaining lines are control lines used to regulate daka transfer.

Devices coupled to the HP-IB can play one of 3 active roles:
(1) Controller; (2) Talker; or (3~ Listener. Unless a device is ~ssigned an active role it remains inactive. At system configurati~n, one of the devices is designated by means of switches v/ on that device as the System Controller and issued commands to the othex devices to regulate data transfer. One of the 8 control lines known as the Multiple Response h'nable (MRE) line is utilized by the Controller to inform the other devices whether the signal on the data lines represents a commancl or represents data. When the Controller pulls the MR~ line low to signal that a command is present on the data lines all of the other devices must listen to the daka lines and only the ControLler may transmit signals.

Each de~ice contains switches which enable an address to be assigned to it at ~he time of system configura~ion. These addresses enable addressed commands to be placed on the data line for response only by ~he device having the corresponding address. A number of devices are designated as ~isteners by issuing for each of ~hese devices a Lis~en command having the address of ~hat device.
ata transfer is then ini~iated by issuing a Talk command having the address of ~he device which i5 to transmit data (i.e., to be the Talker). Tr~nsmission of data can be terminated by issuing an Untalk command~ All of the Listeners can be placed in an inactive state by issuing an Unlisten command.

S The asynchronous transfer of data from the Talker to the Listener i5 controlled by the three control lines known as Ready for Data (RFD), Data Valid (DAV) and Data Accepted (DAC)o When all of the Listeners are ready to accept data the RFD line goes high to inform the Talker ~hat it can send data. The Talker 13 ~hen places data on the data lines and after a time sufficient to allow transients in the data to settle lets its DAV line go low to signal the Listeners to accept the data. The first Listener to respond begins accepting the data and pulls the RFD line low ~o indicate that the Listeners are busy accepting data. After all o~ ~he ~isteners have accepted the data the DAC line goes high.
The Talker than resets th~ DAV line high and removes the data from the data line~. This handshake is then completed when the Listeners reset the DAC line. This sequence is xepeated until all of the data i5 transferred to the Listeners.

A number of additional addressed commands are also available to regulate data transfer. The Controller can pass con~rol of ~he ~ystem to another device by one of such cGmmands. However, to enable the system user to ini~iate or ~ermina~e an operation, one o~ the Controllers must be able ~o a~sume control of the bus withou~ being addressed itself~ This controller, deslgn~ted at ~he time of system con~iguration as ~he System Controller has 6~

sole control over a control line called End Output (EOP). When EOP goes low all devices other than the System Controller enter an inactive state.

The devices are connected in a logical-OR configuration to a control line known as the Service Request (SRQ) line to enable the devices to signal the Controller that they need attention.
The Controller can determine which of the devices has requested service by either a serial poll or a parallel poll. In a serial poll he Controller executes a series of addressed serial poll commands which ask successive devices if they are the device requiring attention. These poll commands continue until the Controller locates the device requesting service. In a parallel poll, the Controller issues a single parallel poll command and each device which requires service responds by pulling low the data line to which it was assigned at the time of system configuration. Since more than one device can be assigned to a given data line, the parallel poll does not indicate which device or devices has requested service, but inst~ad only indicates those groups of devices that include devices requesting service~ The devices in these groups must then be polled serially to locate the device requesting service.

~ P-IL is a fast general purpose interface suitable for coordinating data acquisition and analysi~ by a sys~em o~ ins~ruments but it is most appropriate for use in a spatially compact system which includes an exp~nsive high speed Controller whose tLme should not be wasted. ThPre are number of relatively low speed low cost '7~

battery powered calculators and peripherals now available for ~hich such interface speed is not required. In addition the relatively high power requirements of HP-IB and high cost of multiwire interconnects is undesirable for use in connecting such devices.

A second interface of interest is the Pierce Loop, discussed at page 372 of the text entitled "Computer Organization" by Hamacher, e~ alu This interface is an example of a loop structured system. Each de~ice in the loop can communicate with any other device in the loop. Data transmission around the loop occurs in equally spaced time frames. Any device seeking to transmit data can transmit in any frame which is empty so that this loop is the functional equivalent of a circular conveyor belt for conveying data. Because of the synchronous nature of transmission, the Pierc~- Loop is not well adapted for controllins data transmission between devices having a wide range oiE speeds.

Because of ~he trend ~o interface a number of devices to Z0 form a coordinated system, ~he recent devPlopment of inexpensive battery operated hand-held calculator~ has produced a need for an inexpen~ive, low~power, compact in1erface for use in systems under the control of such a calculator. The interface can be relatively low-speed because the operation of expensive de~ices ~5 ~ill not be tied up by such lowspeed interfacing, but the in~erface ~hould be asynchronous ~o make it compatible wi~h instrumen~s of disparate speed. ~he interface should also enable enough exchange ~ 7 ;;

i7~t of commands that it is flexible enough to interface a full range of peripherals. The interface should minimize the number of I/O
ports required on controllers because of the relatively small ~ize of such calculators. The inter~ace should also be Pasily useable by nontechnical consumers because this is a large part of the class of users interested in such low-cost devices.

Summary of the Invention ~n accordance with the illustrated preferred embodiment, an asynchronous bit-serial interface is presented that utilizes a 2-wire loop configuration. An object of the invention is to provide an inexpensive, compact interface suitable for connecting a set of inexpensive, possibly battery powered devices to produce a coordinated system. Each device to be incorporated into the system contains one of these interfaces. Each interface includes a central processing unit (CPU) to control the interface operations and includes a 2-wire input terminal and a 2-wire output terminal.
Each device in the loop has its output terminal connected to the 20 input terminal of a succeeding device in the loop 50 that signals travel in only one direction around t:he loop.

The 2-wire loop configuration i~; particularly suitable for linking small inexpensive devices because the interac n each device only requires a 2-wire input terminal and a 2~wire output terminal xegardless o~ ~he number of devices connec~ed to form the system. This enables ~he incorporation of such an interfac2 ~6(9~g in small devices (e.g., handheld calculators) having a limited amount of surface area available for interface terminals. The

2~wire aspect also reduces the power requirements below that in a multiwire interface by only requirin~ power for a single 2-wire output driver. The loop configuration reduces power requirements because each driver only provides a siynal to the next device in the loop rathar than to a plurality of devices as in a multipoint interface like HP-IB. The 2-wire aspect also reduces the cost of cables to interconnect the devices in the loop thereby enhancing the utility of such an interface in an inexpensive system. Because such inexpensive systems typically include relatively low speed devices, the reduction in data transmission speed from that in a multiwire interface is not a serious limitation and is outweighed by the cost and power advantages.

The asynchronous nature of the interface provides the flexibility needed to efficiently interface between devices having a wide range of processing speeds. The asynchxonous transmission is accomplished by a set of handshakes which depend on the type of information being transferred and on the s~a~es of the devices in the loop. The handshakes enable the Source of information to de~ermine when the devices receiving such information are ready t~ accept further information.

Although informa~ion is ~ransferred in bit~serial format, the bits are grouped into 11 ~i~ messag~ units called frames.
The beginning of e~ch frame is indica~:ed by a ~pecial synchroniæation signal which not only transmits the binary information contained in the first bit of the frame but in addition indicates that that bit is the first bit of a frame. Each frame consists of 8 data bits preceded by 3 control bits which indicate how ~o interpret the data bits. The 8 classes of framec; definable by the 3 control bits represent 5 different kinds of fr~l~es: (1) a Data frame used to transfer data; ~2) an End frame which is a data frame that additionally indicates the end of a data file ~i.e., when the data transferred by an End frame is stored, an indica~ion is also stored at that point to indica~e that the associated piece of data is the last piece of informati~n in a data file); (3) a Command frame to control system operation; (4) a Ready frame for use in establishing interface handshakes; and (5) an Identify frame for use in checking loop integrity or the need for service by a device in the loop.

In Data frames the data bits represent thP data being transferred between devices~ In Command frames the data bits determine the command involved and divide these fr~nes into 5 classes of commands:
~l) Universal commands to which all devices respond; (2~ Talker address commands to designa~e which device is to be the Source of data (i.e., the Tal~er), (3) ~istener address commands ~o indicate which devices are to receive the data transmitted ~y the Talker li.e., the ~isteners); (4) Addressed commands to which only the Talker and Listeners can respond; and (5) Secondary Addre6ses to designate functional components of a device having a Primary ~ddress (e.g., to select particular components within a main~rame where ~he :LO

.

mainframe itself is assigned to prLmary address). In Ready frames the data bits determine the type of handshake informa~ion being transferred and divide the Ready fr~nes into the following 3 groups:
~1) the Ready for Command (RFC) frame employed in ~he handshake used for transmission of commands; (2) the Auto-Address group for use in assigning addresses to devices; and (3) the remaining Ready commands which are collectively called the Addressed Ready group. In an Identify fr2me ~he data ~,its are used to perform a parallel poll of the devices ~o see if any devices need service.

At any given time during information transfer around the loop, one of the devices functions as a Source of frames and the remaining devices function as Receivers. Any device that acts as a Source of Command frames is called a Controller because system operation is controlled by means of commands. In general a system can include more than one device capable of being the Controller, ~ut at the time of system configuration the user must designate (e.g., by means of switches on these devices) which one is the System Controller~ ~t system turn-on the System Controller is the Source of all frames and controls loop opera~ion. By means of commandsl loop control can be passed to any of the other potential Controllers but only the System Controller can unilaterally retake control of ~he æystem -- all other po~ential Controllers can only have control passed to them by the active Controller.

At system GOnfiguratiQn aZdresses are assigned ~o the system devices to enable selective control o these devices. Each device has a register or switches which can be set manually to assign the address for that device. Alternatively ~he addresses can be set by use of the Auto-Address group of Ready frames. In this latter procedure the Controller transmits an Auto-Address fr~ne containing the address 1. The first device (i.e., the de~ice connected to the Controller's output terminal) interface sets an internal address regis~er to l, increments the address portion of the Auto-Address frame by l and then transmits this frame ~o the next device. As the Auto-Address Erame passes around the loop, each device interface sets its address regis~er ~o ~he address in that frame, increments the address !portion of the frame by l and then retransmits the frame to th~e next device in the loop.
By this pxocess, the devices are assigned consecutive addresses.
Once the addresses have been set, addressed commands can ~e used to selectively control the devices in the loop and to transfer the abili~y to source frames for transfer to the other devices.

The transmission of frames around~ the loop and ~he transfer of Source capability are regulated in accordance wi~h a set of handshakes. The particular handshake employed depends on ~he type of frames bein~ transferred and on the states of the devices in the loop. When a frame reaches an interface, the interface first decodes the control bits of the frame to determine ~he type of frame being transferred. For Data frames the interface utilizes a Hold Until Ready handshake ~ When a Da~a frame is ~ransferred around the 1OGP~ each Receiver interface holds ~he frame until it is ready for another frame -- that is, the interface retransmits the frame only when processing by the Receiver is complete.
Therefoxe when a Data frame traverses the loop and ~eturns to the 50urce, the Source knows th~t all devices in the loop are ready for the next Data frame. The Source therefore transmits a Data frame only when the previously transmi1;ted Data frame returns to the Source completing the handshake. This handshake ensures that the Source transmits Data frames no faster than the Receivers in ~he loop can process them. This handshake also enables a simple transmission error checking procedure to be implemented. The Source retains a copy of the transmitted frame until that frame returns. If the frame as it re~urns differs from its copy then the Ssurce interface sets a flag indicating that a transmission error has occurred. At the end of data transmission, the Controller is informed that an error occurred during transmission. This error checking procedure is applied in general and not just for Data frames so that any Source of a frame xetains a ~emporary copy which is compared with the frame as it returns.

The Hold Until Ready handshake has the disadvantage that the Listeners process these frames in series. SinGe Command frames are typically o interest ~o several or all of the loop devices, a different handshake is required for transfer of Commands to enable commands to be processed essentially in par~llel, otherwise the presence of several slow devices in a loop will significantly degrade ~he speed of response of the loop devices ~o Controller commands. Commands are thexefore transferred ~y an ~xpedite handshake in which the command is promptly retransmitted by each ~eceiver - 13 ~

7:~

interface upon determination that it is a Command frame and a copy of this frame is retained in each interface (such a handshake should be appropriate for any transfer of information which is generally of use with several of ~he devices on the loop). This handshake therefore rapidly transfers t;hese frames around the l~op, but the return of such a frame to the Source (i.e., the Controller) no longer indicates that a'Ll of the other devices are read~ for ~he next frame. ~herefore the Controller upon the return of a Command frame promptly transmits the Ready frame known as the Xeady For Command (RFC) frame. The RFC frame passes around the loop via the Hold Until Ready hand~shake so that its arrival back at the Controller signifies that ,all of the devices in the loop are ready to receive and process further frames.

Typically, in the transfer of Data frames it is desired to transmit the data from a single data Source called the Talker to only one or a few of the Receivers known as Listeners. To avoid degrading the speed of data ~ran,sfer due to the non-Listener Receivers t it is advantageous to design the interfaces to enable prompt retransmission of Data frames by non-Listener Receivers.
Therefore, each interface includes a C;et of Status flags which indicat~ whether or not each device i~ Controller active, Talker active, and/or Listener active. In general a device cannot be b~th a Talker and a Listener but it can be both Controll~r and Talker active or Controller and Listener active.

When ~he Controller is also the ~ralker, ~hen ~he ini~iation t~

of data transfer requires only that the Listeners be designated before Data frames are sourced by the Talker. To select the Listeners, the Controller first transmits a Universal Command fr~me called the ~nlisten Co~nand to set each of the Receivers into a listener inactive state in which input Data frames are ~mmediately retransmitted without interaction by the CPU of that interface. The Controller then transmits a set of Listener Address command frames, each having the addresr, of a device that is to become a ~istener. Tho~e devices corresponding to one of the Listener Addxesses enter a listener active state in which input Data frames are transferred to the int,erface CPU. Each Listener retransmits the Data frame only when its CPU is ready for another Data frame. The coding scheme for fr~mes enables each interface to determine whether the input frame is a Data (or End) frame after decoding only one bit of the frame 50 that transmission delays due to non-Listeners are minimized.

When a device other than the Cont:roller is to be the Talker, ~he Data transmission process involves a temporary transfer of ~he ability to source frames. To accomplish this transfer the Controller transmits a Talker Address command having the address ~f the device ~elected to ~e the Talker. That device responds by entering a Talker active sta~e and retransmitting the Talker address irame to pass that frame around the loop to the Controller thereby infonming the Controller that ~he Talker ~ddress frame has reached all of the ReceiversO ~he Controller then sends a Send Data command to tell th~ Talker to begin transmission. The - lS -Talker responds by sending its first Data frame rather than retransmi~ting the Send Data Command. Successive pieces of Data are then transferred via the Hold Until Ready handshake.

When transmission of Data frames is complete the Tal~er transfers the ability to source frames back to the Controller by sending a Universal Command called End of Transmission and then entering a Talker inactive state. When this cc>mmand reaches ~he Controller, the Controller does no~ retransmit ~he frame but instead resumes control of the loop as the active souxce of frames. If ~he Talker had detected an error in data transmission during that data transfer, it would send a modified End ~f Transmission command that informs the Controller of such error as well as transferrins the ability to source frames.

In a similar manner, the active Controller can transfer loop control to another Controller by sending a Controller Address command having the same address of t~e device that is to take over loop control. The Transferor Controller then enters a controller inactive state. On receipt of the Con~roller Address ~ommand the transferee Controller enters the Controller active statc and does not retransmit ~hat command.

The Controller can interrupt data ~ransmission by use of a Ready frame called Not Ready For Data (NRD)~ To interrupt data transmissionl the Controller, upon reception of a data fr~me, temporarily stores that frame and in its place transmits the NRD

~ 16 -fr~m~. The NRD ~rame is passed around the loop to the Talker which recognizes ~hat it i5 to cease transmission. 'rhe NRD frame then passes around the loop from the Talker to the Controller ~hich responds by transmitting the Data frame that it has temporarily stored in order to allow all Lis~eners between the Controller and the Talker to receive this Data frame. ~hen this Data frame reaches the Talker, the Talker sends an End of Transmission message to the Controller to complete this handshake by informing the Controller that it is to resume control of the loop.

The System Controller can also înterrupt data transmission by use of a particular universal command called Interface Clear (IFC). This command actually has greater utility than just interrupting data transmission -- it can be used by the System Controller at any time to retake system control even when another device is acting as ~he Controller. The System Controller can transmit ~his command at any time and need not wait to receive an input frame before transmitting it. Therefore, unlike in the typical case where at most one frame is on the loop at any given time, the IFC command can be on the loop concurrently with another frame. In response to the IFC frame the Talker ceases transmission and the active Controller passes control to the System Controller.

The Controller can source another frame known as the Identify (IDY) frame at any time so that it too can be on the loop concurrently wit~ another frameO One function of t.his frame is to test for breaks in th~ loop and therefore no response is required ~y any of the Receivers other than to promptly retransmit this frame. This handshake is similar to the Expedite handshake for commands in that the IDY frame rapidly traverses the loop but it dif~ers from ~hat handshake in ~hat no copy of this frame is retained by any of the R~ceivers and no associated Ready signal need be sent to determine when the Receivers are ready for another frame.

The IDY frame is also used to perform a parallel poll of the ~eceivers to see if any require service. The eight data bits of the lDY frame provide 8 positions in which the Receiver can signal that it requires service. By use of a set of Addressed C~mmands, the Controller can assign to each data bit of the IDY
frame one or more associated Receivers. Each Receiver can then signal the Controller of i~s need for service by setting its associated bit in the IDY frame before ordering transmission of the IDY frame to the next device in the loop. Generally, eight or fewer Receivers will be associated with these data bits so that each of these Receivers can be exclusively assigned to one of these data bits. In such a case, when the Controller error ~0 checks ~he IDY frame upon its return 1:o the Controller, the Controller can uniquely determine which de~ices need service. On the other hand, if some of the IDY data bits have more than one associated Receiver then this parallel poll merely indicates subsets of the ~eceivers that include at least one Receiver requiring service.
~o then determine which receivers actually require ~ervice, the Controller employs addressed commands ~o serially poll each ReceiVer in these subsets asking each if it required service~ The Data, w 1~

7~

End and IDY frames also include a single control bit which can be set to indicate the need for service. In the case of Data or ~nd frames the Controller would then have to serially poll all ~f the loop de~ices to detexmine which of them requested 6ervice. In this serial poll the Controller sequentially sends an addressed command to each device being polled and in response ~he device being polled modifies this command frame before retransmission if it needs ~ervice or else retransmits this command unmodified if it doesn't need service. In the case of IDY frames, only those Receivers not assigned to one of the IDY data bits will be associated with this control bit so that the serial poll need only be executed on this residuary set of Receivers.

To enhance the friendliness of a system employing this loop interface, each interface includes the ability to identify the del number of the device in which it is incorporated and also the functional capabilities of that device (e.~., printer, voltmeter, etc.). Therefore, after physically connecting the loop, the user need not explicitly inform the Controller of the 2~ character of each device to enable the Controller to know which Receiver to ac~ivate for specific tasks. For example, if the system user wants to have the output from a vol~meter plotted on a graph, the user can simply command the Controller to have a ~Voltmeter" act as thé Talker and have a "plo~er" act as a Listener.
The user need not then inform ~he Controller of the address of either the voltmeter or plotter -- ins~ead the Controller serially poll~ the devices on the loop asking if each is a voltmeter and when it locates one it ends that poll and coT~mands that device to become the Talker~ The Controller similarly locates the first plotter on the loop do~mstream from the plotter and commands it ~ become the Listener.

Because any instrument can malfunction it is sometLmes necessary in a loop configuration to remove a malfunc~ioning device from ~he loop to avoid interfering with loop performance. However, physically removing the device might be inconvenient and also could interfere with loop operation whilé disconnecting the device from the lcop. Therefore each interface can be placed into a Retransmit-All state in which that interface functions simply as a repeater, thereby retransmi~ting all signals with minimal delay.

Each interface also includes a Power Down (PD) state for conserving power. ~his state is beneficial in battery operated devices to conserve power during periods of loop inactivity. In this state the interface turns off all device functions other than an interface function of monitoring its input for incoming signals. Thus, the Controller can be programmed to send a power down command to ~he Receivers during periods of inactivity. Then ~he Controller can reactivate the devices on the loop at a subsequent period for loop activi~y by sending any frame le.g., ~he I~Y frame) around the loop.

- 2~ -~6~7~
An aspect of the invention is as follows:
A process of transferring assorted types of message frames in a loop interface of the type in which a plurality of addressed devices are connected in ~ loop c:4nf iguration, ln which e~ch device has an input pc~r~ connected to the outpu~ port of another device in the loopt in which one o the devices i~ in a ~alker active ~ta~e in which it can ~unctlon as ~che ~ource of message frames and în whi;:h o~her devices in the loop can be placed in a Talke~ active ~tate, ~aid process comprising the ~teps of:
~cransmi~ g a Talk ziddressed message frame rom the source said Talk address~d mess~ge fra~De containing ~he address of a ~elected device which iQ to be 5e~ in~co a Talker active s~ate;
p~s~iny the Talk add essed ~essage ~ame ~round the loop fro~ he ~our ::e ~o the selec~ed device, ~aid elected device entering the Talk ac:tive ~a~e in re~ponse t~ the Talk addressed ~ae~sa~e f r ame;
pa~sing ~he Talk ~ddres~ed messalge frame around 'che ïoop ~co ~he ~ource;
~fter rec~ivins ~he Talk ~addre~sed m~ssage frame at the ~our~e, trals~mit~ng a Start of ~rans~lnis~ion message frame from ~he ~ource 9 sai~ ~ollrce ~l~o ~sn~ering zl Talker inactive state in ~hich it no longer f~ ions ~ ~h~ ource c:~ me55~t9e ~rames;
pas~ing ~che ~tar of Tran~3mission ~e~sage f~ arc3und the 2 -, loop to the d~v~ s:e which is ~alker ac~ive; ~nd the 'calk~r a~:tive devic~ ln r~gpon~e to the reG~?tion o~ the S~ar~ of ~ran~nissiorl me~sage fr~me takirl~ oveE the func on as ~he ~ource o ~e~age :E~2me50 - 20a -Description of the Fiqures Figure lA shows a typical signal lransmitted between devices in t~e loop.

Figure lB shows the response at points C and D in Figure 3 to the signal .in Figure 1 being applied across points A and B
in Figure 3.

Figure 2 is a block diagram of the preferred embodiment of the interface chip.

Fiyure 3 shows synchronous input dector 23 in greater detail.

Figure 4 presents the registers shown in the block diagram in Figure 2.

~0 2~

Description of the Preferred Embodiment In accordance with the preferred embodiment of ~he disclosed interface system, a number of devices are connected in a 2-wire loop configuration to enable cooperative interaction among the devices. Each device in the system has a 2-wire output port connected to a 2-wire input port of another device in the system.
The input and output port of each device are connected to an interface chip which performs some of the decoding and processing of the information signals between the devices. Each interface chip is coupled to a central processing unit (CPU) which complements the interface chip in the processing of information signals. Each CPU is in turn connected to the electronics of the device in order to enable the device to respond to information signals. The use of a CPU in the interface increases the flexibility of the interface by enabling the response of an interface to be varied by varying the programs within the CPU.

The electrical connection from one device to the next is a differential, voltage mode, 2-wire balanced line. The electrical connection is coupled to the interface chip at each end by means of transformer coupling. This allows both wires to float with respect to both deviGes' ground connec~ions so t~at no common ground is requixed for all devices in the circuit. This is especially handy for voltmeters which need to measure value- not referenced to ground. One of the wires is chosen as a reference and the voltage of the other wire is measured only relative to this ~ 22 -reference. This structure has the ad~vantage of avoiding ground loops which can form a substantial source of noise. Since most noise pulses tend to affect both wires eq1lally, this system of connection is relatively noise free. Similarly, because during signal transmission, the voltage on one wire rises when the other falls, the amount of noise due to radiation from the system itself is reduced.

The signal bits are encoded using a 3 level code as shown in Figure 1. The nominal value of the voltage difference for these three levels is 1.5 volts (high~, 0 volts, and -1.5 volts (low). Every message on the loop is sent as a sequence of eleven bits called a message frame. The first bit in each frame is called the sync bit and is coded in a special way to signal the beginning of a message frame in addition to indicating the binary value of that bit.

The first three bits in each frame are called the control bits and determine the type of message frame being transmitted.
Four types of frames are defined by the control bit patterns shown:

C3 C2 Cl Data or End tDOE 3 0 END SR~2 Colrunand (CMD) 1 0 0 Ready (~Y ) 1 0 Identify (IDY) 1 1 SRQ
Table 1 In Table l, Data frames are the device dependent messages which transfer information from one device to another. End frames are Data frames which additionally indicate the end of a data record.
For example, if in a given transmission, several data files are S txansferred from a floppy disk, then the End frame can be used to delimit each file during the ~ransmission. The Data and End messages are processed in the same way and therefore will be referred to collectively as Data or End ~DOE) frames. Command frames are used to configure the loop to control the transfer of DOE frame~.
Ready frames are used to establish addressed for the devices and to pass the ability to source frames from one device to another.
Identify frames are special purpose frames which are used to test loop integrity (i.e., whether the loop is unbroken) and to execute a parallel poll to see if devices on the loop require service.
In DOE and IDY frames, control bit Cl is not needed to designate frame type and so it is used as an alternative way for devices on the loop to signify that they need service. This bit is normally zero in DOE and IDY frames, so that if a device needing service receives one of these frames, that device sets control bit Cl to one when it retransmits the frame to pass the frame along around the loop.

The reception and transmission of message frames ~y the interface can be understood ~y reference to the block diagram of the interface chip shown in Figure 2. ~n input message is supplied to the interface chip on receiver lines 21 and 22 at the input ~ort of the device~ These lines provide the input message ~o an input - ~4 -~6~

detector 23 shown in greater detail in Figure 3.

As shown in Figure 3, receiver lines 21 and 22 are coupled to detector ~3 by a transformer 31 in which the ratio of windings i6 chosen to convert from the 1.5 volt amplitude of the signals on the connecting pairs of wires to the binary logic voltage level of the interface chip. The voltage difference between lines 21 and 22 for a typical input signal is shown in Figure lA. The resulting signals at p~ints C and D are shown in Figure lB. These signals are non-negative and are logic level. Detector 23 uses a pair of Schmidt triggers 32 and 33 followed by a pair of D type flip-flops 34 and 35 clocked at 2 Mhz to detect the signals at points C and D. Bit decoder 36 monitors the flip-flop output to determine the logic level of each bit. The order in which the outpus of flip-flops 34 and 35 go high determines the binary data being transferred. For sync bits the pattern of highs CDCD
indicates a logic 1 whereas the pattern DCDC indicates a logic 0.
For non-sync bits the pattern CD indicates a logic 1 and the pattern DC indicates a logic 0. Bit decoder 36 provides output signals from decoder 23 for ~ransfer of the decoded input message frames.

The response of an interface chip and associated CPU ~o an inpu~ message frame is controlled by the progxamming of the CPU
and by the con~ent of a set of 8 bit registers R0-R70 ~hese registers are shown throughout Figure 2 as registers 28-215 and are also shown for convenience in Figure 4. In several of these regi~ters, ~6~

different bits are accessed by the CPU in a read operation than are accessed by the CPU in a write operation. For example in register R0 (the Status register), the bit RFCR i5 accessed in a read opera~ion by ~he CPU on bus 2 to register R0, whereas bit SLRDY is accessed in a write operation by the CPU on bus 2 to register R0. To indicate ~his register split, the read portion o~ a regis~er will be designated by an R (e.g., ROR for register R0), the write portion will be designated by a W le.g., ROW), whereas the entire register will be designated without an R or W (e.g., RO).

Register RO is called the status r~gister and contains bits which affect the response of an in~erface to an incoming signal.
Bit SC (System Controller) is set at system configuration only in the device which is to function as the System Contr~ller. This bit will ~ypically be set in response to a switch on the console of the device selected as the System Controller. Bit CA ~Controller Ac~iv~) is set in the device which sexves as the active loop Controller. When control is passed from ~he active Con~roller to another Controller, the previ~usly active Controller resets this bit in its in~erface chip and the newly active Controller sets this bit in its interface chip. During a period of Data ~ransmission, the bit TA (Tal~er Active) is se~ in the device ~hat serves as the Talker and bit ~A (Lis~ener Active) is set in those devices tha~ serve as ListeI-ers. Bit SSRQ ~Send Service Requestl is set by ~he CPU in those devices which require service by the active Con~roller. When a DOE or IDY irame is re~ransmitted or sourced by a device with SSRQ se~ t ~he S~Q bit in such a fr~ne is set to one during the transmission but the values of the SRQ
bits in registers R2W and R2R are not Affected.

Bit ~FCR (RFC Mes~age Received) is sP~ when an int~rface chip has detected the reception of the RFC message. Bit SLP~D
(Set Local Ready) is set only by the interface CPU and pro~ides the chip with a simple means ~ handling the CMD-RFC handshake -- it is set when the interface CPU has completed the pr~cessing of a command and is ready for ano~her command. If an RFC command is received when SLRD~ is not set, the ~FC command will not be retransmitted until SLRDY is setO When SLRDY is set the RFC frame is transmitted. Similarly, if SLRDY is already set when RFC is received, RFC is automatically retransmitted. In both cases, RFCR is cleared automatically when the RFC is transmitted. If a command is received which does not affect that device, the CPU
is not interrupted and therefore SLRDY is set by the chip.

When i~ is desired to initialize the chip status, the MCL
(Mas~er Clear) bit is set. This bit is set at device turn-on and can also be set by the CPU ~o clear the status of ~he chip and reset the registers to the status existing at instrument turn-on.

Register Rl is the in~errupt register containing the interrupt ~its IFCR ~IFC Message Received)g SRQR ~S~Q ~essage Received~
FRAV (Frame ~vailable), F~N5 ~rame ~eceived Not ~s Se ) and O~V
(Ou~put Re~ister Available). ~ach of these bi~s serves as an interrupt for the interface CPU. Each of these bits has an associated in~errupt enable bit in RlW. The clearing of any of these enable bits will mask its associated interrupt bit thereby enabling the CP~ to select which of the interrupts has high enough priority ~hat it will respond to that interrupt. Because the IFC command is an important command which e~ables the System Controller to interrupt loop operation and retake control of the loop, ~his interrupt can only be cleared by the interface CPU
by set~ing CLIFCR. CLIFCR is self-resetting -- i.e., it will be automatically cleared ~wo microseconds after it is set. The other interrupt bits can be reset by the interface chip in response to messages from other sources as well as in response to the CPU.
For example, the SRQR is set in an active Controller (i.e., CA=1) when it receives a message indicating that a device on the loop ~5 requires service. However, if before the CPU responds to the IFCR interrupt a succeeding message arrives at the loop i~dicating that no device on the loop now requires service, then SRQR will be cleared in response to such a message without requiring action b~ the CPU.

A Frame is loaded into register R2R only when it needs to be acted on by the interface CPU. The CPU is informed that a frame i5 available for it ~o act on by setting either FRAV or FRNS.
~hen a device interface sources a frame, it retains a copy of ~hat frame in its output register R2W and in the first three bits Of RlWo When that device next receives a frame it checks to see if that frame is ~qual to the frame which it sen~. ~ it is not 7g~
equal then it loads the received frame into R2R and sets FRNS
t.o let the CPU act on this informationO The primary purpose of this procedure is to enable a Talker to see if its Data messages are being passed error free around the loop and to enable the active Controller ~o see if its Command messages ar~ being passed error free around the loop. However, there are a few other ~ituations in which FRNS is set but which do not indicate that a transmission error has occurred. For example if an IDY frame is sent around the loop by the active Controller at a time when at least one device requires service, then such devices will alter a bit in the IDY message to indicate their need for service. In this case ~he setting of FRNS just lets the CPU process the returned IDY message to ~earn that at least one device requires service.
In the cases in which a message is loaded into register R2R and no error has been detected, then FRAV is set instead of FRNS.
Both FRAV and FR~S are reset when R2R is read.

Bit ORAV is set when a loop handshake is complete and the output register is available for sending the next frame. ORAV
is also set in a ew other cases that will be discussed below.

When MCL is set, the chip is initialized by setting bits and latches as follows: (lj interrupt bits IFCR, SRQR, FRNS and YR~V are cleared and in~errupt bit ORAV is ~et; ~2) the five interrupt bits are cleared so that no interrupts can occur until the CPU sets at least one of these bits high; (3) the SC bit is set to 1 if and only if the system user has selected that device as the System Controller (e.g., by means of a switch on the device console); l4) a Retransmit Service ~equest latch (which will be discussed below) is cleared; and (5) an ORE (Ou~put Regis~er) empty bit (which will also be discussed below) is set high.

The response of an interface chip to an input frame is dictated primarily by the status of the bits in registers RO and Rl. The status of ~hese bits causes t:he chip to au~omatically decode most subsequent frames 50 that only those frames which affect a device are routed to the CPU, while o~her frames are automatically retransmitted.

Referring to Figure 2, the bit decoder 36 in decoder 23 is coupled to a multiplexer 25 and an input pointer counter 27 to control transfer of data from decoder 23 to an input buffer 26.
In response to a sync bit, decoder 23 applies a reset signal to buffer 26 and counter 27 to reset these two devices. At each successive bit .in a fxame, counter 27 is incremented by 1.
Multiplexer 25 is controlled in response to counter 27 so that successive bits of a serial input fra~e are loaded successively into the 11 bits of input bu~fer 26. When the 11th bit (D1) of ~he input frame has been loaded into buffer 26, a ~ignal IPT 11 is sen~ from counter 27 to an ~cceptor PL~ 216 to in~orm PLA 21 ~hat loading of the frame into buffex 26 is complete~

The existence of input buffer 26 in addition ~o an input register 217 enables a second frame ~o be entered in~o ~he inter~ace

- 3~ -g~

~i.e., into buffer 26) even before a first frame which is present in input register 217 has been completely processed. This could happen for example if an ID~ or IFC is asynchronously sourced by the active Controller or System Controller, respectively, while another frame is on the loop.

When the frame in input register 217 has been prosessed, gates are opened which allow the contents of input buffer 26 to be copied into input register 217. If the previous frame has been processed before a new frame arrives tas is usually the case), the incoming frame is loaded into buffer 26 and register 217 simultaneously. Decoding of an incoming frame by IDY-CMD decoder 218 begins as soon as the three command bits have been entered into buifer 26. Further decoding by rame decoder 219 begins as soon as frames are being loaded into input register 217. Because only the firs~ bit C3 of a D~E frame need be decoded to identify that type of frAme, this type of frame is very quickly identified.

The determination of the frame type is communicated from decoders 218 and 219 ~o PLA 216 to enable the chip to respond to the input frame~ Depending on the frame type and device status one of three responses will occur: (1) the frame is automatically retransmitted using multiplexer 210; (21 the frame is automatically retransmi~ted using multiplexer 220 and will also be loaded in~o the first 3 ~its of register RlR and into the 8 bits of register R2R; or (3) the frame i~ loaded into registers Rl~ and R2~ without retransmission.

In addition to the above 3 responses, if the interface h~s souced a frame which has not previously returned, the interface Will asume that the receiv~d frame is that frame and will error check the received frame. To enable sourcéd frames to be error checked, a copy of the pxeviously sourced frame is r~tained in output register 20 (i.e., ~he first 3 bits of xegister RlW and ~he 8 bits of register R2W) until after the error check. To accomplish the error check, an output pointer counter is incremented ~hrough an 11 bit range and its contents are simultaneously fed to multiplexers 220 and 221 to strobe corresponding data from these 2 multiplexers into each of the inputs of an exclusive or gate 222. If the two fr~mes being compared are equal then the resulting bit stream from gate 222 will be all zeros. When the received frame is loaded into RlR/R2R for the CPU to read, either interrupt FRAV or interrupt FRNS is set to info~m the CPU that there is a frame for it to read. If there has been no error checking or if an error check has found no error then FRAV is set. However, if an error check has detected an error then FRNS
is set instead of FRAV.

The interface chip includes an address register 212 in which the address of the device is s~oredO The existencP of the device addressed allows command frames ~o be coded so ~hat only selected devices will respond to these c~mmand frames. This is accomplished by dedicating som~ of ~he bi~s in such command frames to indicate the address of ~he device that is ~o respond ~o the command. An address compara~or 224 is connected to input register 217 and ~ 32 -to address register 224 to enable the comparison of the command address with the device add~ess.

A transmit encoder 225 is connec~ed tO an outpu~ multiplexer 226 to select between ~hree alternati~e sources of frames for transmission by the chip. The first ~source is an RFC encoder 227 which is used by the active Controller to source an RFC frame when a previously sourced command frame has returned and been error ~hecked. The second source is multiplexer 220 which is used for automatic retransmission of certain received frames.
The third source is outpu~ register 210 into which a fr~me is written by the CPU after the CPU has processed it and is ready to retransmit it. The act of writing to register 210 triggers the transmission of the frame in that register.

As a frz~e is retransmitted the frame can be altered to indicate the need for service by ~hat device. If Send Service Request (SSRQ) is true in register 28 and the frame being transmitted is a DOE or IDY frame the bit Cl can be set to 1 to indicate the need for service. If the frame is an IDY and the device has been configured for parallel polling, the IDY bit with which that device is associated is set to indicate the need for service~

The interface chip includes a parallel poll regist~r 211 to control the response of a device Xor purposes of a parallel poll. Tha IDY frame is utilized to execute a parallel poll. The IDY message is sourced by the active Controller and can be sen~

1 ~9 6a ~ 9 to check for loop integri~y and/or to see if any devices require ~ervice. In a parallel poll any of the 8 data bits can receive the service request so that up to 8 devices can respond uniquely although more than one device can respond on a single bit.

The active Controller, having sourced the IDY frame, error checks it upon return. ORAV is set to signal the completion of the handshake. If an "error" is detected because one of ~he IDY
bits has been changed by a device on the loop to signal thP need lQ for service, FRNS is set and the frame is made available to the CPU by shifting it into register RlR~R2R. Since IDY also contains the C1 bit to signal need for service, this bit would also be set by any device needing service regardless of whether the device also has responded on one of the parallel poll bits.

Parallel poll register 211 is connected to the transmit encoder 225 to enable the SRQ and parallel poll bits to be set on the fly as a frame i5 transmitted. Register 211 regulates the response of the interface for purposes of parallel polls.

The interface will respond to a parallel poll only if PPIST ~Parallel Poll Individual Status) and PPEN (Parallel Poll Enable~ are both set. If either of these bits is not se~ then the interface will not alter any of the IDY messagesO P~IST is set and cleared by th2 CPU to indicate whe~her the device needs service and PPEN
25 i8 set and cleared in response to co~mmands from the active Controller to indicate whether the controller wants the device to take part in a parallel poll. The use of PPEN enables the active Controller , ~

to enable and disable devices from the parallel poll response ~o that for example several devices can be associated with a given IDY data bit but only one or a few of them are presentlv enabled to respond on the bit~

Bits P3, P2 and Pl represent the binary value of the IDY
data bit on which this interface is ~o respond. PPSENSE ~Parallel Poll Sense) controls the nature of ~he respon~e. If the interfac~
is set to respond on the n-th bit Dn of ~he IDY frame then the response is Dn(out) = Dn(in3 ~ (PPIS~ ~ PPSENSE)PPEN where ~
represents e~clusive or (namely, A ~ B = 1 if and only if A = B).
The effect of this response scheme is that when PPSENSE is low, ~hen if Dn is sent as a zero by the active Controller, it will return as a zero only if all of the clevices enabled to respond on Dn re~uire service. Similarly, when PPSENSE is high, then if Dn is sent as a zero by the active Controller, it will return as a 1 if any of ~he devices enabled to respond on Dn require service. The active Controller can mask the parallel poll response on any given data bi~ by transmitting tha~ bit as a oneO Since this bit will return as a 1 regardless of the s~atus of the bits in parallel poll register 211, no iniormation will be transferred on thi s },i t .

The other two bits in the parallel poll xegister 211 are n~ involved in parallel poll. The ORE (Outp~t Regis~er ~mpty) bi~ is used ~o indicate when register R2W is empty to avoid writing a ~uccessive ~ra~e in~o ~ha~ register before ~he transmission - 3~ ~

of a previous frame is complete. This bit is cleared when a frame is loaded into R2W and is set when all 11 bits have been transmitted.
~it RERR is only set high when a sync bit is received in the middle of a frame ~hereby indicating an error in the received frame.

The command frame~ are divided into five groups: UCG (Universal Command Group), TAG (Talker æddress ~roup), LAG (Listener Address Group), SCG (Secondary Address Group) and ACG (Addressed Comma~d Group). The bit pattern iden~ifying these groups is shown in Table 2:

UCG x O O 1 x x x x SCG x 1 1 x x x x x LAG O O 1ADR ADR3 ADR2 ADR1 ~DRO
ACG x O OO x x x x (x's are "don'~ cares" for decoding and are used to encode diffexent messages within each yroup) Table 2 ~0 The universal commands and secondary commands are those commands which are of interest to all devices and therefore they are always m~de available to the CPU by setting FRAV (or FRNS) and loadlng a received universal command into regis~er RlR/R2R. ~he Talker address commands are used to set ~he selected Talker in~o the Talker active state. In ~his commancl, da~a bits Dl-D5 contain the address ~f the device which is to become ~he Talker. ~ddress 7~
comparator 224 compares these bits with bits Dl-D5 in Address register 212. When the addresses match, that device is set into Talker active state by setting the TA bi~. Sinc2 only one device on the loop is allowed *o be Talker active at one time, all devices for which these addresses aren't equal, clear the TA bit.

In a similar manner, bits D1-D5 in the Listener address command contain the addresses of the device to be set into Listener active state. Since more than one device can be Listener active, the devices which do not correspond to this address do not respond in the manner analogons to that for Talker address commands (namely, by going inactive~. Active Listeners are therefore only deactivated by a universal command which deactivates Listeners. The Addressed commands are only passed to the CPU of devices which are Listener and/or Talker active. Conversely, all command frames other than - the IFC frame are made available to the CPU of devlces with TA
or LA set. The IFC is not made available to the CPU because it is decoded by the chip. Only tho~e cormmands discussed above which are of interest to the device are made available to the CPU. When an IDY frame is received, it can be identified by decoder 218 after 2 bits have been received. ~n :[DY frame is automatically retransmitted by all devices other than the active Controller.

When a command is received, decoder 218 can detect this after 3 bits have been received so that the atuomatic retransmission can begin after three bits have been loaded into buffer 26 or loading of the frame has begun into xegister 217, whichever of ~hese events occurs last.

When a DOE frame is received, it can be identi~ied after ~he first bit has been received~ In devicés which are not Talker or Listener active, the frame is promptly retransmitted -- this avoids delaying passage around the loop by d2vices which are uninterested in data messages. In active Lis~eners, the DOE frame is made available ~o the CPU. In the active Talker, the DOE frame i5 errDr checked since the Talk~r is the source of data frames.

The ~Pady (RD~) frames are divided into two groups: the RFC frame and the other RDY frames. ~he RFC frame is issued automatically by the active Controller's chip when t~e previously issued command return~ and error chec]cs OK. Each device's chip decodes the RFC frame completely and, when its CPU indicates (via SLRDY) that the command has been understood, retransmits it.

The address ready group frames are those RDY frames of interest to addressed devices (i.e., the active Talker, Controller and ~0 Listeners). In such active devices, the ARG frame is made available ~o the CPU. ~n ARG frame is retransmit~ed by writin~ it from the CPU to he output register RlW/R2W. The Address Ready Group includes the Start of Transmission (SOT) framP~, the End of Transmission OK (~TO) frame, ~he End of Transmission with Error (ETE~ frame and the Not Ready for Data (NRD) frame.

The SOT frames are used to initia~e data ~ransmission~ After -6~7~

the ~alker and Li~teners have been designated via commands, the Controller sends the SOT frame. When ~he SOT frame is received ~y an active Talker or Listener, the SOT frame is made available to ~he CPU. When a Talker's CPU decodes the SOT frame, instead of r2transmitking it, the Talker transmits its first DOE frame by writing it to RlW/R2W. Each DOE fr~me is automatically error checked upon return to the Talker. When the Talker is finished, it sources (via a write to RlW/R2W) the ETO ~rame if no errors were detected or ETE if errors were detected during the transfer of Data. Upon receiving the ETO or ETE frame, the Controller's chip sets F~AV allowing its CPU to determine when the Talker is done. Because the appropriate response ~o the occurrence of an error in transmission will vary depending on a nun~er of factors, the choice of response is left open to the system user via appropriate programming.

The NRD frame permits a Controller to interrupt the transfer of Data. When such interrupting is desired by the Controller, the Controller will store the next Data frame it receives and rèplace it with an NRD frame. When the NRD frame is received by the Talker, it is made available to the Talker's CPU to inform the CPU that it is to discontinue sourcing Data. After retaining a co~y of the frame present in its ~u~put regis~er 210 (i.e., the previous Data frame it transmitted), ~he Talker retransmits the NRD lvia a write to RlW/~2W) to pass the NRD back ~o ~he Controller.
Upon receiving the NRD ~he Controller transmits the Data frame that it stored to enable ~isteners between the Controller and Talker to receive it. Upon receiving this Data frame the Talker performs its usual ~rror check. However, since that last frame ~ransmi~ted by the Talker was the NRD, the Talker will detect an error and set both FRNS and ORAV. The CPU responds to thes~
signals by checking the received data frame with the copy which it saved before transmission of the NRD.

The device address stored in address register 212 can be set in a number of ways. In one approach the address can be set at manufacture as a permanent address. This has the disadvantage of ~imiting an interface loop to no redundancy of device type.
In a second approach the address can be set in response to user input such as signals from switches on the device console. In a third approach, device addresses can be set by means of an auto addressing scheme. In this scheme the active Controller sets its own address to 0 and then sources an Auto Address message.
This message has 5 bits which contain the address 1 upon transmission by the Controller. ~t each device other than the Controller, the device makes the message available to its CPU. The CPU sets the address in register 212 equal to the address in this message, and then increases ~he address in the message before retransmitting the message to the next device in the loop.

Each interface includes a number of additional features which enhance loop performance. In response to a Power Down command, ~he interface can turn off all device and chip activity o~her than that of an edge de~ector. This enables a Controller to turn ~ 40 -7'9 off virtually all lo~p activity to conserve energy. ~his is particularly useful in battery operated devices. The edge detector enables all devices to be powered up in response to any siynal transmitted around ~he loop. The interfacé also contains a S Retransmit All input which turns the interface into a simple repea~er when this line is pulled highO In this state, all frames are automatically retransmitted without any other action by the device. This capability enables a device to be effectively removed from the loop (e.g., when the device is malfunctioning), without physically breaking the loop to remove the device. This avoids the inconvenience of having to reconfigure the loop and also avoids pos~i~ly disturbing ongoing loop operation. The Retransmit All state can be set in response to Controller commands or user signals (e.g., from a switch on the console of the device being placed into this state) but since it then will not respond to commands it cannot be taken out of ~his state by Controller commands.

The interface also includes a few features which make it friendly for system users. The identify of the device (e.g., Manufacturer and model number) can be stored in CPU or in a dedicated registex, Likewise the capability of a device (e.g., whether it's a printer, plotter, etc.) can be stored in the CPU on in a dedicated register. Typically, the capability and identity will be stored as 8 bits of data which can be transferred as the dat~ bits of a Data frame. This scheme therefore al~ows 28 different identities and capabilities ~o be coded. Typically 9 a range of codes will be assigned ~o a particular class of devices ~e~g., ~6~

plotters) so tha~ each class can be divided into as many s~bclasses as there are codes in its associated range of codes.

These capabilities not only let the user request such information from loop devices, it also enables the use of friendly pr~grammlng commands. For example if the user desires to plot data measured by a voltmeter, the user need not know the printer or voltmeter in the loop. Instead, the user can simply command that the data being measured 6ay by the Model HP-3468A voltmeter 1~ be printed on ~he Model HP~8216~A prin~er. The Controller will then segmentially poll the devices around the loop as to their identity and/or their capability until it locates the selected devices. The Controller then notes the addresses of these devices and uses them to set the voltmeter into Talker active s ate and the printer into Listener active state.

The serial poll is executed as follows. Beginning at a selected point in the loop (which by default can be chosen as the device at address 1) the Controller sets that device into Talker active state and then sends it a Ready message which tells it the type of data to send and that it is to s~art sendiny now. These Ready irames are analogons to the Start Transmission frames which initiate Data ~ransfer. Two examples of these Ready frames are the Send Iden~i~y and Send Capability frames which initiate the trans~er of the device identi~y and capability respectively~ ~hen a Send Identi~y frame is received by the device whose identity is being requested, ~hat device replaces that frame with a Data frame containing its identity. When this frame reaches the Controller it passes the frame to its CPU for response. The CPU then loads this frame into the output register to retransmit it back to the Talker (i.e., ~he device whose .identity was requested). The Talker error checks the frame and sends an ETO or ETE frame to the Controller to complete the handshake. An analoyons series of steps occur for a Send Capability Ready frame.

In a similar manner, control can be passed from the active Controller to another Controller in the Loop. The active Controller first sends a Talk Address command to set the other Controller into Talker active state and then sends a Take Control ready frame.
Upon sourcing the Take Control ready frame, the active Controller clears its CA bit. Upon reception of ~his frame the other Controller sets iks CA bit and takes over control of the loop.

~ 43 -

Claims (5)

Claims

1. A process of transferring assorted types of message frames in a loop interface of the type in which a plurality of addressed devices are connected in a loop configuration, in which each device has an input port connected to the output port of another device in the loop, in which one of the devices is in a Talker active state in which it can function as the source of message frames and in which other devices in the loop can be placed in a Talker active state, said process comprising the steps of:
transmitting a Talk addressed message frame from the source, said Talk addressed message frame containing the address of a selected device which is to be set into a Talker active state;
passing the Talk addressed message frame around the loop from the source to the selected device, said selected device entering the Talk active state in response to the Talk addressed message frame;
passing the Talk addressed message frame around the loop to the source;
after receiving the Talk addressed message frame at the source, transmitting a Start of Transmission message frame from the source, said source also entering a Talker inactive state in which it no longer functions as the source of message frames;
passing the Start of Transmission message frame around the loop to the device which is Talker active; and \
the talker active device in response to the reception of the Start of Transmission message frame taking over the function as the source of message frames.

2. A process as in claim 1 wherein the Start of Transmission message frame is a special message frame called a Send Data message frame in response to which the talker active device begins to transmit data message frames.

3. A process as in claim 1 wherein the Start of Transmission message frame is a special message frame called a Take Control message frame in response to which the talker active device enters a controller active state in which it functions as the source of control message frames.

4. A process as in claim 1 wherein the Start of Transmission message frame is a special message frame called a Send Identity message frame in response to which the talker active device transmits a data message frame indicating the model number of the talker active device, said process further comprising the steps of:
said talker active device assuming a talker inactive state after transmitting its model identification; and the source, in response to the reception of the data message frame indicating the model number, resuming the function as the source of message frames.

5. A process as in claim 1 wherein the Start of Transmission message frame is a special message frame called a Send Capability message frame in response to which the talker active device transmits data message frames indicating the functional capabilities of the talker active device, said process further comprising the steps of:
said talker active device assuming a talker inactive state after transmitting its functional capabilities; and the source in response to the reception of the data message frames indicating the functional capabilities, resuming the function as the source of message frames.