1. Field of Invention
The present invention relates to the driving program of a peripheral device. More particularly, the present invention relates to the computer system and processing method for the driving program of a smart peripheral device.
2. Description of Related Art
At present, more and more smart peripheral devices such as personal digital assistants (PDA) and smart phones have the capacity to hook up with a personal computer via a peripheral bus such as universal serial bus (USB) and IEEE-1394 bus. Both the USB and the IEEE-1394 have plug-and-play (PnP) features. The operating system of a personal computer may retrieve factory-supplied driving program to drive the peripheral devices once they are plugged to one of the two major types of buses. Using the factory-supplied synchronous programs (for example, palm desktop, active-sync and so on), the personal computer may synchronize with the peripheral device to perform data uploading or transmission.
Because former peripheral devices were mostly single purpose devices, that is, devices purely for data transmission and reception, the application programming interface (API) provided by most factory-supplied driving programs performs simple interface functions. However, with the rapid development of smart peripheral devices, many of the devices are programmable and are receptive to various types of programs. Hence, in some applications, application programs within the personal computer and programs within the peripheral device need to transmit data to each other through the peripheral bus. For example, a touch panel on the peripheral device may serve as a writing board for the personal computer, images on the digital imaging device of a peripheral device may be transmitted to the personal computer for further processing or the PDA may record sound. Yet, all these applications are outside the scope of the original factory-supplied synchronizing programs.
Conventionally, communication with the various programs of a smart peripheral device relies on the application program interface provided by the original driving program provider. Through the factory-provided driving programs, the application programs of a personal computer may transmit data to the smart peripheral device and vice versa via the peripheral bus.
Furthermore, the originating factory provides only minimal API functions rather than general-purpose API functions. If different smart peripheral devices are plugged into the peripheral bus, the application program needs to adjust the calling method according to the API within the driving program supplied by the originating factory and hence generates much inconvenience.
Another method of dealing with smart peripheral device is to switch the peripheral bus into a diagnostic mode. In other words, an API is provided such that the application program at the personal computer end is able to communicate with the smart peripheral device. Under the diagnostic mode, the peripheral bus cannot coexist with the factory-supplied driving programs in the same operating system. Hence, if different smart peripheral devices are used, the peripheral must switch to an appropriate diagnostic mode. Furthermore, only original factory-supplied driving programs are found when a new peripheral device is plugged into the peripheral bus. Because diagnostic mode cannot be switched in a dynamic state, switching must be initiated by a re-plugging of the smart peripheral device. Consequently, if peripheral devices have already been plugged into the peripheral bus and some factory-supplied driving programs has already been downloaded, the smart peripheral device must be re-plugged to switch into the diagnostic mode.
In brief, major drawbacks into conventional techniques include:                1. Operation depends heavily on API provided by factory-supplied driving programs.        2. Factory-supplied API provides minimal functions rather than general-purpose functions. If different smart peripheral devices need to plug into the peripheral bus, the calling method of application programs must be adjusted according to the type of API provided by factory-supplied driving programs resulting in great inconvenience.        3. When the peripheral bus switches into the diagnostic mode, different smart peripheral devices require different diagnostic modes and the smart peripheral device need to be plugged in again. Furthermore, the diagnostic mode cannot coexist with the factory-supplied driving programs in the same operating system.        