Patent Application
20050028172
The present invention relates to a method and apparatus for installing software in a host device, and more particularly, to a method and apparatus for uploading drivers and applications to a host device from a peripheral device which are interfaced with one another utilizing a Universal Serial Bus (USB).
The use of the Universal Serial Bus (USB) protocol for transferring data between a host device (i.e., master device) and a peripheral device (i.e., slave device) is well known. For example, the USB protocol is explained in detail in “Universal Serial Bus System Architecture”, Second Edition, Mindshare, Inc., which is hereby incorporated by reference.
Generally speaking, the peripheral device 20 includes a USB bus interface layer 22, a USB device layer 24 and a functional layer 26. The USB bus interface layer 22 functions to control the receipt and transmission of data between the host device and the peripheral device in accordance with the USB protocol. The USB device layer 24 functions to comprehend the USB communication requirements necessary to transfer data between the given peripheral device and the host device. The functional layer 26 represents the function to be performed by the given peripheral device.
Traditionally, the implementation of USB protocols have been very “PC centric”, in that a personal computer (PC) functioned as the host device when coupling numerous USB compatible devices to one another. As a result, when transferring data between, for example, a digital camera and a printer, it was required to couple both the digital camera and the printer to the host PC so as to allow the PC to function as the host device and manage the transfer of data between the two peripheral devices. In such a setup, the software drivers necessary for the PC to access and communicate with the various peripheral devices were stored in the memory of the PC, as typically, the PC would have an abundance of available memory.
In an effort to eliminate the need for the use of the PC, a new specification referred to as “USB-On-The-GO” has been developed. In accordance with the new USB specification, it is possible for two devices (e.g., the digital camera and the printer) to be coupled to one another directly, without the use of the PC.
While “USB-On-The-Go” specification has been successful in eliminating the need for the use of a PC to transfer data between peripherals, various shortcomings remain. For example, in accordance with the “USB-On-The-Go” specification it is still necessary for one of the peripheral devices to function as the master or host device and the other as the slave or peripheral device. As a result, it is necessary for the host device to contain the software drivers and applications necessary to access and communicate with the peripheral device coupled thereto. For example, utilizing the example noted above, if the digital camera is to act as the host device to a printer coupled thereto, the digital camera must contain the required software drivers and applications that allow the digital camera to communicate with the printer. Thus, it is required that the digital camera contain the drivers and applications of every printer that it is intended to communicate with at the time the device is manufactured (i.e., prior to the sale of the camera). However, as the memory space available for storing drivers and applications in devices such as a digital camera is significantly limited, as a practical matter the number of devices that a digital camera can be coupled to is undesirable quite minimal.
As a result, currently, product manufacturers must decide which devices a given product may be coupled to, and then provide the drivers and applications associated with those devices in the memory of the given product during the manufacturing process. The consumer of the given product is then informed what devices the product is compatible with at the time of purchase. If the consumer attempts to utilize the product with other devices, for which the product does not contain drivers, the consumer would be unable to do so. Furthermore, in many such products, such as the digital camera, there are no means for the consumer to download additional drivers into the products even if the consumer was inclined to do so.
Accordingly, there exists a need to solve the foregoing problem, and more specifically, to allow a device functioning in accordance with the USB-On-The-GO specification to obtain the software drivers and applications necessary to communicate with various devices subsequent to the manufacture and sale of the device so as to allow the consumer to utilize the device with essentially any other suitable peripheral device.
In an effort to solve the aforementioned needs, it is an object of the present invention to provide a method an apparatus for allowing a host device to obtain the necessary software drivers and applications from the peripheral device to which it is coupled, so as to eliminate the need for the host device to contain drivers and applications specific to a given peripheral device prior to the host device being coupled to the peripheral device.
More specifically, the present invention relates to a method of installing a software program in a host device, which is required for the host device to communicate with a peripheral device. The method includes the steps of coupling the host device to the peripheral device, which contains the software program stored in a memory device contained in the peripheral device, utilizing a USB serial interface; uploading the software program from the peripheral device to the host device; and installing the software program in the host device thereby allowing communication between the host device and the peripheral device.
The present invention also relates to a host device capable of communicating with any one of a plurality of peripheral devices utilizing a USB serial interface, where each of the plurality of peripheral devices has the software drivers necessary for communicating with the given peripheral device stored in a memory device contained in the given peripheral. The host device comprises a USB interface capable of defining/identifying the host device as a master device relative to the plurality of peripheral devices, a software driver uploader for uploading the software driver of a given one of the plurality of peripheral devices, which is currently coupled to the host device via the USB serial interface, and a software driver installer for installing the software driver uploaded from the given one of the plurality of peripheral devices so as to allow communication between the host device and the given one of said plurality of peripheral devices.
As described in further detail below, the present invention provides significant advantages over the prior art. Most importantly, the present invention effectively unconditionally expands the number of peripheral devices that a given host device can be connected to. In other words, manufacturers are no longer limited to specifying a set number of peripheral devices that a given host can be coupled to (which in the prior art is limited by the number of drivers that can be stored in the host device at the time of manufacture). In accordance with the present invention, if the host device does not contain the necessary driver and application to interact with a peripheral device, the driver and application are simply uploaded from the peripheral device.
Another advantage is that the present invention reduces the amount of memory required for the host device. More specifically, as the host device is no longer required to store all of the drivers and applications for which the manufacturer wishes the host to be compatible with, the memory requirements of the host device are significantly reduced.
Another advantage is that drivers and applications are easily upgradeable, for example, to add a new feature or correct a newly discovered bug or error.
Additional advantages of the present invention will become apparent to those skilled in the art from the following detailed description of exemplary embodiments of the present invention.
The invention itself, together with further objects and advantages, can be better understood by reference to the following detailed description and the accompanying drawings.
The following detailed description relates to a novel method for installing drivers and applications in a host device operating in accordance with the “USB-On-The-GO” specification. In the description, numerous specific details are set forth regarding the novel method. It will be obvious, however, to one skilled in the art that these specific details need not be employed to practice the present invention, and that the method of the present invention is not limited to “USB-On-The-GO” compliant devices. Moreover, well-known aspects of the USB interface and requirements have not been described in detail in order to avoid unnecessarily obscuring the present invention.
As explained in more detail below, in accordance with the operation of the present invention, when a peripheral device 50 is connected to the host device 40, under command of the USB host controller 42, the USB host driver stack 44 loads the USB driver uploader program 46 from the host device memory 41. The host device 40 then executes the USB driver uploader 46, which results in the host device 46 uploading the driver necessary to communicate with the peripheral device 50 from the peripheral device itself. In other words, in accordance with the present invention, each peripheral device 50 has its corresponding driver stored in memory 51 within the peripheral device 50. Upon being coupled to a host device, the host device 40 functions to upload the driver from the peripheral device so as to allow for communication between the two devices.
Accordingly, the host device 40 no longer has to contain in its memory 41 a driver for every possible peripheral device that the host device may be coupled to. The host device need only contain the USB driver uploader 46 which provides the host device 40 the ability to retrieve the necessary driver from the peripheral device 50. It is noted that in accordance with the present invention, each of the peripheral devices must have its corresponding driver pre-installed in the memory 51 of the peripheral device 50. As a result of the present invention, it is no longer necessary for the manufacturer to predetermine what types and/or models of devices a host device (e.g., digital camera) can communicate with at the time of manufacture. The host device can communicate with any peripheral device having its driver pre-installed therein. Utilizing the foregoing example, practicing the present invention, the host device (i.e., digital camera) can be coupled to any type of peripheral device (e.g., printer), whereas in the prior art device, the digital camera could only be coupled to peripheral devices for which the corresponding drivers were pre-installed in the digital camera.
It is noted that each type of a given class of peripheral devices (e.g., printers) does not necessarily need its own driver. Some drivers (called “class drivers” in USB) are shared among similar products (for example, all printers can use a printer class driver). However, such class drivers have limitations because they only support common features (such as printing), and they do not support special features (such as double sided printing). In such instances, the driver of a particular peripheral device which utilizes such special features can be readily uploaded to the host device using the present invention.
It is noted that in accordance with the “USB-On-The-Go” specification, the host device is identified by utilizing the Host Negotiation Protocol. This protocol can also be utilized by the present invention in order to identify the host device. However, it is not intended that the present invention be limited to only this protocol. Clearly, there are other techniques for identifying/indicating a host device. Any such technique which allows for such identification can be utilized with the present invention. Currently, there are two techniques for determining which device is the host. The first being that the host controller has a A-receptacle (defined by the USB specification), and the second being the Host Negotiation Protocol mentioned above.
Referring again to
Finally,
The operation of the present invention is now described in more detail. When the host device 40 and the peripheral device 50 are first connected together, the role of the host and peripheral are determined in accordance with the “USB On-The-Go” specification. Then, the host will enumerate the peripheral device in accordance with the USB specification. Once this is performed, the USB core of the host device will determine the type of peripheral device and the driver necessary to communicate with the peripheral device. The identification of the peripheral device and the required driver is performed in accordance with the USB specification.
It is noted that the way a particular driver is selected/identified for a given peripheral device is by values described in peripheral device's Device, Interface, and Configuration Descriptors. If the peripheral device vendor ID and product ID (written in the Device Descriptor) matches with a driver, that driver is picked. If the class/subclass/protocol code matches with a class driver, that driver is picked and so forth. This matching framework is given by the USB specification, and the actual values in the descriptor are given by the specific class driver specification. The vendorID and productID values that are in the device descriptor can be taken from the USB Implementers Forum (USB IF). Similarly, the class/subclass/protocol code is written in class driver specification, and can be obtained from the USB IF.
Once the driver is identified, in the current embodiment, the host device 40 will initially check its memory 41 to determine if the required driver has been pre-installed. If so, the USB host driver 44 will load the driver as the client driver. However, if the USB host driver 44 cannot find the required driver in its memory, the USB core will load the USB driver uploader 46 as the client driver, and then execute the driver uploader program. As discussed below, a flowchart illustrating the execution of an exemplary “USB driver uploader program” is set forth in
It is noted that when utilized in conjunction with a Linux operating system, the driver matching process should be performed by priority (e.g., if/else statements). It will choose the driver that matches its Vendor ID/Product ID first. Then it will match with the class drivers. The driver_uploader should be at the lowest priority (the last “else” clause), and it will only be loaded if none of the drivers were matched with the particular device connected to the host.
a is a flowchart illustrating an exemplary USB application uploader program in accordance with the present invention. It is noted that the exemplary flowcharts of
Referring to
Continuing, in the event the host device does not have the required driver pre-installed in memory, the USB core of the host device will call the USB driver uploader 46 as the client driver (Step 142) and execute the program (Step 61 in
However, if the host device determines that it can support the peripheral's driver, the program proceeds (Step 65) and performs the “Call_Get_Driver_Info” task (Step 66), which functions to obtain information regarding the driver from the peripheral device. For example, as shown in Step 82, the driver information includes, but is not limited to, an indication of the version of the driver, the size of the driver (e.g., number of bytes), the name of the driver (i.e., string descriptors), as well as the available configuration numbers, the available interface numbers, and the available setting numbers. If a Linux operating system is being utilized, the additional items may also be included: an endpoint number indicating where the driver will be transferred from and the major number, which is what Linux uses to connect application and driver. It is noted that the endpoint number is necessary regardless of the operating system. The endpoint number is used to indicate which FIFO in the peripheral device stores the driver as data. It is further noted that the configuration numbers, the interface numbers, and the setting numbers are defined in the USB specification, and therefore are not discussed in detail herein. Once this information is obtained, the host device determines whether or not the host device is capable of executing the driver. If the host device determines it cannot execute the peripheral's driver, the uploader program is terminated.
If the host device determines that it can execute the peripheral's driver, the program proceeds (Step 67) and performs the “Get_Device_Driver” task (Step 68), which functions to command the peripheral device to load the selected driver into accessible memory in the peripheral device so as to allow the host to retrieve the driver from the peripheral device. In the example set forth in the flowchart of
Next, referring again to
As noted above, in certain instances it may also be necessary for the host device to retrieve an application from the peripheral device. If this is necessary, the application is uploaded from the peripheral device in substantially the same manner as the driver. In the current embodiment of the invention, the uploading of a given driver will trigger the uploading of all necessary applications associated with the given driver.
Accordingly, continuing with
Referring to
However, if the host device determines that it can execute the application, including the I/O requirements, the program proceeds (Steps 94 and 95) and performs the “Call_Get_App_Info” task (Step 96), which functions to obtain information regarding the application from the peripheral device. For example, as shown in Step 111, the application information includes, but is not limited to, an indication of the version of the application, the size of the application (e.g., number of bytes), and the location of the application in the memory of the peripheral device (i.e., the endpoint “EP” information).
Once the application information is obtained by the host device, the host device determines if the configuration (e.g., available endpoint numbers and endpoint types (USB specific)) is acceptable for executing the program (Step 97) and if the configuration is wrong, the host device calls the “Set-Configuration” task (Step 98) and/or the “Set_Interface” task (Step 99) to reconfigure the device according to the specific application. These “calls” are defined by the USB specification, and the tasks are issued by the host to select sets of endpoint and types that are made available by the device.
Next, the Call “Get_Application” task (Step 100) is performed, which functions to command the peripheral device to load the selected application into accessible memory so as to allow the host device to retrieve the application. In the example set forth in the flowchart of
Referring again to
Thus, in accordance with the present invention, it is possible to upload from a given peripheral device to a host device both the driver and application necessary for providing functional interaction and communication between the peripheral device and the host device.
Of course, the foregoing examples of retrieving either the driver or the application from the peripheral device illustrated in the flowcharts of
Additional variations are also possible. For example, it is possible to store an application, which is generic to numerous models of the given peripheral (e.g., a printer application), in the host so that the host does not have to upload the application each time it is connected to another printer. In this example, the printer application could be utilized with numerous different types of printers.
It addition, it may be possible to load some drivers in the host device during the manufacturing process. For example, if the manufacturer knows in advance that the host device is likely to be coupled to a given peripheral device(s), the manufacturer can install the driver for the given peripheral in the host memory so that the host device will not have to upload the driver if used with the given peripheral. However, the host device would still possess the capabilities of uploading the necessary drivers and applications when coupled to peripheral devices other than the given peripheral. Such a driver is indicated by element 59 in
It is noted that the exemplary flowcharts illustrated herein show the steps of uploading drivers and applications and installation thereof utilizing a Linux operating system. However, the present invention is not intended to be limited to implementation over a Linux operating system. It is clearly possible to performing the uploading of applications and drivers in accordance with the present invention utilizing other operating systems.
As described above, the present invention provides significant advantages over the prior art. Most importantly, the present invention basically unconditionally expands the number of peripheral devices that a given host device can be connected to. In other words, manufacturers are no longer limited to specifying a set number of peripheral devices that a given host can be coupled to (which in the prior art is limited by the number of drivers that can be stored in the host device at the time of manufacture). In accordance with the present invention, if the host device does not contain the necessary driver and application to interact with a peripheral device, the driver and application are simply uploaded from the peripheral device.
Another advantage is that the present invention reduces the amount of memory necessary for the host device. More specifically, as the host device is no longer required to store all of the drivers and applications for which the manufacturer wishes the host to be compatible with, the memory requirements of the host device are significantly reduced.
Although certain specific embodiments of the present invention have been disclosed, it is noted that the present invention may be embodied in other forms without departing from the spirit or essential characteristics thereof. The present embodiments are therefor to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims, and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
