US20020087745A1 - Communications interface and conflict avoidance using a software simulation of a uart - Google Patents

Communications interface and conflict avoidance using a software simulation of a uart Download PDF

Info

Publication number
US20020087745A1
US20020087745A1 US09/030,710 US3071098A US2002087745A1 US 20020087745 A1 US20020087745 A1 US 20020087745A1 US 3071098 A US3071098 A US 3071098A US 2002087745 A1 US2002087745 A1 US 2002087745A1
Authority
US
United States
Prior art keywords
signal
local bus
uart
address
register
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US09/030,710
Inventor
Peter C. Chen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=23701036&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=US20020087745(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Individual filed Critical Individual
Priority to US09/030,710 priority Critical patent/US20020087745A1/en
Publication of US20020087745A1 publication Critical patent/US20020087745A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/105Program control for peripheral devices where the programme performs an input/output emulation function

Definitions

  • the present specification comprises a microfiche appendix A.
  • the total number of microfiche sheets in the microfiche appendix is one.
  • the total number of frames in the microfiche appendix is fifteen.
  • This invention relates to a computer system including a device having a non-standard I/O interface coupled to a local bus and a software emulation of a universal asynchronous receiver transmitter (UART), and further relates to processes and circuit for avoiding conflicts when assigning a COM port to a non-standard device.
  • UART universal asynchronous receiver transmitter
  • a typical personal computer has one or more a local buses such as ISA, VESA, and/or PCI buses for connection of user-selected devices.
  • the PC communicates with the devices using device addresses typically indicated by the settings of jumper wires or toggle switches on the device. Problems can arise because there is no guaranty that a set of devices, made by different manufacturers, can operate together without address conflicts. Even if a set of devices can operated together, connection of the devices to a local bus may require that the user identify address conflicts and change address settings to avoid the conflicts. This can make adding devices to a PC difficult.
  • Common devices connected to an ISA bus include serial input/output (I/O) devices such as a printer, a modem, or a mouse.
  • I/O serial input/output
  • Some operating environments such as Microsoft WINDOWSTM running in conjunction with MS-DOS operating system provide for standardized connections to serial devices coupled to the ISA bus.
  • WINDOWSTM and MS-DOS support four communication or COM ports, each having a predefined base device address. This allows resolution of device address conflicts if each serial device on coupled to the ISA bus has settings for at least four different base device addresses.
  • Each COM port is for connection to a serial device which contains a communication interface known as a Universal Asynchronous Receiver/Transceiver (UART).
  • UART Universal Asynchronous Receiver/Transceiver
  • FIG. 1 illustrates conventional communications between a serial device 110 and an application 140 via an operating environment 130 and a communications driver 120 .
  • Operating environment 130 provides a library of subroutines which application 140 calls to communicate with serial device 110 .
  • the subroutines call communications driver 120 which writes and reads data and control information to and from a UART 105 .
  • the standardized communication interface illustrated in FIG. 1 reduces the complexity of application 140 because application 140 is not required to implement a variety of communication protocols. Accordingly, most application's are written for the standard interface. However, a standard hardware UART may be unsuitable or too expensive for some devices. Accordingly, techniques are needed which provide non-standard devices with the benefits of a standard UART interface.
  • a software emulation of a UART allows a device with a non-standard I/O interface to communicate with an application through an operating environment which contains procedures for accessing standard UART interfaces.
  • the software UART allows a non-standard device to take advantage of protocols which avoid device address conflicts among COM ports. Further, differences between the non-standard device and a standard UART device are transparent to the applications running under the operating environment.
  • a computer system includes a non-standard device and a COM driver for the non-standard device.
  • the non-standard device connects to an I/O slot corresponding to a first COM port but has a register set which differs from the standard register set for a UART.
  • the COM driver contains: a UART emulation which in response a procedure requesting access to a register of a UART at the first COM port, instead accesses storage locations in main memory of the computer system; and an I/O handler which transfers values between the storage locations in main memory and the register set of the device.
  • the system includes a standard device having a UART coupled to an I/O slot corresponding to a second COM port, and the COM driver contains routines for accessing the standard device.
  • the non-standard device has a circuit for setting the device address of the non-standard device.
  • this circuit contains a comparator adapted for receiving a data signal from the local bus and for comparing the data signal to a pattern signal which has a predetermined series of values; a counter coupled to the comparator, wherein the counter resets to an initial state if the comparator indicates the data signal is not equal to the pattern signal and advances toward a final state if the comparator indicates the data signal equals the pattern signal; and a register which, in response to the counter reaching the final state, latches from the local bus a value which indicates the base address of the non-standard device.
  • the circuit also contains an address decoder that selects which data signals the comparator receives from the local bus.
  • the COM driver sets the base address of the non-standard device by sending a predetermined pattern of address and data signals on the local bus and then following the pattern with a signal that indicates the base address of the device.
  • the device starts in a locked state where the device does not have a base address and does not respond to signals on the local bus.
  • the device address is set to the value provided by the COM driver, and the device transitions to an unlocked state. In the unlocked state, the device responds to signals on the local bus which correspond to the base address of the device.
  • FIG. 1 shows a block diagram of a prior art interface between an application and a UART device.
  • FIG. 2 shows a block diagram of an interface in accordance with an embodiment of the invention.
  • FIG. 3A is a block diagram of a circuit which unlocks a device and sets the base device address of the device.
  • FIG. 3B is a block diagram of an embodiment of a base address decoder usable in the circuit of FIG. 3A.
  • FIG. 3C is a block diagram of an embodiment of a pattern generator usable in the circuit of FIG. 3A.
  • FIG. 2 An embodiment of this invention illustrated in FIG. 2 allows an application 140 running in an operating environment 130 to communicate with a serial device 110 having a hardware UART 105 and/or a serial device 210 having non-standard input/output (I/O) interface 205 .
  • a COM driver 220 contains conventional software subroutines for communications with hardware UART 105 and a software UART 222 for serial device 210 .
  • Software UART 222 allows operating environment 130 and application 140 to transparently communicate with non-standard serial device 210 as if serial device 210 contained a hardware UART.
  • operating environment 130 includes microsoft WINDOWSTM which supports four COM ports for communications with up to four serial devices connected to an ISA bus 115 .
  • a standard COM port occupies a slot of eight addresses on ISA bus 115 .
  • the eight addresses correspond to registers of a standard UART, which function as shown in Table 1.
  • 1 Interrupt Enable or Divisor Latch most significant byte.
  • 2 Interrupt Identification 3 Line control 4 Modem control 5 Line status 6 Modem status 7 Scratch
  • the divisor latch indicated in Table 1 is enabled by setting a bit DLAB in the line control register.
  • Serial device 210 logically occupies a COM port but does not have a hardware UART which physically occupies an I/O address slot on ISA bus 115 . Accordingly, the I/O slot for the COM port used by serial device 210 is available for non-standard interface 205 .
  • Non-standard I/O 205 occupies up to eight addresses on ISA bus 115 but need not comply with the standard functions given in Table 1. An example non-standard interface is disclosed below.
  • Application 140 can be any sort of software.
  • a typical application 140 is a communication program that transmits and receives data through a modem.
  • application 140 calls a routine in operating environment 130 .
  • the routine calls COM driver 220 , and COM driver 220 accesses devices 110 and/or 210 via ISA bus 115 .
  • COM driver 220 is software containing a standard COM driver for UART 105 and a software UART 222 and an I/O handler 224 for communications with non-standard I/O device 210 .
  • a computer running application 140 executes software of COM driver 220 when operating environment 130 calls COM driver 120 and during interrupts.
  • Appendix A contains a listing of 8086 assembly language program which implements software UART 222 and I/O handler 224 .
  • Software UART 222 contains a set of virtual registers which are memory locations in the computer running COM driver 220 and which correspond to the registers of a standard UART. The virtual registers are updated using information from serial device 210 and operating environment 130 .
  • I/O handler 224 accesses serial device 210 (hardware) which is referred to as the ASIC in Appendix A.
  • COM driver 220 determines which of the four COM ports are allocated to standard UART devices, determines if a non-standard device is present, and then allocates an unassigned COM port and I/O slot to device 210 .
  • Serial device 210 is initially locked during start-up. When locked, serial device 210 receives a data signal DATA and address signal ADDR from ISA bus 115 , but does not responds to any address.
  • COM driver 220 unlocks device 210 by transmitting address signal ADDR and data signal DATA with values equal to predefined pattern recognized by device 210 . When unlocked, the base device address of device 210 depends on information that COM driver 220 provides while unlocking device 210 . Device 210 replies to the address set by COM driver 220 to indicate that device 210 is present.
  • FIG. 3A shows a block diagram of an unlocking circuit 300 which unlocks a device coupled to a local bus of a computer.
  • unlocking circuit 300 is described herein in the context of a serial device coupled to an ISA bus, unlocking circuit 300 is more generally applicable to any device coupled to a local bus such as a VLB or PCI bus.
  • Unlocking circuit 300 contains a base address decoder 330 and a pattern generator 310 . While the device is locked, base address decoder 330 asserts a signal SEL to pattern generator 310 . Pattern generator 310 generates a signal PAT that represents a byte which is from a predefined sequence and corresponds to the value of signal SEL. Signal SEL starts in an initial state, such as indicating a count value of zero or a maximum count. Each time the local bus carries an address signal ADDR having a recognized value, base address decoder 330 compares data signal DATA from the local bus to signal PAT and if signals PAT and DATA are equal, changes signal SEL so that signal SEL advances toward a final state.
  • signal SEL is reset to indicate to the initial state.
  • Advancing signal SEL can for example increment a count value from an initial state (minimum value) toward a final state (maximum value) or decrement the count from an initial state (maximum value) to a final state (minimum value).
  • base address decoder 330 receives and stores a base address for the device and then asserts a signal PCSYNC to indicate the device is unlocked.
  • the COM driver transmit the base address to the device in a number of ways. For example, the address signal used during transmission of the pattern or a following data signal can indicate the base address.
  • FIG. 3B shows a block diagram of an embodiment of base address decoder 330 .
  • Base address decoder 330 contains AND gates 331 , 332 , and 333 which are coupled address lines of ISA bus 115 .
  • AND gate 333 asserts a signal ADX when signal IOWCN indicates the computer is writing data and address signal ADDR[ 11 : 0 ] has the form 001x 111x 1111 binary where x indicates that bits ADDR 4 and ADDR 8 are “don't care” bits, i.e. can have either value 0 or 1.
  • the COM driver selects values for bits ADDR 8 and ADDR 4 so that signal ADDR[ 11 : 0 ] does not correspond to any other device coupled to the ISA bus.
  • a signal AEN indicates when a DMA controller in the computer places an address on ISA bus 115 .
  • unlocking circuit 300 does not respond to the DMA controller, and signal ADX is only asserted if signal AEN indicates address signal ADDR [ 11 : 0 ] is not from the DMA controller.
  • AND gate 333 deasserts signal ADX when at the end of a write cycle and causes register 339 to latch a byte from signal DATA[ 7 : 0 ] on ISA bus 115 .
  • a comparator 340 compares the latched byte to signal PAT[ 7 : 0 ] and asserts a signal EQUAL if the latched byte equals the byte indicated by signal PAT[ 7 : 0 ].
  • Signal EQUAL determines what occurs the next time signal ADX is asserted.
  • Signal EQUAL acts as a clock enable signal for a counter 335 and a flip-flop 345 and acts as an input signal for flip-flop 341 .
  • counter 335 increments count signal SEL[ 2 : 0 ]
  • flip-flop 341 asserts a signal MATCH
  • flip-flop 345 sets signal PCSYNC to the value of bit SEL 2 of signal SEL[ 2 : 0 ].
  • signal EQUAL deasserted when AND gate 333 asserts signal ADX flip-flop 341 deasserts signal MATCH which resets counter 335 to an initial state with count value zero.
  • counter 335 is reset to zero each time a data byte from ISA bus 115 is not equal to the data byte from the predefined pattern.
  • a signal RESET from ISA bus 115 can reset counter 335 .
  • Count signal SEL[ 2 : 0 ] increments if signal EQUAL is asserted when COM driver 220 generates on ISA bus 115 an address of the form 001x 111x 1111 and a data byte equal to signal PAT[ 7 : 0 ].
  • Incrementing signal SEL[ 2 : 0 ] causes pattern generator 310 to set signal PAT[ 7 : 0 ] to indicate the next byte in the predefined pattern.
  • FIG. 3C is a block diagram of an embodiment of pattern generator 310 .
  • Pattern generator 310 contains multiplexers 311 to 318 which have select terminals coupled to receive signal SEL[ 2 : 0 ]. Input terminals of multiplexers 311 to 314 are coupled to voltage VCC or ground.
  • Signal SEL 0 selects one of the two values for a signal AOUT[ 7 : 0 ] from multiplexers 311 and 312 and one of two values for a signal BOUT[ 7 : 0 ] from multiplexers 313 and 314 .
  • Multiplexers 315 and 316 select an output signal DOUT[ 7 : 0 ] which is equal to either signal AOUT[ 7 : 0 ] or BOUT[ 7 : 0 ] depending on select signal SEL 1 .
  • Multiplexers 317 and 318 select signal PAT[ 7 : 0 ] which is equal to signal DOUT[ 7 : 0 ] or a fixed value depending on the value of select signal SEL 2 .
  • Pattern generator 310 generates a five byte string, the ASCII code for “PCtel”, which indicates the manufacturer of the device.
  • pattern generator 310 can be implemented using a memory such as a read-only memory where signal SEL[ 2 : 0 ] is an address signal or implemented using combinatorial logic where signal SEL[ 2 : 0 ] is an input signal.
  • Each value in the pattern can be longer or shorter than a byte and can be a constant value independent of signal SEL.
  • the predetermined pattern can be longer or shorter that to five values. Increasing the length of the pattern reduces the chance of a device being unintentionally unlocked.
  • bit SEL 2 of signal SEL[ 2 : 0 ] is set when a fifth byte is sent.
  • AND gate 333 asserting signal ADX causes flip-flops 337 and 338 to latch and store bits ADDR 8 and ADDR 4 of address signal ADDR[ 11 : 0 ] and causes flip-flop 345 to assert signal PCSYNC.
  • Signal PCSYNC indicates that the device is unlocked and has a base address of the form 001a 111b 1000, where signals PCA 8 and PCA 4 from flip-flops 337 and 338 indicate the values of bits a and b. Values of bits a and b have four possible combinations which allows COM driver 220 to select a combination that provides a base address that differs from the base addresses of the three other COM ports.
  • Signals PCA 4 and PCA 8 are latched when an address signal ADDR[ 11 : 0 ] is asserted for a byte following the predefined pattern.
  • the byte following the predefined pattern does not match signal PAT[ 7 : 0 ] from pattern generator 310 . Accordingly, counter 335 is reset to the initial state, and bit SEL 2 is cleared.
  • Signals PCA 8 and PCA 4 do not change unless the predefined pattern is retransmitted. Unintentional transmission of the predefined pattern is unlikely during normal operation of the computer system, but if desired, COM driver 220 monitor the pattern being transmitted and prevent repetition of the predefined pattern, for example by writing a no-op value to device 210 .
  • a signal ADBASE indicates whether address signal ADDR[ 11 : 0 ] corresponds to the device.
  • An AND gate 332 asserts a signal ADB if address signal ADDR[ 11 : 0 ] has the form 001x 111x 1xxx when signal AEN indicates the address signal ADDR[ 11 : 0 ] is not from the DMA controller.
  • a comparator 344 asserts signal ADBASE only if signal ADB is asserted, signal PCSYNC is asserted, and bits ADDR 8 and ADDR 4 of address signal ADDR[ 11 : 0 ] equal signals PCA 8 and PCA 4 .
  • Conventional address decoding circuits decode bits ADDR 2 , ADDR 1 , and ADDR 0 to determine which register in the device is being accessed via ISA bus 115 .
  • the additional decoding circuits and the register set of the device can be implemented as required for the function of the device.
  • the standard UART interface need not be followed. This allows an I/O interface to be optimized and implemented for the particular function of the device.
  • FIG. 2 shows an embodiment where serial device 210 contains an analog-to-digital converter (ADC) 206 and a digital-to-analog converter (DAC) 207 which are connected to PSTN phonelines 208 for implementation of a software modem.
  • ADC analog-to-digital converter
  • DAC digital-to-analog converter
  • software UART 222 and I/O handler 224 are part of a software modem 223 .
  • a register set in non-standard I/O interface 205 is described in Table 2. TABLE 2 Offset Register 0 Data Register (Low Byte) 1 Data Register (High Byte) 2 Control/Status Register (Low Byte) 3 Control/Status Register (High Byte) 4 Input/Output Port Register 5 Reserved 6 Reserved 7 Pattern Port Register
  • the data registers are for 16-bit data words sent to DAC 207 or received from ADC 206 by the host computer.
  • Input/output port register are for modem functions such as ring detection and control of an on-off hook relay (to connect or disconnect device 208 to an active phone line) which are implemented by hardware in serial device 210 .
  • the control/status register are general purpose control and status bit for serial device 210 .
  • ADC 206 receives an analog communications signal from phonelines 208 and converts the analog communications signal into a series of sampled digital values.
  • Software modem 223 receives the sampled digital values and based on the waveform represented by the sampled values and on the modem protocol employed determines data received.
  • Software modem 223 also generates a series of digital values which are sent to DAC 207 and transmitted as an analog signal on phonelines 208 .
  • the transmitted analog signal provides a carrier signal and data values formatted according to standard modem protocols such as ITU V.32bis, V.32, V.22bis, V.23, V.22, V.21, V.17, V.29, and V.27ter standards.
  • Device 210 generates periodic interrupts during which software modem 223 reads a set of sampled digital values from ADC 206 and writes a set of digital values which represent the transmitted analog signal.
  • COM driver 220 sets the interrupt number (or IRQ) used by device 210 to a user selected one of eight values.
  • Application 140 communicates with software modem 223 in the same manner as with a conventional hardware modem.
  • Application 140 sends and receives data and control values via operating environment 130 .
  • the data and control values are formatted for a standard UART device so that whether software modem 223 is a standard modem containing a hardware UART or a software modem is completely transparent to application 140 and operating environment 130 .

Abstract

A computer system includes a software UART emulation and uses standard operating system protocols to minimized the chance of I/O conflicts between a serial device having a UART and a non-standard serial device which communicates through the UART emulation. A COM driver which can replace a standard COM driver in an operating environment such as provided by Microsoft WINDOWS™ contains the UART emulation. The COM driver also sets the device address of the non-standard device on an ISA bus by determining the device addresses of COM port I/O slots used by UARTs, sending a predetermined pattern on the ISA bus to indicate a device address is to come, and then sending a value indicating a device address not used by the UARTs. The pattern has a length sufficient to make inadvertent generation of the pattern unlikely. The non-standard device recognizes the predetermined pattern and selects a device address according to the value from the COM driver.

Description

    REFERENCE TO MICROFICHE APPENDIX
  • The present specification comprises a microfiche appendix A. The total number of microfiche sheets in the microfiche appendix is one. The total number of frames in the microfiche appendix is fifteen. [0001]
  • A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. [0002]
  • BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0003]
  • This invention relates to a computer system including a device having a non-standard I/O interface coupled to a local bus and a software emulation of a universal asynchronous receiver transmitter (UART), and further relates to processes and circuit for avoiding conflicts when assigning a COM port to a non-standard device. [0004]
  • 2. Description of Related Art [0005]
  • A typical personal computer (PC) has one or more a local buses such as ISA, VESA, and/or PCI buses for connection of user-selected devices. The PC communicates with the devices using device addresses typically indicated by the settings of jumper wires or toggle switches on the device. Problems can arise because there is no guaranty that a set of devices, made by different manufacturers, can operate together without address conflicts. Even if a set of devices can operated together, connection of the devices to a local bus may require that the user identify address conflicts and change address settings to avoid the conflicts. This can make adding devices to a PC difficult. [0006]
  • Common devices connected to an ISA bus include serial input/output (I/O) devices such as a printer, a modem, or a mouse. Some operating environments such as Microsoft WINDOWS™ running in conjunction with MS-DOS operating system provide for standardized connections to serial devices coupled to the ISA bus. In particular, WINDOWS™ and MS-DOS support four communication or COM ports, each having a predefined base device address. This allows resolution of device address conflicts if each serial device on coupled to the ISA bus has settings for at least four different base device addresses. Each COM port is for connection to a serial device which contains a communication interface known as a Universal Asynchronous Receiver/Transceiver (UART). The UART is well known in the art and described, for example, in the 1994 “Telecommunication Data Book” from National Semiconductor Corporation, which is incorporated by reference herein in its entirety. [0007]
  • FIG. 1 illustrates conventional communications between a [0008] serial device 110 and an application 140 via an operating environment 130 and a communications driver 120. Operating environment 130 provides a library of subroutines which application 140 calls to communicate with serial device 110. The subroutines call communications driver 120 which writes and reads data and control information to and from a UART 105. The standardized communication interface illustrated in FIG. 1 reduces the complexity of application 140 because application 140 is not required to implement a variety of communication protocols. Accordingly, most application's are written for the standard interface. However, a standard hardware UART may be unsuitable or too expensive for some devices. Accordingly, techniques are needed which provide non-standard devices with the benefits of a standard UART interface.
  • SUMMARY OF THE INVENTION
  • In accordance with the invention, a software emulation of a UART (universal asynchronous receiver transmitter) allows a device with a non-standard I/O interface to communicate with an application through an operating environment which contains procedures for accessing standard UART interfaces. The software UART allows a non-standard device to take advantage of protocols which avoid device address conflicts among COM ports. Further, differences between the non-standard device and a standard UART device are transparent to the applications running under the operating environment. [0009]
  • In one embodiment of the invention, a computer system includes a non-standard device and a COM driver for the non-standard device. The non-standard device connects to an I/O slot corresponding to a first COM port but has a register set which differs from the standard register set for a UART. The COM driver contains: a UART emulation which in response a procedure requesting access to a register of a UART at the first COM port, instead accesses storage locations in main memory of the computer system; and an I/O handler which transfers values between the storage locations in main memory and the register set of the device. Optionally, the system includes a standard device having a UART coupled to an I/O slot corresponding to a second COM port, and the COM driver contains routines for accessing the standard device. [0010]
  • To avoid address conflicts with standard devices, the non-standard device has a circuit for setting the device address of the non-standard device. In one embodiment, this circuit contains a comparator adapted for receiving a data signal from the local bus and for comparing the data signal to a pattern signal which has a predetermined series of values; a counter coupled to the comparator, wherein the counter resets to an initial state if the comparator indicates the data signal is not equal to the pattern signal and advances toward a final state if the comparator indicates the data signal equals the pattern signal; and a register which, in response to the counter reaching the final state, latches from the local bus a value which indicates the base address of the non-standard device. Typically, the circuit also contains an address decoder that selects which data signals the comparator receives from the local bus. [0011]
  • The COM driver sets the base address of the non-standard device by sending a predetermined pattern of address and data signals on the local bus and then following the pattern with a signal that indicates the base address of the device. The device starts in a locked state where the device does not have a base address and does not respond to signals on the local bus. Once the device recognizes the pattern sent by the COM driver, the device address is set to the value provided by the COM driver, and the device transitions to an unlocked state. In the unlocked state, the device responds to signals on the local bus which correspond to the base address of the device. [0012]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 shows a block diagram of a prior art interface between an application and a UART device. [0013]
  • FIG. 2 shows a block diagram of an interface in accordance with an embodiment of the invention. [0014]
  • FIG. 3A is a block diagram of a circuit which unlocks a device and sets the base device address of the device. [0015]
  • FIG. 3B is a block diagram of an embodiment of a base address decoder usable in the circuit of FIG. 3A. [0016]
  • FIG. 3C is a block diagram of an embodiment of a pattern generator usable in the circuit of FIG. 3A.[0017]
  • Use of the same reference symbols in different figures indicates similar or identical items. [0018]
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • An embodiment of this invention illustrated in FIG. 2 allows an [0019] application 140 running in an operating environment 130 to communicate with a serial device 110 having a hardware UART 105 and/or a serial device 210 having non-standard input/output (I/O) interface 205. A COM driver 220 contains conventional software subroutines for communications with hardware UART 105 and a software UART 222 for serial device 210. Software UART 222 allows operating environment 130 and application 140 to transparently communicate with non-standard serial device 210 as if serial device 210 contained a hardware UART.
  • In one embodiment of the [0020] invention operating environment 130 includes microsoft WINDOWS™ which supports four COM ports for communications with up to four serial devices connected to an ISA bus 115. A standard COM port occupies a slot of eight addresses on ISA bus 115. The eight addresses correspond to registers of a standard UART, which function as shown in Table 1.
    TABLE 1
    Offset Register
    0 Rx/Tx Buffer (read/write) or Divisor Latch
    least significant byte.
    1 Interrupt Enable or Divisor Latch most
    significant byte.
    2 Interrupt Identification
    3 Line control
    4 Modem control
    5 Line status
    6 Modem status
    7 Scratch
  • The divisor latch indicated in Table [0021] 1 is enabled by setting a bit DLAB in the line control register.
  • [0022] Serial device 210 logically occupies a COM port but does not have a hardware UART which physically occupies an I/O address slot on ISA bus 115. Accordingly, the I/O slot for the COM port used by serial device 210 is available for non-standard interface 205. Non-standard I/O 205 occupies up to eight addresses on ISA bus 115 but need not comply with the standard functions given in Table 1. An example non-standard interface is disclosed below.
  • [0023] Application 140 can be any sort of software. A typical application 140 is a communication program that transmits and receives data through a modem. To access a device connected to ISA bus 115, application 140 calls a routine in operating environment 130. The routine calls COM driver 220, and COM driver 220 accesses devices 110 and/or 210 via ISA bus 115. COM driver 220 is software containing a standard COM driver for UART 105 and a software UART 222 and an I/O handler 224 for communications with non-standard I/O device 210. A computer running application 140 executes software of COM driver 220 when operating environment 130 calls COM driver 120 and during interrupts.
  • Appendix A contains a listing of 8086 assembly language program which implements [0024] software UART 222 and I/O handler 224. Software UART 222 contains a set of virtual registers which are memory locations in the computer running COM driver 220 and which correspond to the registers of a standard UART. The virtual registers are updated using information from serial device 210 and operating environment 130. I/O handler 224 accesses serial device 210 (hardware) which is referred to as the ASIC in Appendix A.
  • During initialization of COM ports, [0025] COM driver 220 determines which of the four COM ports are allocated to standard UART devices, determines if a non-standard device is present, and then allocates an unassigned COM port and I/O slot to device 210. Serial device 210 is initially locked during start-up. When locked, serial device 210 receives a data signal DATA and address signal ADDR from ISA bus 115, but does not responds to any address. COM driver 220 unlocks device 210 by transmitting address signal ADDR and data signal DATA with values equal to predefined pattern recognized by device 210. When unlocked, the base device address of device 210 depends on information that COM driver 220 provides while unlocking device 210. Device 210 replies to the address set by COM driver 220 to indicate that device 210 is present.
  • FIG. 3A shows a block diagram of an unlocking circuit [0026] 300 which unlocks a device coupled to a local bus of a computer. Although, unlocking circuit 300 is described herein in the context of a serial device coupled to an ISA bus, unlocking circuit 300 is more generally applicable to any device coupled to a local bus such as a VLB or PCI bus.
  • Unlocking circuit [0027] 300 contains a base address decoder 330 and a pattern generator 310. While the device is locked, base address decoder 330 asserts a signal SEL to pattern generator 310. Pattern generator 310 generates a signal PAT that represents a byte which is from a predefined sequence and corresponds to the value of signal SEL. Signal SEL starts in an initial state, such as indicating a count value of zero or a maximum count. Each time the local bus carries an address signal ADDR having a recognized value, base address decoder 330 compares data signal DATA from the local bus to signal PAT and if signals PAT and DATA are equal, changes signal SEL so that signal SEL advances toward a final state. Otherwise, signal SEL is reset to indicate to the initial state. Advancing signal SEL can for example increment a count value from an initial state (minimum value) toward a final state (maximum value) or decrement the count from an initial state (maximum value) to a final state (minimum value).
  • When signal SEL reaches the final state, [0028] base address decoder 330 receives and stores a base address for the device and then asserts a signal PCSYNC to indicate the device is unlocked. The COM driver transmit the base address to the device in a number of ways. For example, the address signal used during transmission of the pattern or a following data signal can indicate the base address.
  • FIG. 3B shows a block diagram of an embodiment of [0029] base address decoder 330. Base address decoder 330 contains AND gates 331, 332, and 333 which are coupled address lines of ISA bus 115. AND gate 333 asserts a signal ADX when signal IOWCN indicates the computer is writing data and address signal ADDR[11:0] has the form 001x 111x 1111 binary where x indicates that bits ADDR4 and ADDR8 are “don't care” bits, i.e. can have either value 0 or 1. The COM driver selects values for bits ADDR8 and ADDR4 so that signal ADDR[11:0] does not correspond to any other device coupled to the ISA bus. A signal AEN indicates when a DMA controller in the computer places an address on ISA bus 115. In the embodiment shown, unlocking circuit 300 does not respond to the DMA controller, and signal ADX is only asserted if signal AEN indicates address signal ADDR [11:0] is not from the DMA controller.
  • AND [0030] gate 333 deasserts signal ADX when at the end of a write cycle and causes register 339 to latch a byte from signal DATA[7:0] on ISA bus 115. A comparator 340 compares the latched byte to signal PAT[7:0] and asserts a signal EQUAL if the latched byte equals the byte indicated by signal PAT[7:0]. Signal EQUAL determines what occurs the next time signal ADX is asserted. Signal EQUAL acts as a clock enable signal for a counter 335 and a flip-flop 345 and acts as an input signal for flip-flop 341. With signal EQUAL asserted when AND gate 333 asserts signal ADX, counter 335 increments count signal SEL[2:0], flip-flop 341 asserts a signal MATCH, and flip-flop 345 sets signal PCSYNC to the value of bit SEL2 of signal SEL[2:0]. With signal EQUAL deasserted when AND gate 333 asserts signal ADX, flip-flop 341 deasserts signal MATCH which resets counter 335 to an initial state with count value zero. Thus, counter 335 is reset to zero each time a data byte from ISA bus 115 is not equal to the data byte from the predefined pattern. Additionally, a signal RESET from ISA bus 115 can reset counter 335.
  • Count signal SEL[[0031] 2:0] increments if signal EQUAL is asserted when COM driver 220 generates on ISA bus 115 an address of the form 001x 111x 1111 and a data byte equal to signal PAT[7:0]. Incrementing signal SEL[2:0] causes pattern generator 310 to set signal PAT[7:0] to indicate the next byte in the predefined pattern.
  • FIG. 3C is a block diagram of an embodiment of [0032] pattern generator 310. Pattern generator 310 contains multiplexers 311 to 318 which have select terminals coupled to receive signal SEL[2:0]. Input terminals of multiplexers 311 to 314 are coupled to voltage VCC or ground. Signal SEL0 selects one of the two values for a signal AOUT[7:0] from multiplexers 311 and 312 and one of two values for a signal BOUT[7:0] from multiplexers 313 and 314. Multiplexers 315 and 316 select an output signal DOUT[7:0] which is equal to either signal AOUT[7:0] or BOUT[7:0] depending on select signal SEL1. Multiplexers 317 and 318 select signal PAT[7:0] which is equal to signal DOUT[7:0] or a fixed value depending on the value of select signal SEL2. Pattern generator 310 generates a five byte string, the ASCII code for “PCtel”, which indicates the manufacturer of the device.
  • Many alternative patterns and pattern generators may be used in place of the embodiment shown in FIG. 3C. For example, [0033] pattern generator 310 can be implemented using a memory such as a read-only memory where signal SEL[2:0] is an address signal or implemented using combinatorial logic where signal SEL[2:0] is an input signal. Each value in the pattern can be longer or shorter than a byte and can be a constant value independent of signal SEL. Further, the predetermined pattern can be longer or shorter that to five values. Increasing the length of the pattern reduces the chance of a device being unintentionally unlocked.
  • If [0034] COM driver 220 sends a sequence of five data bytes matching the predefined pattern, counter 335 increments to final state and bit SEL2 of signal SEL[2:0] is set when a fifth byte is sent. With bit SEL2 set, AND gate 333 asserting signal ADX causes flip- flops 337 and 338 to latch and store bits ADDR8 and ADDR4 of address signal ADDR[11:0] and causes flip-flop 345 to assert signal PCSYNC. Signal PCSYNC indicates that the device is unlocked and has a base address of the form 001a 111b 1000, where signals PCA8 and PCA4 from flip- flops 337 and 338 indicate the values of bits a and b. Values of bits a and b have four possible combinations which allows COM driver 220 to select a combination that provides a base address that differs from the base addresses of the three other COM ports.
  • Signals PCA[0035] 4 and PCA8 are latched when an address signal ADDR[11:0] is asserted for a byte following the predefined pattern. The byte following the predefined pattern does not match signal PAT[7:0] from pattern generator 310. Accordingly, counter 335 is reset to the initial state, and bit SEL2 is cleared. Signals PCA8 and PCA4 do not change unless the predefined pattern is retransmitted. Unintentional transmission of the predefined pattern is unlikely during normal operation of the computer system, but if desired, COM driver 220 monitor the pattern being transmitted and prevent repetition of the predefined pattern, for example by writing a no-op value to device 210.
  • Once the device is unlocked, a signal ADBASE indicates whether address signal ADDR[[0036] 11:0] corresponds to the device. An AND gate 332 asserts a signal ADB if address signal ADDR[11:0] has the form 001x 111x 1xxx when signal AEN indicates the address signal ADDR[11:0] is not from the DMA controller. A comparator 344 asserts signal ADBASE only if signal ADB is asserted, signal PCSYNC is asserted, and bits ADDR8 and ADDR4 of address signal ADDR[11:0] equal signals PCA8 and PCA4. Conventional address decoding circuits (not shown) decode bits ADDR2, ADDR1, and ADDR0 to determine which register in the device is being accessed via ISA bus 115.
  • The additional decoding circuits and the register set of the device can be implemented as required for the function of the device. The standard UART interface need not be followed. This allows an I/O interface to be optimized and implemented for the particular function of the device. [0037]
  • FIG. 2 shows an embodiment where [0038] serial device 210 contains an analog-to-digital converter (ADC) 206 and a digital-to-analog converter (DAC) 207 which are connected to PSTN phonelines 208 for implementation of a software modem. In this embodiment, software UART 222 and I/O handler 224 are part of a software modem 223. A register set in non-standard I/O interface 205 is described in Table 2.
    TABLE 2
    Offset Register
    0 Data Register (Low Byte)
    1 Data Register (High Byte)
    2 Control/Status Register (Low Byte)
    3 Control/Status Register (High Byte)
    4 Input/Output Port Register
    5 Reserved
    6 Reserved
    7 Pattern Port Register
  • In the register set of Table 2, the data registers are for 16-bit data words sent to [0039] DAC 207 or received from ADC 206 by the host computer. Input/output port register are for modem functions such as ring detection and control of an on-off hook relay (to connect or disconnect device 208 to an active phone line) which are implemented by hardware in serial device 210. The control/status register are general purpose control and status bit for serial device 210.
  • [0040] ADC 206 receives an analog communications signal from phonelines 208 and converts the analog communications signal into a series of sampled digital values. Software modem 223 receives the sampled digital values and based on the waveform represented by the sampled values and on the modem protocol employed determines data received. Software modem 223 also generates a series of digital values which are sent to DAC 207 and transmitted as an analog signal on phonelines 208. The transmitted analog signal provides a carrier signal and data values formatted according to standard modem protocols such as ITU V.32bis, V.32, V.22bis, V.23, V.22, V.21, V.17, V.29, and V.27ter standards. Device 210 generates periodic interrupts during which software modem 223 reads a set of sampled digital values from ADC 206 and writes a set of digital values which represent the transmitted analog signal. COM driver 220 sets the interrupt number (or IRQ) used by device 210 to a user selected one of eight values.
  • [0041] Application 140 communicates with software modem 223 in the same manner as with a conventional hardware modem. Application 140 sends and receives data and control values via operating environment 130. The data and control values are formatted for a standard UART device so that whether software modem 223 is a standard modem containing a hardware UART or a software modem is completely transparent to application 140 and operating environment 130.
  • Although the present invention has been described with reference to particular embodiments, the description is only an example of the invention's application and should not be taken as a limitation. Various adaptations and combinations of features of the embodiments disclosed will be apparent to those skilled in the art and are within the scope of the present invention as defined by the following claims. [0042]

Claims (16)

I claim:
1. A system comprising:
a computer having a processing unit, a main memory, and a local bus;
a device coupled to the local bus, wherein the device occupies an I/O slot which corresponds to a first communications port on the local bus, and the device has a register set which differs from a register set for a UART;
an operating system executed by the processing unit, wherein the operating system includes a procedure for accessing a register of a UART corresponding to the first communications port; and
a communications driver executed by the processing unit, comprising:
a UART emulation which in response to execution of the procedure for accessing a register of a UART, accesses storage locations in the main memory; and
an I/O handler which transfers values between the storage locations in the main memory and the register set of the device.
2. The system of claim 1, wherein the local bus comprises an ISA bus.
3. The system of claim 1, wherein the device coupled to the local bus, further comprises:
a comparator adapted for receiving a data signal from the local bus;
a pattern generator coupled to the comparator, wherein the pattern generator generates a signal for comparison with the data signal;
a counter operably coupled to the comparator, wherein the counter resets to an initial state following the comparator indicating the data signal is not equal to the pattern signal and advances toward a final state following the comparator indicating the data signal equals the pattern signal; and
a register coupled to the counter and adapted to receive a signal from the local bus, wherein in response to the counter reaching the final state, the register latches from the local bus a value which indicates the base address of the I/O slot occupied by the device.
4. A method for communication between a computer and a device having an I/O interface which differs from the I/O interface of a UART, comprising:
coupling the I/O interface of the device to a local bus in the computer;
allocating in a memory of the computer, storage locations which correspond to registers of a UART; and
transmitting values via the local bus between the I/O interface of the device and the storage locations in the memory of the computer.
5. The method of claim 4, further comprising transmitting from an application to a communications driver a data packet which is formatted for a UART, wherein the communication driver updates a value in the storage locations according to a value in the data packet.
6. The method of claim 5, wherein the communication drive performs the step of transmitting by:
converting a value in the data packet to a converted value compatible with the I/O interface of the device; and
writing the converted value to a register in the device via the local bus.
7. The method of claim 4, wherein transmitting further comprising:
reading values from a register of the device via the local bus; and
updating the storage locations according to the value read.
8. The method of claim 7, further comprising transmitting from a communications driver to an application a data packet containing a value from the storage locations.
9. The method of claim 4, further comprising:
executing on the computer an operating environment which allocates I/O slots on the local bus for UARTs; and
setting a base device address for the device to correspond to one of the I/O slots allocated by the operating environment for a UART.
10. The method of claim 9, wherein setting the base device address comprises:
sensing, by the device, of a data signal on the local bus;
comparing by the data signal to a signal from a pattern generator in the device;
advancing a state indicator toward a final state in response to the data signal being equal to the signal from the pattern generator;
repeating the steps of sensing, comparing, and advancing until the state indicator reaches the final state; and
setting the base address of the device to a value indicated by a signal on the local bus in response to the state indicator reaching the final state.
11. A device for connection to a local bus of a computer, comprising:
a comparator adapted for receiving a data signal from the local bus;
a pattern generator coupled to the comparator, wherein the pattern generator generates a signal for comparison with the data signal;
a counter operably coupled to the comparator, wherein the counter resets to an initial state following the comparator indicating the data signal is not equal to the pattern signal and advances toward a final state following the comparator indicating the data signal equals the pattern signal; and
a register coupled to the counter and adapted to receive a signal from the local bus, wherein in response to the counter reaching the final state, the register latches from the local bus a value which indicates the base address of the device.
12. The device of claim 11, further comprising an address decoder adapted for receiving an address signal from a local bus of a computer, wherein the address decoder selects which data signals the comparator receives from the local bus.
13. The device of claim 11, wherein the register is adapted to latch a signal from an address line of the local bus.
14. The device of claim 11, wherein the local bus comprises an ISA bus.
15. A method for setting the base address of a device coupled to a local bus of a computer, comprising:
sensing, by the device, of a data signal on the local bus;
comparing by the data signal to a signal from a pattern generator in the device;
advancing a state indicator toward a final state in response to the data signal being equal to the signal from the pattern generator;
repeating the steps of sensing, comparing, and advancing until the state indicator reaches the final state; and
setting the base address of the device to a value indicated by a signal on the local bus in response to the state indicator reaching the final state.
16. The method of claim 15, further comprising:
placing the device in a locked state before the first sensing step, wherein in the locked state, the device does not respond to any signals sensed on the local bus; and
placing the device in an unlocked state after the step of setting the base address, wherein in the unlocked state the device responds to signals on the local bus which correspond to the set base address of the device.
US09/030,710 1995-04-25 1998-02-25 Communications interface and conflict avoidance using a software simulation of a uart Abandoned US20020087745A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/030,710 US20020087745A1 (en) 1995-04-25 1998-02-25 Communications interface and conflict avoidance using a software simulation of a uart

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/428,935 US5787305A (en) 1995-04-25 1995-04-25 Host signal processing modem using a software simulation of a UART
US09/030,710 US20020087745A1 (en) 1995-04-25 1998-02-25 Communications interface and conflict avoidance using a software simulation of a uart

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US08/428,935 Continuation US5787305A (en) 1995-04-25 1995-04-25 Host signal processing modem using a software simulation of a UART

Publications (1)

Publication Number Publication Date
US20020087745A1 true US20020087745A1 (en) 2002-07-04

Family

ID=23701036

Family Applications (2)

Application Number Title Priority Date Filing Date
US08/428,935 Expired - Lifetime US5787305A (en) 1995-04-25 1995-04-25 Host signal processing modem using a software simulation of a UART
US09/030,710 Abandoned US20020087745A1 (en) 1995-04-25 1998-02-25 Communications interface and conflict avoidance using a software simulation of a uart

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US08/428,935 Expired - Lifetime US5787305A (en) 1995-04-25 1995-04-25 Host signal processing modem using a software simulation of a UART

Country Status (4)

Country Link
US (2) US5787305A (en)
EP (1) EP0740253B1 (en)
JP (2) JP3759234B2 (en)
DE (2) DE740253T1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050044277A1 (en) * 2003-08-20 2005-02-24 Zilavy Daniel V. Configurable mapping of devices to bus functions
EP4187395A1 (en) * 2021-11-26 2023-05-31 Göpel electronic GmbH Method and device for emulating transmission protocols for controlling electronic components on a bus system

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5742845A (en) * 1995-06-22 1998-04-21 Datascape, Inc. System for extending present open network communication protocols to communicate with non-standard I/O devices directly coupled to an open network
EP0788057B1 (en) 1996-01-31 2003-05-02 Compaq Computer Corporation Computer system with controllerless modem
US5864710A (en) * 1996-07-23 1999-01-26 Compaq Computer Corporation Controllerless modem
JP2001507835A (en) * 1996-12-30 2001-06-12 シーラス ロジック,インコーポレイテッド Past compatible operating system real-time services
US6353857B2 (en) * 1997-03-31 2002-03-05 Intel Corporation Controllerless modem
US6230118B1 (en) * 1997-06-30 2001-05-08 Cirrus Logic, Inc. DOS based application supports for a controllerless modem
US6128674A (en) * 1997-08-08 2000-10-03 International Business Machines Corporation Method of minimizing host CPU utilization in driving an adapter by residing in system memory a command/status block a soft interrupt block and a status block queue
US6134609A (en) * 1998-03-31 2000-10-17 Micron Electronics, Inc. Method for using computer system memory as a modem data buffer by transferring modem I/O data directly to system controller and transferring corresponding system controller data directly to main memory
US6272452B1 (en) * 1998-04-02 2001-08-07 Ati Technologies, Inc. Universal asynchronous receiver transmitter (UART) emulation stage for modem communication
US6661848B1 (en) 1998-09-25 2003-12-09 Intel Corporation Integrated audio and modem device
US6711206B1 (en) 1998-09-25 2004-03-23 Intel Corporation Modem using a digital signal processor and separate transmit and receive sequencers
US6625669B1 (en) * 2000-02-17 2003-09-23 Microsoft Corporation Renaming of virtual communication port for IR devices
US20030093809A1 (en) * 2001-09-28 2003-05-15 Zhengjin Shu Channel equalization
JP2003264602A (en) * 2002-03-08 2003-09-19 Fujitsu Ltd Communication control unit, communication control program and communication control method
DE20204651U1 (en) 2002-03-18 2003-08-07 Peeters Bernd Device for protection against unauthorized use of software
DE60317816D1 (en) * 2002-10-15 2008-01-10 Socket Communications Inc SOFTWARE COMPATIBLE PARALLEL INTERFACE WITH BIDIRECTIONAL HANDSHAKING FOR SERIAL PERIPHERALS
US7623894B2 (en) 2003-10-09 2009-11-24 Freescale Semiconductor, Inc. Cellular modem processing
US20060075149A1 (en) * 2004-10-01 2006-04-06 Via Telecom Co., Ltd. Communications command control system with a software based at command receiver/transmitter
US20070288937A1 (en) * 2006-05-08 2007-12-13 Microsoft Corporation Virtual Device Driver
US9842072B2 (en) 2015-03-27 2017-12-12 Toshiba Global Commerce Solutions Holdings Corporation Systems and methods for implementing a user mode virtual serial communications port emulator

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE2916139A1 (en) * 1979-04-20 1980-10-30 Bayer Ag NEW POLYURETHANE UREA MATERIALS WITH AROMATIC UREA GROUPS CONTAINING SULFUR AND METHOD FOR THE PRODUCTION THEREOF
US4373181A (en) * 1980-07-30 1983-02-08 Chisholm Douglas R Dynamic device address assignment mechanism for a data processing system
EP0173905A2 (en) * 1984-09-07 1986-03-12 Tektronix, Inc. Dynamic address assignment system
US4773005A (en) * 1984-09-07 1988-09-20 Tektronix, Inc. Dynamic address assignment system
US4730251A (en) * 1985-10-28 1988-03-08 International Business Machines Corporation Automatic I/O address assignment
US4817147A (en) 1985-11-18 1989-03-28 General Datacomm, Inc. Intelligent synchronous modem and communication system incorporating the same
US4875186A (en) * 1986-02-28 1989-10-17 Prime Computer, Inc. Peripheral emulation apparatus
US4949333A (en) 1987-04-02 1990-08-14 Advanced Micro Devices, Inc. Enhanced universal asynchronous receiver-transmitter
US5170470A (en) * 1988-05-02 1992-12-08 National Semiconductor Corp. Integrated modem which employs a host processor as its controller
EP0378037B1 (en) * 1989-01-10 1993-08-04 International Business Machines Corporation Modem having a software-adapted modulation rate
JP2547654B2 (en) * 1990-06-29 1996-10-23 三洋電機株式会社 Data processing device
EP0464433A3 (en) * 1990-06-29 1994-05-18 Nat Semiconductor Corp Microcontroller device having remotely programmable eprom & method of programming
US5428748A (en) * 1992-09-24 1995-06-27 National Semiconductor Corporation Method and apparatus for automatically configuring a computer peripheral
US5450530A (en) * 1993-11-03 1995-09-12 Rockwell International Corporation High speed receiver/transmitter interface
EP0653704A1 (en) * 1993-11-05 1995-05-17 Advanced Micro Devices, Inc. System and method for configuring expansion cards in a computer
US5477415A (en) 1993-11-12 1995-12-19 Texas Instruments Incorporated Automatic computer docking station having a motorized tray, cammed side connectors, motorized side connectors, and locking and unlocking guide pins
US5408614A (en) * 1993-12-17 1995-04-18 Xircom, Inc. Modem adapter for use with standard PC parallel port
US5678059A (en) 1994-02-18 1997-10-14 Lucent Technologies Inc. Technique for time-sharing a microprocessor between a computer and a modem
US5654983A (en) 1994-06-10 1997-08-05 Hayes Microcomputer Products, Inc. Method and apparatus of operating data communications equipment in command mode and autobauding
US5604870A (en) * 1994-08-01 1997-02-18 Moss; Barry UART emulator card
US5644593A (en) 1994-09-02 1997-07-01 Microcom Systems, Inc. High performance communications interface
US5557634A (en) 1994-10-14 1996-09-17 International Business Machines Corporation Multiprotocol directed infrared communication controller
US5812820A (en) 1995-09-29 1998-09-22 Pacific Commware, Inc. Virtual UART

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050044277A1 (en) * 2003-08-20 2005-02-24 Zilavy Daniel V. Configurable mapping of devices to bus functions
US7003591B2 (en) 2003-08-20 2006-02-21 Hewlett-Packard Development Company, L.P. Configurable mapping of devices to bus functions
US20060161692A1 (en) * 2003-08-20 2006-07-20 Zilavy Daniel V Configurable mapping of devices to bus functions
US7757012B2 (en) 2003-08-20 2010-07-13 Hewlett-Packard Development Company, L.P. Configurable mapping of devices to bus functions
EP4187395A1 (en) * 2021-11-26 2023-05-31 Göpel electronic GmbH Method and device for emulating transmission protocols for controlling electronic components on a bus system

Also Published As

Publication number Publication date
DE740253T1 (en) 1997-11-20
JPH0926944A (en) 1997-01-28
EP0740253A2 (en) 1996-10-30
JP2000112868A (en) 2000-04-21
EP0740253A3 (en) 1997-02-12
EP0740253B1 (en) 2002-07-31
DE69622627T2 (en) 2003-03-06
JP3759234B2 (en) 2006-03-22
US5787305A (en) 1998-07-28
DE69622627D1 (en) 2002-09-05

Similar Documents

Publication Publication Date Title
US5787305A (en) Host signal processing modem using a software simulation of a UART
US5649128A (en) Multiple bus interface adapter for connection to a plurality of computer bus architectures
US5568619A (en) Method and apparatus for configuring a bus-to-bus bridge
US5724529A (en) Computer system with multiple PC card controllers and a method of controlling I/O transfers in the system
US5953511A (en) PCI bus to IEEE 1394 bus translator
US5175536A (en) Apparatus and method for adapting cards designed for a VME bus for use in a VXI bus system
EP0588191B1 (en) Exchanging data and clock lines on multiple format data buses
US5619722A (en) Addressable communication port expander
US6618773B1 (en) Receiving a particular identification file among an analog identification file and a digital identification file in response to a request to a dual-interface monitor
WO1998048356A1 (en) A single chip microcontroller having down-loadable memory organization supporting 'shadow' personality, optimized for bi-directional data transfers over a communication channel
US6779052B2 (en) Electronic apparatus, system and method for controlling communication among devices coupled through different interfaces
US5765021A (en) Computer system having second program for transferring data between second port connected to a first port and the software portion of a modem
US5590374A (en) Method and apparatus for employing a dummy read command to automatically assign a unique memory address to an interface card
US5937175A (en) PCI bus to IEEE 1394 bus translator employing pipe-lined read prefetching
EP1552404B1 (en) Deferred tuple space programming of expansion modules
US6230216B1 (en) Method for eliminating dual address cycles in a peripheral component interconnect environment
US6470404B1 (en) Asynchronous communication device
US5754769A (en) Coupling between non-CTOS host and CTOS network
US20030005176A1 (en) Accessing a translated resource descriptor of a hardware device
JP4683845B2 (en) System and method for implementing hidden addresses in a communication module
US6889280B1 (en) Motherboard extension features to provide plug and play information
US20050086415A1 (en) PCI-PCMCIA smart card reader
US6272576B1 (en) Method for extending the available number of configuration registers
US6301631B1 (en) Memory mapping method for eliminating dual address cycles in a peripheral component interconnect environment
US6598111B1 (en) Backplane physical layer controller

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION