Systems, devices, and methods for transferring data between an intelligent docking station and a handheld personal computer

RELATED APPLICATIONS

[0001] This patent application is related to and claims priority from co-owned and assigned U.S. patent application Ser. No. 10/051,264 to Scott, et al. entitled System for Integrating an Intelligent Docking Station with a Handheld Personal Computer, filed on Feb. 1, 2002. This patent application is also related to and claims priority from co-owned and assigned U.S. patent application Ser. No. 10/061,997 to Scott, et al. entitled Method for Integrating an Intelligent Docking Station with a Handheld Personal Computer, filed on Feb. 1, 2002.

REFERENCED APPLICATIONS

[0002] The invention is related to U.S. Pat. No. 6,088,752 to Ahem, et al, entitled Method and apparatus for exchanging information between buses in a portable computer and docking station through a bridge employing a serial link, which was filed on Aug. 6, 1998 and which issued on Jul. 11, 2000, and which is incorporated herein by reference. The invention is further related to U.S. Pat. No. 6,256,691 to Moroz, et al., entitled Universal Docking Station, which was filed on Jan. 11, 2000 and which issued on Jul. 3, 2001, and which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

[0003] 1. Technical Field

[0004] The present invention generally relates to desktop, mobile, or portable computing.

[0005] 2. Problem Statement

[0006] In part because of the ability to make businesses and households more efficient, personal computers (PCs) have earned a solid place in homes and businesses. However, PCs are typically bulky, require large amounts of power, and occupy a large amount of surface area, called a “footprint.”

[0007] Computers small enough to be held in a single hand, called “handhelds” or personal digital assistants (PDAs), provide significant computing power in a small device that uses relatively little power. Unfortunately, handhelds do not offer the most user-friendly input/output devices, such as a keyboard and mouse. Instead, a user of a handheld must be content with using a stylus or other data entry device. Accordingly, it is desirable to provide a device, system, and method for integrating the convenience of a handheld into a PC-type input/output environment. The invention provides such devices, systems, and methods.

SUMMARY OF THE INVENTION

[0008] The invention achieves technical advantages transferring a data element from a device to a handheld computer, and from a handheld computer to a device. The invention may be embodied as a method. In general, the method receives a device-enabled data element at a docking station enabled co-processor, performs a driver conversion to convert the device-enabled data element into a bus-enabled data element, and places the bus-enabled data element on a handheld compatible bus. In one embodiment, the method may transform a data packet by detecting an input packet, retrieving a packet identifier (ID) from the input packet, and dispatching the input packet to a device driver enabled on the packet ID, the device driver capable of converting the input packet from a handheld computer packet type to a device packet type.

[0009] The invention, in another embodiment, is also a system that enables the method. For example, the invention is in one embodiment a software system for an intelligent docking station. The software system includes an IDS operating system, a top-level device driver, the top-level device driver capable of assembling handheld device-enabled data elements on an input packet and capable of formatting IDS device-enabled data elements for the handheld low-level device driver on an output packet, a communication driver, the communication device driver capable of sending and receiving bus-enabled data elements, and a low-level device driver (the low-level device driver being capable of controlling peripheral devices with device-enabled data elements.) The IDS operating system is enabled to assemble data elements from the communication driver and format the data elements for the low-level device driver.

[0010] In yet another embodiment, the invention is a device. As a device, the invention is an intelligent docking station. The intelligent docking station includes a co-processor capable of converting a handheld-enabled data element into a device enabled data element, a bus interface coupled to the co-processor, and a port coupled to the co-processor. The invention may also be embodied as a system that incorporates the intelligent docking station.

[0011] The methods may be embodied as manufactured devices. For example, the methods may be placed on a computer readable medium, such as a computer diskette, CD ROM, or other memory device. In addition, the methods maybe placed in a computer memory or hard-written onto a processor to enable a general computing device to be transformed into a specific computing machine, or specific system. A computer system may be set up as a network capable of executing any of the methods. One such network could be the Internet, and the network could employ an application service provider. In addition, the invention may be embodied as one or more data signals that transform a general network into a task-specific network (or, task specific distributed machine).

[0012] Of course, other features and embodiments of the invention will be apparent to those of ordinary skill in the art. After reading the specification, and the detailed description of the exemplary embodiment, these persons will recognize that similar results can be achieved in not dissimilar ways. Accordingly, the detailed description is provided as an example of the best mode of the invention, and it should be understood that the invention is not limited by the detailed description. The invention is limited only by the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Various aspects of the invention, as well as an embodiment, are better understood by reference to the following detailed description. To better understand the invention, the detailed description should be read in conjunction with the drawings in which:

[0014]FIG. 1 depicts an intelligent docking station system;

[0015]FIG. 2 shows a software system for an intelligent docking station; and

[0016]FIG. 3 illustrates a block-flow diagram of an intelligent docking station (IDS) algorithm;

[0017]FIG. 4 is a logic-flow diagram of a PDA docking algorithm;

[0018]FIG. 5 is a block-flow diagram of an IDS docking algorithm; and

[0019]FIG. 6 illustrates one embodiment of an intelligent docking station system which incorporates at least one aspect of the referenced patents

BRIEF DESCRIPTION OF PRIOR ART FIGURES REFERENCED IN THE DETAILED DESCRIPTION

[0020]FIG. 1 ('752 prior art) is a schematic block diagram showing a bridge split by a link within the bridge, in accordance with principles of the present invention;

[0021]FIG. 2 ('752 prior art) is a schematic block diagram showing a bridge in accordance with principles of the present invention using the link of FIG. 1 ('752 prior art);

[0022]FIG. 3 ('752 prior art) is a schematic block diagram showing the bridge of FIG. 2 ('752 prior art) used in a docking system in accordance with principles of the present invention;

[0023]FIG. 4 ('752 prior art) is a cross-sectional view of the cable of FIG. 3 ('752 prior art);

[0024]FIG. 5 ('752 prior art) is a schematic illustration of the bridge of FIG. 3 ('752 prior art) shown connected to a portable computer and a variety of peripheral devices; and

[0025]FIG. 6 ('752 prior art) shows a docking station similar to that of FIG. 5 ('752 prior art) but with the portable computer modified to contain an application-specific integrated circuit designed to support a link to the docking station.

[0026]FIG. 1 ('691 prior art) is a block diagram showing a docking station in accordance with one embodiment of the invention connected to various peripheral devices and connected to a computer via a standard universal interface.

[0027]FIG. 2 ('691 prior art) is a more detailed block diagram of the docking station represented in FIG. 1 ('691 prior art).

[0028]FIG. 3 ('691 prior art) is a flow chart showing a method of initializing a device driver into an operating system.

[0029]FIG. 4 ('691 prior art) is a flow chart of steps that occur in handling insertion of a PCMCIA card into a PCMCIA port of a computer.

[0030]FIG. 5 ('691 prior art) is a flow chart of steps that occur when the docking station shown in FIG. 1 ('691 prior art) causes an interrupt on the computer requesting service for one of the peripheral devices.

[0031]FIG. 6 ('691 prior art) is a timing diagram showing the write timing used to interface multiple peripheral devices to the PCMCIA port.

[0032]FIG. 7 ('691 prior art) is a timing diagram showing the read timing used to interface multiple peripherals to the PCMCIA port.

DETAILED DESCRIPTION

[0033] Interpretative Considerations

[0034] When reading this section (An Exemplary Embodiment of a Best Mode, which describes an exemplary embodiment of the best mode of the invention, hereinafter “exemplary embodiment” or “Detailed Description”), one should keep in mind several points. First, the following exemplary embodiment is what the inventor believes to be the best mode for practicing the invention at the time this patent was filed. Thus, since one of ordinary skill in the art may recognize from the following exemplary embodiment that substantially equivalent structures or substantially equivalent acts may be used to achieve the same results in exactly the same way, or to achieve the same results in a not dissimilar way, the following exemplary embodiment should not be interpreted as limiting the invention to one embodiment.

[0035] Likewise, individual aspects (sometimes called species) of the invention are provided as examples, and, accordingly, one of ordinary skill in the art may recognize from a following exemplary structure (or a following exemplary act) that a substantially equivalent structure or substantially equivalent act maybe used to either achieve the same results in substantially the same way, or to achieve the same results in a not dissimilar way.

[0036] Accordingly, the discussion of a species (or a specific item) invokes the genus (the class of items) to which that species belongs as well as related species in that genus. Likewise, the recitation of a genus invokes the species known in the art. Furthermore, it is recognized that as technology develops, a number of additional alternatives to achieve an aspect of the invention may arise. Such advances are hereby incorporated within their respective genus, and should be recognized as being functionally equivalent or structurally equivalent to the aspect shown or described.

[0037] Second, the only essential aspects of the invention are identified by the claims. Thus, aspects of the invention, including elements, acts, functions, and relationships (shown or described) should not be interpreted as being essential unless they are explicitly described and identified as being essential. Third, a function or an act should be interpreted as incorporating all modes of doing that function or act, unless otherwise explicitly stated (for example, one recognizes that “tacking” may be done by nailing, stapling, gluing, hot gunning, riveting, etc., and so a use of the word tacking invokes stapling, gluing, etc., and all other modes of that word and similar words, such as “attaching”). Fourth, unless explicitly stated otherwise, conjunctive words (such as “or”, “and”, “including”, or “comprising” for example) should be interpreted in the inclusive, not the exclusive, sense. Fifth, the words “means” and “step” are provided to facilitate the reader's understanding of the invention and do not mean “means” or “step” as defined in §112, paragraph 6 of 35 U.S.C., unless used as “means for—functioning—” or “step for—functioning—” in the Claims section.

[0038] Computer Systems as Software Platforms

[0039] A computer system typically includes hardware capable of executing machine-readable instructions, other hardware, as well as the software for executing acts (typically machine-readable instructions) that produce a desired result. In addition, a computer system may include hybrids of hardware and software, as well as computer sub-systems. The way hardware is organized within a system is known as the system's architecture (discussed below).

[0040] Software includes machine code stored in memory, such as RAM or ROM, or machine code stored on devices (such as floppy disks, or a CD ROM, for example). Software may include executable code, an operating system, or source or object code, for example. In addition, software encompasses any set of instructions capable of being executed in a client machine or server—and, in this form, is often called a program or executable code.

[0041] Programs often execute in portions of code at a time. These portions of code are sometimes called modules or code-segments. Often, but not always, these code segments are identified by a particular function that they perform. For example, a counting module (or “counting code segment”) may monitor the value of a variable. Furthermore, the execution of a code segment or module is sometimes called an act. Accordingly, software may be used to perform a method that comprises acts. In the present discussion, sometimes acts are referred to as steps to help the reader more completely understand the exemplary embodiment.

[0042] Software also includes description code. Description code specifies variable values and uses these values to define attributes for a display, such as the placement and color of an item on a displayed page. For example, the Hypertext Transfer Protocol (HTTP) is the software used to enable the Internet and is a description software language.

[0043] Hybrids (combinations of software and hardware) are becoming more common as devices for providing enhanced functionality and performance to computer systems. A hybrid is created when traditionally software functions are directly manufactured into a silicon chip—this is possible since software may be assembled and compiled into ones and zeros, and, similarly, ones and zeros can be represented directly in silicon. Typically, the hybrid (manufactured hardware) functions are designed to operate seamlessly with software. Accordingly, it should be understood that hybrids and other combinations of hardware and software are also included within the definition of a computer system and are thus envisioned by the invention as possible equivalent structures and equivalent methods.

[0044] Computer sub-systems are combinations of hardware or software (or hybrids) that perform some specific task. For example, one computer sub-system is a soundcard. A soundcard provides hardware connections, memory, and hardware devices for enabling sounds to be produced and recorded by a computer system. Likewise, a soundcard may also include software needed to enable a computer system to “see” the soundcard, recognize the soundcard, and drive the soundcard.

[0045] Sometimes the methods of the invention may be practiced by placing the invention on a computer-readable medium. Computer-readable mediums include passive data storage, such as a random access memory (RAM) as well as semi-permanent data storage such as a compact disk read only memory (CD-ROM). In addition, the invention may be embodied in the RAM of a computer and effectively transform a standard computer into a new specific computing machine.

[0046] Data elements are organizations of data. One data element could be a simple electric signal placed on a data cable. One common and more sophisticated data element is called a packet. Other data elements could include packets with additional headers/footers/flags. Data signals comprise data, and are carried across transmission mediums and store and transport various data structures, and, thus, may be used to transport the invention. It should be noted in the following discussion that acts with like names are performed in like manners, unless otherwise stated.

[0047] Description of the Drawings

[0048] Reference is now made to the figures, and in particular with reference to FIG. 1, which depicts an intelligent docking station system. The intelligent docking station system comprises an intelligent docking station <b>100</b>, which is capable of coupling to a handheld computer <b>140</b> or a device. In general, the intelligent docking station <b>100</b> includes a co-processor <b>110</b> capable of converting a handheld computer-enabled data element into a device enabled data element, a bus interface (BI) <b>130</b> coupled to the co-processor <b>110</b>, and a port <b>160</b>, coupled to the co-processor <b>110</b>.

[0049] In one embodiment, the intelligent docking station <b>100</b> includes logic (not shown) that is coupled between each port <b>160</b> and the co-processor <b>110</b>. The BI <b>130</b> may be any bus system used in any handheld computer, and is preferably a bi-directional bus such as Card Bus, PCMCIA, PCI, VME, ISA, SCSI, or a wireless bus. Similarly, the BI <b>130</b> may be simulated via USB, Firewire, or NIC, for example. The logic is employed to provide additional functionality to the intelligent docking station <b>100</b>.

[0050] For example, the logic could be a modem, thus enabling the intelligent docking station <b>100</b> to connect with special devices or networks, such as the base station (BS) device <b>158</b>. Other devices that may be coupled to the co-processor <b>110</b> through corresponding logic, which is preferably device specific logic, include a monitor <b>150</b>, a printer <b>152</b>, a mouse <b>154</b>, a data storage device (not shown), or a network <b>156</b>, such as the Internet. Of course, it should be understood that the devices provided herein are exemplary only, and any type of input or output device that is connectable to a PC is also connectable to the intelligent docking station <b>100</b> using the invention.

[0051] In another embodiment, the invention is an intelligent docking station system. The system includes a docking station <b>100</b> having a co-processor <b>110</b> capable of converting a hand held-enabled data element into a device enabled data element, a bus <b>130</b> that couples the docking station <b>100</b> to a handheld computer <b>140</b>, and a device coupled to the docking station <b>100</b>.

[0052] In yet another embodiment, the invention provides for the intelligent docking system to communicate with a personal digital assistant (or, hand held computer) via a link, such as a wireless link, a bridge, or a bus. In a preferred embodiment, the link interfaces the IDS to the PDA having data on a bus via a PCMCIA bus by providing data to be written to the IDS on the PCMCIA bus without waiting for the end of any current transactions. In another embodiment, the link sends information between the PDA and the IDS over a single connection by serial transmission through a link in a format different from that of the PDA and the IDS, and allows the PDA to individually address a device in communication with the IDS, wherein the PDA uses substantially the same type of addressing as is used to access a device directly using only the IDS. In a further embodiment, the link interfaces the IDS to the PDA when the PDA has data on a bus via a PCMCIA bus, by a) providing data to be written to the PDA on the PCMCIA bus without waiting for the end of any current transactions, and b) writing the data to the PDA via the PCMCIA bus. In addition, information may be sent between the IDS and the PDA over a single connection by serial transmission through a link in a format different from that of the PDA and the IDS, and the system may allow a peripheral device to individually address the PDA in communication with the IDS, wherein the peripheral device uses substantially the same type of addressing as is used to access the IDS.

[0053]FIG. 2 shows a software system <b>220</b> for an intelligent docking station. The software system for an intelligent docking station (the software system <b>220</b>) <b>220</b> includes an IDS operating system (IDS OS) <b>232</b>, which could be any common embedded or handheld operating system. Common operating systems include QNX RTOS, WindRiver VxWorks, Lineo Embeddix, Palm OS, Windows CE, Windows for Pocket PC, EPOC, and other Linux variants, for example. In addition, the software system <b>220</b> includes a communication device driver <b>226</b> which is capable of sending and receiving bus-enabled data elements, a low-level driver <b>236</b> that is capable of sending and receiving device-enabled data elements, and a top-level device driver <b>234</b> capable of assembling handheld device-enabled data elements on an input packet and capable of formatting IDS device-enabled data elements for the handheld low-level device driver <b>206</b> on an output packet.

[0054] Top level device drivers typically perform at least two functions. First, when a top level device driver receives an output data element from a communication driver, it gathers a packet and/or packet identification information and assembles a device-enabled data element that is understandable by a low level device driver. In addition, prior to sending input data elements received from a low level device driver, the top level device driver formats the data for an appropriate low level device driver. The low level device driver then passes the data element to a specific device, alters the data element in some way, or invokes an operating system to do something with the device.

[0055] The low-level device driver <b>236</b> is typically a device specific driver that sends and/or receives data elements from a specific device, such as a monitor or keyboard (in which case the device driver is called a display device driver or a keyboard device driver). In a preferred embodiment, the IDS operating system <b>232</b> is enabled to format the device-enabled data elements for the low-level handheld low-level device driver <b>206</b> and forward the formatted device-enabled data elements to the communication driver <b>226</b>. In a preferred embodiment, the IDS OS <b>232</b>, the top-level device driver <b>234</b>, and the low-level device driver <b>236</b> are maintained on the co-processor <b>230</b>. However, separate logic, software, or firmware may be used to accomplish the same conversions.

[0056] Other elements of the software system <b>220</b> include a bus module <b>228</b> which controls traffic across a bus that couples the IDS to a handheld computer. In addition, the software system <b>220</b> may include logic (not shown) for providing specific functionality to a device module <b>280</b>.

[0057] The invention is also a software system, embodied as a PDA system <b>210</b>. The PDA system <b>210</b> includes any embedded or handheld computer operating system <b>210</b>, which may be any of the systems discussed above, or any other common embedded or handheld computer operating system. The PDA system <b>210</b> also includes a handheld-enabled low-level device driver <b>206</b> that is capable of transferring handheld-enabled data directly between the PDA system <b>210</b> and a device, such as a monitor or a keyboard. The PDA system <b>210</b> has a top-level device driver <b>214</b> for formatting hand held-enabled device data to IDS specific low-level device data (<b>236</b>). In addition, the PDA system <b>210</b> has a communication driver <b>216</b> for converting the information normally handled by the device driver <b>214</b> into bus-enabled data that can be transferred across a bus that couples the handheld device to an intelligent docking station. Of course, although the communication driver <b>216</b> discussed above is described as software, the communication driver <b>216</b> may be embodied in firmware, or maintained within the PDA OS <b>212</b>.

[0058] Exemplary Methods

[0059]FIG. 3 illustrates a block-flow diagram of an intelligent docking station (IDS) algorithm <b>300</b>. In general, the IDS algorithm <b>300</b> can control a data flow between a handheld computer and a device. As a method of transferring a data element from a device to a handheld computer, after detecting a docking condition, and activating a communication driver in response to the docking condition (a docking detection act), the IDS algorithm <b>300</b> receives a device-enabled data element at a docking station enabled co-processor in a receive device data element act. The device-enabled data element is generated by a specific device, or, may be generated by device simulation software.

[0060] Next, if necessary, a top-level device driver reformats the device data element to the handheld device-enabled data element, which is then converted into a bus-enabled data element in a convert data element act by the communication driver. The conversion may take place in the IDS OS of the intelligent docking station, in separate software, or in firmware. Then, the IDS algorithm <b>300</b> places the bus-enabled data element on a handheld compatible bus in a bus placement act. In a system implementation of the IDS algorithm <b>300</b>, the bus-enabled data element is received in a handheld computer, and the bus-enabled data element is converted into a handheld data element in a convert to handheld act.

[0061] Similarly, the IDS algorithm <b>300</b> can transform data from a handheld to a device. Accordingly, the IDS algorithm <b>300</b> detects a docking condition in a detect docking act. Then, when handheld-enabled data is to be sent to a device, a handheld-enabled data element is converted into a bus-enabled data element via a communication driver in a bus enable act. Then, in a bus placement act, the bus-enabled data element is placed on a handheld compatible bus. Next, as a conversion act, the bus-enabled data element is received at a docking station enabled co-processor, and a driver converts the bus-enabled data element into a device-enabled data element. Accordingly, the device-enabled data is placed on an output port in a send data act.

[0062] The preferred IDS algorithm <b>300</b> is specifically illustrated by the block-flow diagram of FIG. 3. First, the IDS algorithm <b>300</b> detects a docking condition in a detect docking act <b>310</b>. Accordingly, within a detect docking act <b>310</b> a communication driver in the IDS waits in a low-power standby state act <b>312</b>, once docked the handheld will send an initiation command for the IDS to initialize the IDS docking sequence <b>314</b>. If no initialization sequence is detected as illustrated by the “n” arrow designation, then the IDS algorithm <b>300</b> returns to a standby state act <b>312</b>, which occurs between detection sequences. Of course, in the event of wireless docking, a wireless device will be detected by the IDS.

[0063] If the detection sequence <b>314</b> is initiated when the handheld computer is docked with an intelligent docking station, then the IDS algorithm <b>300</b> proceeds to a detect packet act <b>320</b>. In the detect packet act <b>320</b> the IDS detection algorithm <b>300</b> queries ports on the IDS as well as the bus that couples the handheld computer to the IDS. If no packet is detected, then the IDS detection algorithm <b>300</b> returns to the detect docking act <b>310</b>.

[0064] If a packet is detected on a port or a bus in the detect packet act <b>320</b>, in one embodiment by activating an Input Data line, then the IDS detection algorithm <b>300</b> proceeds to retrieve at least a packet identifier (ID) in a get packet act <b>330</b>. Alternatively, the IDS detection algorithm <b>300</b> may gather the entire packet in the get packet act <b>330</b>. Next, in a dispatch packet act <b>340</b>, the packet is sent to a communication driver.

[0065] Finally, in a destination act <b>350</b>, in the event that the packet is headed for a device, the handheld OS sends the packet to the appropriate device via the appropriate port. Similarly, if in the destination act <b>350</b>, the packet is destined for a handheld computer, the IDS destination algorithm <b>300</b> send the packet to the handheld OS for further processing as is known in the art.

[0066] For example, one may follow the flow of a graphics packet from the handheld computer to a display device. First, a communication driver detects that a docking condition has occurred in a detect docking act <b>310</b>. Then, the IDS OS detects that a packet has arrived on the bus by detecting a signal on an Input Data line. Accordingly, the IDS OS retrieves at least the packet ID, and knows from this packet ID that the packet should be delivered to a display device driver, and so dispatches the display device driver to convert the graphics packet from a bus-enabled data element to a display device-enabled data element. Finally, the IDS OS sends the display device-enabled data element to the display device.

[0067] Similarly, one may follow the flow of a packet from a keyboard to the handheld computer. First, a communication driver detects that a docking condition has occurred in a detect docking act <b>310</b>. Accordingly, the IDS OS retrieves at least the packet ID, and knows from this packet ID that the packet is a keyboard stroke or a series of keyboard strokes, and so the IDS OS dispatches the keyboard device driver to convert the device data element packet from a keyboard data element into a bus-enabled data element. Then, the IDS OS directs the IDS enabled communication driver to place the bus-enabled data element on the bus. Finally, the communication driver actually places the bus-enabled data element on the bus.

[0068] In one embodiment, the communication drivers are used to negotiate docking. Accordingly, FIG. 4 is a logic-flow diagram of a PDA docking algorithm <b>400</b>. The PDA docking algorithm <b>400</b> begins with either a docking event act <b>410</b> or a software (S.W.) docking act <b>415</b>. In the docking event act <b>410</b> a docking of a PDA and an IDS is initiated via hardware, such as a signal on a pin setting a flag, or for a wireless network a proximity detection is achieved wirelessly, for example. A docking event may also be defined as an undocking of a PDA with an IDS. Next, in an initiate PDA act <b>420</b>, the PDA OS toggles from PDA-based top-level device drivers, to top-level IDS device drivers, where appropriate. For example, the PDA OS toggles from PDA-based top-level video device drivers, to top-level IDS video device drivers. Device drivers are toggled in the preferred order of video device drivers, keyboard device drivers, mouse device drivers, and other device drivers. Of course, it is anticipated that as technology develops, other input and output devices will emerge, and those may be inserted into this hierarchy where appropriate.

[0069] In the SW docking act <b>415</b>, a user initiates a search for an IDS connection in the PDA software. Next, in a detect docking query <b>245</b>, the PDA, and preferably the PDA's communication driver, “pings”, queries various pins and/or caches, or otherwise test the connection between the PDA and the IDS until an indication of docking is found, or until a time-out event has occurred. A time-out is a predetermined period of time, such that if no docking connection is detected during the predetermined period of time, a time-out event is said to have occurred. If no docking connection is detected by the time a time-out event has occurred in the detect docking query <b>425</b>, then the PDA docking algorithm <b>400</b> proceeds to a display error message act <b>435</b> wherein the PDA OS directs the displaying of an error message on the PDA's display. If in the detect docking query <b>425</b> a docking connection is detected, then the PDA docking algorithm <b>400</b> proceeds to the initiate PDA act <b>420</b>.

[0070] Following the initiate PDA act <b>420</b>, the PDA docking algorithm <b>400</b> advances to a push act <b>430</b>. In the push act <b>430</b>, the communications driver in the PDA pushes a predetermined quantity of data to the IDS using any one of a number of available protocols. Alternatively, protocols may be selected dynamically to increase the efficiency of data transfer. The push act <b>430</b> continues until an interrupt event is detected, or until a predetermined period of time has passed without a data transfer. Thus, if an interrupt event is detected or a predetermined period of time passes, next, in a detect undocking query <b>440</b>, the PDA docking algorithm <b>400</b> queries the appropriate pins and caches to determine if the PDA and the IDS are docked. Undocking events are also preferably detected by a communication driver in the PDA. In the event the PDA and the IDS are docked, no undocking is detected and the PDA docking algorithm <b>400</b> returns to the push act <b>430</b> as shown by the “N” decision path. If, however, after a predetermined period of time no data or other indication of a connection is detected in the detect undocking query, it is determined that an undocking event has occurred, and the PDA docking algorithm <b>400</b> moves to the “y” decision path to a toggle act <b>450</b>.

[0071] In the toggle act <b>450</b> the PDA OS reverts back to the PDA-based top level device drivers. For example, the PDA goes from using the IDS-based video device driver to the PDA-based video device driver. Following the toggle act <b>450</b>, an error message is displayed on the PDA screen in a display error message act <b>460</b>. In one embodiment, an error message states “Error: PDA Needs Redocking”.

[0072] Docking initiated events also occur in the IDS. FIG. 5 is a block-flow diagram of an IDS docking algorithm <b>500</b>. By default, an IDS is in a “sleep” state, in which power to the processor and the IDS is minimized. However, when a docking is detected the IDS “wakes” up and becomes fully powered in a wake act <b>510</b>. Docking may be detected when a flag-pin is appropriately set, when something is received on the IDS port, or when a wireless sequence is detected, for example. Then, a detect PDA data query <b>520</b> takes place. In the PDA data query <b>520</b>, the IDS communication checks to see if data is present on the IDS port. If data is not present, as illustrated by the “N” decision, then the IS docking algorithm <b>500</b> determines that no docking as actually occurred and returns the IDS to a sleep mode in a sleep act <b>530</b>. If, on the other hand, the PDA data query <b>520</b> detects that data is present on the IDS port, by, for example, examining the port for a packet header, and evaluating the packet header to determine that the packet is intended for the IDS, then the IDS docking algorithm <b>500</b> proceeds to a pass data act <b>540</b>, as indicated by the “Y” decision. In the pass data act <b>540</b> the communication driver moves packets from the IDS port to the IDS OS or other appropriate location as indicated by the packet header. Likewise, in the pass data act <b>540</b> the communication driver moves packets to the IDS port from appropriate location of the IDS.

[0073] The pass data act <b>540</b> continues until an undocking condition is detected (such as flag indicating undocking is received), or until a predetermined period of time has passed without data transfer. Thus if an undocking condition is detected or a predetermined period of time passes without data transfer, then the IDS docking algorithm <b>500</b> proceeds to a detect undocking query <b>550</b>. In the detect undocking query <b>550</b> the communications driver queries the appropriate pins and caches to determine if the IDS is docked with the PDA. The detect undocking query <b>550</b> may also be performed by the IDS OS. In the event the PDA and the IDS are docked, no undocking is detected and the IDS docking algorithm <b>500</b> returns to the detect PDA act <b>520</b>, as shown by the “N” decision path. If, however, after a predetermined period of time, no data or other indication of a docking is detected, it is assumed that an undocking event has occurred, and the IDS docking algorithm <b>500</b> proceeds along the “y” decision path to a display error message act <b>560</b>. An error message is displayed on the monitor screen attached to the IDS, such as “Error: PDA Needs Redocking”. Then, in a sleep act <b>570</b>, the IDS returns to a sleep mode.

[0074] Exemplary Methods for Transmitting Data Between a PDA and an IDS

[0075] U.S. Pat. No. 6,088,752 to Ahem, et al, entitled Method and apparatus for exchanging information between buses in a portable computer and docking station through a bridge employing a serial link, which was filed on Aug. 6, 1998 and which issued on Jul. 11, 2000, and which is incorporated herein by reference discloses a method of transferring data between a mobile computer and a regular, prior-art (sometimes called a “dumb”) docking station (the '752 patent). Relevant sections of the '752 patent are here presented, with figures provided for the '752 patent designated below by “('752 prior art)”:

[0076] Referring to FIG. 1, a bridge is shown connecting between a first bus <b>10</b> and a second bus <b>12</b> (also referred to as primary bus <b>10</b> and secondary bus <b>12</b>). These buses may be PCI or PCMCIA 32-bit buses, although other types of buses are contemplated and the present disclosure is not restricted to any specific type of bus. Buses of this type will normally have address and data lines. In some cases, such as with the PCI bus, address and data are multiplexed onto the same lines. In addition, these buses will have signaling lines for allowing devices on the bus to negotiate transactions. For the PCI standard, these signaling lines will include four lines that are used either for control or byte enabling (C/BE[3:0]). Others signaling lines under the PCI standard exist for gaining control over the bus, for handshaking, and the like (e.g., FRAME#, TRDY#, IRDY#, STOP#, DEVSEL#, etc.)

[0077] Buses <b>10</b> and <b>12</b> are shown connecting to a first interface means <b>14</b> and 30 second interface means <b>16</b>, respectively (also referred to as interfaces <b>14</b> and <b>16</b>). Bus information selected for transmission by interfaces <b>14</b> and <b>16</b> are loaded into registers <b>18</b> and <b>20</b>, respectively. Incoming bus information that interfaces <b>14</b> and <b>16</b> select for submission to the buses are taken from registers <b>22</b> and <b>24</b>, respectively. In one embodiment, registers <b>18</b>-<b>24</b> are each 16.times.38 FIFO registers, although different <img file="US20030172218A1-20030911-P00001.TIF" id="EMI-00001" img-format="tif" img-content="ui" /><img file="US20030172218A1-20030911-P00002.TIF" id="EMI-00002" img-format="tif" img-content="ui" /><img file="US20030172218A1-20030911-P00003.TIF" id="EMI-00003" img-format="tif" img-content="ui" /><img file="US20030172218A1-20030911-P00004.TIF" id="EMI-00004" img-format="tif" img-content="ui" />

[0078] types of registers having different dimensions may be used in alternate embodiments.

[0079] In this embodiment, registers <b>18</b>-<b>24</b> are at least 38 bits wide. Thirty six of those bits are reserved for the 4 control bits (C/BE#[3:0]) and the 32 address/data bits (AD[31:0]) used under the PCI bus standard. The remaining two bits can be used to send additional tags for identifying the nature of the transaction associated therewith. Other bits may be needed to fully characterize every contemplated transaction. Transactions can be tagged as: addressing cycle; acknowledgment of a non-posted write; data burst; end of data burst (or single cycle). Thus outgoing write transactions can be tagged as a single cycle transaction or as part of a burst. Outgoing read requests can also be tagged as part of a burst with a sequence of byte enable codes (C/BE) for each successive read cycle of the burst. It will be appreciated that other coding schemes using a different number of bits can be used in other embodiments.

[0080] The balance of the structure illustrated in FIG. 1 is a link designed to establish duplex communications between interfaces <b>14</b> and <b>16</b> through registers <b>18</b>-<b>24</b>. For example, encoder <b>28</b> can accept the oldest 38 bits from register <b>20</b> and parse it into five bytes (40 bits). The extra two bits of the last byte are encoded to signify the interrupts, status signals and error signals that may be supplied from block <b>34</b>.

[0081] Each of these five bytes is converted into a 10 bit frame that can carry the information of each byte, as well as information useful for regulating the link. For example, these frames can carry comma markers, idle markers, or flow control signals, in a well-known fashion. A transceiver system working with bytes that were encoded into such 10 bit frames is sold commercially by Hewlett Packard as model number HDMP-1636 or -1646. Frames produced by encoder <b>28</b> are forwarded through transmitter <b>44</b> along simplex link <b>46</b> to receiver <b>48</b>, which supplies the serial information to decoder <b>30</b>. Likewise, encoder <b>26</b> forwards serial information through transmitter <b>38</b> along simplex link <b>40</b> to receiver <b>42</b>, which supplies the serial information to decoder <b>32</b>.

[0082] Flow control may be necessary should FIFO registers <b>22</b> or <b>24</b> be in danger of overflowing. For example, if FIFO register <b>22</b> is almost full, it supplies a threshold detect signal <b>36</b> to encoder <b>26</b>, which forwards this information through link <b>40</b> to decoder <b>32</b>. In response, decoder <b>32</b> issues a threshold stop signal <b>50</b> to encoder <b>28</b>, which then stops forwarding serial information, thereby preventing an overflow in FIFO register <b>22</b>. In a similar fashion, a potential overflow in FIFO register <b>24</b> causes a threshold detect signal <b>52</b> to flow through encoder <b>28</b> and link <b>46</b> to cause decoder <b>30</b> to issue a threshold stop signal <b>54</b>, to stop encoder <b>26</b> from sending more frames of information. In some embodiments, the system will examine the received information to determine if it contains transmission errors or has been corrupted in some fashion. In such event the system can request a retransmission of the corrupted information and thereby ensure a highly reliable link.

[0083] In this embodiment, elements <b>14</b>, <b>18</b>, <b>22</b>, <b>26</b>, <b>30</b>, <b>38</b> and <b>48</b> are part of a single, application specific integrated circuit (ASIC) <b>56</b>. Elements <b>16</b>, <b>20</b>, <b>24</b>, <b>28</b>, <b>32</b>, <b>42</b> and <b>44</b> are also part of an ASIC <b>58</b>. As described further hereinafter, first ASIC <b>56</b> and second ASIC <b>58</b> have an identical structure but can be operated in different modes. It will be appreciated that other embodiments may not use ASIC's but may use instead alternate circuitry, such as a programable logic device, or the like. As shown herein, ASIC <b>56</b> is operating in a mode designed to service primary bus <b>10</b>, and (for reasons to be described presently) will be sending outputs to block <b>57</b>. In contrast block <b>34</b> of ASIC <b>58</b> will receive inputs from block <b>34</b>.

[0084] Encoders <b>26</b> and <b>28</b> have optional parallel outputs <b>27</b> and <b>29</b>, respectively, for applications requiring such information. Also for such applications, decoders <b>30</b> and <b>32</b> have parallel inputs <b>31</b> and <b>33</b>, respectively. These optional inputs and outputs may be connected to an external transceiver chip, such as the previously mentioned device offered by Hewlett Packard as model number HDMP-1636 or -1646. These devices will still allow the system to transmit serial information, but by means of an external transceiver chip. This allows the user of the ASIC's <b>56</b> and <b>58</b> more control over the methods of transmission over the link.

[0085] Referring to FIG. 2, previously mentioned ASIC's <b>56</b> and <b>58</b> are shown in further detail. The previously mentioned encoders, decoders, transmitters, receivers, and FIFO registers are combined into blocks <b>60</b> and <b>62</b>, which are interconnected by a duplex cable formed of previously mentioned simplex links <b>40</b> and <b>46</b>. Previously mentioned interface <b>14</b> is shown connected to primary bus <b>10</b>, which is also connected to a number of bus-compatible devices <b>64</b>. Similarly, previously mentioned interface <b>16</b> is shown connected to secondary bus <b>12</b>, which is also connected to a number of bus-compatible devices <b>66</b>. Devices <b>64</b> and <b>66</b> may be PCI-compliant devices and may operate as memory devices or input/output devices.

[0086] Interface <b>14</b> a shown connected to a first register means <b>68</b>, which acts as a configuration register in compliance with the PCI standard. Since this system will act as a bridge, configuration registers <b>68</b> will have the information normally associated with a bridge. Also, configuration registers <b>68</b> will contain a base register and limit register to indicate a range or predetermined schedule of addresses for devices that can be found on the secondary bus <b>12</b>. Under the PCI standard, devices on a PCI bus will themselves each have a base register, which allows mapping of the memory space and/or I/O space. Consequently, the base and limit registers in configuration registers <b>68</b> can accommodate the mapping that is being performed by individual PCI devices. The information on configuration registers <b>68</b> are mirrored on second configuration register <b>67</b> (also referred to as a second configuration means). This makes the configuration information readily available to the interfaces on both sides of the link.

[0087] In this embodiment, ASIC <b>58</b> has an arbiter <b>70</b>. Arbiters are known devices that accept requests from masters on secondary bus <b>12</b> for control of the bus. The arbiter has a fair algorithm that grants the request of one of the contending masters by issuing it a grant signal. In this hierarchical scheme, secondary bus <b>12</b> requires bus arbitration, but primary bus <b>10</b> will provide its own arbitration. Accordingly, ASIC <b>56</b> is placed in a mode where arbiter <b>72</b> is disabled. The modes of ASIC's <b>56</b> and <b>58</b> are set by control signals applied to control pins <b>74</b> and <b>76</b>, respectively. Because of this mode selection, the signal directions associated with blocks <b>57</b> and <b>34</b> will be reversed.

[0088] In this embodiment, ASIC <b>58</b> is in a mode that implements a third bus <b>78</b>. Bus <b>78</b> may follow the PCI standard, but is more conveniently implemented in a different standard. Bus <b>78</b> connects to a number of devices that act as a port means. For example, devices <b>80</b> and <b>82</b> can implement PS/2 ports that can connect to either a mouse or a keyboard. Device <b>84</b> implements an ECP/EPP parallel port for driving a printer or other device. Device <b>86</b> implements a conventional serial port. Devices <b>80</b>, <b>82</b>, <b>84</b> and <b>86</b> are shown with input/output lines <b>81</b>, <b>83</b>, <b>85</b> and <b>87</b>, respectively. Devices <b>80</b>-<b>86</b> maybe addressed on bus <b>10</b> as if they were PCI devices on bus <b>12</b>. Also in this embodiment, a bus <b>88</b> is shown in ASIC <b>56</b>, with the same devices as shown on bus <b>78</b> to enable an OEM to implement these ports without the need for separate input/output circuits.

[0089] Referring to FIG. 3, previously mentioned ASIC <b>58</b> is shown in a docking station <b>130</b> connected to an oscillator <b>91</b> for establishing a remote and internal clock. ASIC <b>58</b> has its lines <b>81</b> and <b>83</b> connected through a connection assembly <b>90</b> for connection to a keyboard and mouse, respectively. Serial lines <b>85</b> and parallel lines <b>87</b> are shown connected to transceivers <b>92</b> and <b>94</b>, respectively, which then also connect to connection assembly <b>90</b> for connection to various parallel and serial peripherals, such as printers and modems.

[0090] ASIC <b>58</b> is also shown connected to previously mentioned secondary bus <b>12</b>. Bus <b>12</b> is shown connected to an adapter card <b>96</b> to allow the PCI bus <b>12</b> to communicate with an IDE device such as a hard drive, backup tape drive, CD-ROM drive, etc. Another adapter card <b>98</b> is shown for allowing communications from bus <b>12</b> to a universal serial port (USB). A network interface card <b>100</b> will allow communications through bus <b>12</b> to various networks operating under the Ethernet standard, Token Ring standard, etc. Video adapter card <b>102</b> (also referred to as a video means) allows the user to operate another monitor. Add-on card <b>104</b> may be one of a variety of cards selected by the user to perform a useful function. While this embodiment shows various functions being implemented by add-on cards, other embodiments may implement one or more of these function on a common circuit board in the dock (e.g., all functions excluding perhaps the IDE adapter card).

[0091] ASIC <b>58</b> communicates through receiver/transmitter <b>106</b>, which provides a physical interface through a terminal connector <b>108</b> to cable <b>40</b>, <b>46</b>. Connector <b>108</b> may be a <b>20</b> pin connector capable of carrying high speed signals with EMI shielding (for example a low force helix connector of the type offered by Molex Incorporated), although other connector types may be used instead. The opposite end of cable <b>40</b>, <b>46</b> connects through a gigabit, terminal connector <b>110</b> to physical interface <b>112</b>, which acts as a receiver/transmitter. Interface <b>112</b> is shown connected to previously mentioned first ASIC <b>56</b>, which is also shown connected to an oscillator <b>114</b> to establish a local clock signal. This specific design contemplates using an external transmitter/receiver (external SERDES of lines <b>27</b>,<b>29</b>, <b>31</b>, and <b>33</b> of FIG. 1), although other embodiments can eliminate these external devices in favor of the internal devices in ASIC's <b>56</b> and <b>58</b>.

[0092] This embodiment is adapted to cooperate with a portable computer having a PCMCIA 32-bit bus <b>10</b>, although other types of computers can be serviced. Accordingly, ASIC <b>56</b> is shown in a package <b>116</b> having an outline complying with the PCMCIA standard and allowing package <b>116</b> to fit into a slot in a portable computer. Therefore, ASIC <b>56</b> has a connector <b>118</b> for connection to bus <b>10</b>. Cable <b>40</b>, <b>46</b> will typically be permanently connected to package <b>116</b>, but a detachable connector may be used in other embodiments, where a user wishes to leave package <b>116</b> inside the portable computer.

[0093] Power supply <b>120</b> is shown producing a variety of supply voltages used to power various components. In some embodiments, one of these supply lines can be connected directly to the portable computer to charge its battery.

[0094] Referring to FIG. 4, the previously mentioned simplex links <b>40</b> and <b>46</b> are shown as twin axial lines <b>40</b>A and <b>46</b>A, wrapped with individual shields <b>40</b>B and <b>46</b>B. A single shield <b>122</b> encircles the lines <b>40</b> and <b>46</b>. Four parallel wires <b>124</b> are shown (although a greater number may be used in other embodiments) mounted around the periphery of shields <b>122</b> for various purposes. These wires <b>124</b> may carry power management signals, dock control signals or other signals that may be useful in an interface between a docking station and a portable computer. While twin axial lines offer high performance, twisted pairs or other transmission media may be used in other embodiments where the transmission distance is not as great and where the bit transfer speed need not be as high. While a hard wire connection is illustrated, in other embodiments a wireless or other type of connection can be employed instead.

[0095] Referring to FIG. 5, previously mentioned package <b>116</b> is shown in position to be connected to a PCMCIA slot in portable computer <b>126</b>. Computer <b>126</b> is shown having primary bus <b>10</b> and a host processor <b>128</b>. Package <b>116</b> is shown connected through cable <b>40</b>, <b>46</b> to previously mentioned connector <b>108</b> on docking station <b>130</b>. Previously mentioned docking station <b>130</b> is shown connecting through PS/2 ports to keyboard <b>132</b> and mouse <b>134</b>. A printer <b>136</b> is shown connected to a parallel port in docking station <b>130</b>. Previously mentioned video means <b>102</b> is shown connected to a monitor <b>138</b>. Docking station <b>130</b> is also shown with an internal hard drive <b>140</b> connecting to the adapter card previously mentioned. A CD-ROM drive <b>142</b> is also shown mounted in docking station <b>130</b> and connects to the secondary bus through an appropriate adapter card (not shown). Previously mentioned add-on card <b>104</b> is shown with its own cable <b>144</b>.

[0096] Referring to FIG. 6, a modified portable computer <b>126</b>′ is again shown with a host processor <b>128</b> and primary bus <b>10</b>. In this embodiment however, portable computer <b>126</b>′ contains previously mentioned ASIC <b>56</b>. Thus there is no circuitry required (other than perhaps drivers) between ASIC <b>56</b> and cable <b>40</b>,<b>46</b>. In this case, the laptop end of cable <b>40</b>, <b>46</b> has a connector <b>143</b> similar to the one on the opposite end of the cable (connector <b>108</b> of FIG. 5). Connector <b>143</b> is designed to mate with connector <b>141</b> and support the high-speed link. As before, connectors <b>141</b> and <b>143</b> can also carry various power management signals, and other signals associated with a docking system.

[0097] An important advantage of this arrangement is the fact that ASIC <b>56</b> contains circuitry for providing ports, such as a serial port, a parallel port, PS/2 ports for a mouse and keyboard, and the like. Since portable computer <b>126</b>′ would ordinarily provide such ports, ASIC <b>56</b> simplifies the design of the portable computer. This advantage is in addition to the advantage of having a single ASIC design (that is, ASIC's <b>56</b> and <b>58</b> are structured identically), which single design is capable of operating at either the portable computer or the docking station, thereby simplifying the ASIC design and reducing stocking requirements, etc.

[0098] To facilitate an understanding of the principles associated with the foregoing apparatus, its operation will be briefly described. This operation will be described in connection with the docking system of FIGS. 3 and 5 (which generally relates to FIG. 2), although operation would be similar for other types of arrangements. For the docking system, a connection is established by plugging package <b>116</b> (FIG. 5) into portable computer <b>126</b>. This establishes a link between the primary bus <b>10</b> and ASIC <b>56</b> (FIG. 3).

[0099] At this time an initiator (the host processor or a master) having access to primary bus <b>10</b> may assert control of the bus. An initiator will normally send a request signal to an internal arbiter (not shown) that will eventually grant control to this initiator. In any event, the initiator asserting control over primary bus <b>10</b> will exchange the appropriate handshaking signals and drive an address onto the bus <b>10</b>. Control signals simultaneously applied to the signaling lines of bus <b>10</b> will indicate whether the transaction is a read, write, or other type of transaction.

[0100] Interface <b>14</b> (FIG. 2) will examine the pending address and determine whether it represents a transaction with devices on the other side of the bridge (that is, secondary bus <b>12</b>) or with the bridge itself. Configuration register <b>68</b> has already been loaded in the usual manner with information that indicates a range of addresses defining the jurisdiction of the interface <b>14</b>.

[0101] Assuming a write transaction is pending on bus <b>10</b>, interface <b>14</b> will transfer 32 address bits together with four control bits (PCI standard) to FIFO register <b>18</b> (FIG. 1). Encoder <b>26</b> will add at least two additional bits tagging this information as an addressing cycle. The information is then broken into frames that can carry flow control and other signals before being transmitted serially over link <b>40</b>.

[0102] Without waiting, interface <b>14</b> will proceed to a data cycle and accept up to 32 bits of data from bus <b>10</b> together with four byte enable bits. As before, this information will be tagged, supplemented with additional information and broken into frames for serial transmission over link <b>40</b>. This transmitted information will be tagged to indicate whether it is part of a burst or a single cycle.

[0103] Upon receipt, decoder <b>32</b> restores the frames into the original 38 bit format and loads the last two described cycles onto the stack of register <b>24</b>. Interface <b>16</b> eventually notices the first cycle as an addressing cycle in a write request. Interface <b>16</b> then negotiates control over bus <b>12</b> in the usual fashion and applies the address to bus <b>12</b>. A device on bus <b>12</b> will respond to the write request by performing the usual handshaking.

[0104] Next, interface <b>16</b> will drive the write data stacked on register <b>24</b> into bus <b>12</b>. If this transaction is a burst, interface <b>16</b> will continue to drive data onto bus <b>12</b> by fetching it from register <b>24</b>. If however this transaction is a single cycle write, interface <b>16</b> will close the transaction on bus <b>12</b> and load an acknowledgment into register <b>20</b>. Since this acknowledgment need not carry data or address information, a unique code may be placed into register <b>20</b>, so that encoder <b>28</b> can appropriately tag this line before parsing it into frames for transmission over link <b>46</b>. Upon receipt, decoder <b>30</b> will produce a unique code that is loaded into register <b>22</b> and eventually forwarded to interface <b>14</b>, which sends an acknowledgment to the device on bus <b>10</b> that the write has succeeded.

[0105] If the initiator instead sets its control bits during the address cycle to indicate a read request, interface <b>14</b> would also accept this cycle, if it has jurisdiction. Interface <b>14</b> will also signal the initiator on bus <b>10</b> that it is not ready to return data (e.g., a retry signal, which may be the stop signal as defined under the PCI standard). The initiator can still start (but not finish) a data cycle by driving its signaling lines on bus <b>10</b> with byte enable information. Using the same technique, the address information, followed by the byte enable information, will be accepted by interface <b>14</b> and loaded with tags into register <b>18</b>. These two lines of information will be then encoded and transmitted serially over link <b>40</b>. Upon receipt, this information will be loaded into the stack of register <b>24</b>. Eventually, interface <b>16</b> will notice the first item as a read request and drive this address information onto secondary bus <b>12</b>. A device on bus <b>12</b> will respond and perform the appropriate handshaking. Interface <b>16</b> will then forward the next item of information from register <b>24</b> containing the byte enables, onto bus <b>12</b> so the target device can respond with the requested data. This responsive data is loaded by interface <b>16</b> into register <b>20</b>. If pre-fetching is indicated, interface <b>16</b> will initiate a number of successive read cycles to accumulate data in register <b>20</b> from sequential addresses that may or may not be requested by the initiator.

[0106] As before, this data is tagged, broken into frames and sent serially over link <b>46</b> to be decoded and loaded into register <b>22</b>. The transmitted data can include pre-fetched data that will be accumulated in register <b>22</b>. Interface <b>14</b> transfers the first item of returning data onto primary bus <b>10</b>, and allows the initiator to proceed to another read cycle if desired. If another read cycle is conducted as part of a burst transaction, the requested data will already be present in register <b>22</b> for immediate delivery by interface <b>14</b> to bus <b>10</b>. If these pre-fetched data are not requested for the next cycle, then they are discarded.

[0107] Eventually the initiator will relinquish control of bus <b>10</b>. Next, an initiator on bus <b>12</b> may send a request for control of bus <b>12</b> to arbiter <b>70</b> (FIG. 2). If arbiter <b>70</b> grants control, the initiator may make a read or write request by driving an address onto bus <b>12</b>. Interface <b>16</b> will respond if this address does not fall within the jurisdictional range of addresses specified in configuration register <b>67</b> (indicating the higher level bus <b>10</b> may have jurisdiction). In the same manner as before, but with a reversed flow over links <b>40</b>, <b>46</b>, interface <b>16</b> may accept address and data cycles and communicate them across link <b>40</b>, <b>46</b>. Before being granted bus <b>10</b>, interface <b>14</b> will send a request to an arbiter (not shown) associated with bus <b>10</b>.

[0108] In some instances, an initiator on primary bus <b>10</b> will wish to read from, or write to, port means <b>80</b>, <b>82</b>, <b>84</b>, or <b>86</b>. These four items are arranged to act as devices under the PCI standard. Interface <b>16</b> will therefore act as before, except that information will be routed not through bus <b>12</b>, but through bus <b>78</b>.

[0109] Other types of transactions may be performed, including reads and writes to the configuration registers <b>67</b> and <b>68</b> (FIG. 2). Other types of transactions, as defined under the PCI standard (or other bus standards) may be performed as well.

[0110] Interrupt signals may be generated by the ports or other devices in ASIC <b>58</b>. Also external interrupts may be received as indicated by block <b>34</b>. As noted before, interrupt signals may be embedded in the code sent over link <b>46</b>. Upon receipt, system <b>60</b> decodes the interrupts and forwards them on to block <b>57</b>, which may be simply one or more pins from ASIC <b>56</b> (implementing, for example, INTA of the PCI standard). This interrupt signal can either be sent over the bus <b>10</b> or to an interrupt controller that forwards interrupts to the host processor. System errors may be forwarded in a similar fashion to produce an output on a pin of ASIC <b>56</b> that can be routed directly to bus <b>10</b> or processed using dedicated hardware. The designer may wish to send individual status signals, which can be handled in a similar fashion along link <b>40</b>, <b>46</b>.

[0111] The use of the docking methods taught in the '752 patent can be applied to the teachings of the present invention to achieve inventive results.

[0112] U.S. Pat. No. 6,256,691 to Moroz, et al., entitled <i>Universal Docking Station, </i>which was filed on Jan. 11, 2000 and which issued on Jul. 3, 2001, and which is incorporated herein by reference, discloses additional methods of transferring data between a mobile computer and a regular, prior-art (sometimes called a “dumb”) docking station (the '691 patent). Relevant sections of the '691 patent are here presented, with figures provided for the '691 patent designated below by “('691 prior art)”:

[0113] The universal docking station or expansion base of the present invention allows a portable computer user to interface a portable computer to several different peripheral devices, such as CD-ROMs, Hard Disk Drives, Floppy Disk Drives, Tape Backups, standard size keyboards and mice, standard size VGA/super VGA monitors, networks, and other peripherals that typically utilize serial and/or parallel ports.

[0114] Rather than using proprietary connectors to connect the computer to the docking station, the present invention accomplishes this task using a standard universal interface. One such interface is the Personal Computer Memory Card International Association (“PCMCIA”) slot, port or socket provided on most portable computers. To interface with the PCMCIA slot, the docking station uses a PCMCIA card (“PC Card”) as the connection between the portable computer and the docking station. With this arrangement, portable computer users can connect their portable computers to multiple peripherals with one PCMCIA card. Because PCMCIA ports on portable computers are almost identical physically and electrically from computer to computer, the present docking station will work with almost any portable computer having such a port. With this arrangement, the docking station of the present invention can be positioned not only at a user's office and home, but at airports, libraries, business associates' offices, and virtually anywhere else computers are used. Portable computer users would no longer be limited by the make and model of computer they carry. <img file="US20030172218A1-20030911-P00005.TIF" id="EMI-00005" img-format="tif" img-content="ui" /><img file="US20030172218A1-20030911-P00006.TIF" id="EMI-00006" img-format="tif" img-content="ui" /><img file="US20030172218A1-20030911-P00007.TIF" id="EMI-00007" img-format="tif" img-content="ui" /><img file="US20030172218A1-20030911-P00008.TIF" id="EMI-00008" img-format="tif" img-content="ui" /><img file="US20030172218A1-20030911-P00009.TIF" id="EMI-00009" img-format="tif" img-content="ui" /><img file="US20030172218A1-20030911-P00010.TIF" id="EMI-00010" img-format="tif" img-content="ui" />

[0115] Background on 16-Bit PCMCIA cards can be found in Mindshare, Inc. &amp; Don Anderson, PCMCIA System Architecture 16 Bit PC Cards, Second Edition (Addison-Wesley Publishing Company 1995), which is hereby incorporated by reference. Background on 32-bit PCMCIA standard known as “card bus” can be found in Mind Share, Inc., Card Bus System Architecture (Addison-Wesley Publishing Company 1995), which is hereby incorporated by reference.

[0116] Referring to the drawings, particularly FIG. 1, a portable computer <b>101</b> having a PCMCIA port <b>102</b> is connected to a PCMCIA card <b>105</b> which interfaces to a docking station <b>103</b>. The PCMCIA card <b>105</b> completes the interface between the portable computer <b>101</b> and the docking station <b>103</b>. Several peripheral devices <b>106</b> are coupled to the docking station <b>103</b>. Possible peripheral devices include: keyboard <b>107</b>, joy stick <b>109</b>, mouse <b>111</b>, modem <b>113</b>, network interface <b>115</b>, hard disk <b>117</b>, floppy disk <b>119</b>, CD ROM <b>121</b>, tape backup <b>123</b>, printer <b>125</b>, and monitor <b>127</b>.

[0117] In one embodiment, the docking station <b>103</b> contains two standard expansion slots <b>129</b> and <b>131</b> configured and arranged to receive any combination of two of the following standard internal peripheral devices: hard disk <b>117</b>, floppy drive <b>119</b>, CD ROM <b>121</b> and tape backup <b>123</b>. Other embodiments of the present invention may provide for additional expansion slots for receiving additional internal peripheral devices.

[0118] As indicated above, the portable computer <b>101</b> contains at least one PCMCIA slot. The portable computer <b>101</b> also includes a central processing unit (CPU) coupled to a Read Only Memory (ROM) and Random Access Memory (RAM). The computer communicates with the PCMCIA slot and other internal and external components through an internal or input/output (I/O) bus. A controller or Host Bus Adaptor (HBA) links signals coming from the PCMCIA slot (or from a PCMCIA card installed in the slot) to the I/O bus of the portable computer. The computer may also include one or more data storage devices, such as a hard disk drive, a floppy disk drive, and CD-ROM drive. In one embodiment, software used in connection with the present invention may be stored and distributed on a CD-ROM, which may be inserted into and read by the CD-ROM drive. The computer is also coupled to a display, and a user input device such as a mouse or keyboard.

[0119] A memory window can be created in the portable computer's address space into which memory and configuration registers of the PCMCIA card can be individually mapped. This memory window can be set up by a device driver of the PCMCIA card, and typically remains the same size and keeps the same memory location on the portable computer.

[0120] Referring to FIG. 2, the docking station <b>103</b> interfaces to the computer <b>101</b> via a PCMCIA bus <b>201</b> on the computer <b>101</b>. The computer <b>101</b> includes a PCMCIA slot or socket connected to the PCMCIA bus <b>201</b>, into which a PCMCIA card can be inserted to connect the PCMCIA <b>20</b> card to the PCMCIA bus <b>201</b>. As used herein, a PCMCIA card refers, generically, to a standardized interface between a peripheral device and an internal bus of a computer. Typically, the PCMCIA card will be of a standard length and width, and will have a thickness determined by the card type (e.g., Type I=3.3 mm thick; Type II=5.0 mm thick; Type III=10.5 mm thick). The PCMCIA card is configured to fit into a PCMCIA slot or socket. When inserted into the PCMCIA slot or socket, the PCMCIA card can be connected to a wide variety of host buses, typically via host bus adapters designed for a particular bus interface. The PCMCIA bus <b>201</b> is an expansion of the computer's internal bus, and allows devices connected to the PCMCIA port to be accessed by the computer as if they were inside the computer. The PCMCIA physical interface allows for devices to be inserted and removed at anytime from the computer.

[0121] The PCMCIA bus <b>201</b> operatively couples a PCMCIA control bus <b>239</b>, an address bus <b>241</b> and a data bus <b>243</b> to core logic <b>202</b> of the docking station <b>103</b> to the computer <b>101</b>. The core logic <b>202</b> includes address decode and control logic <b>203</b>, configuration registers <b>205</b>, and attribute memory <b>207</b>.

[0122] In one exemplary embodiment, the address decode and control logic <b>203</b> is implemented using field programmable gate arrays (FPGA). Alternatively, the address decode and control logic <b>203</b> could be implemented using a program array logic (PAL) or other similar programmable devices or custom integrated circuits (IC) so long as the particular implementation can handle the timing requirements of the PCMCIA bus <b>201</b> as well as all of the peripheral devices <b>106</b> connected to the docking station <b>103</b>.

[0123] In the exemplary embodiment, the configuration registers <b>205</b> contain five registers. The first configuration register is a standard PCMCIA register needed for all PCMCIA devices, commonly referred to as the configuration option register. This register contains 8 bits to enable the PCMCIA card to behave as an I/O card and also has a bit that resets the card to a known state. The second configuration register is a 16 bit register that contains the I/O address for the configuration registers of the different peripheral devices attached to the docking station <b>103</b>. The third register is an interrupt flag which is an 8 bit register that contains a bit for each device to interrupt the computer for services. The fourth register is a 16 bit register that is loaded with the address for the IOIS 16 signal used by the IDE interface. The IOIS 16 is a signal used to inform the computer that a device desires to carry out a 16 bit transfer as opposed to an 8 bit transfer to the computer. The last register is a keyboard configuration register which is a 16 bit register that is loaded with the I/O address that the keyboard controller needs to be mapped to in the system.

[0124] In the above described exemplary embodiment, the configuration registers <b>205</b> are implemented using a field programmable gate array (FPGA). The configuration registers <b>205</b> could also be implemented using random access memory (RAM) or a programmable array logic (PAL) device. Different size registers may also be sued as dictated by the actual implementation.

[0125] The attribute memory <b>207</b> is implemented in the exemplary embodiment with an electronically erasable programmable read only memory (EEPROM) or other suitable standard nonvolatile memory. In one embodiment, only about 1024 bytes of memory are required to store all the values needed for the docking station <b>103</b>.

[0126] Peripheral devices <b>106</b> can be connected to the docking station <b>103</b> through appropriate connectors (<b>223</b>-<b>237</b>). Once connected, the peripheral devices <b>106</b> interface through the address decode and control logic <b>203</b>.

[0127] A parallel connector is connected through connection <b>249</b> to a parallel controller <b>209</b>. The parallel controller <b>209</b> is connected to the address decode and control logic <b>203</b> via control bus <b>245</b> and address bus <b>247</b>. Parallel controller <b>209</b> is also connected to configuration registers <b>205</b> with control bus <b>245</b> and address bus <b>247</b>. A data bus <b>243</b> is linked to, and can provide data to, the configuration registers <b>205</b>, the attribute memory <b>207</b>, and the parallel controller <b>209</b>. The parallel controller <b>209</b> may be implemented, for example, using a standard 8255 compatible parallel controller used on IBM XT/AT compatible computers. This supports the optional PS/2 bidirectional parallel port (SPP), the Enhanced Parallel Port (EPP) and the Extended Capabilities Port (ECP) modes. This interface is useful for connecting printers, removable media high density storage devices and scanners to the docking station <b>103</b>. A Standard Microsystems Corporation (SMC) FDC37C93X Plug and Play Compatible Ultra I/O Controller includes a parallel port and can be used for this purpose.

[0128] A serial connector <b>225</b> is connected via connection <b>251</b> to a serial controller <b>211</b>. The serial controller <b>211</b> is connected to the address decode and control logic <b>203</b>, configuration registers <b>205</b> by way of control bus <b>245</b>, address bus <b>247</b> and data bus <b>243</b>, as indicated in FIG. 2. The serial controller <b>211</b> may be a NS16C550 compatible serial controller or other serial controller that can handle high speed communication (i.e., communication above 460K Baud), and has a built in FIFO for handling data received by the serial port at a rate faster than can be sent through the interface to the computer. The serial controller may be a standard 16C550 compatible Universal Asynchronous Receiver/Transmitter (UART), for example, with a 16 byte FIFO. The UART performs the serial-to-parallel conversion for receiving characters and the parallel-to-serial conversion for transmitting characters. This UART allows for data rates from 50 to 460.8K baud. The character options are programmable for 1 start; 1, 1.5 or 2 stop bits; even, odd, sticky or no parity; and prioritized interrupts. The UART contains a programmable baud rate generator that is capable of dividing the input clock or crystal by a number from 1 to 65535. The UART is also capable of supporting Musical Instrument Digital Interface (MIDI) data rate. An SMC FDC37C93X Plug and Play Compatible Ultra I/O Controller can be used for this purpose. Other serial controllers may also be used so long as they support a communications speed of 460K baud and contain a FIFO for handling data overflow.

[0129] An Integrated Drive Electronic (IDE) connector <b>227</b> is connected via connection <b>253</b> to IDE interface logic <b>213</b>. The IDE enables hard disk drives with embedded controllers to be interfaced to the host processor. The IDE interface performs the address decoding for the IDE device. This interface also supports devices such as CD-ROM drives and newer high density removable storage devices. The IDE <b>213</b> includes an address decoder for the specific drive or mass storage device to be <b>20</b> interfaced to, and interrupt circuitry to allow the device to request service from the computer. The interrupt source goes back through the control bus <b>245</b> through the address decode and control logic <b>203</b> back into the PCMCIA bus <b>201</b>. In an exemplary embodiment, the SMC FDC37C93X Plug and Play Compatible Ultra I/O Controller provides the IDE interface.

[0130] A keyboard connector <b>229</b> is connected via connection <b>255</b> to a keyboard and mouse controller <b>215</b>. A mouse connector <b>231</b> is also connected via connection <b>257</b> to the keyboard and mouse controller <b>215</b>. The keyboard and mouse controller <b>215</b> interfaces through the control bus <b>245</b>, address bus <b>247</b> and data bus <b>243</b>. The keyboard and mouse controller <b>215</b> should contain means for communicating to a keyboard and a mouse and means for interfacing with a computer. The keyboard and mouse controller <b>215</b> may be implemented using a universal keyboard control with a standard Intel 8042 micro controller CPU core. The SMC FDC37C93X Plug and Play Compatible Ultra I/O Controller, for example, provides the keyboard and mouse controller <b>215</b>. Other standard keyboard and mouse controllers may also be used.

[0131] A floppy disk connector <b>233</b> is connected to the floppy disk controller (FDC) <b>217</b> via connection <b>259</b>. The FDC <b>217</b> is connected to the control bus <b>245</b>, address bus <b>247</b> and data bus <b>243</b>. An IBM compatible FDC can be used, and preferably one with a CMOS <b>755</b> floppy disk controller that supports a 2.88 megabyte super floppy drive. This FDC <b>217</b> can handle up to two floppy disk drives or tape backups. The FDC integrates the functions of the Formatter/Controller, Digital Separator. Write Precompensation and Data Rate Selection logic for IBM XT/AT compatible FDC are also provided. The true CMOS 765B core guarantees 100% IBM PC XT/AT computability in addition to providing data overflow and underflow protection. In an exemplary embodiment, the SMC FDC37C93X Plug and Play Compatible Ultra I/O Controller provides the FDC.

[0132] A VGA connector <b>235</b> is connected to a VGA controller <b>219</b> via connection <b>261</b>. The VGA connector <b>235</b> interfaces through the control bus <b>245</b>, address bus <b>247</b> and data bus <b>243</b>. The VGA controller <b>261</b> can have some VGA memory integrated into it, support up to 1024 by 756 pixels, and be compatible with a super VGA monitor.

[0133] A network connector <b>237</b> is connected to a network controller <b>221</b> through connection <b>263</b>. The network controller <b>221</b> interfaces through the control bus <b>245</b>, address bus <b>247</b> and data bus <b>243</b>. Between a 10 megabyte and a 100 megabyte controller can be supported. In the exemplary embodiment, the network controller <b>221</b> is an Ethernet controller.

[0134] As indicated, the keyboard and mouse controller <b>215</b>, FDC <b>217</b>, parallel controller <b>209</b>, serial controller <b>211</b>, and IDE interface <b>213</b> can be implemented using a Standard Microsystems Corporation (SMC) FDC37C93X Plug and Play Compatible Ultra I/O Controller. This device incorporates a keyboard interface, SMC's true CMOS 765B floppy disk controller, advance digital separator, 16 byte data FIFO, 16C550 compatible UARTs, a Multi-Mode parallel port and an IDE interface. The FDC37C93X also provides support for the ISAPlug-andPlay Standard (Version 1.0a) and provides for the recommended functionality to support Windows '95.

[0135] Most PCMCIA socket controllers designed into most computers have a limited I/O window size. Typically, only two I/O windows are permitted. This will allow for one or two functions to have I/O ports. With more than two functions on the docking station it is necessary to combine all of the I/O ports into two contiguous pieces of I/O memory.

[0136] Almost all of the functions on the SMC chip can be relocated in I/O address space via configuration registers. The only function that is fixed is the keyboard and mouse controller. To accommodate this a Xilinx FPGA is built into the hardware of the docking station. The Xilinx device includes logic to match an address and output the appropriate address to the SMC chip.

[0137]FIG. 3 shows a flow chart depicting steps performed in inserting the docking station device driver <b>301</b> into the RAM of the portable computer <b>101</b>. Processing begins with decision step <b>303</b> which detects whether card services (a piece of software that is used to interface with the PCMCIA port at a high level) is installed on the computer; if not, an error is flagged at step <b>307</b>, processing stops, and the device driver is not installed into the operating system. If card services is installed, processing continues with step <b>311</b> wherein the device driver registers with card services and sets up a call back handler, thereby allowing card services to inform the docking station device driver of events that happen in the PCMCIA port such as a PCMCIA card being inserted or removed. After the device driver is registered with card services, processing continues with step <b>313</b> which polls for interrupt vectors and loads the interrupt vectors into memory to allow the device driver to handle different functions of the docking station. Once in memory, the device driver stays in memory waiting for one of the callback events from card services to tell it that the docking station PCMCIA card has been inserted into the computer's PCMCIA port as shown in item <b>317</b>.

[0138] The PCMCIA standard specifies that all PCMCIA devices must behave as a memory device until configured by the host computer. After configuration, the PCMCIA device must convert some of the interface pins to the PCMCIA bus to support the I/O interface. This is accomplished in one embodiment of the universal docking station <b>103</b> by using a Xilinx FPGA to control the functions of the flexible interface pins. All PCMCIA devices must also have memory on board that identifies the device's functions and capabilities. This is accomplished in the exemplary embodiment of the present invention by using a 2K EEPROM that is accessible by the computer at any time. The EEPROM also allows for software to write new information to it when upgrades or modifications are necessary.

[0139]FIG. 4 depicts the steps performed during card configuration. Processing begins at step <b>401</b> when a PCMCIA card is inserted into the PCMCIA port on the computer, and card services informs the device driver through the callback handler that a card has been inserted. Next, in step <b>403</b>, the device driver asks card services for the manufacture ID of the card that was inserted. If the card inserted is the docking station PCMCIA card, the manufacturer ID is stored in attribute memory <b>207</b>. In decision step <b>405</b>, the manufacturer ID of the card inserted is compared to the ID designated for the docking station; if no match is found, the system ignores the card as shown in step <b>407</b> and continues waiting for another card to be installed. If the manufacturer ID is correct, processing continues with step <b>409</b> which gets the first configuration entry that is stored in the attribute memory on the card.

[0140] Next, the device driver tries to configure the I/O port and different interfaces needed for using the docking station card in the system given the particular configuration entry. The first step is the I/O port step <b>411</b> which is requested from card services and card services either allows the docking station card to have the I/O port or not. If not, the system will determine in decision step <b>413</b> whether the configuration allows other I/O ports to be used. If there are more I/O ports in this particular configuration, the system will return to step <b>411</b> to try requesting the next I/O port. This routine will continue until an I/O port is successfully requested or all I/O ports of this particular configuration entry are exhausted. If there are no more I/O ports in the particular configuration, decision step <b>423</b> determines whether there are other configurations available. If so, step <b>425</b> gets the next configuration entry and processing continues at step <b>411</b>. If no other configurations exist, an error is reported at step <b>433</b>.

[0141] If an I/O port is successfully requested in step <b>411</b>, the processing will continue with step <b>415</b> which requests an interrupt. A similar process will happen with respect to the interrupt as with the I/O port; if the system does not get an interrupt, decision step <b>417</b> checks the configuration to see if another interrupt is allowed. If there is a possibility of another interrupt, it will go back and try to request the next interrupt. This process will continue until it either runs out of possible interrupts to try or it successfully allocates an interrupt for use with the docking station card. If it runs out of interrupts to try, step <b>418</b> releases the I/O port previously requested in step <b>411</b>, and decision step <b>423</b> determines whether other configurations exist. If not, step <b>433</b> reports an error. If so, step <b>425</b> gets the next configuration entry and processing starts over at step <b>411</b>.

[0142] If an interrupt is successfully requested in step <b>415</b>, step <b>419</b> requests a direct memory address (DMA) channel. If the request fails, decision step <b>421</b> determines whether the configuration supports other DMA's. If so, step <b>419</b> will request that DMA, and this process will continue until it either runs out of possible DMAs or it successfully allocates a DMA channel. If decision step <b>421</b> determines that no more DMAs exist for the particular configuration, step <b>422</b> releases the I/O port and the interrupt, and moves to decision step <b>423</b> to determine if other configurations are available. If so, step <b>425</b> gets the next configuration and processing continues at step <b>411</b>. If not, step <b>433</b> reports an error.

[0143] If a DMA channel is successfully requested in step <b>419</b>, step <b>421</b> requests a memory block. If step <b>421</b> fails, step <b>428</b> releases the I/O port, the IRQ, and the DMA channel. Next, decision step <b>423</b> determines whether another configuration is available. If not, step <b>433</b> reports an error. If so, step <b>425</b> gets the next configuration entry and processing continues from step <b>411</b>.

[0144] Upon successfully requesting the I/O, the IRQ, DMA and memory, step <b>427</b> requests configuration for the docking station, step <b>429</b> configures the hardware on the docking station board, and step <b>431</b> indicates that card configuration is complete.

[0145]FIG. 5 shows a flowchart of the interrupt service routine. The interrupt service routine comprises a series of steps performed when one of the peripheral devices <b>106</b> connected to the docking station <b>103</b> requests service from the computer <b>101</b> by setting its interrupt flag in the interrupt flag register of the control logic <b>203</b>.

[0146] The PCMCIA specification and available controller hardware support only one interrupt per card. This presents a problem when more than one function on a card needs to interrupt the host computer for servicing. The PCMCIA 1995 specification solves this issue by having the card services (high level interface to PCMCIA devices for applications) handle the interrupts from a card. When a card is configured the card services starts with the first function and assigns it an interrupt if needed. Card services then stores the vector for this interrupt in a table and places its own interrupt vector in the appropriate memory location. When card services configures the next function on the card it stores that function's interrupt vector in the table next to the first function's interrupt vector. This continues until all functions are configured.

[0147] When an interrupt occurs, card services' interrupt handler is called from the vector in memory. Card services will then interrogate the PCMCIA cards interrupt status register to identify the source of the interrupt. Card services will then call the appropriate service routine for the function by calling the function pointed to by the vector in the stored table.

[0148] Step <b>503</b> reads an interrupt status register on the docking station <b>103</b>. In a preferred embodiment, the interrupt status register will be in the configuration register <b>205</b> shown in FIG. 2, and have one bit in it for each function of the docking station <b>103</b>. The interrupt service routine will then look at these bits and decide whether or not one of the devices is in need of service. If any of the devices connected to the expansion box set their interrupt flag in the interrupt flag register, the control logic <b>203</b> will then send the interrupt flag to the PCMCIA bus which will cause a hardware interface on the particular interrupt line that has been configured in accordance with FIG. 4.

[0149] After the interrupt service handler has read the interrupt status register, it decides which interrupts to handle in a prioritized fashion starting with the IDE interface in decision step <b>505</b>, and proceeding downward in priority as shown in FIG. 5, until it reaches the keyboard which is lowest in priority. If decision step <b>505</b> determines that the flag is set for the IDE, then step <b>523</b> branches to the IDE interrupt service routine. Upon completion of this interrupt service routine, step <b>521</b> cleans up any registers that may have information pushed on to their stacks and returns from the interrupt. If the flag is not set for the IDE, decision step <b>507</b> determines whether the interrupt flag is set for the VGA. If so, step <b>525</b> branches to the VGA interrupt service routine.

[0150] If decision step <b>509</b> determines that the flag is set for the floppy disk controller, step <b>527</b> branches to the floppy interrupt service routine. If decision step <b>511</b> determines that the flag is set for the serial port, step <b>529</b> branches to the serial interrupt service routine. If decision step <b>513</b> determines that the flag is set to the parallel port, step <b>531</b> branches to the parallel port interrupt service routine. If decision step <b>515</b> determines that the flag is set to a network, step <b>533</b> branches to the network interrupt service routine. If decision step <b>517</b> determines that the flag is set to the mouse, step <b>535</b> gets the mouse event from the keyboard controller and puts it in the mouse input buffer. If decision step <b>519</b> determines that the flag was set by the keyboard, step <b>537</b> gets the keystroke from the input buffer of the keyboard controller and puts it into the BIOS input buffer of the operating system on the computer.

[0151] Although priority may be altered from that shown in FIG. 5, the priority shown has certain advantages over other possible schemes because of the relative speed of each device and the capability of the devices to hold data before being manipulated. Those devices that have room to store data for longer periods of time (e.g., keyboard) will be lower in priority than other devices which will throw away this information in a short period of time if it does not get taken out of the buffer.

[0152] An example of the serial controller <b>211</b> taking control of the PCMCIA bus <b>201</b> follows. The serial controller <b>211</b> would be configured to receive information from the serial connector <b>225</b> and would then send this data through the connections of <b>251</b> into the serial controller <b>211</b>. The serial controller <b>211</b> would then request servicing to the computer <b>101</b> by setting the interrupt flag through the control bus <b>245</b> to the configuration registers <b>205</b>. The configuration registers <b>205</b> would then set the interrupt flag through the control bus <b>245</b> to the address, decode and control logic <b>203</b> and the decode and control logic would send the signal through <b>239</b> to the PCMCIA bus <b>201</b>.

[0153]FIG. 6 shows a timing diagram for <b>110</b> write timing and illustrates a solution to the type of problems encountered when interfacing standard peripheral devices <b>106</b> to the PCMCIA port. Because PCMCIA was originally designed for memory devices, the specifications for interfacing with I/O devices are more constrained than other specifications for interfacing with I/O devices. Nonetheless, in order to interface with I/O devices through the PCMCIA port, one must somehow meet these constraints. This problem has been addressed conventionally by designing the I/O device with the PCMCIA constraints in mind, and, therefore, by designing the constraints right into the device. In contrast, the present invention allows the use of standard off-the-shelf devices that would normally be connected to the ISA (Industry Standard Architecture) bus of a computer, and use them on the PCMCIA bus. In other words, the PCMCIA interface is used in the present invention in a manner not contemplated by its design, and yet is also being used to interface off-the-shelf peripherals. The present invention addresses these competing interests.

[0154] Most IDE devices are designed to conform to the ANSI AT Attachment Interface for Disk Drives specification (ANSI X3.221-1994). This specification was designed to interface IDE devices directly to an Industry Standard Architecture (ISA) bus. This bus differs id some ways from the PCMCIA bus. In order to allow a standard IDE device to be connected to the docking station, the timing of some of the main control signals is modified since the timing constraints of a standard IDE device do not match that of the PC bus.

[0155] For example, the specification for PCMCIA does not require that the data bus be held active for any amount of time after a write signal goes high, but I/O devices need the data bus to be stable for a period of time after the I/O write signal goes inactive. The present invention overcomes this problem by extending the period of time the data bus is allowed to remain stable. In an exemplary embodiment, the period of time the data bus is allowed to remain stable is extended by activating early write signals.

[0156] To accomplish this task a Xilinx FPGA was designed into the hardware of the docking station. This device allows for a large amount of flexible glue logic to be utilized without taking up a large amount of printed circuit board real-estate and for a reasonable cost.

[0157] By way of example, if the computer <b>101</b> writes a byte of information to a peripheral device <b>106</b>, e.g., the serial controller, the computer <b>101</b> first sets up the address bus signal <b>601</b>. When the address bus signal <b>601</b> settles out and is determined to be the correct address as in the address and decode logic <b>203</b> in FIG. 2, the computer <b>101</b> waits for a short period of time and then either activates the IOIS16 signal <b>611</b> (for a 16 bit transfer) or does not activate the IOIS16 line <b>611</b> (for an 8 bit transfer). The IOIS16 signal <b>611</b> is used to inform the host computer that the IDE device would like to transfer 16 bits of data instead of 8. This signal is output from an IDE device and is active within 90 ns from the activation of a valid address. The PCMCIA spec requires this signal to be active within 35 ns of a valid address.

[0158] To overcome this problem the Xilinx FPGA on the docking station main printed circuit board (PCB) has a logic circuit in it to match the valid address and assert the IOIS16 line within the PCMCIA timing constraint.

[0159] Then the computer <b>101</b> activates the register signal <b>603</b> in the PCMCIA port. At about the same time, the computer activates CE[1:0] <b>605</b>. CE[0] would be activated for an 8 bit transfer and both CE[1:0] would be activated for a 16 bit transfer. About a third period of time after that, the computer would activate the I/O write signal <b>607</b> letting the peripheral device that is addressed activate the address line <b>601</b>, telling the device to set up the address line <b>601</b> of the data bus for the value that is going to be written to it. The Din signal <b>615</b> represents the data being sent by the computer. It settles out after a period of time. The peripheral device also sets the wait signal <b>613</b> to tell the computer to extend this write period for a longer period of time than a standard write. The Wait signal is another signal that could not meet the time constraints of the PCMCIA interface. This signal is asserted by an I/O device to inform the host computer that it needs more time to accomplish a task. The timing specs for PCMCIA and IDE both require this signal to be active within 35 ns. However, because all of the other timing critical signals must run through the Xilinx and other hardware on the PCB, this timing was not possible to meet. Therefore the Xilinx FPGA was used to activate an early wait signal. This signal delays the host computer by 100 to 500 ns to allow the other signals to settle.

[0160] At that point, the hardware on the docking station sets the early I/O write signal <b>609</b> so that the peripheral device, in this case the serial port, would see the actual write signal happen and on the other edge of that write signal (i.e., the rising edge) the device would then write the data on the data bus <b>615</b> into the particular register that is mapped out by the address bus <b>601</b>. This early I/O write signal is activated a period of time before the actual I/O write signal occurs to allow the device to have valid data on the data bus <b>615</b> for a longer period of time. The I/O write signal then goes inactive, the CE[1:0] signal <b>605</b> goes inactive, and the read signals go inactive. Finally, the end of the address signal <b>601</b> becomes unstable.

[0161]FIG. 7 shows a timing diagram showing the read timing used to interface with the PCMCIA port. The address bus <b>701</b> is the first signal to become stable and settle on the bus to indicate to the docking station <b>103</b> that one of the peripheral devices <b>106</b> on the docking station is to be addressed. The REG signal <b>703</b> then goes low and CE[1:0] (again, CE[0] would be activated for an 8 bit transfer and both CE[1:0] would be activated for a 16 bit transfer) becomes low. The control logic <b>203</b> in FIG. 2 activates the IOIS16 signal if a 16 bit transfer is desired for this particular read cycle. After the IOIS16, REG, and CE[1:0] signals have become low, the I/O read signal <b>707</b> would go low. This would indicate to the peripheral device (e.g., the serial port) that the computer wants to read information from it. The INPACK signal <b>709</b> would then go low to access a PCMCIA card register and notify the HBA that access belongs to the PCMCIA card. This allows the PCMCIA interface to drive the signal onto the internal bus of the computer. The docking station would then bring the wait signal <b>713</b> low to extend the time of the read cycle from the computer. This causes the computer to stretch out the read timing to allow the peripheral device to activate the data output <b>715</b> in a reasonable amount of time so that the computer can handle reading this information back and so that data would then become stable on the data bus. The read signal <b>707</b> would then be brought back high causing the computer to read in the information on the data bus. On completion of the actual read on the rising edge of the read signal <b>707</b>, the CEL[1:0] <b>705</b> and REG signals <b>703</b> would then be brought back high. The address signal <b>701</b> would then become unstable or start transitioning the next read value item <b>701</b> and a short time after that INPACK 709 and IOIS16 signal would be deactivated.

[0162] When the present invention is implemented without a VGA controller, a 16 bit PCMCIA port may be used. However, if a VGA controller is included in the docking station, a 32 bit PCMCIA port called “card bus” is preferable. This is because a 16 bit PCMCIA port runs at around 8 or 10 megahertz which is a fairly slow rate for updating video memory. A 32 bit PCMCIA port, however, runs at about 33 megahertz, which is similar to a PCI (Peripheral Component Interconnect) bus which is internal to computers. Interfacing the docking station to the card bus interface will provide for the wider bandwidth that is needed to handle video signals. The multiplexing and demultiplexing of the data and address lines must be properly adjusted to the PCMCIA standard chosen to ensure that the entire 16 (or 32) bit address and 16 (or 32) bit data are captured.

[0163] The use of the docking methods taught in the '691 patent can be applied to the teachings of the present invention to achieve inventive results. Furthermore, since the link between the PDA and the IDS may be a bus or a bridge, the invention may be modified to incorporate the advantages of the '691 patent or the '752 patent in ways unique from either of these patents, as well as different from other prior art, either alone or in combination.

[0164] For example, FIG. 6 illustrates one embodiment of an integrated intelligent docking station system <b>600</b> which incorporates at least one aspect of the referenced patents. With reference to FIG. 1 (which depicts an intelligent docking station system), one should notice that the integrated intelligent docking station system <b>600</b> (the integrated system <b>600</b>) provides the intelligent docking station <b>100</b> of FIG. 1, and uses a first portable computer based ASIC <b>610</b> and a second intelligent docking station based ASIC <b>620</b>, which function substantially as disclosed in the '752 patent. Other aspects of the referenced patents can be similarly applied to the present invention.

[0165] Though the invention has been described with respect to a specific preferred embodiment, many variations and modifications will become apparent to those skilled in the art upon reading the present application. It is therefore the intention that the appended claims be interpreted as broadly as possible in view of the prior art to include all such variations and modifications.