+

WO1996023261A1 - Method and apparatus for communication over a parallel port - Google Patents

Method and apparatus for communication over a parallel port Download PDF

Info

Publication number
WO1996023261A1
WO1996023261A1 PCT/US1996/001032 US9601032W WO9623261A1 WO 1996023261 A1 WO1996023261 A1 WO 1996023261A1 US 9601032 W US9601032 W US 9601032W WO 9623261 A1 WO9623261 A1 WO 9623261A1
Authority
WO
WIPO (PCT)
Prior art keywords
lines
data
port
electronic device
control
Prior art date
Application number
PCT/US1996/001032
Other languages
French (fr)
Inventor
Donald K. Schuman
Jay Lowe
Original Assignee
Parallel Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Parallel Technologies, Inc. filed Critical Parallel Technologies, Inc.
Priority to AU49041/96A priority Critical patent/AU4904196A/en
Publication of WO1996023261A1 publication Critical patent/WO1996023261A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G06F13/385—Information transfer, e.g. on bus using universal interface adapter for adaptation of a particular data processing system to different peripheral devices

Definitions

  • the present invention relates to methods and apparatus for communication, and more particularly, to methods and apparatus for communication between electronic devices over a parallel port.
  • one electronic device say, a personal computer - PC
  • an external electronic device say, a printer
  • this interconnection is a wire cable configured for the specific purpose.
  • One popular standard for communication between a PC and a printer is the Centronics standard. According to this standard, the information is transmitted in parallel form, so that all of the bits that make up each unit of information are transmitted simultaneously to the external device over separate lines in the wire cable.
  • each of the two electronic devices confirms the presence of, and correct interaction or interconnection with, the other device.
  • the device that is the source of the information prepares the first unit of information to be transmitted.
  • the information source sends a control signal to the information recipient to notify the recipient.
  • the information recipient configures itself for receipt of the information and sends an acknowledgement signal back to the signal source, typically on a status signal, verifying that the unit of information was received. This process is then repeated until all of the intended information has been transmitted.
  • This standard was originally established to facilitate communication between a PC and a Centronics (or compatible/standard) printer with a parallel I/O port which provided a number of parallel lines.
  • the typical parallel I/O port has twenty-five lines - seventeen signal lines and eight ground lines.
  • FIG 13 is a block diagram of interconnected I/O ports in accordance with the prior art. As shown in Figure 13, the two
  • I/O ports 200 and 202 are respectively parts of first and second electronic devices 204 and 206.
  • the two I/O ports 200 and 202 are interconnected by a plurality of parallel lines 208. This plurality of lines is divided into functional subsets.
  • One subset, the DATA lines 210 are used to transfer the parallel signals representing data from one electronic device to the other.
  • Another subset, the CONTROL lines 212 are used to transfer control signals from one electronic device to the other.
  • the third subset, the STATUS lines 214 are used to transfer status signals between the two electronic devices in the direction opposite to the direction in which the CONTROL lines 212 carry their signals.
  • the parallel port signal lines were placed into three categories: DATA signals, STATUS signals and CONTROL signals.
  • the eight DATA signal lines (labelled DATA1 through DATA8) each carried a specific one of the eight bits of the data word (the unit of information) that is being transmitted.
  • the CONTROL signal lines are sometimes bidirectional, although the Centronics standard only called for them to be unidirectional (from the PC to the Centronics compatible/standard external device) .
  • the five STATUS signals (typically labelled BUSY, ACKNOWLEDGE, SELECT_IN, PAPER ERROR, and FAULT) were unidirectional from the external device to the PC and provided status indications from the external device to the PC.
  • the four CONTROL signals (typically labelled STROBE, AUTOFEED, INIT and SELECT IN) were intended to be unidirectional from the PC when sending data to a printer and provided signals necessary to control transfer of the data on the DATA lines to the external device.
  • One of the implementations that exploited the bidirectionality of some of the signals in the IBM PC's implementation of the Centronics standard is exemplified by the specification and claims of U.S. Patent No. 5,293,497. That patent is directed toward transmission of some data between the CONTROL registers of the two computers and transmission of the remainder of the data from the DATA output register of the sending computer to the STATUS register of the receiving computer.
  • the technique most commonly used to control the transfer of data from an external device to a PC is to have the driver software in the PC set a CONTROL signal for receipt by the external device.
  • the external device responds in one of two ways, depending on whether it is equipped with an 8- bit bidirectional parallel I/O port. If the external device has an 8-bit bidirectional parallel I/O port, it prepares all 8 bits of the data for transmission over the DATA signal lines. If the external device does not have an 8-bit bidirectional parallel I/O port, it prepares the data in smaller units, (say, four bits at a time) for transmission over a predetermined four of the five STATUS signal lines.
  • the driver software in the PC then reads the data from the appropriate place (i.e., 8-bit bidirectional parallel I/O port, or four of the STATUS signal lines) , stores the data, and then toggles the logic sense of a "CONTROL" signal to indicate to the external device to send the next unit of information.
  • the appropriate place i.e., 8-bit bidirectional parallel I/O port, or four of the STATUS signal lines.
  • the LapLink method of data transfer between two PCs is typical of the process described above. Most Laplink-like file transfer programs use the DATA port exclusively for both control and data transfers. The use made of the DATA port depends upon whether data or other information is being transferred. If data is being transferred, four of the DATA signals are assigned to carry data and another one of the DATA signals is assigned to carry a handshake signal (i.e., a signal to facilitate a handshake between devices) . In this method, the data is transferred from one PC to the other, four bits (one nibble) at a time. At other times, the DATA signals may transmit other control or status information from one PC to the other.
  • a handshake signal i.e., a signal to facilitate a handshake between devices
  • data is carried, a nibble at a time, from one PC to the other from the D1-D4 signal lines of the first PC's DATA port respectively to the ERROR, SELECT, PAPER and ACKNOWLEDGE signal lines of the other PC's STATUS port.
  • the D5 signal line of the first PC is used to handshake with the BUSY STATUS signal line of the other PC.
  • the first PC when the first PC has the least significant nibble (LSN) of the current byte of data ready, the first PC initiates transfer, either by toggling the DATA port signal D4 or by setting the handshake DATA port signal (D5) .
  • the toggled DATA port signal D4 causes the ACKNOWLEDGE signal on the other PC to toggle.
  • setting the handshake DATA port signal invites the other PC to respond by setting its own handshake DATA port signal, which the first PC receives on the BUSY signal line of its STATUS port.
  • the first PC sends the other PC a data packet. It does this by transmitting the first nibble of data on the DATA port signals D1-D4 and then changing the state of the dedicated handshake DATA port signal D5.
  • the other PC monitors the STATUS port BUSY signal, waiting for the handshake signal from the first PC.
  • the second PC detects the handshake signal, it reads the nibble of data from its STATUS port signals ACKNOWLEDGE, PAPER, SELECT and ERROR, and then changes the state of its own dedicated handshake DATA port signal D5.
  • the first PC simultaneously monitors its own STATUS port BUSY signal, waiting for the other PC to respond to its handshake signal.
  • the first PC detects a change in the BUSY signal, it recognizes that the second PC has read the transmitted nibble of data and can then transmit the next nibble. This process continues until all of the data is transferred.
  • the choice of signals to be used for data and handshakes is generally arbitrary.
  • FIG. 1 is a schematic diagram of a prior art "high speed” 4- bit transfer of data from a first external device 16 (such as a PC) to another device 18.
  • the first external device 16 divides each 8-bit byte 20 of the data to be sent into two 4-bit “nibbles,” designated the “least significant nibble” (LSN) 22 and the “most significant nibble” (MSN) 24.
  • a nibble selector signal 26 (normally one of the CONTROL or DATA signal lines) is used to select whether the LSN 22 or the MSN 24 of the current byte 20 will be presented to the STATUS port by the external device.
  • the nibble 22 or 24 to be sent is not immediately available after the nibble selector signal 26 is toggled.
  • the external device is signalled that the receiving device is ready for another byte 20 of data through impulses in a "Get Next Byte” signal 28, typically coincident with (but not necessarily) every transition of the nibble selector signal 26.
  • the external device is signalled that the receiving device is ready for another nibble 22 or 24 of data through impulses in a "Send Next Nibble” signal 30.
  • the impulses in the "Get Next Byte” signal 28 are coincident with every other impulse in the "Send Next Nibble” signal 30.
  • the external device 16 After the time that the receiving device transmits each of the impulses in the "Send Next Nibble" signal 30 coincident with every transition of nibble selector signal 26, the external device 16 has delays (and the CONTROL signal 26 may have delays) between the time the receiving device software commands signal 26 to change state and the point at which the nibble is available. This is called the “wait” period 32. During this "wait” period 32, the external device retrieves the requested nibble and has it ready to be read by the receiving device. The second device then transmits a "Nibble of Data Ready" signal 34 (typically on an additional signal line) having impulses at the times when the second device has prepared the requested nibble of data for transmission to the receiving device.
  • a "Nibble of Data Ready" signal 34 typically on an additional signal line
  • FIG. 2 is a schematic diagram of one typical implementation of a conventional 8-bit transfer of data from an external device, in accordance with the prior art.
  • the byte to be sent is available some time after a downward transition 40 in a complete toggle 42 of a "Byte Access Control" signal 44.
  • the Byte Access Control signal 44 is typically one of the parallel I/O port's CONTROL signals (STROBE, INIT, AUTOFEED, or SELECT IN) .
  • the external device is signalled that the receiving device is ready for another byte 46 of data through impulses in a "Send Next Byte" signal 48.
  • the external device 16 After the time that the receiving device transmits each of the impulses in the "Send Next Byte" signal 48, coincident with every transition of signal 44, the external device 16 has delays (and the CONTROL signal 44 may have delays) between the time the receiving device software commands CONTROL signal 44 to change state and the point at which the byte is available. This is called the “wait” period 50. During this "wait” period 50, the external device retrieves the requested byte and has it ready to be read by the receiving device. The second device then transmits a "Byte Ready to be Read” signal 52 (for example, on an additional signal line) having impulses at the times when the second device has prepared the requested byte of data for transmission to the receiving device.
  • a "Byte Ready to be Read” signal 52 for example, on an additional signal line
  • FIG 3 is a schematic diagram of a prior art "high speed” 8- bit transfer of data from an external device.
  • the external device is capable of sending the data sometime after receiving each change 60 in the state of the "Byte Access and Selector Control" signal 62, which is typically one of the CONTROL signal lines. This capability is provided by conventional logic circuitry in the external device.
  • the external device is signalled that the receiving device is ready for another byte 64 of data through impulses 66 in a "Send Next Byte" signal 68.
  • the external device 16 After the time that the receiving device transmits each of the impulses 66 in the "Send Next Byte" signal 68, coincident with every transition of signal 62, the external device 16 has delays ( and the CONTROL signal 62 may have delays) between the time the receiving device software commands control signal 62 to change state and the point at which the byte is available. This is called the “wait” period 70. During this "wait” period 70, the external device retrieves the requested byte and has it ready to be read by the receiving device. The second device then transmits a "Byte Ready to be Read” signal 72 (for example, on an additional signal line) having impulses 74 at the times when the second device has prepared the requested byte of data for transmission to the receiving device.
  • a "Byte Ready to be Read” signal 72 for example, on an additional signal line
  • FIG. 2 A comparison of Figures 2 and 3 shows that the primary difference between the conventional 8-bit transfer and the "high ⁇ speed" 8-bit transfer is in their response to the CONTROL signal lines that cause the external device to access the next byte to be transmitted.
  • the CONTROL signal is toggled to a low level and then back to a high level for each byte of data, whereas in the "high-speed" transfer, the external device is caused to access the next byte of data after each toggle of the CONTROL signal.
  • This increases the data throughput capability of the external device since, for each byte of data, there are two fewer input/output (I/O) instructions required in the "high-speed" mode than in the conventional mode.
  • FIG 4 is a schematic diagram of a portion of a typical parallel I/O port hardware design known in the prior art.
  • the typical parallel I/O port has CONTROL port signals with open collector drivers having 3-6 kiloohm pullup resistors. This causes timing delays in the signals for external devices when these signals are used to control access or to provide status.
  • Figure 5 is a timeline showing the data access delays caused by the typical parallel I/O port hardware design shown in Figure 4.
  • Table 1 a portion of the ideal set of software instructions that is desirable to use for causing the transmission shown in Figure 5, and consequently causing the data from the external device to be read via the parallel I/O port, is shown in Table 1, below: Table 1
  • MOV DX ontrol_Port_ Address ; this instruction sets the address of the CONTROL port MOV AL, Control_Signal_State ; sets up the value to be ou ⁇ ut to the CONTROL signal lines OUT DX, AL ; output the new state of the CONTROL signal lines
  • the driver software in the computer has virtually no delay between the CONTROL signal line change (caused by the instruction in the third line in the software listing, shown as A2 in Figure 5) and its reading of the data from the external device (caused by the instruction in the fifth line in the software listing shown as A3, in Figure 5).
  • the software instruction listing of Table 1, and all other software listings in this application are written in an assembly language code specific to the IBM PC.
  • Another way that current external devices are designed to eliminate the ambiguities of timing caused by the delay in the CONTROL signal lines, cable capacitances, and device delays is to use one of the STATUS signals lines as a "WAIT" signal .
  • the WAIT signal is set in one state by the external device when the device has data ready and in another state when the external device does not have data ready.
  • the driver software can then read this "WAIT" STATUS signal to determine when the external device has data ready (if reading from the external device) or determine when the device has finished processing the data which was written to it (if writing to the external device) .
  • This approach makes the handshaking between the computer and the external device more reliable and less affected by timing differences due to parallel I/O port and hardware designs as well as cable capacitance and delays in the device getting data ready.
  • the approach also has a major drawback due to the added instructions required in the driver software to read the STATUS signal line and the corresponding increase in time required to execute those instructions for each unit of information transferred.
  • the maximum theoretical data transfer through the parallel I/O port is defined by the absolute time that it takes to execute the I/O and other instructions on a particular PC and for its particular design. As the central processing units (CPUs) for the PC are made to execute instructions faster and faster, the time it takes to execute an I/O instruction has remained relatively constant at about 1.0 to 1.5 microseconds. This timing is regulated by the bus speed of the particular PC.
  • CPUs central processing units
  • the PC driver software typically must toggle an output signal capable of use (either a DATA port signal or a CONTROL port signal) as a handshake signal.
  • the handshake signal indicates to the external device that the PC is ready to send data or receive data.
  • the external device Upon detecting a change in the output handshake signal, the external device then transmits data to the PC or receives data from the PC.
  • the data transfer is primarily limited to the maximum speed at which the I/O instructions can be executed. There are approximately twice as many instructions required for 4-bit transfers of data as are required for 8-bit transfers of data. Thus, the maximum data transfer rate for a 4-bit transfer is only about half the rate of an 8-bit transfer. (Of course to send 8-bit data to an external device, the 8-bit mode can be used since all IBM PC compatible parallel I/O ports are designed to transmit data on the DATA lines.) In order to reach the maximum data transfer rates there must be as few instructions (especially I/O instructions) as possible in the driver software which controls the data transfer.
  • the PC can begin to execute its I/O and data write instructions without having to wait for the external device to become ready. The reason is that when reading data the next unit of information will be available to be read by the time the PC reaches the input I/O instruction in its program. Similarly, when the PC is writing data to the external device, the external device will accept the data immediately upon receiving the signal that tells it to accept the data. It will then be ready to accept the next unit of data from the PC by the time the PC reaches the next instruction that tells the external device to accept the next unit of data.
  • the ALWAYS READY approach allows the PC software instructions to be minimized. This, in turn maximizes the data transfer through the PC's parallel I/O port, regardless of whether the PC is writing data to an external device in 8-bit mode or reading data from an external device in 4-bit mode or 8- bit mode.
  • the invention is an apparatus for transferring information from a first electronic device to a second electronic device.
  • the two electronic devices are connected by a plurality of lines, including a first plurality of data lines and a second plurality of additional lines.
  • the first data lines are for the unidirectional parallel transfer of signals representing data information from the second electronic device to the first electronic device.
  • the second additional lines are for the transfer of signals representing additional information between the first electronic device and the second electronic device.
  • the apparatus comprises a first circuit in the first electronic device and a second circuit in the second electronic device.
  • the first circuit is connected to the first plurality of data lines and to the second plurality of additional lines. It is also adapted to receive control signals from the second electronic device over the first plurality of data lines, and it is further adapted to transmit data signals over the second plurality of additional lines in response to the control signals.
  • the second circuit in the second electronic device is connected to the first plurality of data lines and to the second plurality of additional lines. It is also adapted to transmit the control signals to the first electronic device over the first plurality of data lines, and it is further adapted to receive the data signals transmitted by the first circuit over the second plurality of additional lines in response to the control signals.
  • the invention is an apparatus for transferring information from a first electronic device to a second electronic device.
  • the two electronic devices are connected by a plurality of lines, including a first plurality of data lines and a second plurality of additional lines .
  • the data lines are for the unidirectional parallel transfer of signals representing data information from the second electronic device to the first electronic device.
  • the second plurality of additional lines are for the transfer of signals representing additional information between the first electronic device and the second electronic device.
  • the apparatus comprises a first circuit in the first electronic device and a second circuit in the second electronic device.
  • the first circuit is connected to the first plurality of data lines and to the second plurality of additional lines.
  • the first circuit is also adapted to receive control signals from the second electronic device over the first plurality of data lines, and is further adapted to transmit data signals over the second plurality of additional lines in response to the control signals.
  • the second circuit in the second electronic device is connected to the first plurality of data lines and to the second plurality of additional lines. It is also adapted to transmit the control signals to the first electronic device over the first plurality of data lines, and further adapted to receive the data signals transmitted by the first circuit over the second plurality of additional lines in response to the control signals.
  • the invention is a method for transferring information from a first electronic device to a second electronic device.
  • the two electronic devices are connected by a plurality of lines, including a first plurality of data lines and a second plurality of additional lines.
  • the first plurality of data lines is for the unidirectional parallel transfer of signals representing data information from the second electronic device to the first electronic device.
  • the second plurality of additional lines is for the transfer of signals representing additional information between the first electronic device and the second electronic device.
  • the method includes the steps of a) installing a first circuit in the first electronic device and b) installing a second circuit in the second electronic device.
  • the first circuit is installed to connect to the first plurality of data lines and to the second plurality of additional lines, to receive control signals from the second electronic device over the first plurality of data lines, and also to transmit data signals over the second plurality of additional lines in response to the control signals.
  • the second circuit is installed to connect to the first plurality of data lines and to the second plurality of additional lines, is adapted to transmit the control signals to the first electronic device over the first plurality of data lines, and is further adapted to receive the data signals transmitted by the first circuit over the second plurality of additional lines in response to the control signals.
  • the invention is an apparatus for transferring information from a first electronic device to a second electronic device, where the two electronic devices are connected by a plurality of control lines for the transmission of signals.
  • the apparatus comprises a first circuit and a second circuit.
  • the first circuit is in the first electronic device and connected to the plurality of control lines.
  • the second circuit is in the second electronic device, the second circuit being connected to the plurality of control lines.
  • the signals transmitted over the control lines include one or more event occurrence signals having separate portions occurring in distinct time intervals. Portions of the event occurrence signal that occur in consecutive distinct time intervals are transmitted over different lines in the second plurality of additional lines according to a predetermined order.
  • the invention is a method for transferring information from a first electronic device to a second electronic device, where the two electronic devices being connected by a plurality of control lines for the transmission of signals.
  • the method comprises the steps of a) forming a first circuit in the first electronic device, where the first circuit is connected to the plurality of control lines, and b) forming a second circuit in the second electronic device, where the second circuit is connected to the plurality of control lines, the first and second circuits being adapted so that the signals transmitted over the control lines include an event occurrence signal having segments, wherein different consecutive segments of the event occurrence signal are transmitted over different lines in the plurality of control signal lines.
  • Figure 1 is a schematic diagram of a prior art "high speed" 4-bit transfer of data from an external device.
  • Figure 2 is a schematic diagram of a prior art conventional 8-bit transfer of data from an external device.
  • Figure 3 is a schematic diagram of a prior art "high speed" 8-bit transfer of data from an external device.
  • Figure 4 is a schematic diagram of a portion of a typical parallel I/O port hardware design known in the prior art.
  • Figure 5 is a timeline showing the data access delays caused by the typical parallel I/O port hardware design shown in Figure 4.
  • Figure 6 is a timeline showing the response of a first preferred embodiment of the invention.
  • Figure 7 is a timeline showing the response of a second preferred embodiment of the invention.
  • Figure 8 is a timeline showing the response of a third preferred embodiment of the invention.
  • Figure 9 is a timeline showing the response of a fourth preferred embodiment of the invention.
  • Figure 10 is a timeline showing the response of a fifth preferred embodiment of the invention.
  • Figure 11 is a timeline showing the response of a sixth preferred embodiment of the invention.
  • Figure 12 is a timeline showing the response of a seventh preferred embodiment of the invention.
  • Figure 13 is a block diagram of interconnected I/O ports in accordance with the prior art.
  • Figure 14 is a block diagram of interconnected I/O ports in accordance with the present invention.
  • Figure 15 is a flowchart showing the operations performed by the software shown in Table 4.
  • Figure 16 is a flowchart showing the operations performed by the software shown in Table 5.
  • Figure 17 is a flowchart showing the operations performed by the software shown in Table 6.
  • Figure 18 is a flowchart showing the operations performed by the software shown in Table 7.
  • Figure 19 is a flowchart showing the operations performed by the software shown in Table 10.
  • Figure 20 is a flowchart showing the operations performed by the software shown in Table 11.
  • Figure 21 is a flowchart showing the operations performed by the software shown in Table 12.
  • All of the aspects of the invention relate to the process of transferring data to or from an external device via another device's parallel I/O port.
  • These aspects can either be embodied in the form of hardware or in the form of software operating on a programmable device. These designs, regardless of whether they are realized in hardware or software, or some combination of the two, provide specific mechanisms that work with the programmable device (for example, the PC) .
  • the data, control or status signals may be transferred either through a wired cable or through a wireless communication channel, such as one operating by the transmission and receipt of infrared (IR) and/or radio frequency (RF) electromagnetic signals.
  • IR infrared
  • RF radio frequency
  • the design of the external device must also accommodate operation with the hardware or software aspects of this invention.
  • the external device must provide hardware logic which can respond to the PCs handshake signal with the correct timing. This is necessary so that data being read from the device is available at the proper time to allow the PC driver software to read it correctly (whether reading data in 8- bit mode via the DATA port or in 4-bit mode via the STATUS port) .
  • FIG 14 is a block diagram of interconnected I/O ports in accordance with the present invention.
  • the present invention is a method and apparatus for communication over a parallel port 250 connected between a first device 252 and a second device 254.
  • the port 250 is an I/O port which has a modified function from the I/O port known in the prior art.
  • the port 250 includes "DATA" lines 256 and "ADD'L" lines 258 which are interconnected between the first and second devices 252 and 254.
  • the communication between the first and second devices 252 and 254 is for the purpose of transmitting information from the first device 252 to the second device 254.
  • the parallel port 250 is structured to transfer data bidirectionally between the first device 252 and the second device 254 over the "DATA" lines 256.
  • the "ADD'L” lines 258 are unidirectional lines used to transfer information other than data information from the first device 252 to the second device 254.
  • the "DATA" lines 256 and the "ADD'L” lines 258 are connected between first and second circuits 260 and 262, which are formed within the first and second devices 252 and 254, respectively.
  • the first and second circuits 260 and 262 can take the form of physical components, such as a logic circuit, or the form of standard PC circuitry which is reconfigured in accordance with a software program that is loaded into and run by the standard PC circuitry.
  • the "Add'l" lines 258 are used to transfer data unidirectionally from the first circuit 260 in the first device 252 to the second circuit 262 in the second device 254.
  • the "DATA" lines 256 are used to transfer control signals from the second circuit 262 in the second device 254 to the first circuit 260 in the first device 252.
  • the invention uses multiple CONTROL signal lines to reduce or eliminate timing delay. This allows 8- bit data transfers to be as fast as the PC is able to execute I/O instructions.
  • This aspect of the invention is an improvement over most parallel I/O ports, in which the CONTROL port signals are typically driven with conventional open collector driver chips. Accordingly, when a CONTROL port signal is driven low, there is very little signal delay. However, when that same signal is driven high, long delays can occur between the time the driver software executes the instruction that sets the signal HIGH and the point at which the signal actually reaches a high level. Because of this, the device logic hardware and software is designed to recognize only the falling edges of the CONTROL port signals during critical data transfer times.
  • At least two CONTROL port signals are used, so that while one signal is recovering from a low to high transition, another signal can be used to signal an I/O operation by a high to low transition.
  • the external device is designed to access and transfer the first byte of data when CONTROL signal 1 transitions from a high to a low level.
  • the second byte is accessed and transferred when CONTROL signal 2 transitions from a high level to a low level, and so on.
  • the logic is designed to ignore the CONTROL signal levels during the data transfer cycles except for any high to low transitions.
  • Figure 6 is a timeline showing the response of a first preferred embodiment of the invention
  • Figure 7 is a timeline showing the response of a second preferred embodiment of the invention
  • Figure 8 is a timeline showing the response of a third preferred embodiment of the invention.
  • this type of design allows the driver software to reduce the timing delays it normally has to add after changing the state of the CONTROL port signals . This results in significantly faster I/O code and higher data throughput than is known in the prior art .
  • a downward transition 86 in the second CONTROL signal 88 begins the handshake process for byte 2 (at time 90) , shortly after which the data for byte 2 is valid.
  • the first CONTROL signal 82 recovers from its downward transition 80, and is ready to incur another downward transition 92 to cause the required handshake signal for transfer of byte 3.
  • this rotating handshake technique can be generalized to more than only two CONTROL signals.
  • the order of rotation can be any one of many possibilities, including a fixed cyclic rotation (for example, ...,1,2,3,1, ...) , any other fixed periodic order (for example,
  • Figures 7 and 8 are similar to Figure 6.
  • Figure 7 shows a rotating handshake technique using transitions in CONTROL port signals to cause handshaking for transfer of each unit of information (e.g., nibble of data) where the two CONTROL port signals are used alternately.
  • Figure 8 is very nearly the same as Figure 7, except that Figure 8 shows that the handshake signals occur during the times that the units of information
  • WordTransferLoop out dx, al output 1st CONTROL handshake - high to low transition dec dx point dx at DATA port I/O address dec dx insb input byte of data from device - write data directly to memory inc dx point dx at CONTROL port I/O address inc dx xchg al, ah get the second handshake level out dx, al output 2nd to CONTROL handshake - low to high transition dec dx point dx at DATA port I/O address dec dx insb input byte of data from device - write data directly to memory inc dx point dx at CONTROL port I/O address inc dx xchg al, ah get the second handshake level loop WordTransferLoop loop until all data is transferred...
  • Figure 15 is a flowchart showing the operations performed by the software shown in Table 4. From the start of the code, or software, (block 280) shown in Figure 15, the next operation is to store the memory buffer pointers, the handshake values, the I/O address registers, and the number of words to be read from the external device (block 282, software lines 1-4) . Following this operation, the handshake value is written to the CONTROL port (block 284, software line 5), and then the I/O port address register is changed to the DATA port (block 286, software lines 6 and 7) . Next, the first byte of the data word is read from the DATA port directly in the memory buffer and the memory buffer pointer is incremented (block 288, software line 8) .
  • the I/O port address register is changed to the CONTROL port (block 290, software lines 9-10) and the handshake value is changed (block 292, software line 11) .
  • the handshake value is changed, it is written to the CONTROL port (block 294, software line 12) .
  • the I/O port address register is then again changed to the DATA port (block 296, software lines 13-14) .
  • the register changed the second byte of the data word is read from the DATA port directly into the memory buffer and the memory buffer pointer is incremented (block 298, software line 15) .
  • the I/O port address register is changed to the CONTROL port (block 300, software line 16) and the handshake value is changed (block 302, software line 18) .
  • the word counter (CX) is decremented and a test performed on its value (decision block 304) . Based on the results of that test, the loop including the blocks 284-302 is performed again (if all of the words have not been transferred) , or the end of the code is reached (block 306, if all of the words have been transferred) .
  • the WordTransferLoop portion of the program shown in Table 4 is based on a unit of information consisting of two bytes. A similar WordTransferLoop can be used if the unit of information is different from two bytes, as will be readily understood by those skilled in the art .
  • ByteTransferLoop out dx, al output 1st CONTROL handshake - high to low transition dec dx point dx at STATUS port I/O address insb input Nibble of data from device - write data directly to memory inc dx point dx at CONTROL port I/O address xchg al, ah get the second handshake level out dx, al output 2nd to CONTROL handshake - low to high transition dec dx point dx at STATUS port I/O address insb input Nibble of data from device - write data directly to memory inc dx point dx at CONTROL port I/O address xchg al, ah get the second handshake level loop ByteTransferLoop loop until all data is transferred...
  • Figure 16 is a flowchart showing the operations performed by the software shown in Table 5. From the start of the code, or software, (block 310) shown in Figure 16, the next operation is to store the memory buffer pointers, the handshake values, the I/O address registers, and the number of bytes to be read from the external device (block 312, software lines 1-4) . Following this operation, the handshake value is written to the CONTROL port (block 314, software line 5), and then the I/O port address register is changed to the STATUS port (block 316, software line 6) . Next, the first nibble of the data byte is read from the STATUS port directly in the memory buffer and the memory buffer pointer is incremented (block 318, software line 7) .
  • the I/O port address register is changed to the CONTROL port (block 320, software line 8) and the handshake value is changed (block 322, software line 9) .
  • the handshake value is changed, it is written to the CONTROL port (block 324, software line 10) .
  • the I/O port address register is then again changed to the STATUS port (block 326, software line 10) .
  • the register changed the second nibble of the data byte is read from the STATUS port directly into the memory buffer and the memory buffer pointer is incremented (block 328, software lines 11-12) .
  • the I/O port address register is changed to the CONTROL port (block 330, software line 13) and the handshake value is changed (block 332, software line 14) .
  • the byte counter (CX) is decremented and a test performed on its value (decision block 334, software line 15) . Based on the results of that test, the loop including the blocks 314-332 is performed again (if all of the bytes have not been transferred) , or the end of the code is reached (block 336, if all of the bytes have been transferred) .
  • the ByteTransferLoop portion of the program shown in Table 5 is based on a unit of information consisting of two nibbles.
  • a similar ByteTransferLoop can be used if the unit of information is different from two nibbles, as will be readily understood by those skilled in the art.
  • On most higher speed microprocessors it is more efficient to process the nibbles of data back into bytes or into their original form by having a separate segment of software that accomplishes the nibble processing.
  • the nibble processing may also be done within the nibble receiving software loop (and may be more efficient to do so on certain microprocessors) by simply modifying the instructions shown in Table 5 and adding the instructions necessary to process the received nibbles as they are received and before writing the data to the memory buffer. This would be readily understood by anyone skilled in the art.
  • WordTransferLoop outsb output byte of dau to device - write data directly to memory inc dx point dx at CONTROL port I/O address inc dx out dx, al output next CONTROL handshake - high to low transition dec dx point dx at DATA port I/O address dec dx xchg al, ah get the next hanrlRhaln. level outsb output byte of dau to device - write dau directly to p.
  • Figure 17 is a flowchart showing the operations performed by the software shown in Table 6. From the start of the code, or software, (block 340) shown in Figure 17, the next operation is to store the memory buffer pointers, the handshake values, the I/O address registers, and the number of words to write to the external device (block 342, software lines 1-4) . Following this operation, the first byte of the data word is written directly from the memory buffer to the DATA port and the memory buffer pointer is incremented (block 344, software line 5) . Then, the I/O port address register is changed to the CONTROL port (block 346, software line 6) and the handshake value is written to the CONTROL port (block 348, software lines 7-8) .
  • the I/O port address register is then again changed to the DATA port (block 350, software lines 9-10) and the handshake value is changed (block 352, software line 11) .
  • the register and handshake value changed, the second byte of the data word is written directly from the memory buffer to the DATA port and the memory buffer pointer is incremented (block 354, software line 12) .
  • the I/O port address register is changed to the
  • CONTROL port (block 356, software lines 13-14) and the handshake value is written to the CONTROL port (block 358, software line 15) .
  • the I/O port address register is changed once more to the DATA port (block 360, software lines 16-17) and the handshake value is changed (block 362, software line 18) .
  • the byte counter (CX) is decremented and a test performed on its value (decision block 364, software line 19) . Based on the results of that test, the loop including the blocks 344-362 is performed again (if all of the words have not been transferred) , or the end of the code is reached (block 366, if all of the bytes have been transferred) .
  • the WordTransferLoop portion of the program shown in Table 6 is based on a unit of information consisting of two bytes .
  • a similar WordTransferLoop can be used if the unit of information is different from two bytes, as will be readily understood by those skilled in the art.
  • the DATA port signals can be used for high-speed data transfer handshaking with an external device on a PC's parallel I/O port for the 4-bit mode.
  • This aspect of the invention uses the DATA port signal lines to reduce or eliminate timing delays, so that 4-bit data transfers can be as fast as the computer can perform I/O instructions.
  • Figure 9 is a timeline showing the response of a fourth preferred embodiment of the invention. As shown in connection with table 7, the embodiment has a timing-based handshake technique with a DATA port signal, where the rotation is between the alternating low-going and high-going transitions 100 and 102 of the DATA port signal 104. In this case, the handshake signal occurs between the periods 106 when the nibbles are valid.
  • Figure 18 is a flowchart showing the operations performed by the software shown in Table 7. From the start of the code, or software, (block 370) shown in Figure 18, the next operation is to store the memory buffer pointers, the handshake values, the I/O address registers, and the number of bytes to be read from the external device (block 372, software lines 1-4) . Following this operation, the handshake value is written the DATA port (block 374, software line 5) and then the I/O port address register is changed to the STATUS port (block 376, software line 6) . Next, the first nibble of the data byte is read directly from the STATUS port into the memory buffer and the memory buffer pointer is incremented (block 380, software line 7) .
  • the I/O port address register is changed to the DATA port (block 382, software line 8) and the handshake value is changed (block 384, software line 9) .
  • the handshake value is then written into the DATA port (block 386, software line 10) and the I/O port address register is changed to the STATUS port (block 388, software line 11) .
  • the register and handshake value changed, the second nibble of the data byte is written directly into the memory buffer from the STATUS port and the memory buffer pointer is incremented (block 390, software line 12) .
  • the I/O port address register is changed to the DATA port (block 392, software line 13) and the handshake value is changed (block 394, software line 14) .
  • the byte counter (CX) is decremented and a test performed on its value (decision block 396, software line 15) . Based on the results of that test, the loop including the blocks 344-362 (starting with software line 5) is performed again (if all of the bytes have not been transferred) , or the end of the code is reached (block 398, if all of the bytes have been transferred) .
  • the ByteTransferLoop portion of the program shown in Table 7 is based on a unit of information consisting of two nibbles. A similar ByteTransferLoop can be used if the unit of information is different from two nibbles, as will be readily understood by those skilled in the art.
  • nibble processing may also be done within the nibble receiving software loop (and may be more efficient to do so on certain microprocessors) by simply modifying the instructions shown in Table 5 and adding the instructions necessary to process the received nibbles as they are received and before writing the data to the memory buffer. This would be readily understood by anyone skilled in the art.
  • a first version of a timing mechanism is used to transfer data to or from an external device which does not require a handshake operation for every byte or nibble of data transferred.
  • Figure 10 is a timeline showing the response of a fifth preferred embodiment of the invention
  • Figure 11 is a timeline showing the response of a sixth preferred embodiment of the invention.
  • the invention works by having the PC or device which is sending data transmit the first byte 120 (or nibble 140) of data, and then, during the transmission of the first byte 120 (or nibble 140) of data, cause the state of a CONTROL signal 122 (or DATA handshake signal 142) to change in a transition 124 (144) .
  • the receiving device After the transition 122 (or 144) in the CONTROL signal, the receiving device transmits a predetermined additional number (say, four) of bytes 126 (or nibbles 146) before the receiving device causes a transition 128 (148) in its CONTROL signal 130 (remote handshake signal 150) .
  • the CONTROL signal 122 DATA handshake signal 142 transitions in the opposite sense, causing the transfer of another predetermined number of bytes 132 and 134 (nibbles 152 and 154) .
  • the bytes 126 or 134 are transmitted at specifically timed intervals, under control of a conventional clocking mechanism (not shown) .
  • the receiving PC or device simply reads data at specifically timed intervals after detecting that the CONTROL signal has changed state and then changes the state of a handshake signal when it has finished reading the sending device's data.
  • DoubleWordTransferLoop outsb output bytel of dau to device-write dau directly to parallel port from memory in al,61h I/O instruction used to provide specific tuning period of 1.0 to 1.5 usec.
  • WA ⁇ _FOR_RECEIVER_HANDSHAKE in al.dx -read STATUS port test al, RECEIVE HSH ; has receiver responded to our handshake? If not... keep waiting.. jz WAIT FOR RECEIVER HANDSHAKE dec dx point dx at DATA port I/O address outsb output bytel of dau to device-write dau directly to parallel port from memory in al. ⁇ lh I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. inc dx point dx at CONTROL port I/O address inc dx mov al, DeviceRoutingHandshake 1 in al.
  • WAIT_FOR_RECEIVER_HANDSHAKE in al.dx ;read STATUS port test al, RECEIVE HSH ; has receiver responded to our handshake? If not... keep waiting... jnz WA_T_FOR_RECEIVER_HANDSHAKE loop WordTransferLoop ; loop until all dau is transferred...
  • DoubleWordTransferLoop portion of the program shown in Table 8 is based on a unit of information consisting of two bytes.
  • a similar DoubleWordTransferLoop can be used if the unit of information is different from two bytes, as will be readily understood by those skilled in the art.
  • DoubleWordTransferLoop WAIT_FOR_SENDER_HANDSHAKE: in al.dx ; read STATUS port test al, RECEIVE HSH ; has sender handshake changed rinse? - If not...keep waiting... jnz WA ⁇ _FOR_SENDER_HANDSHAKE insb ; input bytel of dau from device - read dau directly into memory in al. ⁇ lh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec.
  • inc dx point dx at CONTROL port I/O address inc dx ; insb ; input byte4 of dau from device - read dau directly into memory in al. ⁇ lh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. insb ; input byte4 of dau from device - read dau directly into memory in al. ⁇ lh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec.
  • WAIT_FOR_SENDER_HANDSHAKE in al.dx ;read STATUS port test al, RECEIVE HSH ; has sender handshake changed rinse? - If not...keep waiting... jz WA ⁇ T_FOR_SENDER_HANDSHAKE insb ; input bytel of dau from device - read dau directly into memory in al. ⁇ lh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. inc dx ; point dx at CONTROL port I/O address inc dx ; insb ; input byte2 of dau from device - read dau directly into memory in al. ⁇ lh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec.
  • DoubleWordTransferLoop portion of the program shown in Table 9 is based on a unit of information consisting of two bytes.
  • a similar DoubleWordTransferLoop can be used if the unit of information is different from two bytes, as will be readily understood by those skilled in the art.
  • a second version of a timing mechanism is used to transfer data to or from an external device.
  • the handshake consists of a signal from the first device to the second device without a corresponding return signal from the second device to the first device.
  • Figure 12 is a timeline showing the response of a seventh preferred embodiment of the invention. Tables 10-12 show programs for accomplishing the advantage of this embodiment, by the storage of nibbles of data which are later reconstructed by the receiving device.
  • a DATA handshake signal 160 includes downward- and upward-going transitions 162 and 164 which occur during corresponding periods when the nibbles to be transferred are valid.
  • the handshake signal occurs at the corresponding times 166 of the transitions 162 and 164.
  • the data and the data handshake signal state are stored in sequential locations in memory, where the first location in memory stores a first nibble, along with the state of the corresponding data handshake signal 162.
  • the second location contains nibble 2 and the state of data handshake signal 164, and so on.
  • the second device reads each of these memory locations sequentially and then transmits them one after the other until the entire set of data and data handshake information has been sent.
  • the data handshake signal and the nibble data are transmitted simultaneously because they are stored together in the same memory location and transmitted in response to the same I/O instructions.
  • Table 10 On entry... ES:SI register pair points to send dau buffer
  • ByteTransferLoop read next Nibble to send out dx, al ; output byte of dau to Receiving device via DATA po ⁇ out dx, al ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. out dx, al ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. lodsb ; read next Nibble to send oouutt ddxx,, aall ; output byte of dau to Receiving device via DATA po ⁇ out dx, al ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. out dx, al ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. loop ByteTransferLoop ; loop until all dau is transferred...
  • Figure 19 is a flowchart showing the operations performed by the software shown in Table 10. From the start of the code, or software, (block 410) shown in Figure 19, the next operation is to store the memory buffer pointers, the I/O address registers, and the number of nibbles to be read from the external device (block 412, software lines 1-2) . Following this preliminary operation, the nibble data and handshake combination is read from the memory buffer and the memory buffer pointer is incremented (block 414, software line 3) . Then, the combination nibble data and handshake value is written to the DATA port (block 416, software line 4) .
  • a wait of 1.0 to 1.5 microseconds is caused (block 418, software line 5), followed by another wait of 1.0 to 1.5 microseconds (block 420, software line 6) .
  • the byte counter (C) is decremented and a test performed to determine whether all of the nibbles have been transferred (decision block 422, software line 11) . Based on the results of that test, the loop including the blocks 414-420 is performed again (if all of the words have not been transferred), or the end of the code is reached (block 424, if ali of the nibbles have been transferred) .
  • the WordTransferLoop portion of the program shown in Table 10 is based on a unit of information consisting of two nibbles. A similar WordTransferLoop can be used if the unit of information is different from two nibbles, as will be readily understood by those skilled in the art.
  • WAIT_FOR_SENDER_TO_START in al.dx ; wait for sending PC or device to sun sending die block of dau test al, DATA_HANDSHAKE jz WATT_FOR_SENDER_TO_START
  • Figure 20 is a flowchart showing the operations performed by the software shown in Table 11. From the start of the code, or software, (block 430) shown in Figure 20, the next operation is to store the memory buffer pointers, the I/O address registers, and the number of nibbles to be read from the external device (block 432, software lines 1-2) . Following this preliminary operation, a test is performed to determine whether the sending device has started (block 434, software lines 3-5) . If the device has not started sending, the program control returns to the block 434 (software line 3) ,* if the device has started sending, the program moves to the step shown in block 436.
  • the nibble data and handshake combination are read directly from the STATUS port into the memory buffer and the memory buffer pointer is incremented (block 436, software line 6) .
  • the counter (CX) is decremented and it is determined whether all of the nibbles have been transferred (decision block 438, software line 7) .
  • the loop including the blocks 436-438 (software lines 6-7) is performed again (if all of the nibbles have not been transferred) , or the end of the code is reached (block 440, if all of the nibbles have been transferred) .
  • the ByteTransferLoop portion of the program shown in Table 11 is based on a unit of information consisting of two nibbles.
  • a similar ByteTransferLoop can be used if the unit of information is different from two nibbles, as will be readily understood by those skilled in the art.
  • LOOK FOR VALID NIBBLE 1 lodsb ; get received Nibble from input buffer test al, NIBBLE HANDSHAKE ; has Dau Handshake changed doctor? jz LOOK_FOR_V ALID_NIBBLE 1 lodsb ; get valid Nibble from input buffer mov ah, al ; save Nibble for a little while in ah
  • LOOK_FOR_VALID_NIBBLE2 lodsb get received Nibble from input buffer test al, NIBBLE HANDSHAKE has Dau Handshake changed 9? jnz LOOK_FOR_VALID_NIBBLE2 lodsb get valid Nibble from input buffer shr al, 4 move low order nibble into original byte position and ah, OFOh strip off extra bits or al, ah restore original byte stosb store byte in output buffer cmp si, cx test if the input buffer has been completely processed jl LOOK_FOR_V ALID_NIBBLE 1 keep processing until end of input buffer
  • Figure 21 is a flowchart showing the operations performed by the software shown in Table 12. From the start of the code, or software, (block 450) shown in Figure 21, the next operation is to store the memory buffer pointers and the number of combination nibble data and handshake bytes to process (block 452, software lines 1-2) . Following this preliminary operation, the next byte of combination nibble data and handshake is read from the memory buffer and the memory buffer pointer is incremented (block 454, software line 3) . Then a test is performed on the handshake bit (block 456, software line 4) . If the handshake bit has changed state, the program moves forward; otherwise, the program returns to the step represented by block 454.
  • the valid nibble data and handshake combinations are saved (block 458, software lines 5-7) .
  • the next byte of combination nibble data and handshake is read from the memory buffer and the memory buffer pointer is incremented (block 460, software line 8) .
  • a test is performed to determined whether the handshake bit has changed state. If it has not changed state, the program returns to the step represented by the block 460; otherwise, the program moves forward.
  • valid nibble and handshake combinations are processed with previously saved nibble and handshake combinations to rebuild the original byte and to store it in memory (block 464, software lines 10-15) .
  • the counter (CX) is decremented and it is determined whether all of the bytes have been processed (decision block 466, software line 16) . Based on the results of that test, the loop including the blocks 454-466 (software lines 3-17) is performed again (if all of the words have not been transferred) , or the end of the code is reached (block 468, if all of the bytes have been processed) .
  • the LOOK_FOR_VALID_NIBBLEl and LOOK_FOR_VALID_NIBBLE2 portions of the program shown in Table 12 are based on units of information each consisting of one nibble. Similar other portions can be used if the unit of information is different from one nibble, as will be readily understood by those skilled in the art. While the foregoing is a detailed description of the preferred embodiment of the invention, there are many alternative embodiments of the invention that would occur to those skilled in the art and which are within the scope of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Systems (AREA)

Abstract

A method and apparatus for communication over a parallel port (250). The I/O port (250) of a first electronic device (such as a PC) is connected to the I/O port of a second electronic device (such as a PC). In the prior art, DATA lines, CONTROL lines and STATUS lines connecting the I/O ports are used to transfer data, control (including strobe) and status signals, respectively, between the first and second electronic devices (204, 206). In an important disclosed embodiment of the present invention, a subset of the DATA lines (256) are used to transmit data signals. In another important disclosed embodiment of the present invention, consecutive portions of the strobe signal are transmitted over different ones of the DATA lines in a predetermined order. This allows a faster transmission of data by transmitting the strobe signal over a different DATA line while the DATA line that was just used recovers. In an additionally disclosed embodiment, faster transmission of data is also accomplished by allowing the I/O ports (250) to respond to both positive and negative-going transitions.

Description

Description
METHOD AND APPARATUS FOR COMMUNICATION OVER A PARALLEL PORT
Technical Field
The present invention relates to methods and apparatus for communication, and more particularly, to methods and apparatus for communication between electronic devices over a parallel port.
Background of the Invention
It is common for one electronic device (say, a personal computer - PC) to communicate information to an external electronic device (say, a printer) over an interconnection. Typically this interconnection is a wire cable configured for the specific purpose. One popular standard for communication between a PC and a printer is the Centronics standard. According to this standard, the information is transmitted in parallel form, so that all of the bits that make up each unit of information are transmitted simultaneously to the external device over separate lines in the wire cable.
There are many protocols for communication between two electronic devices according to the scenario described above. Generally there is a "handshake" phase in which each of the two electronic devices confirms the presence of, and correct interaction or interconnection with, the other device. Next the device that is the source of the information prepares the first unit of information to be transmitted. After the unit of information is prepared and transmitted on the data lines, the information source sends a control signal to the information recipient to notify the recipient. The information recipient configures itself for receipt of the information and sends an acknowledgement signal back to the signal source, typically on a status signal, verifying that the unit of information was received. This process is then repeated until all of the intended information has been transmitted. As technology has progressed, a number of different protocols have developed, and so has the need for higher speed transfer of information between two electronic devices. As a result, certain standards for such protocols have been developed. As one example, some of these standards are described in "Standard Signaling Method for a Bi-directional Parallel Peripheral
Interface for Personal Computers," IEEE P1284 D2.00, published in draft form on September 30, 1993 and approved on March 30, 1994.
This document, which distinguishes compatible/standard I/O ports from the extended capabilities port (ECP) and the enhanced parallel port (EPP) , is hereby incorporated by reference. In accordance with such standards, it is important to be able to interconnect two electronic devices regardless of their own individual protocols. Further, once the two electronic devices are interconnected, for most applications it is important that the transfer of information be as fast as possible.
Heretofore, increased information transmission speeds have been realized by using signals for purposes other than those for which they were originally intended. For example, wires that were originally intended for the unidirectional transfer of notification and acknowledgement signals are also used to transfer additional bits of the information, thereby increasing the information transmission speed. However, this approach typically requires changes in the software (and, possibly, the hardware) of the information source and recipient devices. If the source and recipient devices are then later used in other configurations, it may be necessary to change the software or hardware again for this new use. One standard of communication between a personal computer (PC) and external devices that was established soon after PCs became available in the above-mentioned Centronics standard. This standard was originally established to facilitate communication between a PC and a Centronics (or compatible/standard) printer with a parallel I/O port which provided a number of parallel lines. The typical parallel I/O port has twenty-five lines - seventeen signal lines and eight ground lines.
Figure 13 is a block diagram of interconnected I/O ports in accordance with the prior art. As shown in Figure 13, the two
I/O ports 200 and 202, are respectively parts of first and second electronic devices 204 and 206. The two I/O ports 200 and 202 are interconnected by a plurality of parallel lines 208. This plurality of lines is divided into functional subsets. One subset, the DATA lines 210 are used to transfer the parallel signals representing data from one electronic device to the other. Another subset, the CONTROL lines 212, are used to transfer control signals from one electronic device to the other. The third subset, the STATUS lines 214, are used to transfer status signals between the two electronic devices in the direction opposite to the direction in which the CONTROL lines 212 carry their signals.
Under the implementation of the Centronics standard as applied to the IBM PC, the parallel port signal lines were placed into three categories: DATA signals, STATUS signals and CONTROL signals. At any point during the transmission of data, the eight DATA signal lines (labelled DATA1 through DATA8) each carried a specific one of the eight bits of the data word (the unit of information) that is being transmitted. Today, the CONTROL signal lines are sometimes bidirectional, although the Centronics standard only called for them to be unidirectional (from the PC to the Centronics compatible/standard external device) . The five STATUS signals (typically labelled BUSY, ACKNOWLEDGE, SELECT_IN, PAPER ERROR, and FAULT) were unidirectional from the external device to the PC and provided status indications from the external device to the PC. The four CONTROL signals (typically labelled STROBE, AUTOFEED, INIT and SELECT IN) were intended to be unidirectional from the PC when sending data to a printer and provided signals necessary to control transfer of the data on the DATA lines to the external device. One of the implementations that exploited the bidirectionality of some of the signals in the IBM PC's implementation of the Centronics standard is exemplified by the specification and claims of U.S. Patent No. 5,293,497. That patent is directed toward transmission of some data between the CONTROL registers of the two computers and transmission of the remainder of the data from the DATA output register of the sending computer to the STATUS register of the receiving computer.
It has generally been known from the schematics of the IBM PC (which were published with the reference manual at the PC's introduction in 1982) that some of the signal lines (including the CONTROL lines) in the PC's parallel I/O port had bidirectional capability. Also, the parallel I/O port has come to be widely used for parallel communication with a number of external devices besides printers. These additional external devices include software security keys, parallel I/O port network adapters, parallel I/O port hard disk products and other peripherals. Accordingly, there has been greater interest in providing a high-speed bidirectional data transfer capability between an external device and a PC (or other device equipped with a parallel I/O port) . If the two devices which are to communicate are both equipped with 8-bit bidirectional parallel I/O ports, transfer of data is relatively straightforward. However, if one of the devices does not have 8-bit bidirectional capability, it is possible to accomplish data transfers by transferring fewer bits at a time, say 4 bits in parallel at a time, by using 4 of the 5 STATUS lines. The actual choice of which STATUS lines are used affects how fast the data can be transferred in 4-bit mode.
Currently, on standard/compatible parallel I/O ports, the speed at which data can be transferred to or from an external device is directly affected by several factors. These factors include a) processor speed and the signal line choices for data transfer and control, b) the length of any cable necessary to connect the two devices, and c) the software instructions used to access the data through the parallel I/O port.
The technique most commonly used to control the transfer of data from an external device to a PC (or between two PCs) is to have the driver software in the PC set a CONTROL signal for receipt by the external device. The external device responds in one of two ways, depending on whether it is equipped with an 8- bit bidirectional parallel I/O port. If the external device has an 8-bit bidirectional parallel I/O port, it prepares all 8 bits of the data for transmission over the DATA signal lines. If the external device does not have an 8-bit bidirectional parallel I/O port, it prepares the data in smaller units, (say, four bits at a time) for transmission over a predetermined four of the five STATUS signal lines. The driver software in the PC then reads the data from the appropriate place (i.e., 8-bit bidirectional parallel I/O port, or four of the STATUS signal lines) , stores the data, and then toggles the logic sense of a "CONTROL" signal to indicate to the external device to send the next unit of information.
The LapLink method of data transfer between two PCs is typical of the process described above. Most Laplink-like file transfer programs use the DATA port exclusively for both control and data transfers. The use made of the DATA port depends upon whether data or other information is being transferred. If data is being transferred, four of the DATA signals are assigned to carry data and another one of the DATA signals is assigned to carry a handshake signal (i.e., a signal to facilitate a handshake between devices) . In this method, the data is transferred from one PC to the other, four bits (one nibble) at a time. At other times, the DATA signals may transmit other control or status information from one PC to the other.
Specifically, in one common configuration, data is carried, a nibble at a time, from one PC to the other from the D1-D4 signal lines of the first PC's DATA port respectively to the ERROR, SELECT, PAPER and ACKNOWLEDGE signal lines of the other PC's STATUS port. The D5 signal line of the first PC is used to handshake with the BUSY STATUS signal line of the other PC.
In this specific configuration, when the first PC has the least significant nibble (LSN) of the current byte of data ready, the first PC initiates transfer, either by toggling the DATA port signal D4 or by setting the handshake DATA port signal (D5) . In the first case, the toggled DATA port signal D4 causes the ACKNOWLEDGE signal on the other PC to toggle. In the second case, setting the handshake DATA port signal invites the other PC to respond by setting its own handshake DATA port signal, which the first PC receives on the BUSY signal line of its STATUS port.
Once the two PCs are properly synchronized, the first PC sends the other PC a data packet. It does this by transmitting the first nibble of data on the DATA port signals D1-D4 and then changing the state of the dedicated handshake DATA port signal D5. The other PC monitors the STATUS port BUSY signal, waiting for the handshake signal from the first PC. When the second PC detects the handshake signal, it reads the nibble of data from its STATUS port signals ACKNOWLEDGE, PAPER, SELECT and ERROR, and then changes the state of its own dedicated handshake DATA port signal D5. The first PC simultaneously monitors its own STATUS port BUSY signal, waiting for the other PC to respond to its handshake signal. When the first PC detects a change in the BUSY signal, it recognizes that the second PC has read the transmitted nibble of data and can then transmit the next nibble. This process continues until all of the data is transferred. Those skilled in the art will recognize that the choice of signals to be used for data and handshakes is generally arbitrary.
Figure 1 is a schematic diagram of a prior art "high speed" 4- bit transfer of data from a first external device 16 (such as a PC) to another device 18. In the case of such "high speed" 4-bit data transfers, the first external device 16 divides each 8-bit byte 20 of the data to be sent into two 4-bit "nibbles," designated the "least significant nibble" (LSN) 22 and the "most significant nibble" (MSN) 24. A nibble selector signal 26 (normally one of the CONTROL or DATA signal lines) is used to select whether the LSN 22 or the MSN 24 of the current byte 20 will be presented to the STATUS port by the external device. Typically, due to conventional control logic in the CONTROL signal line and in the external device, the nibble 22 or 24 to be sent is not immediately available after the nibble selector signal 26 is toggled. The external device is signalled that the receiving device is ready for another byte 20 of data through impulses in a "Get Next Byte" signal 28, typically coincident with (but not necessarily) every transition of the nibble selector signal 26. Then the external device is signalled that the receiving device is ready for another nibble 22 or 24 of data through impulses in a "Send Next Nibble" signal 30. The impulses in the "Get Next Byte" signal 28 are coincident with every other impulse in the "Send Next Nibble" signal 30. After the time that the receiving device transmits each of the impulses in the "Send Next Nibble" signal 30 coincident with every transition of nibble selector signal 26, the external device 16 has delays (and the CONTROL signal 26 may have delays) between the time the receiving device software commands signal 26 to change state and the point at which the nibble is available. This is called the "wait" period 32. During this "wait" period 32, the external device retrieves the requested nibble and has it ready to be read by the receiving device. The second device then transmits a "Nibble of Data Ready" signal 34 (typically on an additional signal line) having impulses at the times when the second device has prepared the requested nibble of data for transmission to the receiving device. Figure 2 is a schematic diagram of one typical implementation of a conventional 8-bit transfer of data from an external device, in accordance with the prior art. In the case of such conventional 8-bit data transfers, due to conventional control logic in the receiving device, the byte to be sent is available some time after a downward transition 40 in a complete toggle 42 of a "Byte Access Control" signal 44. The Byte Access Control signal 44 is typically one of the parallel I/O port's CONTROL signals (STROBE, INIT, AUTOFEED, or SELECT IN) . The external device is signalled that the receiving device is ready for another byte 46 of data through impulses in a "Send Next Byte" signal 48. After the time that the receiving device transmits each of the impulses in the "Send Next Byte" signal 48, coincident with every transition of signal 44, the external device 16 has delays (and the CONTROL signal 44 may have delays) between the time the receiving device software commands CONTROL signal 44 to change state and the point at which the byte is available. This is called the "wait" period 50. During this "wait" period 50, the external device retrieves the requested byte and has it ready to be read by the receiving device. The second device then transmits a "Byte Ready to be Read" signal 52 (for example, on an additional signal line) having impulses at the times when the second device has prepared the requested byte of data for transmission to the receiving device.
Figure 3 is a schematic diagram of a prior art "high speed" 8- bit transfer of data from an external device. In the case of such "high speed" 8-bit data transfers, the external device is capable of sending the data sometime after receiving each change 60 in the state of the "Byte Access and Selector Control" signal 62, which is typically one of the CONTROL signal lines. This capability is provided by conventional logic circuitry in the external device. The external device is signalled that the receiving device is ready for another byte 64 of data through impulses 66 in a "Send Next Byte" signal 68. After the time that the receiving device transmits each of the impulses 66 in the "Send Next Byte" signal 68, coincident with every transition of signal 62, the external device 16 has delays ( and the CONTROL signal 62 may have delays) between the time the receiving device software commands control signal 62 to change state and the point at which the byte is available. This is called the "wait" period 70. During this "wait" period 70, the external device retrieves the requested byte and has it ready to be read by the receiving device. The second device then transmits a "Byte Ready to be Read" signal 72 (for example, on an additional signal line) having impulses 74 at the times when the second device has prepared the requested byte of data for transmission to the receiving device. A comparison of Figures 2 and 3 shows that the primary difference between the conventional 8-bit transfer and the "high¬ speed" 8-bit transfer is in their response to the CONTROL signal lines that cause the external device to access the next byte to be transmitted. In the conventional transfer, the CONTROL signal is toggled to a low level and then back to a high level for each byte of data, whereas in the "high-speed" transfer, the external device is caused to access the next byte of data after each toggle of the CONTROL signal. This increases the data throughput capability of the external device since, for each byte of data, there are two fewer input/output (I/O) instructions required in the "high-speed" mode than in the conventional mode. Figure 4 is a schematic diagram of a portion of a typical parallel I/O port hardware design known in the prior art. The typical parallel I/O port has CONTROL port signals with open collector drivers having 3-6 kiloohm pullup resistors. This causes timing delays in the signals for external devices when these signals are used to control access or to provide status.
In addition, in many cases, manufacturers of PCs and parallel I/O port boards (for use in PCs and external devices) attach large capacitances to the CONTROL signal lines to help the PCs and the parallel I/O port boards pass Federal Communications Commission (FCC) test requirements. This practice contributes substantially to the delay times experienced on the CONTROL signal lines, in particular. These delays have heretofore reduced the effective transfer rate.
Figure 5 is a timeline showing the data access delays caused by the typical parallel I/O port hardware design shown in Figure 4. As an example, a portion of the ideal set of software instructions that is desirable to use for causing the transmission shown in Figure 5, and consequently causing the data from the external device to be read via the parallel I/O port, is shown in Table 1, below: Table 1
MOV DX, ontrol_Port_ Address ; this instruction sets the address of the CONTROL port MOV AL, Control_Signal_State ; sets up the value to be ouφut to the CONTROL signal lines OUT DX, AL ; output the new state of the CONTROL signal lines
MOV DX, Data_Port_ Address ; this instruction sets the address of the DATA port IN AL, DX ; read the DATA port to get data from external device
In this example the driver software in the computer has virtually no delay between the CONTROL signal line change (caused by the instruction in the third line in the software listing, shown as A2 in Figure 5) and its reading of the data from the external device (caused by the instruction in the fifth line in the software listing shown as A3, in Figure 5). (The software instruction listing of Table 1, and all other software listings in this application are written in an assembly language code specific to the IBM PC. Those skilled in the art of assembly language programming will understand how to write similar assembly language (or other language) 2programs for other computers, based on these examples.) Because of the timing delay introduced by the rise time of the CONTROL signal line, the external device does not recognize the change in the CONTROL signal line until point A4, which occurs after the computer has executed the instruction that reads the data from the DATA signal portion of the parallel I/O port. Therefore, typical designs require the driver software to have a wait period added to its instructions to read data from (or write data to) an external device via the parallel I/O port. This allows ample time for the CONTROL signal lines to settle and for the device to be ready before trying to read the data from the external device. In contrast to the software shown in Table 1, a "wait" period is provided by the wait loop that is added between the third and fifth lines of the software of Table 1, producing the revised software shown in Table 2, below (see the fifth through seventh lines of the software listing) : Table 2
MOV D Control_Port_ Address ; this instruction sets the address of the CONTROL port
MOV AL, Control_Signal_State ; sets up the value to be output to the CONTROL signal lines
OUT DX, AL ; output the new state of the CONTROL signal lines
MOV DX, Data_Port_ Address ; this instruction sets the address of the DATA port
MOV CX, Delay Count ; load CX with number of times to loop WAJT_HERE:
LOOP WAIT_HERE ; loop until CX=0
IN AL, DX ; read the DATA port to get data from external device
Another way that current external devices are designed to eliminate the ambiguities of timing caused by the delay in the CONTROL signal lines, cable capacitances, and device delays is to use one of the STATUS signals lines as a "WAIT" signal . The WAIT signal is set in one state by the external device when the device has data ready and in another state when the external device does not have data ready. The driver software can then read this "WAIT" STATUS signal to determine when the external device has data ready (if reading from the external device) or determine when the device has finished processing the data which was written to it (if writing to the external device) .
Typical software to accomplish this (when reading data from an external device) is shown in Table 3, below:
Table 3
MOV DX, ontrol_Port_ Address ; this instruction sets the address of the CONTROL port
MOV AL, Control_Signal_State ; sets up the value to be output to the CONTROL signal lines
OUT DX, AL ; output the new state of the CONTROL signal lines
MOV DX, Status_Port_ Address ; this instruction sets the address of the STATUS port
IN AL, DX ; get current state of the STATUS signal lines
WAIT 4 WATT STATUS: ; the code jumps back to here until "WAIT_Status_Signal" =true
TEST AL, WAIT_Status Signal test the level of the "WATT" STATUS signal line JZ WAIT_4_WA_T_STATUS keep waiting for the "WAIT" STATUS signal MOV DX, Data_Port_ Address this instruction sets the address of the DATA port
IN AL, DX read the DATA port to get data from external device
This approach makes the handshaking between the computer and the external device more reliable and less affected by timing differences due to parallel I/O port and hardware designs as well as cable capacitance and delays in the device getting data ready. However, the approach also has a major drawback due to the added instructions required in the driver software to read the STATUS signal line and the corresponding increase in time required to execute those instructions for each unit of information transferred.
The maximum theoretical data transfer through the parallel I/O port is defined by the absolute time that it takes to execute the I/O and other instructions on a particular PC and for its particular design. As the central processing units (CPUs) for the PC are made to execute instructions faster and faster, the time it takes to execute an I/O instruction has remained relatively constant at about 1.0 to 1.5 microseconds. This timing is regulated by the bus speed of the particular PC. To receive data through the parallel I/O port from an external device the instruction "IN AL, DX" is used. The corresponding output instruction is "OUT DX, AL" .
Because there is no automatic handshake transmission signal on compatible/standard PC parallel I/O ports, the PC driver software typically must toggle an output signal capable of use (either a DATA port signal or a CONTROL port signal) as a handshake signal. The handshake signal indicates to the external device that the PC is ready to send data or receive data. Upon detecting a change in the output handshake signal, the external device then transmits data to the PC or receives data from the PC.
For PCs having fast CPUs with very fast execution time of non-I/O instructions, the data transfer is primarily limited to the maximum speed at which the I/O instructions can be executed. There are approximately twice as many instructions required for 4-bit transfers of data as are required for 8-bit transfers of data. Thus, the maximum data transfer rate for a 4-bit transfer is only about half the rate of an 8-bit transfer. (Of course to send 8-bit data to an external device, the 8-bit mode can be used since all IBM PC compatible parallel I/O ports are designed to transmit data on the DATA lines.) In order to reach the maximum data transfer rates there must be as few instructions (especially I/O instructions) as possible in the driver software which controls the data transfer. Also, there must be little or no additional delays added to wait for external hardware to change state or to make data available to the receiving device or to receive data from the sending device. In general, there are typically four distinct ways for one electronic device to initiate I/O activity with another electronic device. These are: 1) for the first device to signal the second device that it is ready to receive information, 2) for the second device to signal the first device that it has information to transmit, 3) for the first device to poll all devices that are connected to it (including the second device) in order to determine whether any of the connected devices has information to transmit, and 4) for the first device to sample the second device to determine whether it has any information to transmit. While the foregoing description has discussed the first two ways for communication, it is also possible for the methods of the prior art to be used to support communication in the second two ways.
It is desirable to have alternative higher speed data transfer mechanism which would operate on a PC in conjunction with both the specific driver software instructions and the design of external devices which connect to and operate through the parallel I/O port of a PC.
Summary of the Invention The prior art described above has been improved in a way to increase the performance of the present-day parallel I/O port interface. This improvement results in the "ALWAYS READY" interface, a term that means the external device or PC is ready to respond to a CONTROL signal set by the PC (within a very short period of up to l microsecond, but typically around 500 nanoseconds) .
If the CONTROL signal is intended to cause the external device to accept data from the PC (i.e., the PC write mode), the PC can begin to execute its I/O and data write instructions without having to wait for the external device to become ready. The reason is that when reading data the next unit of information will be available to be read by the time the PC reaches the input I/O instruction in its program. Similarly, when the PC is writing data to the external device, the external device will accept the data immediately upon receiving the signal that tells it to accept the data. It will then be ready to accept the next unit of data from the PC by the time the PC reaches the next instruction that tells the external device to accept the next unit of data. The ALWAYS READY approach allows the PC software instructions to be minimized. This, in turn maximizes the data transfer through the PC's parallel I/O port, regardless of whether the PC is writing data to an external device in 8-bit mode or reading data from an external device in 4-bit mode or 8- bit mode.
According to one aspect, the invention is an apparatus for transferring information from a first electronic device to a second electronic device. The two electronic devices are connected by a plurality of lines, including a first plurality of data lines and a second plurality of additional lines. The first data lines are for the unidirectional parallel transfer of signals representing data information from the second electronic device to the first electronic device. The second additional lines are for the transfer of signals representing additional information between the first electronic device and the second electronic device. The apparatus comprises a first circuit in the first electronic device and a second circuit in the second electronic device. The first circuit is connected to the first plurality of data lines and to the second plurality of additional lines. It is also adapted to receive control signals from the second electronic device over the first plurality of data lines, and it is further adapted to transmit data signals over the second plurality of additional lines in response to the control signals.
The second circuit in the second electronic device is connected to the first plurality of data lines and to the second plurality of additional lines. It is also adapted to transmit the control signals to the first electronic device over the first plurality of data lines, and it is further adapted to receive the data signals transmitted by the first circuit over the second plurality of additional lines in response to the control signals. In a further aspect, the invention is an apparatus for transferring information from a first electronic device to a second electronic device. The two electronic devices are connected by a plurality of lines, including a first plurality of data lines and a second plurality of additional lines . The data lines are for the unidirectional parallel transfer of signals representing data information from the second electronic device to the first electronic device. The second plurality of additional lines are for the transfer of signals representing additional information between the first electronic device and the second electronic device.
The apparatus comprises a first circuit in the first electronic device and a second circuit in the second electronic device. The first circuit is connected to the first plurality of data lines and to the second plurality of additional lines. The first circuit is also adapted to receive control signals from the second electronic device over the first plurality of data lines, and is further adapted to transmit data signals over the second plurality of additional lines in response to the control signals. The second circuit in the second electronic device is connected to the first plurality of data lines and to the second plurality of additional lines. It is also adapted to transmit the control signals to the first electronic device over the first plurality of data lines, and further adapted to receive the data signals transmitted by the first circuit over the second plurality of additional lines in response to the control signals. Accordingly, in this aspect of the invention, at least one of the first and second electronic devices is a programmable computer. In a still further aspect, the invention is a method for transferring information from a first electronic device to a second electronic device. The two electronic devices are connected by a plurality of lines, including a first plurality of data lines and a second plurality of additional lines. The first plurality of data lines is for the unidirectional parallel transfer of signals representing data information from the second electronic device to the first electronic device. The second plurality of additional lines is for the transfer of signals representing additional information between the first electronic device and the second electronic device. The method includes the steps of a) installing a first circuit in the first electronic device and b) installing a second circuit in the second electronic device. The first circuit is installed to connect to the first plurality of data lines and to the second plurality of additional lines, to receive control signals from the second electronic device over the first plurality of data lines, and also to transmit data signals over the second plurality of additional lines in response to the control signals. The second circuit is installed to connect to the first plurality of data lines and to the second plurality of additional lines, is adapted to transmit the control signals to the first electronic device over the first plurality of data lines, and is further adapted to receive the data signals transmitted by the first circuit over the second plurality of additional lines in response to the control signals. In a still further aspect, the invention is an apparatus for transferring information from a first electronic device to a second electronic device, where the two electronic devices are connected by a plurality of control lines for the transmission of signals. The apparatus comprises a first circuit and a second circuit. The first circuit is in the first electronic device and connected to the plurality of control lines. The second circuit is in the second electronic device, the second circuit being connected to the plurality of control lines. The signals transmitted over the control lines include one or more event occurrence signals having separate portions occurring in distinct time intervals. Portions of the event occurrence signal that occur in consecutive distinct time intervals are transmitted over different lines in the second plurality of additional lines according to a predetermined order.
According to an event further aspect, the invention is a method for transferring information from a first electronic device to a second electronic device, where the two electronic devices being connected by a plurality of control lines for the transmission of signals. The method comprises the steps of a) forming a first circuit in the first electronic device, where the first circuit is connected to the plurality of control lines, and b) forming a second circuit in the second electronic device, where the second circuit is connected to the plurality of control lines, the first and second circuits being adapted so that the signals transmitted over the control lines include an event occurrence signal having segments, wherein different consecutive segments of the event occurrence signal are transmitted over different lines in the plurality of control signal lines.
Brief Description of the Drawings Figure 1 is a schematic diagram of a prior art "high speed" 4-bit transfer of data from an external device.
Figure 2 is a schematic diagram of a prior art conventional 8-bit transfer of data from an external device.
Figure 3 is a schematic diagram of a prior art "high speed" 8-bit transfer of data from an external device.
Figure 4 is a schematic diagram of a portion of a typical parallel I/O port hardware design known in the prior art.
Figure 5 is a timeline showing the data access delays caused by the typical parallel I/O port hardware design shown in Figure 4.
Figure 6 is a timeline showing the response of a first preferred embodiment of the invention. Figure 7 is a timeline showing the response of a second preferred embodiment of the invention.
Figure 8 is a timeline showing the response of a third preferred embodiment of the invention. Figure 9 is a timeline showing the response of a fourth preferred embodiment of the invention.
Figure 10 is a timeline showing the response of a fifth preferred embodiment of the invention.
Figure 11 is a timeline showing the response of a sixth preferred embodiment of the invention.
Figure 12 is a timeline showing the response of a seventh preferred embodiment of the invention.
Figure 13 is a block diagram of interconnected I/O ports in accordance with the prior art. Figure 14 is a block diagram of interconnected I/O ports in accordance with the present invention.
Figure 15 is a flowchart showing the operations performed by the software shown in Table 4.
Figure 16 is a flowchart showing the operations performed by the software shown in Table 5.
Figure 17 is a flowchart showing the operations performed by the software shown in Table 6.
Figure 18 is a flowchart showing the operations performed by the software shown in Table 7. Figure 19 is a flowchart showing the operations performed by the software shown in Table 10.
Figure 20 is a flowchart showing the operations performed by the software shown in Table 11.
Figure 21 is a flowchart showing the operations performed by the software shown in Table 12. Detailed Description of the Preferred Embodiment of the Invention All of the aspects of the invention relate to the process of transferring data to or from an external device via another device's parallel I/O port. These aspects can either be embodied in the form of hardware or in the form of software operating on a programmable device. These designs, regardless of whether they are realized in hardware or software, or some combination of the two, provide specific mechanisms that work with the programmable device (for example, the PC) . Further the data, control or status signals may be transferred either through a wired cable or through a wireless communication channel, such as one operating by the transmission and receipt of infrared (IR) and/or radio frequency (RF) electromagnetic signals.
The design of the external device must also accommodate operation with the hardware or software aspects of this invention. In particular, the external device must provide hardware logic which can respond to the PCs handshake signal with the correct timing. This is necessary so that data being read from the device is available at the proper time to allow the PC driver software to read it correctly (whether reading data in 8- bit mode via the DATA port or in 4-bit mode via the STATUS port) .
On the other hand, if writing data to a device, the device must store the data it receives from the PC after the data has been validated. Figure 14 is a block diagram of interconnected I/O ports in accordance with the present invention. The present invention is a method and apparatus for communication over a parallel port 250 connected between a first device 252 and a second device 254. The port 250 is an I/O port which has a modified function from the I/O port known in the prior art. As known in the prior art, the port 250 includes "DATA" lines 256 and "ADD'L" lines 258 which are interconnected between the first and second devices 252 and 254. The communication between the first and second devices 252 and 254 is for the purpose of transmitting information from the first device 252 to the second device 254. When used in its configuration known in the prior art, the parallel port 250 is structured to transfer data bidirectionally between the first device 252 and the second device 254 over the "DATA" lines 256. The "ADD'L" lines 258 are unidirectional lines used to transfer information other than data information from the first device 252 to the second device 254. As used in the present invention, however, the "DATA" lines 256 and the "ADD'L" lines 258 are connected between first and second circuits 260 and 262, which are formed within the first and second devices 252 and 254, respectively. The first and second circuits 260 and 262 can take the form of physical components, such as a logic circuit, or the form of standard PC circuitry which is reconfigured in accordance with a software program that is loaded into and run by the standard PC circuitry.
In the present invention, the "Add'l" lines 258 are used to transfer data unidirectionally from the first circuit 260 in the first device 252 to the second circuit 262 in the second device 254. In addition, the "DATA" lines 256 are used to transfer control signals from the second circuit 262 in the second device 254 to the first circuit 260 in the first device 252.
In a first aspect, the invention uses multiple CONTROL signal lines to reduce or eliminate timing delay. This allows 8- bit data transfers to be as fast as the PC is able to execute I/O instructions. This aspect of the invention is an improvement over most parallel I/O ports, in which the CONTROL port signals are typically driven with conventional open collector driver chips. Accordingly, when a CONTROL port signal is driven low, there is very little signal delay. However, when that same signal is driven high, long delays can occur between the time the driver software executes the instruction that sets the signal HIGH and the point at which the signal actually reaches a high level. Because of this, the device logic hardware and software is designed to recognize only the falling edges of the CONTROL port signals during critical data transfer times. To have a sufficient number of falling edges available, at least two CONTROL port signals are used, so that while one signal is recovering from a low to high transition, another signal can be used to signal an I/O operation by a high to low transition. The external device is designed to access and transfer the first byte of data when CONTROL signal 1 transitions from a high to a low level. The second byte is accessed and transferred when CONTROL signal 2 transitions from a high level to a low level, and so on. The logic is designed to ignore the CONTROL signal levels during the data transfer cycles except for any high to low transitions.
Figure 6 is a timeline showing the response of a first preferred embodiment of the invention, Figure 7 is a timeline showing the response of a second preferred embodiment of the invention, and Figure 8 is a timeline showing the response of a third preferred embodiment of the invention. As shown in Figures 6-8 and the respective tables 4-6, this type of design allows the driver software to reduce the timing delays it normally has to add after changing the state of the CONTROL port signals . This results in significantly faster I/O code and higher data throughput than is known in the prior art .
Next, a downward transition 86 in the second CONTROL signal 88 begins the handshake process for byte 2 (at time 90) , shortly after which the data for byte 2 is valid. During this latter period of time, the first CONTROL signal 82 recovers from its downward transition 80, and is ready to incur another downward transition 92 to cause the required handshake signal for transfer of byte 3. As can be seen, this rotating handshake technique can be generalized to more than only two CONTROL signals. In addition, the order of rotation can be any one of many possibilities, including a fixed cyclic rotation (for example, ...,1,2,3,1, ...) , any other fixed periodic order (for example,
...,1,2,3,1,3,1, ..., or ...,1,3,2,4,1, ...), or even random orders that may not be predetermined but rather established by instantaneous circuit conditions.
Figures 7 and 8 are similar to Figure 6. Figure 7 shows a rotating handshake technique using transitions in CONTROL port signals to cause handshaking for transfer of each unit of information (e.g., nibble of data) where the two CONTROL port signals are used alternately. Figure 8 is very nearly the same as Figure 7, except that Figure 8 shows that the handshake signals occur during the times that the units of information
(e.g., bytes) are valid, not between the times that the units of information are valid.
Table4 ;On entry... ES:DI register pair points to receive data buffer
mov ex, TransferWordCount load ex register with data transfer word count mov al, DeviceRotaάngHandshakel CONTROL port device Rotating handshake value mov ah, DeviceRotatingHandshake2 CONTROL poπ device Rotating handshake value mov dx, CONTROL port load dx register with CONTROL port I/O address
WordTransferLoop: out dx, al output 1st CONTROL handshake - high to low transition dec dx point dx at DATA port I/O address dec dx insb input byte of data from device - write data directly to memory inc dx point dx at CONTROL port I/O address inc dx xchg al, ah get the second handshake level out dx, al output 2nd to CONTROL handshake - low to high transition dec dx point dx at DATA port I/O address dec dx insb input byte of data from device - write data directly to memory inc dx point dx at CONTROL port I/O address inc dx xchg al, ah get the second handshake level loop WordTransferLoop loop until all data is transferred... Figure 15 is a flowchart showing the operations performed by the software shown in Table 4. From the start of the code, or software, (block 280) shown in Figure 15, the next operation is to store the memory buffer pointers, the handshake values, the I/O address registers, and the number of words to be read from the external device (block 282, software lines 1-4) . Following this operation, the handshake value is written to the CONTROL port (block 284, software line 5), and then the I/O port address register is changed to the DATA port (block 286, software lines 6 and 7) . Next, the first byte of the data word is read from the DATA port directly in the memory buffer and the memory buffer pointer is incremented (block 288, software line 8) . Then, the I/O port address register is changed to the CONTROL port (block 290, software lines 9-10) and the handshake value is changed (block 292, software line 11) . After the handshake value is changed, it is written to the CONTROL port (block 294, software line 12) . The I/O port address register is then again changed to the DATA port (block 296, software lines 13-14) . With the register changed, the second byte of the data word is read from the DATA port directly into the memory buffer and the memory buffer pointer is incremented (block 298, software line 15) . Once again, the I/O port address register is changed to the CONTROL port (block 300, software line 16) and the handshake value is changed (block 302, software line 18) . After each pass through the loop including the blocks 284-302 (starting at software line 5) , the word counter (CX) is decremented and a test performed on its value (decision block 304) . Based on the results of that test, the loop including the blocks 284-302 is performed again (if all of the words have not been transferred) , or the end of the code is reached (block 306, if all of the words have been transferred) . The WordTransferLoop portion of the program shown in Table 4 is based on a unit of information consisting of two bytes. A similar WordTransferLoop can be used if the unit of information is different from two bytes, as will be readily understood by those skilled in the art .
Table5
;On entry...ES:DI register pair points to receive data buffer - (2)
Nibbles (1 byte) transferred on each pass through loop
mov ex, TransferByteCount load x register with data transfer byte count mov al, DeviceRotatingHandshakel CONTROL port device Rotating handshake value mov ah, DeviceRotatingHandshake2 CONTROL port device Routing handshake value mov dx, CONTROL port load dx register with CONTROL port I/O address
ByteTransferLoop: out dx, al output 1st CONTROL handshake - high to low transition dec dx point dx at STATUS port I/O address insb input Nibble of data from device - write data directly to memory inc dx point dx at CONTROL port I/O address xchg al, ah get the second handshake level out dx, al output 2nd to CONTROL handshake - low to high transition dec dx point dx at STATUS port I/O address insb input Nibble of data from device - write data directly to memory inc dx point dx at CONTROL port I/O address xchg al, ah get the second handshake level loop ByteTransferLoop loop until all data is transferred...
Figure 16 is a flowchart showing the operations performed by the software shown in Table 5. From the start of the code, or software, (block 310) shown in Figure 16, the next operation is to store the memory buffer pointers, the handshake values, the I/O address registers, and the number of bytes to be read from the external device (block 312, software lines 1-4) . Following this operation, the handshake value is written to the CONTROL port (block 314, software line 5), and then the I/O port address register is changed to the STATUS port (block 316, software line 6) . Next, the first nibble of the data byte is read from the STATUS port directly in the memory buffer and the memory buffer pointer is incremented (block 318, software line 7) . Then, the I/O port address register is changed to the CONTROL port (block 320, software line 8) and the handshake value is changed (block 322, software line 9) . After the handshake value is changed, it is written to the CONTROL port (block 324, software line 10) . The I/O port address register is then again changed to the STATUS port (block 326, software line 10) . With the register changed, the second nibble of the data byte is read from the STATUS port directly into the memory buffer and the memory buffer pointer is incremented (block 328, software lines 11-12) . Once again, the I/O port address register is changed to the CONTROL port (block 330, software line 13) and the handshake value is changed (block 332, software line 14) . After each pass through the loop including the blocks 314-332, the byte counter (CX) is decremented and a test performed on its value (decision block 334, software line 15) . Based on the results of that test, the loop including the blocks 314-332 is performed again (if all of the bytes have not been transferred) , or the end of the code is reached (block 336, if all of the bytes have been transferred) .
The ByteTransferLoop portion of the program shown in Table 5 is based on a unit of information consisting of two nibbles. A similar ByteTransferLoop can be used if the unit of information is different from two nibbles, as will be readily understood by those skilled in the art. On most higher speed microprocessors it is more efficient to process the nibbles of data back into bytes or into their original form by having a separate segment of software that accomplishes the nibble processing. The nibble processing may also be done within the nibble receiving software loop (and may be more efficient to do so on certain microprocessors) by simply modifying the instructions shown in Table 5 and adding the instructions necessary to process the received nibbles as they are received and before writing the data to the memory buffer. This would be readily understood by anyone skilled in the art.
Table 6
On entry... ES:DI register pair points to receive data buffer
mov ex, TransferWordCount load ex register with data transfer word count mov al, DeviceRotat gHandshakel CONTROL port device Rotating handshake value mov ah, DeviceRotatingHandshake2 CONTROL port device Routing handshake value mov dx, DATA port load dx register with DATA port I/O address
WordTransferLoop: outsb output byte of dau to device - write data directly to memory inc dx point dx at CONTROL port I/O address inc dx out dx, al output next CONTROL handshake - high to low transition dec dx point dx at DATA port I/O address dec dx xchg al, ah get the next hanrlRhaln. level outsb output byte of dau to device - write dau directly to p. port inc dx point dx at CONTROL port I/O address inc dx out dx, al output next CONTROL handshake - high to low transition dec dx point dx at DATA port I/O address dec dx xchg al, ah get the next handshake level loop WordTransferLoop loop until all dau is transferred...
Figure 17 is a flowchart showing the operations performed by the software shown in Table 6. From the start of the code, or software, (block 340) shown in Figure 17, the next operation is to store the memory buffer pointers, the handshake values, the I/O address registers, and the number of words to write to the external device (block 342, software lines 1-4) . Following this operation, the first byte of the data word is written directly from the memory buffer to the DATA port and the memory buffer pointer is incremented (block 344, software line 5) . Then, the I/O port address register is changed to the CONTROL port (block 346, software line 6) and the handshake value is written to the CONTROL port (block 348, software lines 7-8) . The I/O port address register is then again changed to the DATA port (block 350, software lines 9-10) and the handshake value is changed (block 352, software line 11) . With the register and handshake value changed, the second byte of the data word is written directly from the memory buffer to the DATA port and the memory buffer pointer is incremented (block 354, software line 12) . Once again, the I/O port address register is changed to the
CONTROL port (block 356, software lines 13-14) and the handshake value is written to the CONTROL port (block 358, software line 15) . Then, the I/O port address register is changed once more to the DATA port (block 360, software lines 16-17) and the handshake value is changed (block 362, software line 18) . After each pass through the loop including the blocks 344-362, the byte counter (CX) is decremented and a test performed on its value (decision block 364, software line 19) . Based on the results of that test, the loop including the blocks 344-362 is performed again (if all of the words have not been transferred) , or the end of the code is reached (block 366, if all of the bytes have been transferred) .
The WordTransferLoop portion of the program shown in Table 6 is based on a unit of information consisting of two bytes . A similar WordTransferLoop can be used if the unit of information is different from two bytes, as will be readily understood by those skilled in the art.
In another aspect of the invention, the DATA port signals can be used for high-speed data transfer handshaking with an external device on a PC's parallel I/O port for the 4-bit mode. This aspect of the invention uses the DATA port signal lines to reduce or eliminate timing delays, so that 4-bit data transfers can be as fast as the computer can perform I/O instructions. Figure 9 is a timeline showing the response of a fourth preferred embodiment of the invention. As shown in connection with table 7, the embodiment has a timing-based handshake technique with a DATA port signal, where the rotation is between the alternating low-going and high-going transitions 100 and 102 of the DATA port signal 104. In this case, the handshake signal occurs between the periods 106 when the nibbles are valid.
Table 7 ;On entry... ES:DI register pair points to receive dau buffer - (2) nibbles transferred per pass through loop
mov ex, TransferByteCount load ex register with dau transfer byte count mov al, DeviceHandshakel DATA port device handshake value mov ah, DeviceHandshake2 DATA port device handshake value mov dx, DATA PORT load dx register with DATA port I/O address
ByteTransferLoop: out dx, al ; output 1st DATA Port handshake inc dx ; point dx at STATUS port I/O address
; input Nibble of dau from device - read input dau directly into memory dec dx ; point dx at DATA port I/O address xchg al, ah ; get the second DATA Port handshake value out dx, al ; output 2nd to DATA hanrishaln- . low to high transition inc dx ; point dx at STATUS port I/O address
; input Nibble of dau from device - read input dau directly into memory dec dx ; point dx at DATA port I/O address xchg al, ah ; get the 1st DATA Port handshake value again loop ByteTransferLoop ; loop until all nibbles of dau are transferred...
Figure 18 is a flowchart showing the operations performed by the software shown in Table 7. From the start of the code, or software, (block 370) shown in Figure 18, the next operation is to store the memory buffer pointers, the handshake values, the I/O address registers, and the number of bytes to be read from the external device (block 372, software lines 1-4) . Following this operation, the handshake value is written the DATA port (block 374, software line 5) and then the I/O port address register is changed to the STATUS port (block 376, software line 6) . Next, the first nibble of the data byte is read directly from the STATUS port into the memory buffer and the memory buffer pointer is incremented (block 380, software line 7) . Then, the I/O port address register is changed to the DATA port (block 382, software line 8) and the handshake value is changed (block 384, software line 9) . The handshake value is then written into the DATA port (block 386, software line 10) and the I/O port address register is changed to the STATUS port (block 388, software line 11) . With the register and handshake value changed, the second nibble of the data byte is written directly into the memory buffer from the STATUS port and the memory buffer pointer is incremented (block 390, software line 12) . Once again, the I/O port address register is changed to the DATA port (block 392, software line 13) and the handshake value is changed (block 394, software line 14) . After each pass through the loop including the blocks 374-394, the byte counter (CX) is decremented and a test performed on its value (decision block 396, software line 15) . Based on the results of that test, the loop including the blocks 344-362 (starting with software line 5) is performed again (if all of the bytes have not been transferred) , or the end of the code is reached (block 398, if all of the bytes have been transferred) . The ByteTransferLoop portion of the program shown in Table 7 is based on a unit of information consisting of two nibbles. A similar ByteTransferLoop can be used if the unit of information is different from two nibbles, as will be readily understood by those skilled in the art. On most higher speed microprocessors it is more efficient to process the nibbles of data back into bytes or into their original form by having a separate segment of software that accomplishes the nibble processing. The nibble processing may also be done within the nibble receiving software loop (and may be more efficient to do so on certain microprocessors) by simply modifying the instructions shown in Table 5 and adding the instructions necessary to process the received nibbles as they are received and before writing the data to the memory buffer. This would be readily understood by anyone skilled in the art.
In a still further aspect of the invention, a first version of a timing mechanism is used to transfer data to or from an external device which does not require a handshake operation for every byte or nibble of data transferred.
Figure 10 is a timeline showing the response of a fifth preferred embodiment of the invention, and Figure 11 is a timeline showing the response of a sixth preferred embodiment of the invention. As indicated in conjunction with respective tables 8 and 9, Figure 10 (and Figure 11) the invention works by having the PC or device which is sending data transmit the first byte 120 (or nibble 140) of data, and then, during the transmission of the first byte 120 (or nibble 140) of data, cause the state of a CONTROL signal 122 (or DATA handshake signal 142) to change in a transition 124 (144) . After the transition 122 (or 144) in the CONTROL signal, the receiving device transmits a predetermined additional number (say, four) of bytes 126 (or nibbles 146) before the receiving device causes a transition 128 (148) in its CONTROL signal 130 (remote handshake signal 150) . After this handshake process occurs, the CONTROL signal 122 (DATA handshake signal 142) transitions in the opposite sense, causing the transfer of another predetermined number of bytes 132 and 134 (nibbles 152 and 154) . During the period of transmission of the byte 126 or 134 (or nibble 146 or 154) , after the CONTROL signal changes state, the bytes 126 or 134 (or nibbles 146 or 154) are transmitted at specifically timed intervals, under control of a conventional clocking mechanism (not shown) .
To summarize the foregoing description of Figures 10 and 11, the receiving PC or device simply reads data at specifically timed intervals after detecting that the CONTROL signal has changed state and then changes the state of a handshake signal when it has finished reading the sending device's data.
Table 8
;On entry... ES:DI register pair points to send dau buffer
mov x, TransferDoubleWordCount ; load ex register with dau transfer double word count/2 mov al, DeviceRoutingHandshake 1 CONTROL port device Routing handshake value mov ah, DeviceRoutingHandshake2 CONTROL port device Routing handshake value mov dx, DATA_port load dx register with DATA port I/O address
DoubleWordTransferLoop: outsb output bytel of dau to device-write dau directly to parallel port from memory in al,61h I/O instruction used to provide specific tuning period of 1.0 to 1.5 usec. inc dx point dx at CONTROL port I/O address inc dx mov al, DeviceRoutingHandshake 1 out dx,al ; output 2nd CONTROL handshake - high to low transition dec dx ; point dx at DATA port I/O address dec dx outsb ; output byte2 of dau to device-write dau directly to parallel port from memory in al,61h ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. outsb ; output byte4 of dau to device-write dau directly to parallel port from memory in al,61h ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. inc dx ; point dx at STATUS port I/O address
WAΓΓ_FOR_RECEIVER_HANDSHAKE: in al.dx -read STATUS port test al, RECEIVE HSH ; has receiver responded to our handshake? If not... keep waiting.. jz WAIT FOR RECEIVER HANDSHAKE dec dx point dx at DATA port I/O address outsb output bytel of dau to device-write dau directly to parallel port from memory in al.όlh I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. inc dx point dx at CONTROL port I/O address inc dx mov al, DeviceRoutingHandshake 1 in al. όlh ; output 1st CONTROL handshake - high to low transition dec dx ; point dx at DATA port I/O address dec dx outsb ; output byte2 of dau to device-write dau directly to parallel port from memory in al.όlh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. outsb ; output byte3 of dau to device-write data directly to parallel port from memory in al,61h ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. outsb ; output byte4 of dau to device-write dau direcdy to parallel poπ from memory in al.όlh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. inc dx ; point dx at STATUS poπ I/O address
WAIT_FOR_RECEIVER_HANDSHAKE: in al.dx ;read STATUS port test al, RECEIVE HSH ; has receiver responded to our handshake? If not... keep waiting... jnz WA_T_FOR_RECEIVER_HANDSHAKE loop WordTransferLoop ; loop until all dau is transferred...
The DoubleWordTransferLoop portion of the program shown in Table 8 is based on a unit of information consisting of two bytes. A similar DoubleWordTransferLoop can be used if the unit of information is different from two bytes, as will be readily understood by those skilled in the art.
Table 9
On entry... ES:DI register pair points to receive dau buffer
mov ex, TransferDoubleWordCount ; load ex register with dau transfer double word count/2 mov dx, STATUS port load dx register with DATA port I/O address
DoubleWordTransferLoop: WAIT_FOR_SENDER_HANDSHAKE: in al.dx ; read STATUS port test al, RECEIVE HSH ; has sender handshake changed sute? - If not...keep waiting... jnz WAΓΓ_FOR_SENDER_HANDSHAKE insb ; input bytel of dau from device - read dau directly into memory in al.όlh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. inc dx ; point dx at CONTROL port I/O address inc dx ; insb ; input byte4 of dau from device - read dau directly into memory in al.όlh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. insb ; input byte4 of dau from device - read dau directly into memory in al.όlh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. insb ; input byte4 of dau from device - read dau directly into memory mov al, DeviceRoutingHandshake 1 out dx, al ; output 1st CONTROL handshake - high to low transition dec dx ; point dx at STATUS poπ I/O address
WAIT_FOR_SENDER_HANDSHAKE: in al.dx ;read STATUS port test al, RECEIVE HSH ; has sender handshake changed sute? - If not...keep waiting... jz WAΓT_FOR_SENDER_HANDSHAKE insb ; input bytel of dau from device - read dau directly into memory in al.όlh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. inc dx ; point dx at CONTROL port I/O address inc dx ; insb ; input byte2 of dau from device - read dau directly into memory in al.όlh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. insb ; input byte3 of dau from device - read dau directly into memory in al.όlh ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. insb ; input byte4 of dau from device - read dau directly into memory mov al, DeviceRoutingHandshake out dx, al ; output 1st CONTROL handshake - high to low transition dec dx ; point dx at STATUS port I/O address loop WordTransferLoop ; loop until all dau is transferred...
The DoubleWordTransferLoop portion of the program shown in Table 9 is based on a unit of information consisting of two bytes. A similar DoubleWordTransferLoop can be used if the unit of information is different from two bytes, as will be readily understood by those skilled in the art.
In an even further aspect of the invention, a second version of a timing mechanism is used to transfer data to or from an external device. In this case, the handshake consists of a signal from the first device to the second device without a corresponding return signal from the second device to the first device. Figure 12 is a timeline showing the response of a seventh preferred embodiment of the invention. Tables 10-12 show programs for accomplishing the advantage of this embodiment, by the storage of nibbles of data which are later reconstructed by the receiving device. As shown in the timeline of Figure 12, a DATA handshake signal 160 includes downward- and upward-going transitions 162 and 164 which occur during corresponding periods when the nibbles to be transferred are valid. During these periods, the handshake signal occurs at the corresponding times 166 of the transitions 162 and 164. Preferably, the data and the data handshake signal state are stored in sequential locations in memory, where the first location in memory stores a first nibble, along with the state of the corresponding data handshake signal 162. The second location contains nibble 2 and the state of data handshake signal 164, and so on. The second device reads each of these memory locations sequentially and then transmits them one after the other until the entire set of data and data handshake information has been sent. At each point 166, the data handshake signal and the nibble data are transmitted simultaneously because they are stored together in the same memory location and transmitted in response to the same I/O instructions. Table 10 ;On entry... ES:SI register pair points to send dau buffer
mov ex, TransferByteCount ; load ex register with dau transfer byte count mov dx, DATA port ; load dx register with DATA port I/O address
ByteTransferLoop: read next Nibble to send out dx, al ; output byte of dau to Receiving device via DATA poπ out dx, al ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. out dx, al ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. lodsb ; read next Nibble to send oouutt ddxx,, aall ; output byte of dau to Receiving device via DATA poπ out dx, al ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. out dx, al ; I/O instruction used to provide specific timing period of 1.0 to 1.5 usec. loop ByteTransferLoop ; loop until all dau is transferred...
Figure 19 is a flowchart showing the operations performed by the software shown in Table 10. From the start of the code, or software, (block 410) shown in Figure 19, the next operation is to store the memory buffer pointers, the I/O address registers, and the number of nibbles to be read from the external device (block 412, software lines 1-2) . Following this preliminary operation, the nibble data and handshake combination is read from the memory buffer and the memory buffer pointer is incremented (block 414, software line 3) . Then, the combination nibble data and handshake value is written to the DATA port (block 416, software line 4) . Next, a wait of 1.0 to 1.5 microseconds is caused (block 418, software line 5), followed by another wait of 1.0 to 1.5 microseconds (block 420, software line 6) . After each pass through the loop including the blocks 414-420 (the second pass is governed by software lines 7-10) , the byte counter (C) is decremented and a test performed to determine whether all of the nibbles have been transferred (decision block 422, software line 11) . Based on the results of that test, the loop including the blocks 414-420 is performed again (if all of the words have not been transferred), or the end of the code is reached (block 424, if ali of the nibbles have been transferred) .
The WordTransferLoop portion of the program shown in Table 10 is based on a unit of information consisting of two nibbles. A similar WordTransferLoop can be used if the unit of information is different from two nibbles, as will be readily understood by those skilled in the art.
Table 11
;On entry... ES:DI register pair points to receive dau buffer
mov ex, TransferByteCount*3 ; load ex register with dau transfer byte count * 3 mov dx, STATUS poπ ; load dx register with DATA poπ I/O address
WAIT_FOR_SENDER_TO_START: in al.dx ; wait for sending PC or device to sun sending die block of dau test al, DATA_HANDSHAKE jz WATT_FOR_SENDER_TO_START
ByteTransferLoop: rep insb ; this repeats 'til ex =0... input from STATUS poπ directly into mem loop ByteTransferLoop ; loop until block of Nibble dau is transferred...
Figure 20 is a flowchart showing the operations performed by the software shown in Table 11. From the start of the code, or software, (block 430) shown in Figure 20, the next operation is to store the memory buffer pointers, the I/O address registers, and the number of nibbles to be read from the external device (block 432, software lines 1-2) . Following this preliminary operation, a test is performed to determine whether the sending device has started (block 434, software lines 3-5) . If the device has not started sending, the program control returns to the block 434 (software line 3) ,* if the device has started sending, the program moves to the step shown in block 436. In this step, the nibble data and handshake combination are read directly from the STATUS port into the memory buffer and the memory buffer pointer is incremented (block 436, software line 6) . Then another test is performed. In this test, the counter (CX) is decremented and it is determined whether all of the nibbles have been transferred (decision block 438, software line 7) . Based on the results of that test, the loop including the blocks 436-438 (software lines 6-7) is performed again (if all of the nibbles have not been transferred) , or the end of the code is reached (block 440, if all of the nibbles have been transferred) .
The ByteTransferLoop portion of the program shown in Table 11 is based on a unit of information consisting of two nibbles. A similar ByteTransferLoop can be used if the unit of information is different from two nibbles, as will be readily understood by those skilled in the art.
Table 12
;On entry... ES:SI register pair points to receive dau buffer - ES:DI register paid points to output byte buffer
mov ex. si ; save copy of current input buffer pointer add cx, TransferByteCount*3 ; load cx register with value indicating end of input buffer
LOOK FOR VALID NIBBLE 1: lodsb ; get received Nibble from input buffer test al, NIBBLE HANDSHAKE ; has Dau Handshake changed sute? jz LOOK_FOR_V ALID_NIBBLE 1 lodsb ; get valid Nibble from input buffer mov ah, al ; save Nibble for a little while in ah
LOOK_FOR_VALID_NIBBLE2: lodsb get received Nibble from input buffer test al, NIBBLE HANDSHAKE has Dau Handshake changed sute? jnz LOOK_FOR_VALID_NIBBLE2 lodsb get valid Nibble from input buffer shr al, 4 move low order nibble into original byte position and ah, OFOh strip off extra bits or al, ah restore original byte stosb store byte in output buffer cmp si, cx test if the input buffer has been completely processed jl LOOK_FOR_V ALID_NIBBLE 1 keep processing until end of input buffer
Figure 21 is a flowchart showing the operations performed by the software shown in Table 12. From the start of the code, or software, (block 450) shown in Figure 21, the next operation is to store the memory buffer pointers and the number of combination nibble data and handshake bytes to process (block 452, software lines 1-2) . Following this preliminary operation, the next byte of combination nibble data and handshake is read from the memory buffer and the memory buffer pointer is incremented (block 454, software line 3) . Then a test is performed on the handshake bit (block 456, software line 4) . If the handshake bit has changed state, the program moves forward; otherwise, the program returns to the step represented by block 454. In the next step of the program the valid nibble data and handshake combinations are saved (block 458, software lines 5-7) . The next byte of combination nibble data and handshake is read from the memory buffer and the memory buffer pointer is incremented (block 460, software line 8) . Once again, a test is performed to determined whether the handshake bit has changed state. If it has not changed state, the program returns to the step represented by the block 460; otherwise, the program moves forward. In the next step valid nibble and handshake combinations are processed with previously saved nibble and handshake combinations to rebuild the original byte and to store it in memory (block 464, software lines 10-15) . After completion of this step, the counter (CX) is decremented and it is determined whether all of the bytes have been processed (decision block 466, software line 16) . Based on the results of that test, the loop including the blocks 454-466 (software lines 3-17) is performed again (if all of the words have not been transferred) , or the end of the code is reached (block 468, if all of the bytes have been processed) .
The LOOK_FOR_VALID_NIBBLEl and LOOK_FOR_VALID_NIBBLE2 portions of the program shown in Table 12 are based on units of information each consisting of one nibble. Similar other portions can be used if the unit of information is different from one nibble, as will be readily understood by those skilled in the art. While the foregoing is a detailed description of the preferred embodiment of the invention, there are many alternative embodiments of the invention that would occur to those skilled in the art and which are within the scope of the present invention.
Accordingly, the present invention is to be determined by the following claims.

Claims

Claims
l. An apparatus for transferring information from a first electronic device to a second electronic device, the two electronic devices being connected by a plurality of lines, the plurality of lines including a first plurality of data lines for the unidirectional parallel transfer of signals representing data information from the second electronic device to the first electronic device and a second plurality of additional lines for the transfer of signals representing additional information between the first electronic device and the second electronic device, the apparatus comprising-. a first circuit in the first electronic device, the first circuit being connected to the first plurality of data lines and to the second plurality of additional lines, being adapted to receive control signals from the second electronic device over the first plurality of data lines, and further being adapted to transmit data signals over the second plurality of additional lines,* and a second circuit in the second electronic device, the second circuit being connected to the first plurality of data lines and to the second plurality of additional lines, being adapted to transmit the control signals to the first electronic device over the first plurality of data lines, and further being adapted to receive the data signals transmitted by the first circuit over the second plurality of additional lines in response to the control signals.
2. The apparatus of claim l, wherein at least one of the first electronic device and the second electronic device is a computer.
3. The apparatus of claim 1, wherein the second plurality of additional lines includes status lines, the status lines carrying at least one signal that indicates a status of one of the first and second devices from that device to the other.
4. The apparatus of claim 1, wherein the second plurality of additional lines includes control lines, the control lines carrying at least one signal for a particular purpose from one of the first and second devices to the other device.
5. The apparatus of claim 1, wherein the second plurality of additional lines includes control lines, the control lines carrying at least one control signal for a particular purpose from one of the first and second devices to the other device, the control signal including one or more strobe signals for signalling either the actual occurrence of or the forecast occurrence of predetermined events, each of the one or more strobe signals including separate portions occurring in distinct time intervals, portions of the strobe signal that occur in consecutive distinct time intervals being transmitted over different lines in the second plurality of additional lines according to a predetermined order.
6. The apparatus of claim 4, wherein at least one of the first and second circuits includes a controller.
7. The apparatus of claim 4, wherein the first circuit further includes a hard-wired circuit.
8. The apparatus of claim 4, wherein the first and second circuits include first and second computers, respectively.
9. The apparatus of claim 4, urther comprising a wireless communication channel wherein the communication channel is connected between a first I/O port and a second I/O port in the first and second electronic devices, respectively.
10. The apparatus of claim 4, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, and at least one of the first and second circuits is included in the corresponding I/O port.
11. The apparatus of claim 4, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, each of the first and second circuits being included in the corresponding I/O port.
12. The apparatus of claim 4, wherein the predetermined order is a repetitive order that causes the portions of the strobe signal that occur in consecutive distinct time intervals to be transmitted over each of the different lines in the second plurality of additional lines before a portion of the strobe signal is transmitted again over any one of the different lines in the second plurality of additional lines.
13. The apparatus of claim 12, wherein at least one of the first and second circuits includes a controller.
14. The apparatus of claim 12, wherein the first circuit further includes a hard-wired circuit.
15. The apparatus of claim 12, wherein the first and second circuits include first and second computers, respectively.
16. The apparatus of claim 12, further comprising a wireless communication channel wherein the communication channel is connected between a first I/O port and a second I/O port in the first and second electronic devices, respectively.
17. The apparatus of claim 12, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, and at least one of the first and second circuits is included in the corresponding I/O port.
18. The apparatus of claim 12, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, each of the first and second circuits being included in the corresponding I/O port.
19. The apparatus of claim 12, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, and at least one of the first and second circuits is included in the corresponding I/O port.
20. The apparatus of claim 1, wherein the data signals include distinct parallel sets of data, each distinct parallel set of data being transmitted only after the second electronic device receives a corresponding event signal.
21. The apparatus of claim 1, wherein at least one of the first and second circuits includes a programmed controller.
22. The apparatus of claim 21, wherein the first circuit further includes a hard-wired circuit.
23. The apparatus of claim 1, wherein the first and second circuits include hard-wired first and second electronic circuits, respectively.
24. An apparatus for transferring information from a first electronic device to a second electronic device, the two electronic devices being connected by a plurality of lines, the plurality of lines including a first plurality of data lines for the parallel transfer of signals representing data information between the first electronic device and the second electronic device, a second plurality of control lines for carrying at least one control signal for a particular purpose from the second device to the first device, and a third plurality of status lines for carrying at least one signal that indicates a status of the first device to the second device, the apparatus comprising: a first circuit in the first electronic device, the first circuit being connected to the first plurality of data lines and to the second plurality of additional lines, being adapted to receive data signals over lines chosen from the class of lines including data lines, control lines and status lines, being adapted to transmit control signals over different lines chosen from the class of lines including data lines, control lines and status lines, and being adapted to transmit status signals over still different lines chosen from the class of lines including data lines, control lines and status lines,- and a second circuit in the second electronic device, the second circuit being connected to the first plurality of data lines and to the second plurality of additional lines, being adapted to transmit data signals over lines chosen from the class of lines including data lines, control lines and status lines, being adapted to receive control signals over different lines chosen from the class of lines including data lines, control lines and status lines, and being adapted to receive status signals over still different lines chosen from the class of lines including data lines, control lines and status lines.
25. The apparatus of claim 24, wherein the second plurality of additional lines are status lines.
26. The apparatus of claim 24, wherein the second plurality of additional lines are control lines.
27. The apparatus of claim 24, wherein the second plurality of additional lines are control lines, the control signals including a strobe signal having serial segments, different consecutive serial segments of the serial strobe signal being transmitted over different lines in the second plurality of additional lines according to a predetermined order.
28. The apparatus of claim 27, wherein the predetermined order is a repetitive order that causes the different consecutive serial segments of the serial strobe signal to be transmitted over each of the different lines in the second plurality of additional lines before a serial segment of the serial strobe signal is transmitted again over any one of the different lines in the second plurality of additional lines.
29. The apparatus of claim 24, wherein the data signals include distinct parallel sets of data, each distinct parallel set of data being transmitted only after the second electronic device receives a corresponding control signal .
30. The apparatus of claim 24, wherein the first and second circuits include first and second programmed controllers, respectively.
31. The apparatus of claim 30, wherein the first circuit further includes a hard-wired circuit.
32. The apparatus of claim 24, wherein the first and second circuits are hard-wired first and second electronic circuits, respectively.
33. An apparatus for transferring information from a first electronic device to a second electronic device, the two electronic devices being connected by a plurality of lines, the plurality of lines being adapted to transfer parallel signals representing handshake information between the first electronic device and the second electronic device, the apparatus comprising: first and second circuits in the first electronic device, the first and second circuits being connected to transfer parallel signals representing the handshake information therebetween.
34. The apparatus of claim 33, wherein the first circuit transfers at least a portion of the handshake information to the second circuit .
35. The apparatus of claim 33, wherein the second circuit transfers at least a portion of the handshake information to the first circuit.
36. The apparatus of claim 35, wherein the first circuit transfers at least a portion of the handshake information to the second circuit.
37. An apparatus for transferring information from a computer to an external device, the computer and the electronic device being connected by a plurality of lines, the plurality of lines including a first plurality of data lines for the unidirectional parallel transfer of signals representing data information from the external device to the computer and a second plurality of control lines for the bidirectional transfer of signals representing control information between the computer and the external device, the apparatus comprising: a first circuit in the computer, the first circuit being connected to the first plurality of data lines and to the second plurality of control lines, being adapted to receive control signals from the external device over the first plurality of data lines, and further being adapted to transmit data signals over the second plurality of control lines in response to the control signals; and a second circuit in the external device, the second circuit being connected to the first plurality of data lines and to the second plurality of control lines, being adapted to transmit the control signals to the computer over the first plurality of data lines, and further being adapted to receive the data signals transmitted by the first circuit over the second plurality of control lines in response to the control signals.
38. The apparatus of claim 37, wherein the computer and the external electronic device include first and second programmed controllers, respectively.
39. The apparatus of claim 38, wherein the computer further includes a hard-wired circuit.
40. The apparatus of claim 37, wherein the computer and the external electronic circuit include hard-wired first and external circuits, respectively.
41. A method for transferring information from a first electronic device to a second electronic device, the two electronic devices being connected by a plurality of lines, the plurality of lines including a first plurality of data lines for the unidirectional parallel transfer of signals representing data information from the second electronic device to the first electronic device and a second plurality of additional lines for the transfer of signals representing additional information between the first electronic device and the second electronic device, the method comprising the steps of: a) installing a first circuit in the first electronic device, the first circuit being installed to connect to the first plurality of data lines and to the second plurality of additional lines, to receive control signals from the second electronic device over the first plurality of data lines, and further being adapted to transmit data signals over the second plurality of additional lines in response to the control signals,- and b) installing a second circuit in the second electronic device, the second circuit being installed to connect to the first plurality of data lines and to the second plurality of additional lines, being adapted to transmit the control signals to the first electronic device over the first plurality of data lines, and further being adapted to receive the data signals transmitted by the first circuit over the second plurality of additional lines in response to the control signals.
42. An apparatus for transferring information from a first electronic device to a second electronic device, the two electronic devices being connected by a plurality of lines, the plurality of lines including a first plurality of data lines for the parallel transfer of signals representing data information between the first electronic device and the second electronic device, a second plurality of control lines for carrying at least one control signal for a particular purpose from the second device to the first device, and a third plurality of status lines for carrying at least one signal that indicates a status of the first device to the second device, the apparatus comprising: a first circuit in the first electronic device, the first circuit being connected to the first plurality of data lines and to the second plurality of additional lines, being adapted to receive data signals over lines chosen from the class of lines including data lines, control lines and status lines, being adapted to transmit control signals over different lines chosen from the class of lines including data lines, control lines and status lines, and being adapted to transmit status signals over still different lines chosen from the class of lines including data lines, control lines and status lines,* and a second circuit in the second electronic device, the second circuit being connected to the first plurality of data lines and to the second plurality of additional lines, being adapted to transmit data signals over lines chosen from the class of lines including data lines, control lines and status lines, being adapted to receive control signals over different lines chosen from the class of lines including data lines, control lines and status lines, and being adapted to receive status signals over still different lines chosen from the class of lines including data lines, control lines and status lines.
43. The apparatus of claim 42, wherein the second plurality of additional lines are status lines.
44. The apparatus of claim 42, wherein the second plurality of additional lines are control lines.
45. The apparatus of claim 42, wherein the second plurality of additional lines are control, lines, the control signals including a strobe signal having serial segments, different consecutive serial segments of the serial strobe signal being transmitted over different lines in the second plurality of additional lines according to a predetermined order.
46. The apparatus of claim 45, wherein the predetermined order is a repetitive order that causes the different consecutive serial segments of the serial strobe signal to be transmitted over each of the different lines in the second plurality of additional lines before a serial segment of the serial strobe signal is transmitted again over any one of the different lines in the second plurality of additional lines.
47. The apparatus of claim 42, wherein the data signals include distinct parallel sets of data, each distinct parallel set of data being transmitted only after the second electronic device receives a corresponding control signal.
48. The apparatus of claim 42, wherein the first and second circuits include first and second programmed controllers, respectively.
49. The apparatus of claim 48, wherein the first circuit further includes a hard-wired circuit .
50. The apparatus of claim 42, wherein the first and second circuits are hard-wired first and second electronic circuits, respectively.
51. An apparatus for transferring information from a first electronic device to a second electronic device, the two electronic devices being connected by a plurality of control lines for the transmission of signals, the apparatus comprising: a first circuit in the first electronic device, the first circuit being connected to the plurality of control lines,- and a second circuit in the second electronic device, the second circuit being connected to the plurality of control lines, the signals transmitted over the control lines including one or more event occurrence signals having separate portions occurring in distinct time intervals, portions of the strobe signal that occur in consecutive distinct time intervals being transmitted over different lines in the second plurality of additional lines according to a predetermined order.
52. The apparatus of claim 51, wherein the second plurality of additional lines includes status lines.
53. The apparatus of claim 51, wherein the second plurality of additional lines includes control lines.
54. The apparatus of claim 51, wherein the second plurality of additional lines includes control lines, the control lines carrying at least one control signal for a particular purpose from one of the first and second devices to the other device, the control signal including one or more strobe signals for signalling either the actual occurrence of or the forecast occurrence of predetermined events, each of the one or more strobe signals including separate portions occurring in distinct time intervals, portions of the strobe signal that occur in consecutive distinct time intervals being transmitted over different lines in the second plurality of additional lines according to a predetermined order.
55. The apparatus of claim 54, wherein at least one of the first and second circuits includes a controller.
56. The apparatus of claim 54, wherein the first circuit further includes a hard-wired circuit.
57. The apparatus of claim 54, wherein the first and second circuits include first and second computers, respectively.
58. The apparatus of claim 54, further comprising a wireless communication channel wherein the communication channel is connected between a first I/O port and a second I/O port in the first and second electronic devices, respectively.
59. The apparatus of claim 54, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, and at least one of the first and second circuits is included in the corresponding I/O port.
60. The apparatus of claim 54, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, each of the first and second circuits being included in the corresponding I/O port.
61. The apparatus of claim 54, wherein the predetermined order is a repetitive order that causes the portions of the strobe signal that occur in consecutive distinct time intervals to be transmitted over each of the different lines in the second plurality of additional lines before a portion of the strobe signal is transmitted again over. any one of the different lines in the second plurality of additional lines.
62. The apparatus of claim 61, wherein at least one of the first and second circuits includes a controller.
63. The apparatus of claim 61, wherein the first circuit further includes a hard-wired circuit.
64. The apparatus of claim 61, wherein the first and second circuits include first and second computers, respectively.
65. The apparatus of claim 61, further comprising a wireless communication channel wherein the communication channel is connected between a first I/O port and a second I/O port in the first and second electronic devices, respectively.
66. The apparatus of claim 61, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, and at least one of the first and second circuits is included in the corresponding I/O port.
67. The apparatus of claim 61, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, each of the first and second circuits being included in the correspondin I/O port.
68. The apparatus of claim 61, wherein the plurality of lines are connected to a first I/O port and a second I/O port in the first and second electronic devices, respectively, and at least one of the first and second circuits is included in the corresponding I/O port.
69. The apparatus of claim 51, wherein the data signals include distinct parallel sets of data, each distinct parallel set of data being transmitted only after the second electronic device receives a corresponding handshake signal.
70. The apparatus of claim 69, wherein the first and second circuits include first and second programmed controllers, respectively.
71. The apparatus of claim 51, wherein the first circuit further includes a hard-wired circuit.
72. The apparatus of claim 51, wherein the first and second circuits are hard-wired first and second electronic circuits, respectively.
73. The apparatus of claim 51, wherein the predetermined order is a repetitive order that causes the different consecutive serial segments of the serial strobe signal to be transmitted over each of the different lines in the second plurality of additional lines before a serial segment of the serial strobe signal is transmitted again over any one of the different lines in the second plurality of additional lines.
74. A method for transferring information from a first electronic device to a second electronic device, the two electronic devices being connected by a plurality of control lines for the transmission of signals, comprising the steps of: a) forming a first circuit in the first electronic device, the first circuit being connected to the plurality of control lines,* and b) forming a second circuit in the second electronic device, the second circuit being connected to the plurality of control lines, the first and second circuits being adapted so that the signals transmitted over the control lines include a strobe signal having segments, wherein different consecutive segments of the strobe signal are transmitted over different lines in the plurality of control signal lines.
PCT/US1996/001032 1995-01-24 1996-01-24 Method and apparatus for communication over a parallel port WO1996023261A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU49041/96A AU4904196A (en) 1995-01-24 1996-01-24 Method and apparatus for communication over a parallel port

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US37731395A 1995-01-24 1995-01-24
US08/377,313 1995-01-24

Publications (1)

Publication Number Publication Date
WO1996023261A1 true WO1996023261A1 (en) 1996-08-01

Family

ID=23488603

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1996/001032 WO1996023261A1 (en) 1995-01-24 1996-01-24 Method and apparatus for communication over a parallel port

Country Status (2)

Country Link
AU (1) AU4904196A (en)
WO (1) WO1996023261A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19739849A1 (en) * 1997-09-11 1999-03-18 Steffen Beitler Data transfer method via communications cable

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5293497A (en) * 1991-03-13 1994-03-08 Traveling Software, Inc. Cable for transmitting eight-bit parallel data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5293497A (en) * 1991-03-13 1994-03-08 Traveling Software, Inc. Cable for transmitting eight-bit parallel data

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Small Computer System Interface-2", ANSI X3, 131-1994, AMERICAN NATIONAL STANDARDS INSTITUTE, (New York, NY), 1994, Section 5.6, page 32. *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19739849A1 (en) * 1997-09-11 1999-03-18 Steffen Beitler Data transfer method via communications cable

Also Published As

Publication number Publication date
AU4904196A (en) 1996-08-14

Similar Documents

Publication Publication Date Title
JP2757055B2 (en) Data transfer method for digital computer
EP0281307B1 (en) Asynchronous interface and method for coupling data between a data module and a serial asynchronous peripheral
US4451898A (en) Asynchronous interface message transmission using source and receive devices
CA1325286C (en) Method and apparatus for interfacing a system control unit for a multi-processor system with input/output units
US6742076B2 (en) USB host controller for systems employing batched data transfer
US5587957A (en) Circuit for sharing a memory of a microcontroller with an external device
US5507003A (en) Parallel interface protocol for bidirectional communications between computer and printer using status lines for transmitting data during a reverse channel operation
US5812875A (en) Apparatus using a state device and a latching circuit to generate an acknowledgement signal in close proximity to the request signal for enhancing input/output controller operations
CA1065061A (en) Cpu-1/0 bus interface for a data processing system
US5778253A (en) No repeat byte compression method for achieving high speed data transfer from a parallel port
JPH02227765A (en) Data transfer apparatus for digital computer
GB2288954A (en) Programmable serial communications
CA2111264A1 (en) System and method for peripheral data transfer
US6067591A (en) Method and apparatus for avoidance of invalid transactions in a bus host controller
JPH04334239A (en) Data format detection circuit
US20050097403A1 (en) USB interface and testing method thereof
US5884044A (en) Dedicated DDC integrable multimode communications cell
EP0132069A2 (en) Distributed process control system with means and method of automatic data base management of broadcast information
JPH10254819A (en) Bus converting adapter
US6170027B1 (en) LPC/ISA bridge and its bridging method
WO1996023261A1 (en) Method and apparatus for communication over a parallel port
US4751630A (en) Interactive terminal system using a prepoll prior to transferring information from the controller to the work station
KR20040043198A (en) Bus system and bus interface
US5721891A (en) Detection of N length bit serial communication stream
EP0501489A1 (en) Advanced functionality parallel port interface

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AM AT AU BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LT LU LV MD MG MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TT UA UG US UZ VN

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载