CA1196978A - Asynchronous interface - Google Patents

Abstract

Abstract of the Invention An asynchronous interface is presented which enables the transfer of information between a set of devices having a wide range of operating speed. Each device can enter a Controller active state in which it sources command frames to control the loop operation. Each device can also enter a Talker active state in which it sources Data frames on a Listener active state in which it received Data frames. The transfer of frames is coordinated by a set of handshakes which enable the frames to be transferred in an asynchronous manner.

Description

ASYNCHRONOUS I~TERFACE

Back round of the Invention q This invention relates generally ~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 lin~ar arrangement or in a loop struc~ure. Because of the decreasing cost and increasing use of microprocessors, calculators and computers it is becoming increasingly attractive to combine at least one of these devices with a number of other devices such as test instruments to form a coordinated system in which the devices are coupled by suitable interface apparatus. The necessary struc~ure 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 timing and format of message exchanges) and voltages differed among devic~s in such systems so that an I/O circuit 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 ~o standardize input and output protocol and voltages. Such standard-izatio~ enables system configuration to be changed simply byreconn~cting cables, deleting devices and/or adding devices to the system. The elLmination of the multiplicity of I/O circuit cards also reduces the cost of interconnecting devices ~o form a systemO
. ~
-- 1 ~

Unfortunately, just as one set of voltages and protocol is not ideally su~ted to all devices, a single interface is not ideally suited to all systems. As a result of this, a nur~er of interfaces have already been developed. A discussion of several interfaces is presen~ed in chapters 9 and 12 of the text entitled "Computer Organization" written by Hamacher et al and published by McGraw-Hill in 197S. In general an interface should perform the following functions~ provide device status to assist information transfer; (2) provide a data buffer for temporarily storing input or output information; ~3) recognize device addresses to enable transfer of information between subset of devices in the system; and (4) provide tLming and gating signals to control information transfer. In many interfaces separate lines are provided for transmitting data 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 single data line is required.
In a byte-serial interface, such as ~he Hewlet~-Packard Interface Bus, 8 data lines are required.

Interfaces can be broadly classified as being either synchronous or asynchronous. In a synchronous interface all tLming information is derived from a single system clock which defines equally spaced in~ervals in each of which a single data transfer can ~ake 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 ~he system thereby providing low speed data transfer even between high speed devices. Therefvre, a number of asynchronous interfaces have been developed which do not restrict data trarlsfer to equally spaced intervals. These interfaces are well suited for systems utilizing devices having a wide range of data processing ~peeds. In these interfaces the system clock is replaced by a set of tLming control lines over which the devices signal one another when they have completed 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 configura~ions 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 de~ices are connected in parallel to a single interface bus; the tree configuration in which a set of linking devices 2Q are coupled in a star configuration to the controller and each linking device in turn has a se~ of peripheral devices coupled to it; and the loop co~figuration in which the ou~put port of each device is connected ~o the input port of another device.

The ~ewlett-Packard Interface Bus ~HP-IB) is an example of a byte-serial asynchronous interfaceO This inter~ace utilizes a protocvl which has been adopted as IEE~ Standard 4B8 (1975)~ In this interface the ~evices are connected in a multipoint conflguratLon by a 16 wire bus. Eight of the sixteen wires are data lines enabling this interface to transmit d~a in the by~e-serlal forlnat.
The remaining lines are control lines used to regulate data transfer.

Devices coupled to the HP-IB can play one of 3 active roles:
Il) Controller; l2~ Talker; or ~3j Lis~ener. Unless a device is assigned an ~ctive role it remains inactiveO At system configuration, one of the devices is designated by means of switches on that device as the Sys~em Controller and issued commands to the other devices to regulate data transfer. One of the 8 control lines known as the Multiple Response Enable ~MRE) line lS utilized by the Controller to inform the other devices whether the signal on the data lines represents a command or represents data. When ~he Controller pulls the MRE line low to slgnal that a command is present on the data lines all of the other devices m~st listen to the data lines and only the Con~roller may transmit signals.

~0 Each device contains switches which enable an address to be assigned to it at the tlme of system configuration. These addresses enable addressed commands to be placed on the data line for response only by the device having the corresponding address. A number of devices are designated as ~is~eners by issuing f~r each of ~5 ~hese devices a Listen command having the address of ~hat device.
Data ~ransfer is then ini~iated by issuing a Talk command having ~he ~ddress of ~he device which is ko transmi~ data (i eO, to be 6~

the Talker). Transmission 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.

The asynchronous transfer of data from the Talker to the Listener is controlled by the three control lines known as Ready for Da~a (RFD), Data Valid (DAV) and Data ~ccepted (DAC~o When all of the Listeners are ready to accept data the RFD line goes high to in~orm the Talker that it can send data. The Talker then places data on the da~a 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 ~ata and pulls the RFD line low to indicate that the Listeners are busy accepting data. After all of the Listeners have accepted the data the DAC line goes high.
The Talker than resets the DAV line hiyh and removes the data from the data lines. This handshake is then completed when the Listeners reset the DAC line. This sequence is repeated until all o~ the data is transferred to the Listeners.

A n~mber of additional addressed commands are also available to regulate data transfer. The Controller can pass control of ~he system to another device by one of such commands. However, to enable the system user to ini~iate or terminate an opera~ion, 25 one of the Controllers must be able to assume control of the bus without being addressed itself. ~his Controller, designated at the time ~f system configura~ion a5 the System Con~roller has ; - 5 ~6~

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

S 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 atkention.
The Controller can deter~ine which of the devices has requested service by either a serial poll or a parallel poll. In a serial poll the 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 de~ice 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 de~ice can be assigned to a given data line, the parall~l poll does not indicate which device or devices has requested service, but instead only indicates those groups of devices that include devices requesting service. The devices in these groups must then be polled sexially to locate the device requesting service.

~ P-IL is a fast general purpose interface suitable for coordinating data acquisition and analysis by a system of instruments b~t i~ is most appropriate for use in a spatially compact system which includes an expensive high speed Controller whose time should not be wasted. There are number of relatively low speed low cost battery powered calculators and peripherals now available for which such interfac~ speed is not required. In addition the relatively high power requirements of HP-IB and high cost of multiwire interconnects is undesirable ~or use in connecting such devices.

A second interface of interest is ~he Pierce Loop, discussed at page 372 of th~ text entitled "Computer Organization" by Hamacher, et al. This in~erface is an example of a loop structured system. Each device in the loop can communicate with any other device in the loopO Data txansmission around the loop occurs in equally spaeed time frames. ~ny device seeking to transmit data can transmit in any frame which is empty so that this loop is the ~unctional equivalent of a circular conveyor belt for conveying data. Because of ~he synchronous nature of transmission~
the Pierce Loop is not well adapted for controlling data transmission b~tween de~ices having a wide range of speeds.

Because of the txend to interface a number of devices to form a coordinated system, ~he recent development of inexpensive battery operated hand-held calculators has produced a need for an inexpensive, low-power, compact interface for use in systems und~r the control of such a calculator. The interace can be r~latively low-speed because the opera ion of expe~sive devices will no~ be tied up by such l~w-speed interfacing, bu~ ~he interface ~hould be asynchro~ous to make it compatible with in~truments of disparate speed. The interface ~hould also enable enough exchange of commands that it is flexible enough to interface a full ranye 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 in~erface should also be easily useable by nontechnical consumers bec~use this is a large part of the class of users interested in ~uch low-cost devices.

Summar 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 ~o be incorporated into the system contains one of these interfaces. Each interface includes a cen~ral 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 ~erminal connected to the input ~erminal of a succeeding device in the loop so that signals travel in only one direction around the loop.

~ he 2-wire loop configuration is particularly suitable for linking small inexpe~sive devices because the interface in each device only requires a 2~wire input tenninal and a 2-wire output terminal regardless o~ the number of devices connected ~o form the system. This enables the incorpora~ion of such an interface in small devioes (e.g., handheld ~alculators) having a limited amount of surface area available for interface terminals. The

2-wire aspect also reduces the power requiremenks below that in a multiwire interface by only requiring power for a single 2-wire output driver. The loop configuration reduces power requirements because each driver only provides a signal to the next device in the loop rather than to a plurality of devices as in a multipoint interface like ~P-IB. The 2-wire aspect also reduces the cost of cables to interconnect the devices in the loop thereby enhancing ~he 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 ~he cost and power advantages.

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

Although information is ~ransferred in bit-serial format, the bits are grouped into 11 bit message units called fr~nes.
The beginning of each fr~ne is indicated by a special synchronizatlon _ g _ ~6~

sign~l w~lich 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 o 8 data bits preceded by 3 control bits which indicate how to interpret the data bits. The ~ classes of frames definable by the 3 control bits represent 5 dif~erent kinds of frames: (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.eO, whe the data transferred by an End frame is stored, an in~ication is also stored at that point to indicate that the associated piece o~ data i~ the last piece of information in a data file); (3) a Command frame to control system operation; (43 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 d~vice in the loop.

In Data frames the data bits represent the data being transferred between devicesO In Command frames the data bits determine the command involved and divide these frames into 5 classes of commands:
(1) Universal commands to which all devices respond; (2) Talker address commands to designate which device is to be ~he Sourc~
of data (i.e., the Talker); ~3) ~istener address commands to indicate which devices are to receive ~he da~a ~ransmitted by the Talker ~i.e., the Listeners); (4) ~ddressed commands to ~hich only the Talker and Liste~ers can respond; a~ (5) Secondary ~ddresses to designate fu~ctional components of a device having a Primary ~ddress (e.g., to select particular components wi~hin a mainframP where the - 10 ~

mainframe itself is assigned ~o primary address). In Ready frames the data bits determine the type of handshake information being transferred and divide the Ready frames 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; ar,d (3) the remaining Ready commands which are collectively called ~he Addressed Ready group. In an Identify frame the data bits are used to perform a parallel poll of the devices to 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 ~ommand frames is called a Controller because system operation is controlled by means of commands. In yeneral a system can include more than one device capa~le of being the Controller, but at the time of system configuration the user must desisnate (e.g., by means of switches on these devices) which one is the System Controller. At system turn-on the System Controller is the Source of all frames and controls loop operation. By means of commands, l~op control can be passed to any of the other poten~ial Controllers but only the System Controller can unilaterally retake control of the system -- all other potential Controllers can only have control passed to them by the active Controller.

At system configuration addresses are assigned to ~he system devices to enable selective con~rol of these devices. Each device ~6~

has a register or switches which can he set manually to assign ~he address for that device. ~lternatively the addresses can be set by use of the Auto-Address group of Ready frames. In this latter procedure the Controller transmits an Auto~-Address frame containing the address 1. The firs~ device (i.e., ~he device connected to the Controller's output terminal) in~erface sets an internal address register to 1, increments the address portion of the Auto-Address frame by 1 and then transmits this frame to ~he next device. As ~he Auto-Address frame passes around the loop, ~ach device interface ~ets i~s address register to the address in that frame, increments the address portion of the frame by 1 and then retransmits ~he frame to the next device in the loop.
By this process, the devices are assigned consecutive addresses.
Onc~ the addresses have been set, addressed commands can be used to selectively control the devices in the loop and to transfer the ability to source frames for transfer to the other devices.

The transmission of frames around the loop and the transfer of Source capability are regulated in accordance with a set of handshakes. The particular handshake employed depends on the type of frames being 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 the ~ype of frame being transferred. For Data frames the in~erface utilizes a ~old Until Rea~y handshake ' When a Data frame is ~ransferred around the loop, each Receiver interface holds the frame until it is ready for ano~her frame -- that is, the interface xetransmits ~ ~2 -the frame only when processing by the Receiver is complete.Therefore when a Data frame traverses the loop and returns to the ~ource, the Source knows that all devices in the loop are ready for the next Data rame. The Source therefore transmits a Data frame only when the previously transmitted Data frame returns to the Source completing the handshake. This handshake ensures that the Source transmits Data frames no faster than the Receivers in the 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 returns differs from its copy then the Source 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 50 that any Source of a frame retains a temporary copy which is compared with the frame as it returns.

The Hold Until Ready handshake has the disadvantage that the ~is~eners process these fxames in series. Since Command frames are typically of interest to several or all of the loop devices, a different handshake is required for transfer of Commands to enable commands ~o be processed essentially in parallel, otherwise the presence of several slow devices in a loop will significantly degrade the speed of sesponse of the loop devices to Controller commands. Commands are therefore trans~erred by an ~xpedite handshake in which the command is promptly retransmitted by each ~eceiver ~9G978 interface upon de~ermination 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 vf information which is generally of use with several of ~he devices on the loop). This handshake therefore rapidly transfers these frames around the loop, but the return of such a frame to the Source (i.e., the Controller) no longer indicates that all of the other devices are ready for the next frame. Therefore the Controller upon the return of a Command frame promptly ~ransmits the Ready frame known as ~he Ready For Command (RFC) frame. The RFC frame passes around the loop via the Hold Until Ready handshake so that its arrival back at the Controller signifies that all of the devices in the loop are ready to receive ~nd 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. ~o avoid degrading the spPed of data transfer due to the non-Listener Receivers, it is advantageous to design the interfaces to enable prompt retransmission of Data frames by non-Listener Receivers.
Therefore, each interface includes a set of Status flags which indicate whether or not each device is Controller active, Talker active, and/or Listener active. In general a device cann~t be both a Talker and a Listener but it can be both Controller and Talker active or Controller and Lis~ener active.

When ~he Controller is also the Talker, then the initiation G97~

of data transfer requires only that the Listeners be designated before Data frames are sourced by the Talker. To select the Li~teners, the Controller first transmits a ~niversal Command frame called the Unlisten Command to set each of the Receivers into a listener inactive state in which input Data frames are immediately retransmitted without interaction by ~he CPU of that interface. The Controller then transmits a set of Listener Address c~mmand rames, each having the address of a device that is to b~come a Listener. Those devices corresponding to one of the Listener Addresses enter a listener active state in which input Data frames are transferred to the interface CPU. Fach Listener retransmits the Data frame only when i~s CPU is ready for another Data frame. The coding scheme for frames enables each interface to determine whether the input frame i5 a Data (or End~ frame after decoding only one bit of the frame so that transmission delays due tv non-Listeners are minimized.

When a device other than the Controller is to be the Talker, the Data transmission process involves a temporary ~ransfer of the ability to source frames. To accomplish this transfer the Controller transmits a Talker Address command having the address of the device selected to be ~he Talker. That device responds by entering a Talker active state and retransmitting the Talker address frame to pass that frame around the loop to the Controller thereby informing the Con~roller that the Talker Address frame has reached all o the Receivers. The Controll~r then sends a Send Da~a command to tell the Talker to begin transmission. The ~ 15 -Talker responds by sending its first Data frame rather than retransmitting 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 Talker transfers khe abiliky to source frames back to the Controller by sending a Universal Command called End of Transmission and then entering a Talker inactive state. When ~his command reaches the Controller, ~he Controller does no~ retransmit the frame but instead r~sumes control of the loop as the active source of frames. If the Talker had detected an error in data transmission during that data transfer, it would send a modified End of Transmission command that informs the Controller of such error as well as transferring 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 the device that is to take over loop control. The Transferor Controller then enters a controller inactive state~ On receipt of the Controller Address command the transferee Controller enters the Controller active state and does not retransmit that command.

The Controller can interrupt data transmission by use of a Ready frame called Not Ready For Data (NRD). To interrupt data transmission, the Controller, upon reception of a data rame, temporarily stores ~hat frame and in its place transmits the NRD

7~

frame. The NRD frame is passed around the loop to the Talker which recognizes tha~ it is to cease transmission. ~he MRD frame then passes around the loop from the Talker to the Controller which responds by transmitting the Data frame that it has temporarily stored in order to allow all Listeners between the Controller and ~he Talker to receive this Data frame. When this Data frame reaches the Talker, the Talker sends an End of Transmission message to the Controller ~o complete ~his handshake by informing the Controller that it is to resume control of the loop.

The System Controller can also interrupt data transmission by use of a particular universal command called Interface Clear (IFC). ~his 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 the Controller. The System Controller can transmit this command at any time and need not wait to receive an input fr~me before txansmitting 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 lIDY3 frame at any time so that it too can be on the ~oop concurrently with another frame. One function of this frame is to test for brea~s in ~he loop and therefore no response is requixed by any of 69~7~

the Receivers other ~han to promptly retransmit this frame. ~his handshake is similar to the Expedite handshake for commands in that the IDY frame r~pidly traverses the loop but it differs from that handshake in that no copy of this frame is retain~d by any of the Receivers 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 Receivers t~ see if any require service. The eight data bits of the IDY frame provi~e 8 positions in which the Receiver can signal that it requires service. By use of a set of Addressed Commands, 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 its 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 checks the IDY fram~ upon its return to the Controller, the Controller can uniquely determine which devices 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 Receivers that include at leas~ Dne Receiver r~quiring service~
To then determine which receivers ac~ually require ~ervice, the Controller employs addressed commands to serially poll each ReceivPr in these subsets as~ing each if it required service. ~he Data, 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 End frames the Controller would then have to serially poll all of the loop devices to determine which of them requested 5 service. In this serial poll the Controller sequentially sends an addressed command to each device being polled and in response the device heing polled modifies thir, command frame before retransmission if it needs service or else retransmits this command unmodified if it doesn't need service. In the case of IDY frames, ~0 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 m~del number of the device in which it is incorporated and also the functional capabilities of that device (e.g., printer, voltmeter, etc.~ Therefore, after physically connecting the loop, the user need not explicitly inform the Con~roller of the character of each device to enable i-~e Controller to know which Receiver to activate for specific tasks. For example, if the system user wants to have the output from a voltmeter plotted on a graph, the user can simply co~nand the Controller to have a ~Voltmeter" act as thé Talker and have a "plo~ter" act as a Listener.
The user need not then inform the C~ntroller of the address of either the voltme~er or plotter -- ins~ead ~he Controller serially polls the devices on the loop asking if each is a voltmeter and 97~3 when it locates one it ends that poll and commands that device to bec~me the Talker. The Controller similarly locates the first plotter on the loop downstream from the plotter and commands it to become the Listener.

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

Each interface also includes a ~ower Down (PD) s~ate for conserving power. This state is beneficial in battery operated devices ~o conserve power during per:iods of loop inactivity. ~n this state th~ in~erface turns off aLl device functions other than an interface function of monitoring its input or incoming signals. Thus, the Controller can be programmed to send a power down command to the Receivers during periods of inactivity. Then ~he Controller can reactivate the devices on the loop at a subsequent p~riod for loop activity by sending any frame ~e.g~ the IDY frame) around the loop.

Various aspects of the inventi.on are as follows:

A process of transferring mç!ssage frames in a 1~ near interface of the type in which a~ lea~t one receiver is connected to a sou~ce in a linear configuration, in which the source has an S outpu~ port connect~d ~o an input port of a first receiver, in which any other receiver~ each has an lnput port connected ~o an outpu~ port of a preceeding r~ceiver in the configuration so that message frame~ pass from ~h~ sou~ce along the linear interface to a last r~ceiver~ aid proe~s~ comprising the s~ep~ of:
transmitting a message frame from ~he source to ~he first r~c~iv~r;
each r~ceiver other than the last one passing ~he message frame on to i~ suGceeding receiver in ~he linear conigura~ion;
when th~ first receiver is ready to accept another message 15 fra~e, ~ransmit~ing a Ready signal in the direction from the firs~ r~ceiver ~oward ~h~ las~ receiver;
at each receiver other ~han the firs~ and last ones, when that receiver ~s ready to accept a~other message frame and ha~
also received a Ready ~ignal rom the ~preceding receiver in ~he 20 linear confi~ura~iont trarsmitting a ~eady sigrlal 'co its ~uceeeding receiver in the linear canf.iguratiorl; and oontrolling th~ SOUFCe ts:~ tra~s~i~ a succ:~eding message frame only if ~he l~st receiver has rei:eiv~ a Re~dy ~ignal an is ready itsel to receiv~ another me~sage fraloe, thereby 25 transmitting said ~ucceeding me~sage frame only when all r~ceivers are ready to accep ar~o~her ~essage fram~.

- 20a -A proce~s o t~ansferring message frames in a loop interface of the ~ype in whi ::h a plurali~y of receivers are connec~ed to a ~ource in a loo1? ~oniguration; in which the source and all of ~he receivers each haYe an input port connect~d s to an ou~pu~ psrt of a precedirlg d~vice irl the loop so that message rames transmitted by the source are pa~ed around the loop to the source, said process comprising the step~ of transmitting a me~sage frame from the source;
~ach receiv~r passing the message fxame on 'co its succe ding device ir, the loop;
transloitting f om 'che sourc:e a Ready signal;
a~ eac:h receiver, when tha~ r~ceiv~r i5 ready ~co accept ano~her messaye frame and has al~o received a Ready signal from the preceding receiver in ~he linear eonfiguration, '~ransmitting a ~eady ~ignal to its suc:ceeding device in ~he lin ar coniguration; and contrs: lling ~e source to ~ran~mit a ~ucceeding ~essage fru~e c~nly ater it receives ~e Ready ~ignal, ~chereby tr~nsmi~ting ~u~ceeding m~ssage f rallnes only when all of the receivers on the looE? are ready to rec~ive ~ns:~ther ~ess2ge frame.
A ~evice having a pow~r do~lm Dlode ~ said device c:ompr i ~ing s ~n i~pu~ port for rec:eiving inpu ~ignals;
~r ulp m~an~ ~onn~c~d ~o ~h~ input port a~nd r~pon~iY~ ~o the input o a ~e~sage frame fo~ ~werirlg up any deviee activiti~s o~h~r than ~he E;ower up m~easlsD ~aid other deYice activiti~ being turned of f in . he pow~r down znode ~o reduce power c:onsumptior10 20b Descriptlon of the Fig~res Figure 1~ shows a typical signal transmikted between devices in the loop.

Figure lB shows ~he, 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.

Figure 3 shows synchronous input dector 23 in greater detail.

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

Description of the Preferred Embodiment In accordance with the preferred embodiment of the disclosed interface system, a number of devices are connected in a 2-wire loop configuration ~o enable cooperative interaction arnong 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 i~terface chip which performs some o~ 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 fleY.ibility 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, vol~age mode, 2-wire balanced line. The electrical connection is coupled to the interface chip at each end by means o~ transformer coupling. This allows both wires to float with respect to both devices' ground connections so that no common ground is required for all devices in the circuit. This i5 e~pecially handy ior voltmeters which need to measure values not referenced t,o ground. One of the wires is chosen as a reference and the voltage of the other wire is measured only rela~ive to this - 22 ~

~316~17~3 reference. This structure has the advantage of avoiding ground loops which can form a substantial source of noise. Since most noise pulses tend to affect both wires equally, 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 reducedO

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)O 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 rame are called the control bits and determine the type of message frame being transmitted, Four types of rames are defined by the control bit patterns shown:

C3 C2 Cl Data or End (DOE) 0 END SRQ
Command (CMD) 1 0 0 Ready (RDY~ 1 0 Identify (IDY) 1 1 SRQ

~able 1 ~6~
In Table 1, Data frames are the device dependent messages which transfer inf ormation from one device to another. End frames are Data frames which additionally indicate the end of a data xecord.
FDr example, if in a given transmission, several data files are transferred from a floppy disk, then the End frame can be used to delimi~ each file during the transmission. The Data and End messages are processed in the same way and therefore will be referred to collectively as Data or End (DOE) framesO Command frames are used to configure the loop to control the transfer of DOE frames~
Ready frames are used to establish addressed for the devices and to pass the ability to source frames from one device to an~ther.
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 C1 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 ii a device needing service receives one of these frames, that device sets control bit Cl to one when it retransmits the frame l:o p~ss the frame along around the loop.

The reception and transmission of message frames by the interface can be understood by reference to the block diagram o~ the interface chip shown in Figure 2~ An input message is supplied to the interface chip on receiver lines 21 and 22 at the input por~ of the deviceO These lines pro~ide the inpu~ message to an input - 2~ ~

7~3 detector 23 shown in greater detail in Figure 3.

As shown in Figure 3, receiver lines 21 and 22 axe coupled to detector 23 by a transformer 31 in which the ratio of windings is 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 points C and D are shown in Fiyure lB. These signals are non-negati~e 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 moni~ors 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 o highs CDCD
indica~es a logic 1 whereas the patte;rn 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 ~rom decoder 23 for transfer of the decoded input message frames.

The response of an interface chip and associa~ed CPU ~o an input message frame is con~rolled by the programming of the CPU
and by the content of a set of 8 bit registers R0-~7. These registers are shown throughou~ Figure 2 as registers 28-215 and ~re also shown for convenience in Figure 4. ]n sev~ral of ~hese registers, 6~
different bits are accessed by the CPU in a read operation than are accessed by the CPU in a write operation. For ex~mple in register R0 (the Status regis~er), the bit RFCR is accessed in a read operation by the CPU on bus 2 to register R0, whereas bit SLRDY is accessed in a write operation ~y the CPU on bus 2 to regis~er R0. To indicate this register split, the read portion o a register will be designated by an ~ (e.g., ROR for register R0 the write portion will be designated by a W (e.g., ROW), whereas the entir~ register will be designated without an R or W ~e.g., RO).

Register RO is ~alled the status register and contains bits which affect the response of an interface to an incoming signal.
Bit SC (System Controller~ is set at system configuration only in the de~ice which is to function as the System Controller. This lS bit will typically be set in response to a switch on the console of the device selected as the System Controller. Bit C~ (Con~roller Active) is set in the device which serves as the active loop Controller. When control is passed from the active Controllex to another Controller, the previously active Controller resets this bit in its interface chip and the newly active Controller ~ets this bit in i~s interface chip. During a period of Data transmission, the bit ~A (Talker Active) is set in the device that serves as the Talker and bit L~ (~istener Active) is se~
in those devices tha~ ~erve as ~isteners. Bit SSRQ iSend Service Request) is set ~y the CPU in those devices which require service by ~he active Controller. ~hen a DOE or IDY frame .i~ re~ransmit~ed or sourced ~y a devioe with SSRQ set, the SRQ bit in such a frame ~ 26 -~ ~G~78 is set to one during the transmission but the values of the SRQ
bits in regist$rs R2W and R2R are not affected.

Bit RFCR (RFC Message Received) is se~ when an interface S ~hip has de~ected the reception of the RFC message. Bit SLRD
(Set ~ocal Ready) is set only by the interface CPU and provides the chip with a simple means of handling the CMD-RFC handshake -- it is set when the interface CPU has completed the processing of a command and is ready for another command. If an RFC command is received when SLRDY is not set, the RFC command will not be retransmitted until SLRDY is set. When SLRDY is set the RFC frame is transmitted, Similarly, if SLRDY is already set when RFC is received, RFC is automatically retrans,mitted. In both cases, RFCR is cleared automatically when the RFC is transmitted, If a command is receiYed which does not affect that device, the CPU
is not interrupted and therefore SLRDY is set by the chip.

When it is desired to initialize the chip status, the MCL
~Master Cleax) bit is set. This bit is set at device turn-on and can also be set by the CPU to clear the status of the chip and reset the registers to the status existang at instrument turn-on.

Register Rl is the interrupt register containing the interrupt 25 bits IFCR (IFC Mes~age Received), SRQR (SRQ Message Received~, FRAV SFrame Available3, FRNS (Frame ~eceived No~ ~5 Set) and ORAV
(Output Register A~ailable). Each of these bits serves as an 6~7~

interrupt for the interface CPU. Each of these bits has an associated interrupt enable bit in RlW. The clearing of any of these enable bits will mask its associated interrupt bit ther~by enabling ~he CPU to select which of ~he interrupts has high enough priority that it will respond to that lnterrupt. Because the IFC command is an important command wh:ich enables the System Controller to interrupt loop operation and retake control of the loop, this interrupt can only be cleared by the interface CPU
by setting CLIFCR. CLIFCR is self~resetting -- i.e., i~ will be automatically cleared two 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 t~ the CP~.
For examplet the SRQR is set in an active Controllex (i.e., CA=1) when it receives a message indicating that a device on the loop requires service~ However, if before the CPU responds to the IFCR interrupt a succeeding message arrives at the loop indicating that no device on the loop now requires service, then SRQR will ~e cleared in response to such a message without requiring ac~ion by the C~U.

A Frame is loaded into register R2R only when i~ needs to ~e acted on by the interface CPU. The CPU is i~fonmed t~at a frame is availabl!e for it to act on by setting either FRAV or FRNS.
~hen a device interface sources a fr~ne, it re~ains a copy of ~hat frame in its ~utput register R2W and in the first three bits of RlW. When that device next receiv~es a frame it checks to see if that frame is equal to the frame which i~ sent. If it is not ~ ~6~78 equal then it loads the received frame into R2R and sets FRNS
to let the CPU act on this information. The primary purpose of this pr~cedure is to enable a Talker to see if its Data messages are being passed error free around the loop and to enable the active Con~roller to see if i~s Command messages are being passed error free around the loop. However, there are a few other situations in which FRNS is set but which do not indicate that a transmission error has occurred. For example if an IDY frame is sen~ around the lo~p by the active Controller at a time when at least one device requires servic~, then such devices will alter a bit in the IDY message to indicate their need for service. In this case the setting of FRNS just lets the CPU pr~cess the returned IDY message to learn 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 FRNS are reset when R2R is read.

Bit OR~V is set when a loop handshake is complete and the outpu~ register is available for sending the next frame. ORAV
is also set in a few other cases that will be discussed below.

When MCL is set, the chip is initialized by setting bi~s and latches as follows: (1) interrupt bits IFCR, SR~R, FRNS and - FRAY are cleared and interrupt bit ORAV is set; (2~ ~he five i~terrupt bits are cleared so that no interrupts can occur until ~he CPU sets at least one of ~hese bits high; ~3) the SC bik is set to 1 if and only if ~he system user has ~elected that device as the System Controller te.g., by means, of a switch on the device console); (4) a Retransmit Service Requ~est latch (which will be discussed below~ is cleared; and ~5) an ORE (Output Regis~er) ~mpty bit (which will also be discussed below) is set high.

The response of an interface chip to an input frame is d.ictated primarily by the status of the bits in registers R0 and R1. The status of these bi~s causes the chip to automatically decode most subsequent frames so that only those frames which affect a device are routed ~o the CPU, while other 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 frame, counter 27 is incremented by 1.
~ultiplexer 25 is controlled i~ respo~se to counter 27 so that successive bits of a serial input frame are loaded successively into the 11 bits of input buffer 26. When the 11th bit ~Dl) of the input frame has ~een loaded into buffer 26, a signal IPT 11 is ~ent from counter 27 to an ~cceptor P~A 216 to inform PLA 216 ~hat loading of the frame into buffer 26 is complete.

The existence of input buffer 26 in addition ~o an input regis~er 217 enables a second frame to be entered into the interface ~6~7~

(iOe., 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 IDY or IFC is asynchronously sourced by the active Con~roller or System Contr~ller, respectively, while another frame is on the loop.

When the frame in input register 217 has been processed, gates are opened which allow the conten~s of input buffer 26 to ~e copied into input register 217. lf the previous frame has been processed before a new frame arrives (as 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 ~he three command bits have been entered into buffer 26. Further decoding by frame decoder 219 begins as soon as frames are being loaded into input register 217. Because only the first bit C3 of a DOE 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 to PLA 216 to enable the chip ~o 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; (2) the frame is automatically retransmi~ted using multiplexer 220 and will also be loaded into the first 3 bits of regis~er Rl~ and into the 8 bits of register R2~; or (3) the frame is loaded into regis~ers ~lR and R2R without retransmission.

~ 31 -ll9G9'71~
In addition to the above 3 responses, if ~he interface has souced a frame which has not previously returned, the intexface will asume that the received frame is that frame and will error check ~he received frame. To enable sourced frames to be error checked, a copy of the previously sourced frame is retained in output register 20 (i.e., the first 3 bits of register RlW and the ~ bits of register RZW) un~il after the error check. To accomplish the error check, an output pointer counter is incremented through an 11 bit range and its contents are simultaneously fed to multipl~xers 220 and 2~1 to strobe corresponding data from ~hese 2 multiplexers into each of the inputs of an exclusive or gate 222. If ~he two frames 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 ~Eor the CPU to read, either interrupt FRAV or interrupt FRNS is se~ to inform 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 de-~ected an error then F~NS
is set instead of FRAV.

The interface chip includes an address register 212 in which the address of ~he device is stored. The existence of the device addressed allows command frames to be coded so that only selected devices will respond to ~hese command fr~nesO ~his is accomplished ky dedicating sQme of ~he bi~s in such command frames to indieate the address of the d~vice ~hat is to ~.espond to the command. An address compara~or 224 is connected ~o input regis~er 217 and - 32 ~

~69~
to address register 224 to enable the comparison of the command address with the device address.

A transmit encoder 225 is connected to an output multiplexer 226 to select between ~hree alternative 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 checked. The second source is multiplexer 220 which is used for automatic retransmission of certain received frames.
The third source is output register 210 into which a frame 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 frame is retransmitted the frame can be altered to indicate the need for service by tha~ device. If Send Ser~ice 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 naed for ~ervice. If ~he frame is an IDY and the device has been configured for parallel polling, the XDY bit with which tha~ device is associated is set to indicate the need for service.

The interface chip includes a pa:rallel poll regis~er 211 to control the response of a device for purposes of a par~llel poll. The IDY frame is u~ilized to execute a parallel poll. The IDY message is sourced by the active Controller and can be sent ~196~d~

to check for loop integrity 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 r~turn. ORAV is set to signal the completion of the handshalce. If an "error" is detected because one of the IDY
bits has been changed by a device on the loop to signal the need for service, FRNS is ~et 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 cormected to the transmit encoder ~25 to enable the SRQ and pa.rallel poll bits to be set on the fly as a frame is transmitted. R gister 211 regulates the response of the interface for purposes of parallel polls.
2~ The interface will respond ~o a parallel poll only if PPIS~ (Parallel Poll Individual Status) and PPEN (Parallel Poll Enable3 are both set. If either of ~hese bits is not set then the interface will not alter any of the IDY messages. P~IST is set and cleared by khe CPU to indicate whether the device needs service and PPEN
is set and cleared in response to commands from the active Controller to indicate whether the con~roller wants the device to take part in a parallel poll. The use of PPEN enables ~he active Controller 6~
to enable and disable devices from the parallel poll response so that for example several devices can be associated with a given IDY data bit but only one ox a few of ~hem are presently enabl~d to respond on the bit.

Bits P3, P2 and Pl represent the ~inary value of the IDY
data bit on which this interface is to respond. PPSENSE (Parallel Poll Sense) controls the nature of the response. If the interface is set to respond on the n-th bit Dn of the IDY frame then the response is Dn~out) = Dn(in) ~ (PPIST ~ PPSENSE)PPEN where ~
represents exclusive or (namely, A 0 B = 1 if and only if A = B).
The effect of this response scheme is that when PPSENSE is low, then if Dn is sent as a zero by the active Controller, it will return as a zero only if all of the devices enabled to respond on Dn require 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 the devices enabled to respond on Dn require service~ The active Controller can mask the parallel poll response on any given data bit by transmitting that bit as a one. Since ~his bit will return as a 1 regardlesc, of the status of the bits in parallel poll registex 211, no information will be transferred on this bit.

The other two bits in the parallel poll regis~er 211 are t involved in parallel poll. The O~ tOutput Register Empty) bit is used to indicate when register R2W i5 empty to avoid writing a successive frame into that register before ~he transmission 6~
of a pre~ious frame is complete. This bit is cleared when a frame is l~aded into R2W and is set when all 11 bits have been transmitted.
Bit RERR is only set high when a sync bit is received in the middle of a frame thereby indieating an error in the received fr~me.

Th~ command frames are divided into five groups: UCG (Universal Command Group), TAG (Talker Address Group), LAG (Listener Address Group3, SCG lSeco~dary Address Group~ and ACG [Addressed Command lD Group~. The bit pattern identifying t.hese groups is shown in Table 2:

D8 D7 D6 D5 D4 D3 D2 Di UCG x O O 1 x x x x SCG x 1 1 x x x x x TAG ~ 1 0 ADR4 ADR3 ADR2 AD~1 ADRO

ACG x O OO x . x x x (x's are "donlt cares" for decod:ing and are used to encode different messages within each group) Table 2 2() The universal cosnmands and secondary commands are those commands which are of interest to all device~ and therefore ~h y are always nade available to the CPU by se~ting :FRAV (or FRNS~ and loading a received universal command into register RlR/~2~. The Talker address commands ~re used to set the selected Talker into the Talker active s~ate. In this command, data ~its Dl-D5 contain the address of the device which is to become the Talker. ~ddress comparator 224 c~mpares these bits with bits Dl-D5 in Address register 212. When the addresses match, that device is set into Talker active state by se~ting the TA bit. Since only one device on the loop is allowed ~o be Talker active at one time, all devices ior which these addresses aren't equal, clear the T~ bit.

In a similar manner, bits D1-D5 in the Listener address command contain ~he 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 thi!; address do not respond in the manner a~alogons 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 15 and/or Talker active. Conversely, all command frames other ~han the IFC frame are made available to the CPU of devices ~ith TA
or LA set. The IFC is not made available to the CPU because it is decoded by the chip. Only those co~mmands discussed above which æe of in~erest to ~he device are made available to the CPU. When ~0 an IDY frame is received, it can be identified by decoder 218 after 2 bits haYe been received. An IDY frame is automatically retransmitted by al~ devices o~her ~han the active Con~rollerO

When a command is recei~ed, decoder 218 can detect t~is after

3 bits have been received so that the atuomatic re~ransmission c:an begin after three bits have been loaded into buffer 26 or loading of ~he frame has begun into register 217, whichever of these events occurs last.

When a DOE frame is received, it can be identified after the first bit has been received. In devicés wnich are not Talker or ~istener active, the frame is promptly retransmitted -- this avoids delaying passage around the loop by devices which are uninterested in data messages. In act.ive Listeners, the DOE frame is made available to the CPU. In the active Talker, the DOE frame is error checked since the Talker is the source of data frames~

The Ready (RDY) frames are divided into two groups: the ~FC frame and the other RDY frames. The RFC frame is issued automatically by the active Controller's chip when the previously issued command returns and error checks OK. Each device's chip decodes the RFC frame completely and, when its CPU indicates (via SLRDY) tha~ the command has been understood, retransmits it.

The address ready group frames are those RDY frames of interest to addressed devices (i.e., ~he active Talker, Controller and Listeners). In such ac~ive devices, the ARG frame is made availahle to the CPU. ~n ARG frame is retransmitted by writing it from the CPU to th~ output register RlW/R2W. The Address Ready Group includes ~he Start of Transmission (SOT) frames, the End of Transmission OK (ETO~ frame, the End of Tra~smission with Error iETE) frame and the Not Ready for Data ~N~D~ frame.

The SOT frames are used -to ini~iate da~a transmission. After the Tal~er and I,isteners have been designated via commands, the Controller sends the SOT frame. When the SOT frame is received by an active Talker or Listener, the SOT frame is made available to the CPUO When a Talker's CPU decodes the SOT fra~e, instead of retransmitting it, the Talker transmits its flrst DO~ ~rame by writing it to RlW/R2W. Each DO~ fr2~e is automatically error checked upon return to the Talker. When the Talker is finished, it sources ~via a write to RlW/R2W) the ETO frame if no errors were detected or ETE if errors were de1:ected during the transfer of Data. Upon receiving the ETO or ET~ frame, the Controller's chip sets FRAV allowing its CPU to determine when the Talker is done~ Because the appropriate response to the occurrence of an error in transmission will vary depending on a number 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 Da~a. When such interrupting is desired by the Controller, the Controller will store the next ~ata frame it receives and replace it with an NRD frameO When th,e 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 copy o~ the frame presen in its out:put register 210 liOe~, the previDus Data frame it transmitted~, ~;he Talker retransmits the NRD lvia a write to RlW/R2W) to pass 1:he N~D back to the C~ntroller.
Up~n receiving the NRD the Controller transmits the Da~a rame t~at it stored to enable Listener~ be~tween ~he Controller and ~L9G9~
Talker to receive it. Upon receiving t.his Data frame the Talker performs its usual error check. However, since that last ~rame ~ransmitted by the Talker was the NRD, the Talker will detect an error and set both FRNS and ORAV. The CPU responds to these ~ignals by checking the received data i.rame with the copy which it saved before transmission of the N~).

The device address stoxed 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 ~ype.
In a second approach the address can be set in response to user input such a~ 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 bi~s which contain the address 1 upon ~ransmission by the Controller~ At each device other than the Controller, the device makes the message available to its ~PU. Th~ CPU sets the address in register ~12 equal to the address in this message, and then increases ~he address in the message before retransmitting the message to the next device in ~he 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 edg~ detector. This enables a Controller to ~.urn - ~0 -off virtually all loop activity to conserve energy. This is particularly useful in battery operated devices. The edge detector enables all devices to be powered up in response to any signal transmitted around the loop. The interfacé also contains a Retransmit A11 input which turns the interface into a simple repeater when this line is pulled high. In this state, all frames are automatically re~ransmitted without: any other action by the device. This capability enables a device to ~e effectively removed from the l~op (e.g., when ~he device i~; malfunctioning), without physically breaking the loop to remove the device. This avoids the inconvenience of having to reconfigure the loop and also avoids possibly 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 this 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 register, ~ikewise ~he capability of a device ~e.g., whether it's a printer, plottPr, etc.) can be stored in the CPU on in a dedica~ed register. Typically, the capahility and identity will be ~tored as 8 bits of data which can be transferred as the data bits of a Data fram~O This sch~e therefore allows 2 8 different identities and capabiliti s to be coded. Typically~ a range of codes will be assigned ~o a particular class of devices ~e.g.,

- 4~ -plotters) so that each class can be di~ided into as many subclasses as there are codes in its associated r,~nge of codes.

These capabilities not only let t'he user request such information from loop devices, it also enables the use of friendly programming commands. For example if the user desires to plot data measured by a voltmeter, the user need not ~now the printer or voltmeter in the loop. Instead, the user can simply command that the data being measured say by the Model ~P-3468A vol~meter 1~ be printed on the Model HP-82162A printer. 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 int:o Talker acti~e state and the printer into Listener active state.

The serial poll is execu~ed as follows. Beginning a~ a selected point in the loop ~which by default c~n be chosen as the device at address 1) ~he Controller sets tha~t device into Talker ac~ive state and then sends it a Ready message which tells it the type of data to send and that it is to start sending now. These Ready frames are analogons to ~he Start Transmission frames which initiate Da~a transfr. Two examples of these Ready ~rames are ~he Send Identity and Send Capability frames which initiate the ~ransfer of ~he device id~ntity and capability respectively. ~hen a Send Identity frame is received by the device whose identity is being requested, that device replaces that frame with a ~ata frame containing its identity. When this frame rea~hes 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., the 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 analogons series of steps occur for a Send Capability Ready frame.

In a sLmilar manner, control can be passed from the active Controller to another Controller in the Loop. The active Controller first sends a Talk Address command ~o set the other Con~roller into Talker active state and then send-; a Take Control ready frame.
Upon sourcing the Take Control ready f~.ame, the active Controller clears its CA bit. Upon reception of l~his frame the other Controller sets its CA ~it and takes over control of the loop.

~0 - ~3 -

Claims (35)

Claims

1. A process of transferring message frames in a linear interface of the type in which at least one receiver is connected to a source in a linear configuration, in which the source has an output port connected to an input port of a first receiver, in which any other receivers each has an input port connected to an output port of a preceeding receiver in the configuration so that message frames pass from the source along the linear interface to a last receiver, said process comprising the steps of:
transmitting a message frame from the source to the first receiver;
each receiver other than the last: one passing the message frame on to its succeeding receiver in the linear configuration;
when the first receiver is ready to accept another message frame, transmitting a Ready signal in the direction from the first receiver toward the last receiver;
at each receiver other than the first and last ones, when that receiver is ready to accept another message frame and has also received a Ready signal from the preceding receiver in the linear configuration, transmitting a ready signal to its succeeding receiver in the linear configuration; and controlling the source to transmit a succeeding message frame only if the last receiver has received a Ready signal and is ready itself to receive another message frame, thereby transmitting said succeeding message frame only when all receivers are ready o accept another message frame.

2. A process as in claim 1 wherein the message frames include a first type which is typically of interest only to a small number of receivers, said process further comprising the steps of:
testing the message frame upon reception by each receiver to determine whether it is of the first type; and if it is, then performing the steps of passing it on only when said receiver is ready to accept another message frame whereby the first type of message frame itself is the Ready signal for each receiver.

3. A process as in claim 2 wherein at least one receiver can assume a listener active state or a listener inactive state, wherein receivers in the listener active state respond to each message frame of the first type before performing the step of passing it on and wherein receivers in the listener inactive state promptly perform the step of passing the message frame on upon reception without responding to it.

4. A process as recited in claim 1 wherein the types of message frames include a second type which is typically of interest to a greater number of receivers than the first type of message frame, said process further comprising the steps of:
testing the message frame upon reception by each receiver to determine whether the message frame is of the second type; and if it is, then saving a copy of the message frame and promptly performing the step of passing it on.

3. A process as in claim 4 further comprising, after the step of transmitting a second type of message frame from the source, the step of transmitting a Ready signal from the source to the first receiver, said first receiver transmitting a Ready signal only when it is ready for another message frame and has received the Ready signal transmitted by the source.

6. A process as recited in claim 1 wherein message frames and receivers can be assigned addresses, said process further comprising the step of:
each receiver comparing the address of a message frame to its own address; and responding to the message frame only if there is a match between these addresses.

7. A process as in claim 6 wherein addresses are assigned to the receivers by the steps of:
transmitting an Auto Address message frame from the source, said Auto Address message frame containing an address and each receiver other than the last:
upon reception of the Auto Address message frame and in response to the address in said Auto Address message frame, assigning to said receiver an address to which it will respond;
incrementing the address in the Auto Address message frame;
transmitting the incremented Auto Address message frame to the succeding receiver in the configuration; and upon reception of the incremented Auto Address message frame by the last receiver and in response to the address in said Auto Address message frame assigning to the last receiver an address to which it will respond.

8. A process as in claim 6 wherein the message frames include a universal type of message frame to which all receivers respond regardless of the address or state of each receiver.

9. A process as in claim 8 wherein each receiver can assume a listener active state or a listener inactive state, wherein receivers in the listener active state respond to each message frame of the first type before performing the step of retransmitting it and wherein receivers in the listener inactive state promptly perform the step of retransmitting each message frame of the first type upon reception without responding to it, said process further comprising the steps of:
passing from the source to all of the receivers an Unlisten universal message frame to which each receiver responds by entering the listener inactive state;
passing from the source to all of the receivers at least one listen addressed message frame to which only those receivers having their address matching the address of at least one of these message frames respond by entering the listener active state.

10. A process as in claim 6 wherein at least one receiver can assume a talker active state or a talker inactive state wherein receivers in a talker inactive state do not function as a source for message frames and a receiver in the talker active stave can function as a source of message frames, said process further comprising the steps of:
passing from the source to all of the receivers a Talker addressed message frame to which only the receiver whose address matches the address of this message frame responds by entering the talker active state;
transmitting from the source a Start of Transmission message frame to inform the receiver which has just entered the talker active state that it is to take over as the source of message frames, the source also entering the talker inactive state;
each receiver which receives the Start of Transmission message frame and is in a Talker inactive state, retransmitting the Start of Transmission message frame to pass the Start of Transmission message frame to its succeeding receiver in the configuration;
the receiver which is in the Talker active state, responding to the Start of Transmission message frame by taking over the role as the source of message frames.

11. A process as in claim 10 wherein at least one receiver can assume a controller active state or a controller inactive state, wherein receivers in a controller inactive state do not function as a source of command message frames and wherein a receiver in the talker active state can function as a source of command message frames, said process further comprising the steps of:
passing from the source to all of the receivers a Talk addressed message frame to which only the receiver whose address matches the address of this message frame responds by entering a talker active state;
transmitting from the source a Take Control ready message frame to inform the receiver which has just entered the talker active state that it is to enter the controller active state and take over as the source of message frames;
each receiver which receives the Take Control ready message frame and is in a talker inactive state, retransmitting the Take Control ready message frame to pass it to its succeeding receiver in the configuration;
the receiver which is in the talker active state, responding to the Take Control ready message frame by entering the controller active state and taking over as the source of message frames.

12. A process as in claim 11 wherein a different receiver is in the controller active state than is in the talker active state and in which the talker active receiver is functioning as the source of message frames, said process further comprising the steps of:
after transmission of all of the data message frames to be transmitted by the talker active receiver, transmitting an End of Transmission message frame from the talker active receiver to inform the controller active receiver that data transmission has been completed and the controller active receiver is to resume the function as the source of message frames;
each receiver other than the controller, retransmitting the End of Transmission message frame to pass it on to the controller active receiver; and the controller active receiver in response to the End of Transmission message frame, resuming the function as the source of message frames.

13. A process as in claim 11 wherein a different receiver is in the controller active state than is in the talker active state and in which the talker active receiver is functioning as the source of message frames, said process further comprising the steps of:
when the controller active receiver wants to take back the function of being the source of message frames, then upon receipt of the next message frame from the talker active receiver, temporarily saving that message frame and in its place transmitting a Not Ready For Data message frame;
passing the Not Ready For Data message frame to the talker active receiver to inform it that it is to cease initiating message frames;
passing the Not Ready For Data message frame from the talker active receiver on to the controller active receiver;
passing from the controller active receiver to the talker active receiver the message frame which was temporarily saved;
transmitting from the talker active receiver an End of Transmission message frame and passing it along the configuration to the controller active receiver to inform the controller active receiver that it is to assume the function of initiating message frames; and in response to the End of Transmission message frame, the controller active receiver assuming the function of being the source of message frames.

14. A process as in claim 1 further comprising the steps of:
at system configuration, setting one of the devices in the configuration into a system controller state in which, even when it is not functioning as the source of message frames, it can initiate a special message frame called an Interface Clear message frame to retake control of the loop;
when the system controller active device is not the source of message frames and wants to retake control of the loop, transmitting an Interface Clear message frame;
each receiver other than the system controller, assuming an inactive state in which it will not function as the source of message frames and then passing the Interface Clear message frame on to its succeeding receiver in the loop so that it can pass around the loop to the system controller; and upon reception of the Interface Clear message frame by the system controller, setting that device into an active state in which it serves as the source of message frames.

15. A process of transferring message frames in a loop interface of the type in which a plurality of receivers are connected to a source in a loop configuration, in which the source and all of the receivers each have an input port connected to an output port of a preceding device in the loop so that message frames transmitted by the source are passed around the loop to the source, said process comprising the steps of:
transmitting a message frame from the source;
each receiver passing the message frame on to its succeeding device in the loop;
transmitting from the source a Ready signal;
at each receiver, when that receiver is ready to accept another message frame and has also received a Ready signal from the preceding receiver in the linear configuration, transmitting a Ready signal to its succeeding device in the linear configuration; and controlling the source to transmit a succeeding message frame only after it receives the Ready signal, thereby transmitting succeeding message frames only when all of the receivers on the loop are ready to receive another message frame.

16. A process as in claim 15 wherein the message frames include a first type which is typically of interest only to a small number of receivers, said process further comprising the steps of:
testing the message frame upon reception by each receiver to determine whether it is of the first type; and if it is, then performing the step of passing it on only when said receiver is ready to accept another message frame whereby the first type of message frame itself is the Ready signal for each receiver.

17. A process as in claim 15 wherein at least one receiver can assume a listener active state or a listener inactive state, wherein receivers in the listener active state respond to each message frame of the first type before performing the step of passing it on and wherein receivers in the listener inactive state promptly perform the step of passing the message frame on upon reception without responding to it.

18. A process as recited in claim 15 wherein the types of message frames include a second type which is typically of interest to a greater number of receivers than the first type of message frame, said process further comprising the steps of:
testing the message frame upon reception by each receiver to determine whether the message frame is of the second type, and if it is, then saving a copy of the message frame and promptly performing the step of passing it on.

19. A process as in claim 18 wherein, when the message frame transmitted by the source is of the second type, then the Ready signal is transmitted by the source only after receiving the message frame back at the source.

20. A process as recited in claim 15 wherein message frames and receivers can be assigned addresses, said process further comprising the step of:
each receiver comparing the address of a message frame to its own address; and responding to the message frame only if there is a match between these addresses.

21 . A process as in claim 20 wherein addresses are assigned to the receivers by the steps of:
transmitting an Auto Address message frame from the source, said Auto Address message frame containing an address and each receiver:
upon reception of the Auto Address message frame and in response to the address in said Auto Address message frame, assigning to said receiver an address to which it will respond;
incrementing the address in the Auto Address message frame; and transmitting the incremented Auto Address message frame to the succeeding device in the loop.

22. A process as in claim 20 wherein the message frames include a universal type of message frame to which all receivers respond regardless of the address or state of each receiver.

23. A process as in claim 22 wherein each receiver can assume a listener active state or a listener inactive state, wherein receivers in the listener active state respond to each message frame of the first type before performing the step of retransmitting it and wherein receivers in the listener inactive state promptly perform the step of retransmitting each message frame of the first type upon reception without responding to it, said process further comprising the steps of:
passing from the source to all of the receivers an Unlisten universal message frame to which each receiver responds by entering the listener inactive state;
passing from the source to all of the receivers at least one Listen addressed message frame to which only those receivers having their address matching the address of at least one of these message frames respond by entering the listener active state.

24. A process as in claim 20 wherein at least one receiver can assume a talker active state or a talker inactive state, wherein receivers in a talker inactive state do not function as a source for message frames and wherein a receiver in the talker active state can function as a source of message frames, said process further comprising the steps of:
passing from the source to all of the receivers a Talk addressed message frame to which only the receiver whose address matches the address of this message frame responds by entering the talker active state;
transmitting from the source a Start of Transmission message frame to inform the receiver which has just entered the talker active state that it is to take over as the source of message frames, the source also entering the talker inactive state;
each receiver which receives the Start of Transmission message frame and is in a talker inactive state, retransmitting the Start of Transmission message frame to pass the Start of Transmission message frame to its succeeding receiver in the configuration;
the receiver which is in the talker active state, responding to the Start of Transmission message frame by taking over the role as the source of message frames.

25. A process as in claim 24 wherein at least one receiver can assume a controller active state or a controller inactive state, wherein receivers in a controller inactive state do not function as a source of command message frames and wherein a receiver in the talker active state can function as a source of command message frames, said process further comprising the steps of:

passing from the source to all of the receivers a Talk addressed message frame to which only the receiver whose address matches the address of this message frame responds by entering a talker active state;
transmitting from the source a Take Control ready message frame to inform the receiver which has just entered the talker active state that it is to enter the controller active state and take over as the source of message frames;
each receiver which receives the Take Control ready message frame and is in a talker inactive state, retransmitting the Take Control ready message frame to pass it to its succeeding device in the configuration;
the receiver which is in the talker active state, responding to the Take Control ready message frame by entering the controller active state and taking over as the source of message frames.

26. A process as in claim 25 wherein a different receiver is in the controller active state than is in the talker active state and in which the talker active receiver is functioning as the source of message frames, said process further comprising the steps of:
after transmission of all of the data message frames to be transmitted by the talker active receiver, transmitting an End of Transmission message frame from the talker active receiver to inform the controller active receiver that data transmission has been completed and the controller active receiver is to resume the function as the source of message frames;
each receiver other than the controller, retransmitting the End of Transmission message frame to pass it on to the controller active receiver; and the controller active receiver in response to the End of Transmission message frame, resuming the function as the source of message frames.

27. A process as in claim 25 wherein a different receiver is in the controller active state than is in the talker active state and in which the talker active receiver is functioning as the source of message frames, said process further comprising the steps of:
when the controller active receiver wants to take back the function of being the source of message frames, then upon receipt of the next message frame from the talker active receiver, temporarily saving that message frame and in its place transmitting a Not Ready For Data message frame;
passing the Not Ready for Data message frame to the talker active receiver to inform it that it is to cease initiating message frames;
passing the Not Ready For Data message frame from the talker active receiver on to the controller active receiver;
passing from the controller active receiver to the talker active receiver the message frame which was temporarily saved;
transmitting from the talker active receiver an End of Transmission message frame and passing it around the loop to the controller active receiver to inform the controller active receiver that it is to assume the function of initiating message frames; and in response to the End of Transmission message frame, the controller active receiver assuming the function of being the source of message frames.

28. A process as in claim 15 further comprising the steps of:
at system configuration, setting one of the devices in the configuration into a system controller state in which even when it is not functioning as the source of message frames, it can initiate a special message frame called an Interface Clear message frame to retake control of the loop;
when the system controller active device is not the source of message frames and wants to retake control of the loop, transmitting an Interface Clear message frame;
each receiver other than the system controller, assuming an inactive state in which it will not function as the source of message frames and then passing the Interface Clear message frame on to its succeeding receiver in the loop so that it can pass around the loop to the system controller; and upon reception of the Interface Clear message frame by the system controller, setting that device into an active state in which it serves as the source of message frames.

29. A process as recited in claim 15 wherein the message frame is an Identify message frame which requires no response by any of the devices other than retransmission to the next receiver in the loop; said process further comprising the step of:
testing the message frame upon reception by each receiver to determine if it is the Identify message frame and if it is then immediately performing the step of retransmitting it thereby enabling the source to rapidly determine whether the loop is intact by rapidly passing the Identify message frame around the loop.

30. A process as in claim 28 wherein the Identify message frame has a set of parallel poll bits each of which can be set to its complementary value without changing the status of the message frame as an Identify message frame, said process further comprising the steps of:
before transmitting the Identify message frame from the source, assigning each receiver in a set of selected receivers to an associated one of said parallel poll bits;
upon reception of the Identify message frame by any receiver which has been assigned to a bit and also requires servicing, setting its associated bit to the value which is complementary to the initial value at the time of transmission by the source; and upon reception of the Identify message frame by the source, determining which parallel poll bits have been altered whereby the source determines if any device servicing is requested and in addition determines that the devices requiring service are within the set of devices associated with those bits which have been altered.

31. A process as in claim 15 further comprising the steps of:
keeping in the source a temporary copy of a message frame transmitted by the source; and upon receipt of the message frame by the source, comparing with this copy the next message frame received by the source and if this next message frame is not identical to the copy, then producing an error indication.

32. A process as recited in claim 15 wherein one of the receivers is in a controller active state in which it is responsible for controlling the operation of the loop and wherein a service request bit in a message frame can be altered by a receiver requiring service to signal the controller active device that it requires service, said process further comprising the steps of:
in any receiver needing service, before retransmitting a message frame to pass it on, altering the service request bit;
and checking the service request bit by the controller active receiver to see if any other receivers require service.

33. A process as in claim 15 wherein the message frames are transmitted in a bit serial format in which each message frame comprises a consecutive sequence of bits the first of which is a specially coded sync bit which indicates the start of a message frame.

34. A device having a power down mode, said device comprising:
an input port for receiving input signals;
power up means connected to the input port and responsive to the input of a message frame for powering up any device activities other than the power up means, said other device activities being turned off in the power down mode to reduce power consumption.

35. A device as in claim 34 wherein the device is responsive to a power down input message to enter the power down mode.