WO2010070530A1

WO2010070530A1 - Electronic apparatus comprising a common bus

Info

Publication number: WO2010070530A1
Application number: PCT/IB2009/055575
Authority: WO
Inventors: Jo Degraef
Original assignee: Nxp B.V.
Priority date: 2008-12-19
Filing date: 2009-12-08
Publication date: 2010-06-24

Abstract

An electronic apparatus (100) employs a common bus (150) both for communicating between internal devices (120, 130) using a hardwired connection (110) and for communicating with a detachable external device (200) via a connector (160). The common bus (150) may be a USB bus.

Description

DESCRIPTION

ELECTRONIC APPARATUS COMPRISING A COMMON BUS

Field of the Invention

The invention relates to interfacing electronic devices.

Background of the Invention

Equipment employing an interface compliant with the Universal Serial Bus (USB) standard, available at www.usb.org, is widespread nowadays. The origins of USB lie in the world of personal computers, being intended for connecting devices, such as keyboards, printers, cameras, memory sticks and the like to a host, typically a personal computer. By design every USB system must consist of at least one USB host, which acts as a master, and one or more USB devices, which act as slaves. It is not possible for two USB devices to communicate directly with each other, or for a USB device to initiate communication with a USB host. This host-centric model has allowed USB devices to become practically ubiquitous.

One of the common application areas of USB devices is in mobile phones, and today almost every mobile phone comes equipped with a USB device connector, known as a USB receptacle. In addition to interfacing a mobile phone, or more specifically the baseband processor of a mobile phone, to an external USB host, the baseband processor is coupled to electronic devices internal to the mobile phone. One interfacing arrangement is illustrated in Figure 1. A mobile phone 10, has a baseband processor 20 with two interfaces, a USB bus 50 and a Serial Digital Input Output (SDIO) interface 52. The baseband processor 20 has a USB device 24 for providing the USB bus 50, and an SDIO module 22 for providing the SDIO interface 52. Instead of the SDIO, a Parallel Input Out (PIO) may be used. A personal computer (PC) 60 is coupled to the USB bus 50 by means of a cable 62. In particular, the mobile phone 10 has a USB B type socket 54, and the cable 62 has a USB B type plug for engaging with the USB B type socket 54. The PC 60 operates as a USB host. The USB device 24 has a USB device controller 25 coupled to the USB bus 50 for providing USB device functionality for communication with the PC 60. The USB device 24 also has a USB class driver 26 coupled to the USB device controller 25. The USB device 24 may contain hardware, firmware and software, in particular USB Chapter 9 software.

A peripheral device 30 is coupled to the SDIO interface 52, which is a hardwired interface. The peripheral device 30 is coupled to a wireless module 40 for wireless communication with apparatus external to the mobile phone 10. The baseband processor 20 has a peripheral driver 23 coupled to the SDIO module 22. The peripheral device 30 has an SDIO module 34 coupled to the SDIO interface 52 and peripheral firmware 36 coupled to the SDIO module 34. The SDIO module 22 operates as a master and the SDIO module 34 operates as a slave for communication via the SDIO interface 52. Both SDIO modules 34, 22 may comprise hardware, firmware and software. Firmware is computer program code that runs on a local processor and is dedicated to a specific hardware component. An objective of the invention is to provide improvements in interfacing electronic devices.

Summary of the Invention

According to a first aspect of the invention there is provided an electronic apparatus comprising a first device and a second device, wherein the first device is adapted for communicating with the second device and with a third device via a common bus, and wherein the first device is coupled to the second device by means of a hardwired coupling, and wherein the electronic apparatus further comprises a connector for a detachably coupling the third device to the electronic apparatus. According to a second aspect of the invention there is provided a method of operating an electronic apparatus comprising a first device, a second device coupled to the first device by means of a hardwired coupling, and a connector for a detachably coupling a third device to the electronic apparatus, the method comprising employing a common bus for communicating between the first device and the second device and for communicating between the first device and a third device coupled to the connector.

Therefore, according to the invention, an electronic apparatus employs a single bus for communication between first and second devices which are coupled by means of a hardwired coupling and for communication between first and third devices which are coupled in a detachable manner. By employing the same bus for communicating with both the second and third devices the number of physical connections on the first device may be reduced. For example, the first device may be implemented in an integrated circuit, in which case a chip with fewer connection pads and an integrated circuit package having fewer pins may be employed. Also, by sharing the bus for communicating with both the second and third devices, software, firmware and hardware of the first device may be reused, thereby reducing the complexity of the first device. Because the third device is detachable from the first device, by means of a connector, different types of third device may be coupled to the bus, and the first device may be adapted to communicate with a plurality of types of third devices having different capabilities and different communication characteristics. For example, different types of the third device may communication at different speeds. Because the coupling between the first device and the second device is hardwired, such versatility is not required for communication between the first and second devices, and a sub-set of the protocol used for communication between the first and third devices may be used for communication between the first and second devices, further contributing to reduced complexity. In summary, the electronic apparatus employs a common bus both for communicating between internal devices using a hardwired connection and for communicating with a detachable external device via a connector. Optionally, the first device may be a USB device, the third device may be a USB host, and the common bus may be a USB bus. This feature enables USB components of widespread availability, proven design and low cost to be used, providing a high data rate and plug-and-play functionality between the first device and the third device, whilst also providing high data rate communication via the hardwired coupling between the first and second devices.

Optionally, the first device and the second device may be adapted to communicate via the common bus by employing a subset of the USB standard protocol to provide a tunnel protocol. The method may comprise employing a subset of the USB standard protocol to provide a tunnel protocol for communicating between the first device and the second device over the USB bus. This feature facilitates re-use of the USB protocol for communicating with the second device, which need not support the full range of USB features, thereby contributing to reduced complexity. For example, the subset of the USB standard protocol may comprise at least part of the USB Bulk transfer protocol, such protocol providing error-free delivery of data by means of error detection and retransmission.

Optionally, the electronic apparatus may comprise means for detecting whether the third device is coupled to the electronic apparatus by means of the connector, and for enabling communication between the first device and the second device only if the third device is not coupled to the electronic apparatus and for enabling communication between the first device and the third device otherwise. The method may comprise detecting whether the third device is coupled to the electronic apparatus by means of the connector, and enabling communication between the first device and the second device only if the third device is not coupled to the electronic apparatus and enabling communication between the first device and the third device otherwise. This feature enables communication between the first and third device to take priority over communication between the first and second device, whilst avoiding conflict between these communications. Optionally, the second device may be adapted to transmit a poll signal to the first device, and the first device may be adapted to transmit data to the second device in response to receiving the poll signal. The method may comprise transmitting a poll signal from the second device to the first device, and, in response to receiving the poll signal at the first device, transmitting data from the first device to the second device. This feature enables the first device to operate as a slave both when communicating with the third device in accordance with the USB, or other, protocol, and when communicating with the second device using a subset of the USB, or other, protocol. Optionally, the hardwired coupling may comprise a serial data interface.

The method may comprise transmitting serial data over the hardwired coupling. This feature enables readily available components for implementing a serial data interface to be employed.

Optionally, the hardwired coupling may comprise a parallel data interface. The method may comprise transmitting parallel data over the hardwired coupling. This feature enables complexity to be reduced by reducing the use of components implementing a serial data interface.

Optionally, the second device may comprise means for coupling the third device to the common bus. The method may comprise coupling the third device to the common bus by means of the second device. This feature enables a higher level of component integration, with the second device providing a pass- through tunnel for USB signals passing between the first and third device.

Optionally, the electronic apparatus comprises a wireless device coupled to the second device for wireless communication with a wireless device external to the electronic apparatus. The method may comprise employing a wireless device coupled to the second device for wireless communication with a wireless device external to the electronic apparatus. This feature enables communication to be maintained between the electronic apparatus and the third device, whether or not the third device is coupled by means of a cable to the common bus. For example, if a cable connecting the third device to the electronic apparatus is removed during communication, communication between the first device and the third device may be continued via the second device and the wireless device. Conversely, if a cable is coupled to the connector during wireless communication between the first and third device via the second device and wireless device, communication between the first device and the third device may be continued via the cable. Changeover between these two modes of operation may be automatic in response to detecting the presence or absence of the physical coupling between the electronic apparatus and the third device.

Brief Description of Drawings The invention will now be described, by way of example only, with reference to the accompanying drawings wherein:

Figure 1 is a block schematic diagram of known electronic apparatus; Figure 2 is a block schematic diagram of an electronic apparatus in accordance with the invention; Figure 3 is a sequence diagram illustrating initialisation of a tunnel protocol;

Figure 4 is a sequence diagram illustrating a status message being returned in response to a command;

Figure 5 is a sequence diagram illustrating the sending of a notification; Figure 6 is a sequence diagram illustrating data flow to a peripheral device;

Figure 7 is a sequence diagram illustrating data flow from a peripheral device;

Figure 8 is a first part of flow chart of a scheduler; Figure 9 is a second part of flow chart of a scheduler;

Figure 10 is block schematic diagram of an interface with embedded analogue transceivers;

Figure 11 is block schematic diagram of an interface without embedded analogue transceivers; and Figure 12 is block schematic diagram of an interface without embedded transceivers and with a pass-through tunnel. Detailed Description of the Invention

In this specification, use of the USB standard is considered for illustration, and terminology is used which should be familiar to a person familiar with the USB standard.

Referring to Figure 2, there is an electronic apparatus 100, which may be, for example, a mobile phone. The electronic apparatus 100 has a USB device 120 providing a USB bus 150 for communicating with a personal computer (PC) 200 which is coupled to the USB bus 150. The PC 200 is coupled to the USB bus 150 by means of a USB cable 202. In particular, the electronic apparatus 100 has a connector 160 which is a USB B type socket, and the USB cable 202 has a USB B type plug for engaging with the USB B type socket.

A peripheral device 130 is coupled to the USB bus 150 and to further components of the electronic apparatus 100, for example, a wireless module 140 for wireless communication with apparatus external to the electronic apparatus 100. The wireless module 140 may be, for example, a wireless USB (WUSB) module or a Bluetooth module suitable for communicating with a corresponding wireless module in the PC 200. Indeed, the electronic apparatus 100 may be adapted to detect the presence or absence of the PC 200 coupled to the electronic apparatus 100 by means of the USB cable 202, and attempt to initiate wireless communication with the PC 200 by means of the wireless module 140 if the PC 200 is not coupled by the USB cable 202.

The peripheral device 130 may be coupled to further components instead or, or in addition to, the wireless module 140, for example, a user interface display or keypad.

The USB device 120 provides USB device functionality for communication with the PC 200. When the USB device 120 communicates with the PC 200, which operates as a USB host, the USB device 120 operates as a USB slave. The USB device 120 has a USB device controller 125 coupled to the USB bus 150 and a USB class driver 126 coupled to the USB device controller 125. The USB device 120 may contain hardware, firmware and software, in particular USB Chapter 9 software. A USB class driver is a generic definition of an application driver which is described, or loaded through Chapter 9.

The USB device 120 also has a tunnel class driver 124 coupled to the USB device controller 125. A peripheral driver 127 is coupled to the tunnel class driver 124.

The peripheral device 130 comprises a tunnel controller 164 coupled to the USB bus 150, and peripheral firmware 162 coupled to the tunnel controller 164. In particular, the tunnel controller 164 is hardwired to the USB bus 150 by means of a hardwired coupling 110, and thereby is hardwired to the USB device 120. The tunnel controller 164 may contain hardware, firmware and software. In operation the USB device 120 selectively communicates with the PC 200 via the USB bus 150, specifically via the USB cable 202 which is detachable from the electronic apparatus 100, or with the peripheral device 130 via the USB bus 150 using the hardwired coupling 110 between the USB device 120 and the tunnel controller 164, depending on whether the PC 200 is coupled to the USB bus via the connector 160. A USB host provides power to a USB device by means of a signal named V_BUS- The electronic apparatus 100 may detect the V_BUS signal provided by the PC 200 to determine the presence of the PC 200 coupled to the USB bus 150. Other methods of determining the presence of the PC 200 coupled to the USB bus 150 may be used.

The tunnel controller 164 employs a sub-set of the USB standard, in particular a subset of the USB host protocol defined by the USB standard, for communicating with the USB device 120. The USB device 120 employs a subset of its functionality, in particular a subset of the USB device protocol defined by the USB standard, when communicating with the tunnel controller 164. In this way the tunnel controller 164 and the USB device 120 cooperate to provide a tunnel protocol for communication between the peripheral driver 127 and the peripheral firmware 162 via th. In the USB device 120 and the tunnel controller 164. In this way, a payload protocol operated by the peripheral driver 127 and the peripheral firmware 162 is encapsulated within the USB protocol which acts as delivery protocol between the USB device 120 and the tunnel controller 164. The operation of the electronic apparatus 100 will now be described. Three bidirectional pipes, which are logical channels, are used for communication on the USB bus 150 between the USB device 120 and the tunnel controller 164. These pipes are mapped onto three BULK endpoint (EP) pairs or six physical endpoints of the USB standard, as follows, with OUT denoting the direction from the tunnel controller 164 to the USB device 120, and IN denoting the direction from the USB device 120 to the tunnel controller 164.

1. EP1 OUT is used for conveying notifications, which are interrupts, from the tunnel controller 164 to the USB device 120; 2. EP1 IN is used for conveying commands from the USB device 120 to the tunnel controller 164;

3. EP2 OUT is used for conveying data descriptors from the tunnel controller 164 to the USB device 120;

4. EP2 IN is used for conveying data descriptors from the USB device 120 to the tunnel controller 164;

5. EP3 OUT is used for conveying payload data from the tunnel controller 164 to the USB device 120; and

6. EP3 IN is used for conveying payload data from the USB device 120 to the tunnel controller 164. Additionally, a seventh physical endpoint of the USB standard,

ControlEndpointO, referred to as Control EPO (IN/OUT), is used for initialisation in accordance with the USB specification.

The tunnel controller 164 of the second communication module continuously polls all IN endpoints, EP1 IN, EP2 IN and EP3 IN, for commands or data. When the tunnel controller 164 has notifications or data to send to the USB device 120, it sends them via an appropriate OUT endpoint, EP1 OUT, EP2 OUT or EP3 OUT, to the USB device 120. If the USB device 120 is not ready to process a notification or data, or does not have buffer space available, it can transmit a negative acknowledgement, NAK, in response to the notification or data, and the tunnel controller 164 retransmits the notification or data. This flow control mechanism may be handled by hardware of the USB device 120 and therefore does not require the involvement of firmware of the USB device 120.

The flow of events between the USB device 120 and the tunnel controller 164 will now be described with reference to Figures 3 to 7. Figures 3 to 7 show only one endpoint active at a time. In reality all pipes may behave as independent processes. First, the tunnel is initialised. Initialisation of the tunnel

Upon initialisation of the tunnel, the tunnel controller 164 performs a minimal enumeration, as illustrated in Figure 3. In Figure 3, the left column headed "Tunnel" contains steps performed by the tunnel controller 164 and the right column, headed "USB Device", contains steps performed by the USB device 120. The centre column in Figure 3 illustrates USB traffic, that is signals transmitted on the bus 150 between the tunnel controller 164 and the USB device 120. The flow of time is from top to bottom of Figure 3. Referring to Figure 3, initially the state of the USB device 120 is reset and the USB bus 150 is reset.

Next, the tunnel controller 164 transmits a GetDescriptor command and in response the USB device 120 transmits Device Descriptor data. On receipt of the Device Descriptor data, the tunnel controller 164 checks the Device Descriptor for a Tunnel Descriptor. These steps are optional, for the purpose of version checking.

Next, the tunnel controller 164 transmits, in turn, a SetAddress command, a SetConfiguration command and a Setlnterface command. Transmission of the SetConfiguration command is the standard way of binding a class driver to physical endpoints, and in response to receiving this the USB device 120 loads the peripheral driver 127 and binds it to tunnel driver 124. The USB device 120 also allocates buffer space for OUT endpoints. These steps allow conventional Chapter 9 firmware of a USB device to be reused. USB Chapter 9 is a component required to be present in all USB devices. It is also known as 'Control Endpoint 0'. Next, the tunnel controller 164 activates the tunnel by means of the following steps. In turn, an In Command EP command, an IN DataDescriptor EP command and an IN Data EP command are transmitted, and in response to each of these commands the USB device 120 transmits a negative acknowledgement, NAK.

After these steps the tunnel between the peripheral driver 127, coupled to the USB device 120, and the peripheral firmware 162, in the peripheral device 130, is set up and ready to be used. The peripheral driver 127 may now perform an initialisation process of the peripheral device 130, as follows. Initialisation of the peripheral device, and commands sent to the peripheral device

In Figure 4, the left column contains steps performed by the peripheral device 130, in particular by the peripheral firmware 162 and the tunnel controller 164, and the right column contains steps performed by the peripheral driver 127 and the USB device 120. The centre column in Figure 4 illustrates USB traffic, that is signals transmitted on the USB bus 150 between the USB device 120 and the tunnel controller 164. The flow of time is from top to bottom of Figure 4.

Referring to Figure 4, the peripheral driver 127, coupled to the USB device 120, submits a command to the USB device 120 which in turn stores the command in a buffer assigned for commands, denoted IN1 meaning a buffer for EP1 IN. These commands are freeform as the tunnel protocol treats these as payload. As soon as the buffer is committed the USB device 120 temporarily suspends sending NAKs and instead sends the command, and the tunnel controller 164 will read the command from the buffer and pass the command to the peripheral firmware 162 for execution. The USB device 120 resumes sending NAKs when the data has been acknowledged and the buffer is empty. The peripheral driver 127 can continue this process or wait for a status notification from the peripheral device 130.

In more detail, Figure 4 illustrates: an initial IDLE state; the transmission of a command from the peripheral driver 127 to the peripheral firmware 162; a notification sent by the peripheral firmware 162 to the peripheral driver 127 in response to the command; and return to the IDLE state by both the peripheral device 130 and the USB device 120. In the IDLE state, the tunnel controller 164, indicated by "Tunnel" in Figures 4 to 7, continuously generates IN1 tokens. In response to each IN1 token, the USB device 120 transmits a NAK while the IN1 buffer is empty. At step 4.1 , the peripheral driver 127 initiates the transmission of a ReadReg command to the peripheral firmware 162. At step 4.2, the peripheral driver 127 loads the IN1 buffer with a RegRead command, and at step 4.3, in response to receiving an IN1 token, the USB device 120 transmits the RegRead command to the tunnel controller 164. In response to receiving the RegRead command, the tunnel controller 164 transmits an acknowledgement signal ACK. At step 4.4, on reception of the RegRead command, the tunnel controller 164 raises an interrupt to the peripheral firmware 162, and the peripheral firmware 162 reads the IN1 buffer at step 4.5. At step 4.6 the peripheral firmware 162 executes the RegRead command. Notifications returned from the peripheral device

Continuing to refer to Figure 4, after executing a command from the peripheral driver 127, the peripheral device 130 optionally returns a status message. To do so, at step 4.7, the peripheral firmware 162 deposits a status message in a buffer OUT1 assigned to EP1 OUT. The tunnel controller 164, at step 4.8, generates an OUT1 token to the corresponding endpoint on the USB device 120, and transmits the status message, which is then placed in the OUT1 buffer of the USB device 120. At step 4.9, on receipt of the OUT token the USB device 120 raises an interrupt to USB firmware of the USB device 120, and as a result at step 4.10 the peripheral driver 127 reads the status message from the OUT1 buffer of the USB device 120. At step 4.11 , the peripheral driver 127 processes the status message. Interrupts and notifications from the peripheral device

Referring to Figure 5, interrupts are handled in the same way as notifications. An interrupt is merely a specific status message transmitted without a prior command. It would be wasteful to just transfer the interrupt notification as equivalent to an interrupt line. It is much more efficient to transfer the complete internal status together with the interrupt notification itself.

Figure 5 illustrates an initial IDLE state, the transmission of an interrupt, and the return to the IDLE state. As in Figure 4, the transmission of IN1 tokens and NAKs in the IDLE state is shown. At step 5.1 , at the peripheral firmware 162 an interrupt event occurs, and the peripheral firmware 162 loads the OUT1 buffer with an interrupt. At step 5.3 the tunnel controller 164 generates an OUT1 token, and the interrupt and the OUT1 token are transmitted to the USB device 120.

At step 5.4, on reception of the OUT1 token, the USB device 120 raises an interupt. At step 5.5 the peripheral driver 127 reads the OUT1 buffer, and at step 5.6 the peripheral driver 127 processes the interrupt. Data flow to the peripheral device

Referring to Figure 6, there is illustrated: an initial IDLE state; the flow of data from the USB device 120 to the peripheral device 130, which entails the initial transmission of a data descriptor DSC; and return to the IDLE state. The use of a data descriptor prior to sending the data itself is optional, but is preferred as it allows the peripheral device 130 to prepare to receive the data, for example prepare buffer space.

At step 6.1 , the peripheral driver 127 initiates data transfer, and at step 6.2 passes the data descriptor to the tunnel class driver 124 which deposits the data descriptor in buffer IN2 for EP2 IN. At step 6.3, on receipt of an IN2 token for EP2, the USB device 120 transmits on EP2 IN the data descriptor to the tunnel controller 164.

At step 6.4, reception of the data descriptor by the tunnel controller 164 results in the tunnel controller 164 raising an interrupt to the peripheral firmware 162, and at step 6.5 the peripheral firmware 162 reads the data descriptor from the IN2 buffer and at step 6.6 prepares to receive data.

At step 6.1 ', peripheral driver 127 deposits data through the tunnel class driver 124 into the data buffer IN3 for EP3 IN where the data is transmitted in response to an IN3 token received from the tunnel controller 164. At step 6.2', additional data is transmitted in response to additional IN3 tokens, as required to complete transmission of all the required data. At step 6.3' the tunnel controller 164 stores the data in an appropriate location, for which the peripheral firmware 162 does not need to be involved.

The end of data transfer is indicated by the USB device 120 transmitting a Short or Empty packet according to the rules of the USB standard, and at the tunnel controller the USB Short Packet Semantics indicate EndOfTransfer. Data flow from the peripheral device

The events required for data flow from the peripheral device 130 to the USB device 120 are essentially the same as for the flow of data from the USB device 120 to the peripheral device 130, but with OUT tokens. Referring to

Figure 7, in the initial IDLE state, when no data is required to be transmitted, the tunnel controller 164 does not generate out tokens. The USB device 120 pre- allocates a buffer for a data descriptor.

At step 7.1 , the peripheral firmware 162 initiates data transfer, and at step 7.2 the tunnel controller 164 loads the OUT2 buffer with a data descriptor. At step 7.3 the tunnel controller 164 transmits an OUT2 token followed by the data descriptor. At step 7.4, on receipt of the OUT2 token , the USB device 120 raises an interrupt. At step 7.5, the USB device 120 reads the OUT2 buffer, and at step 7.6 the peripheral driver 127 prepares for data transfer by allocating a buffer OUT3 for EP3 OUT.

At step 7.1 ', the peripheral firmware 62 assigns payload data to buffer OUT3, and at step 7.2' the tunnel controller 164 generates an OUT3 token followed by payload data. If the USB device 120 is not ready to receive data it can transmit a NAK in response to receiving an OUT3 token. If the USB device 120 is ready to receive data, at step 7.3' it transmits an acknowledgement ACK and stores the payload data in an appropriate location. Additional OUT3 tokens and payload data may be transmitted as required, and acknowledged. When all required payload data has been transmitted and acknowledged, the tunnel controller 164 transmits a Short or Empty packet to signify the End Of Transfer according to the rules of the USB standard, and at the USB device 120 the Short Packet Semantics indicate EndOfTransfer. Figure 7 illustrates NAKs being transmitted at one point in the flow of events, for the purpose of flow control. However, the USB device 120 may transmit a NAK anywhere in the flow of events. Similarly the peripheral device 130 may refrain from generating IN tokens whenever it does not have sufficient resources to accept a new command or data transfer. Minimal tunnel implementation

The flow of events described can be implemented using a full USB host implementation at the tunnel controller 164, such as the Open Host Controller Interface (OHCI), Universal Host Controller Interface (UHCI) or a Enhanced Host Controller Interface (EHCI), or a functional equivalent, at the tunnel controller 164. A high speed USB host is preferred for its higher signalling rate, and also because the high speed supports bigger packet sizes. The whole USB protocol stack, comprising, for example, multiple devices and hubs, need not be implemented. The steps described above are all that are needed. These may be a implemented as a hard coded sequence.

USB supports three data rates, high, full and low. A USB host is required to support all three. However, the tunnel controller 164 may support only the high speed. The speed detection and change mechanism of the USB standard may be omitted from an implementation if the USB device 120 can switch its mode independently of the detection. Moreover, support for split tokens may be omitted. Since the tunnel controller 164 uses the Bulk transfer protocol of the USB standard, no support for Isochronous transfers or Interrupt transfers is needed.

In general, none of the typical list structures are required and a simple fixed scheduling scheme may be used. Figures 8 and 9 show a flow diagram for a simple host scheduler, suitable for use at the tunnel controller 164, with a fixed one-packet size buffer for control and notification and a programmable buffer for the data pipe. The pipes are served in a round robin manner.

Referring to Figure 8, at step 801 the scheduler initialises flags to indicate that buffers IN1 , OUT1 , IN2 and OUT 2 are empty, buffer OUT2 is enabled, buffers IN3 and OUT3 are unassigned, and buffer OUT3 is disabled. At step 802, the scheduler enters an IDLE state. At step 803, the scheduler tests whether IN1 buffer is empty. In Figures 8 and 9, the outcome of tests are signified by Y for yes and N for no. If the IN1 buffer is empty, flow proceeds to step 804 where an IN1 token is transmitted, and then flow proceeds to step 805, whereas if the IN1 buffer is not empty, flow proceeds to step 809. There is an independent software process 807 which reads the IN1 buffer at step 807', and then at step 807" clears the IN1 buffer and sets a flag to indicate that the IN1 buffer is empty; it is the status of this flag that is tested at step 803.

At step 805, the success of the transmission of the IN1 token is tested. If the transmission is successful, which may be indicated, for example, by a successful cyclic redundancy check, at step 806 an interrupt is raised and a flag set to indicate that the IN1 buffer is full. Flow then proceeds to step 809. Flow also proceeds to step 809 from step 805 if the transmission of the IN1 token is unsuccessful. There is an independent software process 808 which fills the OUT1 buffer, and sets a flag to indicate that the OUT1 buffer is full.

At step 809, the scheduler tests whether the OUT1 buffer is full. If the OUT1 buffer is full, at step 810 an OUT1 token is transmitted followed by data. Flow proceeds to step 811 where the success of the OUT1 token and data transmission is tested. If the transmission is successful, flow proceeds to step 812 where an interrupt is raised, a flag is set to indicate that the OUT1 buffer is empty, and flow then proceeds to step 813. Flow also proceeds to step 813 if the OUT1 buffer is determined to be not full at step 809, and if at step 811 the transmission is determined to be unsuccessful. At step 813, the scheduler tests whether IN2 buffer is empty, the IN2 buffer being used for the data descriptor. If the IN2 buffer is empty, at step 814 an IN2 token is transmitted and flow proceeds to step 815, whereas if the IN2 buffer is not empty flow proceeds to step 818. At step 815, the success of the transmission of the IN2 token is tested. If the transmission is successful, at step 816 an interrupt is raised and a flag set to indicate that the IN2 buffer is full. Flow then proceeds to step 818. Flow also proceeds to step 818 from step 815 if the transmission of the IN2 token is unsuccessful.

There is an independent software process 817 which reads the IN2 buffer at step 817' and then assigns the IN3 buffer for payload data at step 817". At step 818 the scheduler tests whether the IN3 buffer is assigned. If the

IN3 buffer is assigned, at step 819 an IN3 token is transmitted and flow proceeds to step 820, whereas if the IN3 buffer is not assigned, flow proceeds to step 825 in Figure 9. At step 820, the success of the transmission of the IN3 token is tested. If the transmission is successful, at step 821 a test is made for the end of the transaction. If the end of the transaction is determined, at step 822 an interrupt is raised and a flag set to indicate that the IN3 buffer is not assigned, after which flow proceeds to step 825. Flow also proceeds to step 825 from step 820 if the transmission of the IN3 token is determined to be unsuccessful, and from step 821 if the transaction is determined to be not yet ended. There is an independent software process 823 which reads the IN3 buffer at step 823', and then at step 823" clears the IN2 buffer and sets a flag to indicate that the IN2 buffer is empty. There is also an independent software process 824 in Figure 9 that, at step 824', fills the OUT2 buffer and sets a flag to indicate that the OUT2 buffer is full, and then at step 824" assigns a buffer pointer for the OUT3 buffer.

At step 825, the scheduler tests whether the OUT2 buffer is both full and enabled. If the OUT2 buffer is determined to be both full and enabled, at step

826 an OUT2 token and payload data is transmitted, after which at step 827 the success of the transmission is tested. If the transmission is determined to be successful, then at step 828 the OUT2 buffer is disabled and the OUT3 buffer is enabled and flow proceeds to step 829. Flow also proceeds to step 829 if at step 825 the OUT2 full is determined not to be both full and enabled, and if at step

827 the transmission is determined to be not successful.

At step 829, the scheduler tests whether the OUT3 buffer is enabled. If the OUT3 buffer is enabled, then at step 830 an OUT3 token and payload data is transmitted, and flow proceeds to step 831 where the success of the transmission is tested. If the transmission is determined to be successful, then at step 832 the OUT3 buffer pointer is incremented and at step 833 a test is made for the end of the transaction. If the end of the transaction is determined, then at step 834 the OUT3 buffer is disabled, the OUT2 buffer is enabled, and a flag is set to indicate that the OUT2 buffer is empty. Flow then returns to the IDLE step 802 in Figure 8. Flow also returns to step 802 if at step 829 the OUT3 buffer is determined to be not enabled, or if at step 831 the transmission is determined to be not successful, or if at step 833 the transaction is determined to be not ended. For simplicity, Figures 4 to 7 show non-concurrent transactions on the same pipe. In particular, one command/notification cycle is completed before another is started. Optionally, overlapping transactions may be achieved by maintaining the correct order of the commands and notifications, so both the sending and receiving device can associate each command with the correct notification. Alternatively a random identifier may be used to tag each command. In this way notifications may be returned in random order.

Some USB devices have a limited set of endpoints hardwired into the device. Since a data descriptor is a specific type of command, the number of endpoints required may be reduced by merging the command/notification and data descriptor endpoint. The data pipe may also be merged by inserting a header distinguishing the different pipes. This software multiplexing would however require software intervention on each USB packet received.

Another option is to implement both the data descriptor pipe and the data pipe on the same endpoint. This may be achieved by first sending the data descriptor and then the data via the same endpoint buffer.

Another variant is to implement the tunnel over ControlEPO, by transforming each IN token and OUT token into a 'Get' and 'Set' vendor specific command respectively.

Although BULK endpoint types are best suited for the implementation, the tunnel could be implemented using Interrupt or even ControlEndpointO, using a Vendor Specific request. Isochronous endpoints are less well suited for this type of application as they do not have an error recovery mechanism. However, an application may implement the data pipe over such an endpoint.

In the embodiments described above, a continuous polling scheme has been assumed for all IN endpoints. Such a scheme may be optimised to reduce latency by, for instance polling the command pipe several times before polling the data descriptor pipe, or in a more dynamic way by tying this preference to whether an endpoint has sent NAK recently. As an alternative to continuous polling, polling the data pipe could be started only upon reception of a Data Descriptor. An analogue transceiver (ATX) is conventionally used in a USB implementation to convert between parallel digital signals and serial analogue signals, denoted D+ and D-, which are transmitted between a USB host and a USB device. The USB 2.0 Transceiver Macrocell Interface (UTMI) standard, Version 1.05, 29 March 2001 defines a standard interface for the digital interface of an ATX. In the embodiments of the invention described herein, an ATX is not required as the peripheral device 130 is hardwired to the USB device 120 via the hardwired coupling 110, such that the peripheral device 130 and the USB device 120 do not need to be unplugged, in which case the tunnel controller 164 and the USB device 120 may be coupled using either digital circuits or analogue circuits. Figures 10, 11 and 12 illustrate three alternative ways of coupling the tunnel controller 164 to the USB device 120 in a hardwired manner, and the PC 200 to USB bus 150 in a conventional manner using a USB connector 160.

In Figure 10, the USB device controller 125 comprises a UTMI block 129 for generating and decoding UTMI parallel digital signals, coupled to an ATX 128. The UTMI block 129 transmits and receives UTMI signals to/from the ATX 128. The tunnel controller 164 comprises a UTMI block 168 for generating and decoding UTMI parallel digital signals, coupled to an ATX 166. The UTMI block 168 transmits and receives UTMI signals to/from the ATX 166. The ATX 128 and ATX 166 are coupled for transmitting and receiving the serial analogue USB signals D+ and D- on the USB bus 150. The PC 200 is coupled to the USB bus 150 for transmitting and receiving the signals D+ and D-. The PC 200 provides power by means of V_Bus signal. The PC 200 is coupled to the tunnel controller 164 by means of a connection 204 for delivering the V_Bus signal to a detector 163 at the tunnel controller 164. The detector 163 employs the V_BUS signal to determine whether or not a USB host, such as the PC 200 is coupled to the USB bus 150.

In Figure 11 , the structure of the USB device controller 125 is the same as in Figure 10, except that the ATX 128 transmits and receives USB bus signals to and from the tunnel controller 164 in the form of UTMI parallel digital signals on the USB bus 150, without conversion to serial analogue USB signals D+ and D-. The tunnel controller 164 comprises an inverse UTMI block 167, referred to as I- UTMI, for generating UTMI parallel digital signals for transmission to the USB device controller 125 on the USB bus 150, and for decoding UTMI parallel digital signals received from the USB device controller 125 on the USB bus 150. Coupled to the USB bus 150 and to the PC 200 is an ATX 165 for converting UTMI parallel digital signals to/from serial analogue USB signals D+ and D-. As in Figure 10, the tunnel controller 164 has a detector 163 for detecting the V_BUS signal to determine whether or not a USB host is coupled to the USB bus 150.

The arrangement of Figure 12 is identical to that of Figure 11 , except that an ATX 169 is integrated into the tunnel controller 164, being coupled to the I- UTMI 167, rather than having a separate element ATX 165, such that signals transmitted to or from the PC 200 on the USB bus 150 pass via the I-UTMI 167.

Optionally, in use a descriptor index known to the tunnel controller 164 and USB device 120, and not to the USB host PC 200, may be used. This has the advantage of hiding the tunnel capabilities from a conventional USB host. Along with this, a vendor specific command may be defined to 'bind' the tunnel class driver 124 to the USB device 120 endpoints.

The Suspend, Resume and Remote Wakeup, USB power saving states may be used to temporarily shutdown connectivity while maintaining state. A command may be sent from the USB device 120 to the peripheral device 130 to suspend the tunnel connection. Both the USB device 120 and the peripheral device 130 may then go into power saving mode. When connectivity needs to be restored the USB device 120 may transmit a Remote Wakeup signal, or the peripheral device 130 may transmit a Resume signal.

Although embodiments of the invention have been described which employ the USB standard for the common bus 150, other protocols may be employed for the common bus 150. For example, the common bus may operate according to the IEEE 1394 standards, also known as FireWire.

From reading the present disclosure, other variations and modifications will be apparent to the skilled person. Such variations and modifications may involve equivalent and other features which are already known in the art of interfacing electronic apparatus and which may be used instead of, or in addition to, features already described herein.

Although the appended claims are directed to particular combinations of features, it should be understood that the scope of the disclosure of the present invention also includes any novel feature or any novel combination of features disclosed herein either explicitly or implicitly or any generalisation thereof, whether or not it relates to the same invention as presently claimed in any claim and whether or not it mitigates any or all of the same technical problems as does the present invention.

Features which are described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub- combination.

For the sake of completeness it is also stated that the term "comprising" does not exclude other elements or steps, the term "a" or "an" does not exclude a plurality, and reference signs in the claims shall not be construed as limiting the scope of the claims.

Claims

1. An electronic apparatus (100) comprising a first device (120) and a second device (130), wherein the first device (120) is adapted for communicating with the second device (130) and with a third device (200) via a common bus (150), and wherein the first device (120) is coupled to the second device (130) by means of a hardwired coupling (110), and wherein the electronic apparatus (100) further comprises a connector (160) for a detachably coupling the third device (120) to the electronic apparatus (100).

2. An electronic apparatus (100) as claimed in claim 1 , wherein the first device (120) is a USB device (120), the third device (200) is a USB host, and the common bus (150) is a USB bus (150).

3. An electronic apparatus (100) as claimed in claim 2, wherein the first device (120) and the second device (130) are adapted to communicate via the common bus (150) by employing a sub-set of the USB standard protocol to provide a tunnel protocol.

4. An electronic apparatus (100) as claimed in claim 3 , wherein the subset of the USB standard protocol comprises at least part of the USB Bulk Transfer protocol.

5. An electronic apparatus (100) as claimed in any preceding claim, comprising means (165) for detecting whether the third device (200) is coupled to the electronic apparatus (100) by means of the connector (160), and for enabling communication between the first device (120) and the second device (130) only if the third device (200) is not coupled to the electronic apparatus (100) and for enabling communication between the first device (120) and the third device (200) otherwise.

6. An electronic apparatus (100) as claimed in any preceding claim, wherein the second device (130) is adapted to transmit a poll signal (IN; IN1 ; IN2; IN3) to the first device (120), and the first device (120) is adapted to transmit data to the second device (130) in response to receiving the poll signal.

7. An electronic apparatus (100) as claimed in any preceding claim, wherein the hardwired coupling (110) comprises a serial data interface (D+, D-).

8. An electronic apparatus (100) as claimed in any preceding claim, wherein the hardwired coupling (110) comprises a parallel data interface (UTMI).

9. An electronic apparatus (100) as claimed in any preceding claim, wherein the second device (130) comprises means (169) for coupling the third device (200) to the common bus (150).

10. An electronic apparatus (100) as claimed in any preceding claim, comprising a wireless device (140) coupled to the second device (130) for wireless communication with a wireless device external to the electronic apparatus (100).

11. A method of operating an electronic apparatus (100) comprising a first device (120), a second device (130) coupled to the first device by means of a hardwired coupling (110), and a connector (160) for a detachably coupling a third device (120) to the electronic apparatus (100), the method comprising employing a common bus (150) for communicating between the first device (120) and the second device (130) and for communicating between the first device (120) and a third device (200) coupled to the connector (160).

12. A method as claimed in claim 11 , wherein the first device (120) is a USB device (120), the third device (200) is a USB host, and the common bus (150) is a USB bus (150).

13. A method as claimed in claim 12, comprising employing a sub-set of the USB standard protocol to provide a tunnel protocol for communicating between the first device (120) and the second device (130) over the USB bus (150).

14. A method as claimed in claim 13 , wherein the subset of the USB standard protocol comprises at least part of the USB Bulk Transfer protocol.

15. A method as claimed in any one of claims 11 to 14, comprising detecting whether the third device (200) is coupled to the electronic apparatus (100) by means of the connector (160), and enabling communication between the first device (120) and the second device (130) only if the third device (200) is not coupled to the electronic apparatus (100) and enabling communication between the first device (120) and the third device (200) otherwise.

16. A method as claimed in any one of claims 10 to 15, comprising transmitting a poll signal (IN; IN1 ; IN2; IN3) from the second device (130) to the first device (120), and, in response to receiving the poll signal at the first device (120), transmitting data from the first device (120) to the second device (130).

17. A method as claimed in any one of claims 10 to 16, comprising transmitting serial data (D+, D-) over the hardwired coupling (160) .

18. A method as claimed in any one of claims 10 to 16, comprising transmitting parallel data (UTMI) over the hardwired coupling (160).

19. A method as claimed in any one of claims 10 to 18, comprising coupling the third device (200) to the common bus (150) by means of the second device (130).

20. A method as claimed in any one of claims 10 to 19, comprising employing a wireless device (140) coupled to the second device (130) for wireless communication with a wireless device external to the electronic apparatus (100).