Patent Application
20110040899
The field of invention relates generally to computing systems, and, more specifically, to a host/peripheral local interconnect that is compatible with a self-configurable peripheral device.
Peripheral devices typically include a plurality of different operating modes (or “configurations”) that describe the “services” the peripheral is capable of offering, for example, a Personal Digital Assistant (PDA) device might offer: 1) a digital camera mode, and, 2) a digital camera mode and contact/calendar mode. In configuration 1) above, the peripheral behaves only as a digital camera, whereas, in configuration 2) above, the peripheral behaves as both a digital camera and contact/calendar device. At least when connected to the host 101, the selection of a particular operating mode for the peripheral 102 has been traditionally controlled by the host 101 in a master-slave arrangement. That is, the host 101 determined and established a particular configuration setting for the peripheral 102 which thereafter operated according to the particular setting mandated by the host 101.
Here, perhaps because the functionality of the peripheral 102 was limited, and/or, the user interface of the peripheral 102 was not as easy to use as that of the host 101, the design point was hinged on the assumption that it was easier and/or more practical to configure the peripheral 102 from/through the host 101 rather than at the peripheral 102 itself.
In response, the peripheral 102 sends 112 to the host device 101 a list of the various configuration settings that the peripheral device supports. For example, if the peripheral device 102 supports both “digital camera only” mode (mode 1 described above) and “digital camera and contact/calendaring” mode (mode 2 described above), the peripheral device would respond to the GET DESCRIPTOR command by sending to the host device 101 a list that included both of these modes. With knowledge of the supported modes of the peripheral 102, the host 101 selects one of these modes (e.g., by way of a user selection through a Graphical User Interface (GUI) that is presented on the display of the host 101) and sends a command over the USB to the peripheral that configures the peripheral according to the selected mode (e.g., with a SET_CONFIGURATION command). The prior art USB local interconnect also supports a command (GET_CONFIGURATION) in which the host device asks the peripheral device outright for its current configuration.
Recently, peripheral devices have become more and more intelligent and sophisticated including easier to use user interfaces (e.g., smart phones). As a consequence, not being able to configure a peripheral device from the peripheral device itself when the peripheral device is communicatively coupled to the host is becoming a less natural usage case. Unfortunately, the underlying local interconnect technologies (such as USB) were designed prior to the emergence of sophisticated peripherals, and, correspondingly, the communication protocols of these local interconnects do not contemplate the ability of a peripheral to configure itself. For instance, the applicable USB standards do not provide for an explicit communication from the peripheral to the host that informs the host that the peripheral has configured itself into a particular operating mode.
A host/peripheral local interconnect that is compatible with a self-configurable peripheral device is described. According to processes discussed herein, the peripheral device is self-configured. The host device may be kept aware of the self-configured state of the peripheral device, and/or self-configured changes made at the peripheral device. The host device may scale its applications/uses of the peripheral device in light of such awareness.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
a shows a host, peripheral device and local interconnect;
b shows a prior art peripheral device configuration process executed between a host and peripheral device;
Given that the emergence of more sophisticated peripherals has caused user experiences to more naturally expect that a peripheral device should be able to be configured from the peripheral side even if the peripheral is communicatively coupled to a host through a local interconnect, it behooves system designers to provide for such an environment. Unfortunately, legacy local interconnect technologies (such as USB): 1) are not presently understood to possess communication protocols that fully contemplate self-configurable peripherals, and, 2) are not expected to be replaced in the near future. As such, in order to preserve downward compatibility with existing local interconnects yet embrace self-configurable peripherals, an approach that successfully implements self-configurable peripherals over such existing local interconnects is needed. That having been said, it should be understood that the techniques disclosed herein are equally applicable to local interconnects that do embrace self-configurable peripherals should such local interconnects eventually emerge.
According to the embodiment of
With the host being informed of the suggested peripheral configuration setting the host can next determine if the suggested peripheral configuration setting is appropriate for the host. For example, if the peripheral sends a suggested configuration setting that includes a digital camera and the host has not enabled its software for use with a digital camera peripheral, the host can, for example, enable such software and then accept the peripheral's suggestion, or, can request the peripheral to send alternative configuration settings.
In the former case (the host accepts the peripheral's suggestion), in an embodiment, the host signifies its acceptance of the peripheral's suggestion by sending a command 205 (e.g., a SET_CONFIGURATION command in the case of a USB local interconnect) to the peripheral to effect the suggested configuration setting at the peripheral. In this case it is possible that the peripheral's suggested configuration was its current configuration setting. As such, the command from the host simply instructs the peripheral to enter its current configuration setting—which the peripheral is free to ignore.
In the later case (the host asks the peripheral for additional configuration settings), the host selects which of the additional configuration settings it prefers and instructs the peripheral to enter that configuration 205. If the peripheral's suggested configuration setting was its current configuration setting, then, the command from the host would cause the peripheral to change its configuration state from the current/suggested state to the configuration state commanded by the host. Note that in the case of a USB local interconnect the host can ask for the alternative peripheral configuration settings with a GET_DESCRIPTOR command of type CONFIGURATION.
Note that, according to at least some implementations, the peripheral's configuration could be changed while the peripheral is communicatively coupled to the host through the local interconnect. For instance, consider a peripheral that has the following configuration possibilities: 1) a camera mode (in which the peripheral behaves principally as a digital camera); 2) a camera and “PDA” mode (in which the peripheral behaves principally as a combined camera, music player (including access to an on line music service such as iTunes) and calendaring/contacts device and can also synchronize/install/configure/debug software applications on its own or at the control of the host); 3) a camera/PDA/tethering mode (in which the peripheral behaves as described above with respect to the “camera and PDA” mode but can also support the “tethering” of network traffic for the host); and 4) an audio mode (in which the smartphone behaves principally as a music player including access to an on line music service). Note that tethering is a situation in which the peripheral devices acts as a network interface for the host device. For example, if the peripheral device is a smart phone, the host is able to “surf” the Internet by using the smart phone and its wireless network as an access mechanism to send/receive information to/from the Internet. It is worthwhile to note the wealth of different “services” that a smartphone can provide (camera, calendaring/contacts, tethering and synchronization/installation/configuration/debugging of software), and, that the different configuration settings can be, as described above, different combinations/sets of the different services offered by the smartphone.
In the case of peripheral smart phones having multiple configuration setting possibilities, such as those described above, conceivably, the peripheral could leave any of the multiple configuration modes to enter any of the other modes while the peripheral is communicatively coupled to the host. Again, because traditional local interconnects such as a USB do not fully contemplate self-configurable peripherals, legacy communication protocols of such local interconnects do not readily provide for a communication from a peripheral to a host for the purpose of explicitly telling the host that the peripheral's configuration mode has changed into a new mode (because, again, the configuration of a peripheral has traditionally been under the exclusive control of the host).
As an example, consider a situation in which the peripheral is a smart phone that is in the third “camera/PDA/tethering” mode discussed above. With knowledge that the peripheral is within this mode of operation, the host will understand that, for example, the host is not only free to exchange digital photographs and contact/calendar information with the peripheral, but also is free to “teather” through the peripheral device (among other engagements with the peripheral consistent with the camera/PDA/tethering mode discussed above). If the smart phone suddenly detects that its connection with its wireless network is down (or the user commands the smart phone to enter a mode such as “airplane mode” that causes the smart phone to disable its wireless network radio circuitry), the smart phone is apt to drop from the “camera/PDA/tethering” mode to the “camera” mode. Without knowledge of this event, the host could mistakenly initiate tethering service with the smart phone even though such service is no longer available.
However, by repeatedly 304 querying 301 the smart phone as to its current configuration status, the host will “catch” any such configuration changes made at the peripheral end. In this specific example, the host will realize that the smart phone is no longer capable of offering tethering services and will therefore prevent or otherwise not initiate a tethering session through the peripheral.
Likewise, the reverse is also possible. That is, should the smart phone re-connect with its wireless network, it will jump up from the “camera” mode to the “camera/PDA/tethering” mode. With knowledge of this change through its repeated querying of the smart phone's configuration, the host will realize that tethering services are no longer unavailable and will likewise not squelch a next attempt to tether through the smart phone.
The selection mechanism will therefore select the camera mode (mode #4 above) because that is the highest priority mode that is feasible when the wireless network is not available (note the PDA and audio modes expect a working on line music service such as iTunes). Note that configuration settings imposed by a user through the smart phone's user interface can be picked up through the environmental-awareness mechanism 401. For example, if the user disables the smart phone's wireless radio circuitry—e.g., by causing the smart phone to enter “airplane mode”—the environmental-awareness mechanism will detect/report that the wireless radio circuitry has been disabled and/or that the user has specified airplane mode. Regardless as to how this environmental change is reported, the selection mechanism will be able to determine that tethering is not possible, but camera functions are possible. In view of this environmental condition, the selection mechanism will scan the prioritized list 403 of configuration states for the highest prioritized and feasible configuration state (in this example, the camera configuration mode).
It is pertinent to point out that, although the above examples principally relied on USB as the local interconnect, other local interconnects may readily be used such as Bluetooth or Firewire. Here, note that a number of local interconnects are point-to-point connect connections between a host and a peripheral where the peripheral is not mechanically integrated with the host. These are to be contrasted against, for example, memory sticks, adapter cards or other “peripherals” that are mechanically integrated with the host (e.g., by being plugged into the host device) and communicatively coupled with the host through a multi-drop bus that can carry signals of multiple peripherals (rather than a point-to-point connection that can only entertain the signaling two/from a single peripheral)
As shown in
While
It will be apparent from this description that aspects of the present invention may be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a machine readable storage medium such as a memory (e.g. memory 49 and/or memory 50). In various embodiments, hardwired circuitry may be used in combination with software instructions to implement the present invention. Thus, the techniques are not limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system. In addition, throughout this description, various functions and operations are described as being performed by or caused by software code to simplify description. However, those skilled in the art will recognize what is meant by such expressions is that the functions result from execution of the code by a processor, such as the processing system 47.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
