WO1996006398A1

WO1996006398A1 - Method and apparatus for high-speed communication between computer and peripherals

Info

Publication number: WO1996006398A1
Application number: PCT/US1995/010537
Authority: WO
Inventors: Denis R. Coleman; John S. Forker; Diego Escobar
Original assignee: Visioneer, Inc.
Priority date: 1994-08-19
Filing date: 1995-08-18
Publication date: 1996-02-29
Also published as: AU3492095A

Abstract

High-speed communication between a computer and a peripheral device using low-speed serial and parallel interfaces is achieved by a protocol which sends and receives information through data input, data output, control and status circuits. Extremely high-speed communication using conventional RS-232 serial ports and parallel printer ports is made possible. Communication circuit status may also be interrogated by a device to allow automatic reconfiguration to various serial and parallel communication channels.

Description

DESCRIPTION

METHOD AND APPARATUS FOR HIGH-SPEED COMMUNICATION BETWEEN COMPUTER AND PERIPHERALS

Technical Field The present invention relates generally to a method and apparatus for data communication. In particular, the present invention relates to sending and receiving digital data between a computer and a peripheral device using either a conventional serial port or a conventional parallel port, wherein digital data may be sent or received at high-speed.

Background Art Many applications which incorporate images, digital audio, digital video, or multimedia, use large volumes of data which are either generated or stored by peripheral devices. It is common for such applications to require hundreds of megabytes of data which must be transferred from a peripheral device to a computer. Some examples of these peripheral devices include image scanners, digital signal processors and so called CD ROM drives. In many situations, these peripheral devices operate outside the enclosure of a so called personal computer. Preferably, it should be possible to connect these devices to the computer without removing the computer enclosure, but this implies that any required communication interface must be installed previously with connection points accessible outside the enclosure.

The terms "interface" and "port" are used herein in a manner generally consistent with commonly understood meanings; however, these meanings are not precise. The term "port" generally refers to hardware and the term "interface" generally encompasses both hardware and communication protocols. The term "interface" may also refer to functions performed by hardware, and either term may also extend to devices such as memory-mapped input/output portals, micro-processor controlled circuits and ROM-based software (sometimes called "firmware") which are difficult to classify. The context of the usage helps make the meaning clear.

Many personal computers have such interfaces in the form of two or more serial -communication interfaces, referred to herein as serial interfaces, which are used with equipment such as a modem, a mouse or a serial plotter, and one or more parallel-communication interfaces, referred to herein as parallel interfaces, which are often used with printers. Each type of interface usually has a connection point accessible outside the enclosure in the form of a socket. A peripheral device can be easily connected with a cable having an appropriate plug inserted into the socket, but generally only certain types of interfaces are acceptable because devices intended to operate with one type of interface do not operate properly with another type of interface.

The parallel interfaces usually found in personal computers substantially comply with the so called Centronics parallel-printer standard, or with a variant of this standard. The variant utilized in many IBM^® PC-compatible computers is referred to herein as the PC-Parallel Printer standard. These interfaces are intended for transferring data from a computer to a printer. They are not designed to transfer data from a peripheral device to a computer. The serial interfaces usually found in personal computers substantially comply with a IEEE RS-232 standard and are intended to receive and send data; however, the rate at which they can transfer data is generally too low for the large volumes of data discussed above. A few examples should help illustrate this situation.

Many scanners generate image representations having a resolution of 200 picture elements or "pixels" per inch or 40,000 (40 k) pixels per square inch. A representation of an 8" by 10" image comprises 3.2 million (3.2 M) pixels. In a black and white representation, each pixel can be represented by one bit; therefore, a black and white representation of the 8" x 10" image comprises 3.2 M bits or 400 k bytes. In a 256-leveI grey-scale representation, eight bits are required to represent each pixel; therefore, 25.6 M bits or 3.2 M bytes are required to represent the image. Scanners generate considerably larger volumes of data for color images, particularly for high-quality color images with fine resolutions and many color levels. Many audio signal processors sample audio signals at a rate as high as 44, 100 times per second.

At that rate, a processor generates 441 k samples for ten second audio signal. If sixteen bits are used per sample, nearly 7.1 M bits or 880 k bytes is required to represent a ten second signal. If multiple channels are processed, the volume of data increases proportionally.

Many applications comprise files representing type fonts, databases or hyper-text, for example, which contain hundreds of megabytes of data and are often accessed using high-capacity devices such as CD ROM drives. These applications can require transferring all or major portions of these files from the drive to the computer.

Data compression or redundancy-reduction techniques can be used to reduce the volume of data which must be transferred but, even with the use of such techniques, the volume of data which must be transferred can be considerable.

Many computer applications are either impractical or much less useful because considerable time is required to transfer such large volumes of data. The time can be reduced by increasing the transmission rate, but this requires an increase in communication channel bandwidth.

The bandwidth of a communication channel may be increased by increasing the transmission signalling rate and/or by increasing the number of transmission paths in the channel. An increase in signalling rate increases the number of bits which can be sent along one path in given period of time. An increase in the number of paths increases the number of bits which can be sent along a channel at one time.

Serial channels can transfer one bit at a time and parallel channels can transfer a plurality of bits at a time. In principle, there is no limit to the number of parallel paths which can be used but many practical devices, such as those complying with the Centronics standard, implement a parallel channel capable of transferring eight bits or one byte at a time. Other paths in addition to those used to carry data are generally present to transfer control and status information.

T e RS-232 serial interfaces found in many personal computers today receive and send data at a maximum signalling rate on the order of 115 k bits per second (bps). A common asynchronous transmission protocol uses one start bit and one stop bit to frame each eight data bits; therefore, such a channel and protocol can transfer approximately 11.5 k bytes per second. The time required by a 115 k bps serial channel to transfer the 3.2 M byte grey-scale image of a single page is nearly five minutes.

The Centronics parallel-channel interfaces potentially offer higher bandwidth channels, but these interfaces are usually intended only for transferring data from a computer to a peripheral such as a printer and do not readily support high-volume data transfer to a computer.

One known technique, disclosed in U.S. patents 5,261,060 and 5,293,497, which are incoφorated by reference in their entirety, achieves two-way communication with a conventional parallel -channel interface by transmitting data along paths normally used for transferring control and status information. This technique provides higher-bandwidth two-way communication along four or optionally eight parallel paths but it provides no solution for computers having only serial interfaces available for use. In addition, despite the increase in bandwidth, existing protocols transfer data at a rate which is not as high as is desired.

Interfaces complying with other standards are available in some personal computers. Examples of these standards include the Small Computer Systems Interface (SCSI) standard and the IEEE RS-422 standard. SCSI interfaces are often used with information storage devices and RS-422 interfaces are often used with scientific instruments; however, these types of interfaces are not as widely used as the more common serial and parallel interfaces discussed above.

What is needed is a method and apparatus which provide high-bandwidth communication using commonly available serial and parallel interfaces, use a given bandwidth more effectively to transfer data at even higher speeds, and allow a peripheral device to operate with a wide variety of interfaces.

Summary of Invention

It is an object of the present invention to provide for a method and apparatus which achieve high-bandwidth communication from a peripheral device to a computer using either a serial- or a parallel-channel interface.

An advantage of the present invention is a protocol which can utilize channel bandwidth more effectively.

Another advantage of the present invention is a method and apparatus which allows a peripheral device to operate with a wide variety of interfaces. Other objects and advantages of the present invention are set forth throughout this disclosure. In accordance with the teachings of one aspect of the present invention, data is transferred from output circuits of a communication interface in one device through a multi-path communication channel to status circuits of a serial-communication interface in another device.

In accordance with the teachings of another aspect of the present invention, data is transferred from control circuits of a communication interface in a first device through a multi-path communication channel to input circuits of a communication interface in a second device, and data is transferred from output circuits of the communication interface in the second device through a multi-path communication channel to status circuits of the communication interface in the first device.

In accordance with the teachings of a further aspect of the present invention, data is transferred from output circuits of a communication interface in one device through a multi-path communication channel to four status circuits of a serial-communication interface in another device.

In accordance with the teachings of yet a further aspect of the present invention, data, status and requests are transferred from two or more control circuits of a communication interface in a first device through a multi-path communication channel to input circuits of a communication interface in a second device, and data, status and requests are transferred from output circuits of the communication interface in the second device through a multi-path communication channel to four or more status circuits of the communication interface in the first device. The first device transfers data in response to a request received from the second device and the second device transfers data in response to request or status information received from the first device. In accordance with the teachings of yet another aspect of the present invention, a first device negotiates an optimum signalling rate by asserting a request and waiting an interval of time after asserting the request before receiving data through a communication channel from a second device and, in response to the request, the second device transmits along the communication channel a sequence of information known to the first device. The first device adjusts a wait-time interval in response to errors detected by comparing the received information with the expected known information. The first device uses a heuristic algorithm to adjust the wait-time interval and/or the signalling rate to balance the tradeoff between transmission rate and error rate.

The present invention may be implemented in many different embodiments. Throughout this disclosure, more particular mention is made of transferring data from a peripheral device, in particular an image scanner, to a personal computer; however, it should be understood that the principles and teachings of the present invention may be applied to transfers of data between various combinations of computers and/or peripheral devices in various directions. Furthermore, it should be understood that the present invention is not restricted to use with personal computers, microcomputers or computers incorporating microprocessors and the like. The various features of the present invention and various embodiments may be better understood by referring to the following discussion and to the accompanying drawings in which like reference numbers refer to like features. The contents of the discussion and the drawings are provided as examples only and should not be understood to represent limitations upon the scope of the present invention.

Brief Description of Drawings

Fig. 1 is a schematic representation of a system comprising a personal computer, an image scanner, and a connecting cable.

Fig. 2 is a functional block diagram of a system comprising two devices and a connecting communication channel.

Figs. 3-4 are functional block diagrams of communication interfaces and a communication channel. Figs. 5-10 are a hypothetical graphical representations of signals for several embodiments incorporating various aspects of the invention.

Figs. 11-12 are functional block diagrams of various components which may be used to adapt communication between devices.

Detailed Description of Invention Introduction

Fig. 1 is a schematic representation of one embodiment of a desktop computer system comprising personal computer 10, image scanner 20 and cable 30. A plug at each end of cable 30 connects to a respective communication interface in personal computer 10 and scanner 20. Various elements such as power connections are omitted from the figure for clarity. Fig. 2 is a functional block diagram of a system such as the one illustrated in Fig. 1, for example. Throughout this discussion, device 10 is generally described as a computer, particularly a so called personal computer, device 20 is generally described as a peripheral device such as an image scanner, CD ROM drive or modem, and communication channel 30 is generally described as a multi- wire cable. It should be understood, however, that no particular device and no particular communication channel is critical to the practice of the present invention. Either device may be any of various types of computers, peripheral devices or other equipment, and the communication channel may be implemented using conventional wires, optical, infrared, radio-frequency or other techniques. It should be pointed out that although communication channel 30 provides what appear to be a plurality of parallel communication paths, its actual implementation may be very different. For example, the channel may comprise a single path and techniques such as frequency-division or time-division multiplexing may be used to simulate a true multi-path channel. The various examples are discussed briefly here only to show that various aspects of the present invention may be incorporated into a wide variety of systems and that no particular embodiment is critical to the practice of the present invention.

Device 10 comprises communication interface 100 and device 20 comprises communication interface 200. These interfaces provide a means whereby other components within the respective devices may interact with communication channel 30. Two types of communication interfaces which are commonly present in many computers are serial-communication interfaces and parallel- communication interfaces.

Serial- and Parallel-Communication Interfaces Many serial -communication interfaces comply with the IEEE RS-232 standard. Many parallel- communication interfaces, to some degree at least, comply with the so called Centronics parallel-printer interface standard. Other de facto standards either supplement or supersede the formal standards. These standards define a number of "circuits," where each circuit appears in a connecting socket or plug, how the circuits are used including timing information, and the signal levels that should be asserted in the circuits.

Table I illustrates several circuits included in the RS-232 standard. These circuits provide communication between "data terminal equipment" (DTE), such as a terminal or computer, and "data communication equipment" (DCE), such as a modem or image scanner. For each circuit shown, the table provides a commonly used abbreviation, pin number for DB-25 and DB-9 sockets (shown in the table as a pair of numbers xly for DB-25 and DB-9, respectively), direction of information flow, and brief explanation of function and circuit type with respect to a DTE.

Name Pin DTE / DCE Function Type

TxD 2/3 Transmit Data data-outpu

RxD 3/2 Receive Data data-input

RTS 4/7 Request To Send control

CTS 5/8 Clear To Send status

DSR 6/6 Data Set Ready status

DCD 8/1 Data Carrier Detect status

DTR 20/4 Data Terminal Ready control

RI 22/9 Ring Indicator status

Table I

Table II illustrates several circuits included in the PC-Parallel Printer standard. These circuits provide communication between a computer (PC) and a printer (PRT). For each circuit shown, the table provides a commonly used abbreviation, pin number for a DB-25 socket, direction of information flow, and brief explanation of function and circuit type with respect to a PC. Name Pin PC / PRT Function Type

Strobe 1 -► Indicate data valid control

Data 1 2 -► Data data-output

Data 2 3 -► Data data-output

Data 3 4 -► Data data-output

Data 4 5 -► Data data-output

Data 5 6 -► Data data-output

Data 6 7 -► Data data-output

Data 7 8 -► Data data-output

Data 8 9 -► Data data-output

Ack 10 Acknowledge status

Busy 11 Printer Busy status

PaperOut 12 Out of Paper status

Select 13 Selected (on-line) status

AutoFdXT 14 Line Fd w/ Car. Ret. control

Fault 15 Printer Fault status

Init 16 Reset Printer control

Selectln 17 Select Printer control

Table II

Not all circuits are shown in the tables. For example, ground and signal return circuits are omitted. Each circuit shown is classified into four types: (1) a data-output circuit for sending data, (2) a data-input circuit for receiving data, (3) a status circuit for receiving information other than data, and (4) a control circuit for sending information other than data. The data-output and control circuits are referred to herein collectively as transmitting or output circuits, and the data-input and status circuits are referred to herein collectively as receiving or input circuits. These classifications are made with respect to the device incorporating the interface. According to these classifications, control information passed by one device is received by another device as status information.

Fig. 3 is a functional block diagram illustrating a typical interconnection of two communication interfaces with a communication channel. Data from a first device incorporating interface 100 is passed along path 11 through data-output 101 along communication path 31 to data-input 202 and received by a second device incorporating interface 200 along path 22. Data from the second device may be transmitted in the reverse direction from path 21 through data-output 201 along communication path 32 through data-input 102 to path 12 in the first device. Some interfaces do not include all circuit types. For example, a parallel-communication interface in a computer which complies with the Centronics standard does not include data-input circuits.

The first device may send control information from path 13 through control 103 along communication path 33 through status 204 to path 24. The control information sent by the first device is received by the second device as status information. In a similar manner, the second device may send control information from path 23 through control 203 along communication path 34 through status 104 to path 14. The control information sent by the second device is received by the first device as status information. Fig. 4 is a functional block diagram illustrating one interconnection of communication interfaces according to various aspects of the present invention. In this interconnection, a second device incorporating communication interface 200 sends data and control information through output 205 along communication path 34 through status 104 to path 14. A first device incoφorating communication interface 100 receives both data and status information from path 14. In a similar manner, the first device sends data and control information through control 103 along communication path 33 through input 206 to path 26. The second device receives data and status information from path 26.

In one embodiment, communication interface 100 substantially complies with the RS-232 serial- communication standard. Data-output 101 including the TxD circuit and data-input 102 including the RxD circuit are not used. Control 103 comprises the RTS and DTR circuits. Status 104 comprises the CTS, DSR, DCD and RI circuits.

In another embodiment, communications interface 100 substantially complies with the PC-Parallel Printer standard. Data-output 101 including Data 1 through Data 8 circuits are not used. Data-input 102 is not present in the interface. Control 103 comprises the Strobe and Init circuits. The AutoFdXT and Selectln circuits may be used instead of or in addition to the Strobe and Init circuits; however, these are not preferred because some interface manufacturers choose not to implement them. Status 104 comprises the Ack, Busy, PaperOut and Select circuits.

In yet another embodiment in which communications interface 100 substantially complies with the PC-Parallel Printer standard, two data circuits, say Data 1 and Data 2, are used rather than the Strobe and Init circuits. This embodiment is preferred in applications in which a device incoφorating aspects of the present invention shares an interface with a conventional printer. Using two data circuits rather than the Strobe and Init circuits provides for more reliable operation with conventional printers. The following discussion generally assumes use of the Strobe and Init circuits; however, it should be understood that two data circuits can be substituted for these two control circuits to facilitate sharing.

Protocols

A. Introduction In one embodiment, a first device is a personal computer "host," preferably a so called IBM* PC-compatible personal computer or a Macintosh* personal computer. These computers are referred to herein as a "PC host" and a "Mac host, " respectively. A second device is an image scanner, referred to herein as a "Pmax." In the specification of this embodiment, various timing and signalling relationships are indicated as being required. These requirements should be understood to pertain only to the embodiment described and do not represent general requirements upon the practice of the present invention.

This specification describes the protocol and the "physical layer" used between Pmax and the host (PC and the Macintosh). Since most of the data moves from Pmax to the host, this specification maximizes the data rate in that direction. When connected to a PC host (either via a serial or parallel port), data is moved to the PC host in parallel in 4-bit nibbles and from the PC host serially. This mode may be used with other interfaces such as SCSI, 8-bit parallel, FireWire^®, etc. When connected to a Macintosh serial port, data is moved serially in both directions at high speed. These differences are preferably handled in the "physical layer" so that they remain transparent to the "logical layer" which deals only in bytes. For example, these differences may be handled by software in the host and by circuitry (such as an ASIC) in Pmax.

As used herein, the term "physical layer" comprises that part of Pmax and a host which conforms to specified signal voltages and timing, and encompasses both the physical components of a communication channel as well as low-level software or firmware that is concerned with the processes of moving information along the communication channel. The term "logical layer" as used herein comprises that part of Pmax and a host which handles the information exchanged between Pmax and the host, is independent of the "physical layer," and is not concerned with the processes of moving information along the channel.

Throughout the discussion of this embodiment, several terms may be understood as explained below. These terms pertain to certain embodiments which are discussed herein as examples only and do not represent any limitations on the scope of the present invention.

A "packet" is a set of one or more bytes that convey either requests or information exchanged between a host and Pmax.

A "header byte" is the first byte of a packet that identifies the meaning of the packet and any data that may follow. Many header bytes constitute the only byte of the packet and indicate either a request for information or a response to a request for information. Examples of packet header byte values are shown below in Tables VI and VII.

A "wakeup packet" is a packet sent by one device to another device requesting that the second device change from an idle state to a ready state, or that the second device perform some function. The header byte of a wakeup packet contains a "wakeup code" indicating the nature of the request. For example, when Pmax detects the insertion of a page to scan, it sends a "Paper inserted" wakeup packet requesting the host to prepare to receive data. A list of wakeup codes is shown below in Table VII.

A "session" is a group of one or more packets beginning with a wakeup packet requesting start of a session and ending with the Ack following either an "end of session" (EOS) packet or a "cancel session, reason not specified" (CAN) packet. Many packets may move between the host and Pmax during a session.

As will be explained below, various operations are performed in sessions which may be initiated by either Pmax or the host. If the host and Pmax both attempt to start a session at the same time, Pmax always yields to the host in preferred embodiments. During a session, after Pmax or the host receives a packet, they respond with a single-byte packet indicating either "Nak" (request retransmission of packet) or "Ack" (packet received OK). B. Physical layer 1. Overview a. Pmax to Host

In an embodiment for a PC host using a serial interface, there are 4 signals from Pmax to the PC host (P3-P0) that generally conform to the specifications of the DCD, RI, DSR, and CTS circuits, respectively, defined in the RS-232 standard.

In an embodiment for either PC or Macintosh host using a parallel interface, the four signals

(P3-P0) generally conform to specifications of the Busy, Ack, PaperOut and Select circuits, respectively, defined in the Centronics or PC-Parallel Printer standard. These four signals carry data from Pmax to the host in parallel in 4-bit nibbles using the first of two communication modes described below.

In an embodiment for a Macintosh host using a serial interface, Pmax drives a synchronous clock signal on line Sclk (CTS), preferably running at a speed between 50 kHz and 1 MHz negotiated with the host using a process described below. The Sclk signal provides a synchronous clock for the signal on line PnP (RxD) that carries serial data from Pmax to the Macintosh host. These two signals are used to send data from Pmax to the host serially using the second of two communication modes described below. In a preferred embodiment, the Macintosh host can instruct Pmax to stop the Sclk signal, thereby interrupting a transmission, by raising the Pclk line (DTR). b. Host to Pmax In an embodiment for a PC host using a serial interface, there are two signals from the host to Pmax (SO, Pclk) that generally conform to the specifications of the RTS and DTR circuits defined in the RS-232 standard. In an embodiment for a Macintosh host using a serial interface, the two signals (SO, Pclk) generally conform to the specifications of the TxD and DTR circuits defined in the RS-232 standard. In an embodiment for either a PC or a Macintosh host using a parallel interface, the two signals generally conform to the specifications of the Init and Strobe circuits defined in the Centronics or PC-Parallel Printer standard. Alternatively, the two signals may generally conform to the specifications of any two data circuits to facilitate shared usage with a conventional printer. In each embodiment, the host drives the Pclk signal as a synchronous clock for the SO signal which carries data from the host to Pmax. In some embodiments using serial interfaces, Pmax automatically configures the physical layer to accommodate differences between PC and Macintosh hosts. This feature is illustrated in a portion of the functional block diagram of Fig. 11. SEL/CONFIG 222 in Pmax monitors the state of one or more paths 33a and, in response thereto, (1) selects a set of paths from a plurality of path sets, shown as 34a and 34b, (2) selects a communication mode, such as die parallel or serial modes described below, and/or (3) configures voltages and/or timing of signals. In particular, in one embodiment, Pmax monitors the Pclk line (DTR) and selects a set of paths according to the path sets shown in Table III below. Between sessions with a PC host, the Pclk line PTR) sits in a low state. Between sessions with a Macintosh host, the Pclk line (DTR) sits in a high state. Pmax samples the Pclk line during idle periods and sets up its physical layer appropriately. This allows transparent switching between the two host types (e.g., with an AB switch box). The host should drive Pclk (DTR) to the appropriate level for a minimum period of time, say 20 μsec, before beginning a session to ensure that Pmax has sufficient time to correctly identify the type of host. A PC host must ensure that the high state of the first Pclk cycle of a session completes in less than some maximum period of time, say 10 μsec, otherwise Pmax may incorrectly identify the PC host as a Macintosh host.

This simple technique allows Pmax to reconfigure at any time, allowing transparent switching between different hosts as mentioned above. Unfortunately, the technique has disadvantages. First, it can interfere with other devices because the host must ensure the Pclk line (DTR) is set to the proper state. This state may conflict with the requirements of a device which has already configured the port for its use. Second, hardware differences in various models of Macintosh hosts make it difficult to set the Pclk line (DTR) low during data transmissions. A special "driver" is required for each model to achieve precise control of this line. An alternate passive technique for automatic configuration which overcomes these problems is discussed below. c. Configuration The relationship between these signals and various circuits defined in several interface standards are shown in Table III.

PC Serial PC and Mac Macintosh High Speed pin no. Parallel pin no. Serial pin no. Interface,

Pmax (OB9/DB25Ϊ (DB25) (Mini DIN-9Ϊ e.ε.. SCSI

P0 CTS (8/5) Select (13) Sclk (2) P0

PI DSR (6/6) PaperOut (12) PI

P2 RI (9/22) Ack (10) P2

P3 DCD (1/8) Busy (11) P3

Pclk DTR (4/20) Strobe (1) DTR (1) Pclk

PnP RxD (2/3) RxD (5)

Sclk CTS (8/5) CTS (2) Sclk

SO RTS (7/4) Init (16) TxD (3) SO

Gnd Gnd (5/7) Gnd (18) Gnd (4) Gnd

Pwr Pwr

Table III

As discussed above, any two data circuits such as Data 1 and Data 2 may be used to carry the Pclk and SO signals rather than the Strobe and Init circuits to facilitate sharing a communications interface.

In some embodiments as described above, Pmax may automatically configure itself to use either of two communication modes: 4-bit parallel mode with host driving Pclk, and 8-bit synchronous serial mode with Pmax driving Sclk. These two modes are selected based on the idle state of the Pclk (DTR) signal supplied by the host. Pmax is able to directly interface to a PC serial port (with no adapter) using the 4-bit parallel mode. Pmax is also able to interface to a PC parallel port using an adapter that translates signals as indicated in Table III. Likewise, Pmax is able to interface to a Macintosh serial port using an appropriate adapter. Finally, an embodiment of Pmax can supply power to the cable so that intelligent adapters may be designed to interface to virtually any protocol (e.g., SCSI, 8-bit parallel, FireWire, etc.) using the high speed 4-bit parallel mode. In other embodiments, Pmax may be restricted to one communication mode.

The PnP line can also be used to support automatic configuration of devices and interfaces in environments incoφorating so called "plug and play" techniques. Although plug-and-play compatibility can be provided, its use is not critical to the practice of the present invention.

2. Parallel mode a. Pmax to Host

The parallel communication mode may be used with a PC host and serial interface or with either a PC or a Macintosh host and a parallel interface. In this parallel mode, 4 data lines (P3-P0) are used to send data in 4-bit nibbles from Pmax to the host. When these 4 data lines are not being used to send data, they carry 4-bit codes which convey to the host the condition or state of Pmax. The

Pmax states and the corresponding 4-bit codes are shown in Table IV.

Codes

Pmax state (P3-P0)

1. Pmax not initialized:

(a) Pmax powered off 0000 (xO)

(b) Pmax powered on see text

2. Pmax connected:

(a) Pmax is idle 1010 (xA)

(b) Pmax wants session 0101 (x5)

3. Session in progress:

(a) Pmax wants to transmit 0011 (x3)

(b) Pmax is receiving 0110 (x6)

(c) Pmax idle in session 1100 (xC)

Table IV

Referring to Fig. 5, trace 510 represents the signal on the Pclk line, trace 511 represents the signal on the SO line and trace 512 represents the signals on the P3-P0 lines. In some embodiments, when first powered on. Pmax initializes itself and sets lines P3-P0 to xA (State 2a, "Pmax is idle"). In alternative embodiments which provide for automatic configuration using passive techniques, discussed below, Pmax generates a sequence of codes until configuration has been carried out and Pmax is initialized. In either embodiment, after Pmax is initialized, it is assumed that during interval 500 the signals on lines P3-P0 are set to either a xA code (State 2a, "Pmax is idle") or a xC code (State 3c, "Pmax idle in session"). Pmax indicates during interval 504 that it wants to send data by setting on lines P3-P0 either a x5 code (State 2b, "Pmax wants session") if a session is not in progress, or a x3 code (State 3a, "Pmax wants to transmit") if a session is in progress. In response, the host toggles Pclk twice (from 0 to 1 and back to 0) to receive a wakeup code (see Table VII) in two 4-bit nibbles during interval 505. In response to Pclk going high (from 0 to 1), Pmax places the first nibble 501 on lines P3-P0. In response to Pclk going low (from 1 to 0), Pmax places the second nibble 502 on lines P3-P0. Subsequent bytes in a packet, if any, are transmitted similarly during interval 506 in pairs of 4-bit nibbles. After Pmax has transmitted the second nibble 503 of the last byte in a packet, the host toggles Pclk twice (from 0 to 1 and back to 0) to indicate the last nibble was read. In response, during interval 509 Pmax sets on lines P3-P0 either a xA code (State 2a, "Pmax is idle") if the session has ended or a xC code (State 3c, "Pmax idle in session") if the session continues. In general, a transition to any State 3 condition ("Session in progress") occurs when the host receives a x5 code (State 2(b), "Pmax wants session") and clocks in the first byte which is the wakeup code. After clocking in the byte, the host responds either with Ack or with a packet conveying data. A subsequent transition to any State 2 condition occurs only when:

1) Pmax sends EOS (end of session) or cancels a session by sending, for example, CAN (cancel session for unspecified reason) and host sends Ack;

2) Host sends EOS or CAN (see Table VI), Pmax sends an Ack and then sets lines P3-P0 to a xA code (State 2a, "Pmax is idle") or a x5 code (State 2b, "Pmax wants session"); or

3) Pmax times out, in which case Pmax sets lines P3-P0 to a xA code (State 2a, "Pmax is idle") or a x5 code (State 2b, "Pmax wants session"). Pmax will "time out" if the Pclk line does not toggle between states at least once during a time¬ out interval, say ten seconds. The time-out interval may be adaptively increased or decreased if host components in the logical layer are more or less likely to be preempted, and hence unable to respond, for longer or shorter periods of time, respectively.

In preferred embodiments, Pmax may reset the time-out interval to another value under various conditions. For example, if Pmax detects an invalid packet and/or is unable to correctly determine the expected packet length, Pmax can set a second time-out interval for a much shorter period, say 2 msec, so that Pmax can convey the problem to the host more quickly after the host finishes sending the packet. b. Host to Pmax The host conveys information about various states using the SO and Pclk signals. Various host states are shown in Table V. Line status Host state (SO Pclk

11. Not loaded or power off 00

12. Loaded: (a) Idle 00

(b) Host wants session 11

13. Session in progress:

(a) Host is receiving Ot t = toggled sequence of 1/0 (b) Host is sending dt d = bits of transmitted byte(s) t = toggled sequence of 1/0

Table V

The first byte of a packet sent from the host to Pmax and the last byte of a packet sent from Pmax to the host merit special attention in the use of the Pclk and SO control lines because the Pclk line is used for both sending and receiving. The Pclk line is low (0) during idle states.

Referring to Fig. 6, trace 510 represents the signal on the Pclk line, trace 51 1 represents the signal on the SO line and trace 512 represents the signals on the P3-P0 lines. The host indicates it wants a session (State 12b) by sending to Pmax a single-byte wakeup code (see Table VII). The first or most significant bit (MSB) of the wakeup code must always be a 1 so lines SO-Pclk are set to 11 for the first bit 508 of the code. The host toggles line Pclk to clock out each successive bit of the wakeup code during interval 507; each eight transitions of Pclk (four cycles) causes Pmax to receive eight bits (one byte) from line SO. During interval 507 after receiving the first bit, Pmax sets lines P3-P0 to a x6 code (State 3b, "Pmax is receiving"). Referring again to Fig. 6, the host sends packets to Pmax by clocking out each byte in the packet, one bit at a time. The MSB 508 of the first byte in a packet is always a 1 so the host sets lines SO-Pclk to 11 to begin the transmission. During interval 507 the host toggles line Pclk to clock out each successive bit of the first byte and the bits of subsequent bytes, if any, sent along line SO. During interval 509 after receiving the last bit of the packet, Pmax sets on lines P3-P0 either a xA code (State 2a, "Pmax is idle") if the session has ended or a xC code (State 3c, "Pmax idle in session") if the session continues.

While Pmax is receiving data from the host, it sets lines P3-P0 to a x6 code (State 3b, "Pmax is receiving"). After the last byte which Pmax expects to receive has been sent, Pmax sets lines P3-P0 to a xC code (State 3c, "Pmax idle in session") to indicate that it has received the packet. Subsequently. Pmax will set lines P3-P0 a x3 code (State 3a, "Pmax wants to transmit") to indicate it wants to send to the host either an Ack (packet received OK), a Nak (request retransmission of packet) or a packet with data which also implies an Ack. The host can use this to verify Pmax has received the correct length packet and, in case of error, resynchronize Pmax to the host. The host receives a byte from Pmax (State 13a) by toggling line Pclk to clock in a pair of 4-bit nibbles. The host sets Pclk to 1 to receive the first nibble and sets Pclk to 0 to receive the second nibble. When the received byte is the last byte of a packet, the host then sets Pclk to 1 to allow Pmax to set lines P3-P0 with an appropriate idle state code (State 2a or State 3c), then the host sets Pclk to 0 to complete the clock cycle.

3. Serial Mode The serial communication mode may be used with either a Macintosh or a PC host and a serial interface. Use of the parallel mode is preferred with PC hosts; therefore, more particular mention is made of Macintosh hosts. In the serial mode, the host uses the P0 line as a transmit and receive serial clock (Sclk), running at a rate between approximately 50 kHz to 1 MHz. Each byte of data is transferred over the PnP (RxD) and SO (TxD) lines synchronously in 8-bit frames, starting with the least significant bit (LSB) and ending with the MSB.

In preferred embodiments, the Sclk clock rate is set adaptively in a manner discussed below. Similar techniques can be used to adaptively set signalling rate for either parallel or serial communication modes. For parallel communication modes, the host controls the signalling rate by controlling the clocking rate of the signal on the Pclk line. The host begins a process to adaptively determine an optimum signalling rate by sending a packet to Pmax instructing it to enter a special operating state. In some embodiments, the special operating state is initiated by a "Start counter mode" wakeup packet. While in this operating state, Pmax generates a sequence of data having contents which are known to the host. The known sequence is sent to the host along either path set 34a or 34b as selected by SEL/CONFIG 222. The known sequence may be generated by many techniques including an incrementing or decrementing counter, a pseudo-random number generator starting with a known seed value, a stored table or list of values, or a combination of such techniques. No particular technique is critical. The host increases the clocking rate of the Pclk signal while comparing the contents of the sequence as received against the contents as expected and derives a measure of error in response to the rate of differences detected. The host can then determine a signalling rate which achieves an optimum balance between error rate and data transfer rate. The special operating state may be terminated in response to a request, such as an "End counter mode" packet, and/or after some prescribed interval. For serial communication modes, referring to Fig. 11, CLOCK 226 drives SEQ GEN 224 in

Pmax to generate along path 221 a sequence of data having contents which are known to the host. The known sequence is sent to the host aJong either path set 34a or 34b as selected by SEL/CONFIG 222. The known sequence may be generated by many techniques including an incrementing or decrementing counter, a pseudo-random number generator starting with a known seed value, a stored table or list of values, or a combination of such techniques. No particular technique is critical. The rate of CLOCK 226 is adapted in response to requests received from the host along paths 33a and 225. It should be pointed out that SEL/CONFIG 222 and SEQ GEN 224 may be incoφorated into a single embodiment as shown in the figure, however, either feature may be incoφorated and used independently.

Referring to Fig. 12, RCVR 122 in the host receives from path 34d the sequence of data having known contents. EXP 130 provides the contents of the sequence as expected. COMP 128 compares the contents of the sequence as received against the contents as expected and derives a measure of error in response to the rate of differences detected. In one embodiment, REQ 132 sends to Pmax along path

33a a request to change the clock rate at which the sequence is generated. In another embodiment,

ADJ 126 adjusts a wait-time interval as will be described below. In yet another embodiment, both

REQ 132 and ADJ 126 may be used. In an embodiment incoφorating ADJ 126, WAIT 124 receives a clock signal from Pmax along path 34c and defines times relative to the clock signal when signals received from path 34d can be considered valid. The relation between the time when data is considered valid and some point in a cycle of the clock signal, say a positive transition in clock signal voltage, is referred to as the wait-time interval. ADJ 126 adjusts the wait-time interval used by WAIT 124 in response to the measure of error derived by COMP 128.

When Pmax and a Macintosh host first make contact after a power-on reset, Pmax drives the Sclk line (CTS) with a 50 kHz clock signal. This signalling rate should be within the capability of nearly all hosts. The Macintosh host may then begin negotiating an optimum clock rate by sending along the SO line (TxD) a "Request Speed" wakeup code (see Table VII) to Pmax if a different speed is desired. In response to this request, Pmax changes the clocking rate of the Sclk signal and transmits along line PnP (RxD) a sequence of packets, the contents of which are known to the host.

The host, or host software in many embodiments, uses wait-time intervals to define times when line signals are considered valid. The host adjusts these wait-time intervals in response to errors detected by comparing the contents of the received data with the expected contents. The host may request a higher clock rate if the wait-time intervals are not yet at a minimum and the number of errors is acceptable. The host may request a lower clock rate if the number of errors is too high.

If the clock rate is too high and the host is unable to communicate with Pmax, a "Lost

Communications Timeout¹' expires in Pmax after a preset limit, say 1 sec, and Pmax resets the clock rate to the last known acceptable rate. The host may then select an intermediate clock rate and repeat the process. After the optimum clock rate has been negotiated, the "Lost Communications Timeout" period may be set to a longer period, say 10 sec.

Pmax may use different clock rates for sending and receiving information. Preferably, Pmax sets a receiving clock rate which is slow enough to essentially ensure that the host can always communicate successfully with Pmax and sets a sending clock rate which optimizes the trade off between error rate and transmission rate. During idle states and while receiving from the host, Pmax clocks the Sclk line (CTS) at the receiving rate. While sending to the host. Pmax clocks the Sclk line (CTS) at the sending rate. Referring to Fig. 7, trace 610 represents the signal on the Sclk line (CTS), trace 611 represents the signal on the PnP line (RxD), trace 612 represents the signal on the SO line (TxD) and trace 613 represents the signal on the Pclk line (DTR). When Pmax sends data to the host, it sends one sync character (xl6) during interval 600 followed by an appropriate header byte during interval 601 (see Tables VI and VII). Subsequent bytes, if any, are sent during interval 602. Each bit of the sync character and subsequent bytes is placed on the PnP line (RxD) after Sclk makes a transition from 1 to 0. The host samples the PnP line (RxD) when Sclk makes a transition from 0 to 1.

Synchronization circuitry may be built into both Pmax and the host which recognizes the sync character as the first character of a transmission, establishes proper timing for the remainder of the packet, and strips the sync character before presenting data bytes to the logical layer.

Referring to Fig. 8, trace 610 represents the signal on the Sclk line, trace 611 represents the signal on the PnP line, trace 612 represents the signal on the SO line and trace 613 represents the signal on the Pclk line. When a host wants to send data to Pmax, it sends one sync character during interval 600 followed by an appropriate header byte (see Tables VI and VII) during interval 601. Subsequent bytes, if any, are sent during interval 602. Each bit of the sync character and subsequent bytes is placed on the SO line (TxD) after Sclk makes a transition from 1 to 0. Pmax samples the SO line (TxD) when Sclk makes a transition from 0 to 1.

Pmax and the host establish sessions and make transitions between various states in a manner similar to that described above for the parallel communication mode. Preferably, the host may use the Pclk line (DTR) to control the synchronous clock line Sclk. Referring to Figs. 7 and 8, when the Pclk line (trace 613) is brought low, Pmax stops toggling the Sclk signal (trace 610) after the next falling edge, which suspends transmission. When the Pclk line is brought high, Pmax resumes toggling the Sclk signal and data transmission continues with no loss of synchronization. By using this technique, the host can control data transfers in both directions. This is especially useful for maintaining synchronization when the host is unable to supply data to or receive data from the serial interface fast enough, or if the host must give up control to other processes. Accordingly, the host must bring the Pclk line (DTR) high during out-of-session periods so that Pmax may initiate a session.

4. Alternative Serial Mode An alternative serial communication mode uses the four lines Sclk, PnP, SO and Pclk. Referring to Figs. 9 and 10, trace 610 represents the signal on the Sclk line, trace 611 represents the signal on the PnP line, trace 612 represents the signal on the SO line and trace 613 represents the signal on the Pclk line. Pmax provides a clocking signal on the Sclk line, data is sent from Pmax to host on the PnP line and data is sent from a host to Pmax on the SO line in a manner very similar to the serial mode described above. The principle differences are that no sync character is used and each byte is transmitted in a 10-bit frame 601 comprising start bit 604, eight data bits and stop bit 605. A subsequent byte is sent during interval 602. This technique is compatible with a wider range of serial interface embodiments found in different models of Macintosh computers. Preferably, Pmax provides a clock signal on line Sclk only when the host brings the Pclk line high and immediately stops clocking line Sclk in response to the host bringing the Pclk line low.

5. Passive Detection for Automatic Configuration In some embodiments using serial interfaces, Pmax provides for automatic configuration of the physical layer to accommodate various types of hosts without raising potential conflicts with other devices and without requiring special drivers for various models of hosts. In such embodiments, after being powered on but before being initialized (State lb), Pmax sets a sequence of codes on lines P3-P0. For a period of time, say 250 msec, Pmax toggles the P3 line (DCD) at a low rate, say 500 Hz, to generate an alternating sequence of xO and x8 codes. For another period of time, say 250 msec, provided the Pclk line (DTR) is high, Pmax toggles the P0 line (CTS) at a high rate, say 50 kHz, to generate an alternating sequence of xO and xl codes. This operation continues until either the host responds in a prescribed manner, discussed below, or until an optional time-out period elapses.

A PC host, or more correctly, software running in a PC host, is able to see the state of the P3-P0 lines regardless of the state of the Pclk line (DTR). If the Pclk line (DTR) is high, at some point the PC host may detect an alternating sequence of xO/xl codes on these lines. If such a sequence is detected, it is ignored. If the Pclk line (DTR) is low, the xO/xl sequence is never detected because Pmax does not generate it. At some point, a PC host will detect an alternating sequence of x0/x8 codes. In response to these codes, the host sends to Pmax an "Are you there?" packet. Pmax in turn sends an "I am here" packet and waits for a special Ack (x82) which indicates the host and Pmax have successfully established communication. Pmax can then make various requests of the host such as downloading operating software. When the process has concluded, Pmax sets on the P3-P0 lines an xA code (State 2a, "Pmax is idle"). If the process does not conclude successfully, Pmax returns to State lb and generates the sequence of codes described above.

This technique allows a PC host to examine a number of serial ports and correctly identify the port to which Pmax is connected without changing the state of any line or interface register. This passive technique avoids potential conflict with other devices which is briefly mentioned above.

A Macintosh host, or more correctly, software running in a Macintosh host, cannot be assured that it will see the state of the P3-P0 lines; therefore, an operator must tell the host which serial port to use. The host raises the Pclk line (DTR) high for this serial port. At some point, Pmax clocks the Sclk line (CTS) at a high rate, say 50 kHz, for a period of time, say 250 msec. The host attempts to send an "Are you there?" packet and eventually, the attempt will be made while Pmax clocks the Sclk line (CTS). In response, Pmax will send an "I am here" packet and the process will continue in a manner similar to that described above for a PC host.

6. Header Byte Values Pmax and a host utilize a number of header byte values to initiate sessions and perform a variety of functions. Some header byte values are referred to as wakeup codes. No particular set of values is critical to the practice of the invention. Examples of header bytes for the embodiment described above are shown in the following tables. As explained above, for this embodiment the MSB of each value sent to Pmax must be a 1.

Header Byte (to host) Value

Multi-byte xOl Ack (acknowledge) x02

Nak (negative ack.) x03

EOS (end of session) x04

CAN (cancel session) x05

I am here xOF Header Byte (to Pmax) Value

Multi-byte x81

Ack (acknowledge during init) x82

Nak (negative ack.) x83

EOS (end of session) x84 CAN (cancel session) x85

End counter mode x86

Nak (resend and slow down) x87

Ack (acknowledge) x88

Are you there? x8F Table VI

According to one embodiment, a host and Pmax use the "Ack" and "Nak" codes in a conventional manner to indicate a positive and a negative acknowledgement, respectively. In some embodiments, a unique Ack code is used during initialization to allow a Macintosh host to verify it is responding to Pmax during initialization. If Pmax responds to the special Ack (x82) with a Nak, the host will recongize that Pmax is already initialized and no further information need be sent to Pmax.

The "EOS" code is used to indicate that a session is terminating normally. Either a host or Pmax may use the "CAN" code to terminate a session abnormally without providing a reason for termination. The

"I am here" packet is used by Pmax to respond to an "Are you there?" wakeup packet from the host.

The "multi-byte" packet value is used to indicate that a packet contains more than one byte. In one embodiment, multiple-byte packets consist of a header byte having the "Multi-byte" value, a one-byte packet-type flag identifying the nature of the packet, a one-byte packet sequence number, a two-byte data length field indicating the number of data bytes in the packet, the data bytes, and a two- byte checksum for the entire packet. The packet sequence number allows a device to ensure all packets have been received and that the correct packet has been resent in response to a request for retransmission. The checksum is used for error detection and/or correction. It should be apparent that other formats are possible and that no particular format is critical to the practice of the present invention. For example, a multiple-byte packet could consist of a header byte with a value that indicates both the packet type and the number of data bytes. Wakeup codes are header byte values by which one device, say Pmax, can request a second device, say a host, to change from an idle state to a ready state or to perform some function. Examples of some wakeup codes are shown in the following table.

Wakeup Packet (to host) Code

Paper inserted xl l Request preferences x28

Wakeup Packet (to Pmax) Code

Start counter mode x90

Reset x92

CAN (out of session) x93

Request preferences xA8

Request speed xA9

Send information xAA

Table VII

According to one embodiment, Pmax sends a "Paper inserted" wakeup packet to a host when it detects the insertion of a sheet to scan, requesting that the host prepare to receive data representing an image of the sheet. The "Request preferences" packet sent by Pmax to a host requests that the host send one or more parameters affecting the way in which Pmax performs scanning and prepares image data. A "Start counter mode" packet is used in parallel communication modes and requests that Pmax send a sequence of bytes or packets having values which start with a known value and successively count up or down. A host can use such a sequence to determine an optimum serial clock rate by comparing the values actually received with the values that are expected. The host sends an "End counter mode" packet to request Pmax stop sending the sequence. In serial communication modes, the host can send a "Request speed" packet requesting that Pmax send a known sequence of data. The host can send a subsequent "Request speed" packt requesting that Pmax adjust the clock rate and continue sending the sequence, or a Nak (slow down) packet requesting that Pmax resend the sequence at a lower signalling rate. In another embodiment, Pmax maintains the current signalling rate if the host responds with an "Ack" but reverts to a lower clock rate if the host responds with a "Nak" or a "Lost Communications Timeout" expires. In another embodiment, the "Request speed" packet indicates whether Pmax is to increase of decrease the clock rate. In yet another embodiment, the "Request speed" packet indicates the clock rate which Pmax should use.

A "Reset" packet requests that Pmax assume a known state such as that which exists just after power is applied to Pmax. By sending a "Request preferences" packet or a "Send information" packet, a host requests that Pmax send to the host one or more preference parameters it is currently using or other information, respectively. The values, codes and related functions are discussed here merely to provide examples of the type of information which can be exchanged between devices using the communication methods described above. The various codes and functions described above can be used in a wide variety of combinations. These values and codes and the embodiments described above should not be understood to represent any limitation or requirement on the practice of the present invention which is defined by the following claims.

Claims

1. A system comprising a first device having a first communication interface comprising a plurality of status circuits and a plurality of control circuits, and comprising a data-input circuit and/or a data- output circuit, wherein said first communication interface is a serial-communication interface, a second device having a second communication interface comprising a plurality of input circuits and a plurality of output circuits, and a communication channel comprising a plurality of first paths and a plurality of second paths, wherein a respective one of said first paths connects a respective one of said status circuits to a respective one of said output circuits, and a respective one of said second paths connects a respective one of said control circuits to a respective one of said input circuits, wherein said second device sends data to said first device through said first paths.

2. A system comprising a first device having a first communication interface comprising a plurality of status circuits and a plurality of control circuits, and comprising one or more data-output circuits, a second device having a second communication interface comprising a plurality of input circuits and a plurality of output circuits, and a communication channel comprising a plurality of first paths and a plurality of second paths, wherein a respective one of said first paths connects a respective one of said status circuits to a respective one of said output circuits, and a respective one of said second paths connects a respective one of said control circuits to a respective one of said input circuits, wherein said second device sends data to said first device through said first paths and said first device sends data to said second device through said second paths.

3. A system according to claim 1 or 2 wherein data is sent from said second device to said first device in parallel along a plurality of said first paths.

4. A system according to claim 2 wherein said first communication interface is a serial- communication interface.

5. A system according to claim 2 wherein said first communication interface is a parallel- communication interface.

6. A system according to claim 1 or 2 wherein said second device sends status information and data along one or more of said first paths.

7. A system comprising a first device having a first communication interface comprising four status circuits, wherein said first communication interface is a serial -communication interface, a second device having a second communication interface comprising a plurality of output circuits, and a communication channel comprising four first paths, wherein a respective one of said first paths connects a respective one of said status circuits to a respective one of said output circuits, wherein said second device sends data to said first device through said first paths.

8. A system comprising a first device having a first communication interface comprising four status circuits and a plurality of transmitting circuits, a second device having a second communication interface comprising a plurality of input circuits and a plurality of output circuits, and a communication channel comprising a plurality of first paths and a plurality of second paths, wherein a respective one of said first paths connects a respective one of said status circuits to a respective one of said output circuits, and a respective one of said second paths connects a respective one of said transmitting circuits to a respective one of said input circuits, wherein said second device sends data to said first device through said first paths in response to request and status information sent on one or more of said second paths by said first communication interface, and wherein said second device receives data from said first device through said second paths in response to a send-request asserted on one or more of said second paths by said first communication interface.

9. A system according to claim 8 wherein said transmitting circuits are control circuits.

10. A system according to claim 7 or 8 wherein said second device sends status information and data along said first paths.

11. A system according to claim 1, 2, 7 or 8 wherein said first communication interface is a serial-communication interface substantially conforming to a RS-232 standard and said status circuits correspond to two or more circuits from the set consisting of Clear to Send (CTS), Data Set Ready (DSR), Data Carrier Detect (DCD) and Ring Indicator (RI).

12. A system according to claim 1, 2 or 9 wherein said first communication interface is a serial-communication interface substantially conforming to a RS-232 standard and said control circuits correspond to two or more circuits from the set consisting of Request to Send (RTS) and Data Terminal Ready (DTR).

13. A system according to claim 2 or 8 wherein said first communication interface is a parallel -communication interface substantially conforming to a Centronics parallel-printer standard or a PC-Parallel Printer standard and said status circuits correspond to two or more circuits from the set consisting of Acknowledge, Printer Busy, Out of Paper and Selected.

14. A system according to claim 2 or 9 wherein said first communication interface is a parallel -communication interface substantially conforming to a Centronics parallel-printer standard or a PC-Parallel Printer standard and said control circuits correspond to two or more circuits from the set consisting of Strobe, Reset Printer and Select Printer.

15. A system according to any one of claims 1 through 14 wherein said second device sends a clock signal and data bits to said first device, wherein said second device sends two or more data bits in parallel for each transition in said clock signal.

16. A system according to any one of claims 1 through 15 wherein said second device sends a clock signal to said first device and said first device sends one or more data bits to said second device for each cycle of said clock signal, wherein said second device stops sending said clock signal in response to a request received from said first device.

17. A system according to any one of claims 1 through 16 wherein said second device comprises sending means for sending to said first device first codes sent at a first signalling rate alternating with second codes sent at a second signalling rate, receiving means for receiving from said first device a request, and configuring means for adaptively selecting and/or configuring circuits for sending and receiving data in response to whether said receiving means receives said request while said sending means sends said first codes or said second codes.

18. A system according to any one of claims 1 through 16 wherein said second device adaptively selects and/or configures circuits for sending and receiving data in response to a given input circuit state during idle periods when data is not being transferred between said first device and said second device.

19. A system according to claim 1 through 18 wherein said first device comprises means for receiving a sequence of data from said second device at a signalling rate controlled by said first device, means for comparing said sequence of data as received with expected contents known to said first device and for deriving a measure of error in response to rate of differences detected between said sequence of data as received and said expected contents, and means responsive to said measure of error for changing said signalling rate.

20. A system according to any one of claims 1 through 18 wherein said first device comprises means for receiving a sequence of data from said second device at a signalling rate controlled by said second device, means for comparing said sequence of data as received with expected contents known to said first device and for deriving a measure of error in response to rate of differences detected between said sequence of data as received and said expected contents, and means responsive to said measure of error for sending a request to said second device requesting a change in said signalling rate.

21. A system according to any one of claims 1 through 18 wherein said first device comprises means for receiving a clock signal and a sequence of data from said second device, wherein bits of said sequence of data is received at times relative to cycles of said clock signal defined by a wait interval, means for comparing said sequence of data as received with expected contents known to said first device and for deriving a measure of error in response to rate of differences detected between said sequence of data as received and said expected contents, and means responsive to said measure of error for adjusting said wait interval.

22. A system according to any one of claims 1 through 18 wherein said second device comprises means for sending to said first device a sequence of data having contents known to said first device.

23. A system according to any one of claims 1 through 18 wherein said second device comprises means for sending to said first device at a signalling rate a sequence of data having contents known to said first device, and means for receiving from said first device a speed request and changing said signalling rate in response thereto.

//