KR101005397B1 - Bus connection system - Google Patents

Abstract

The bus station, in the form of a hardware dongle, works in combination with a USB device running the appropriate software. If the bus station determines that the bus host is connected to its first bus communication port, it acts as a transceiver to enable existing bus communication between this bus host and the bus device connected to the second bus communication port. If the bus station determines that a bus device that drives the appropriate software is connected to its first bus communication port, it acts as another host to connect the first bus device and the second bus communication port connected to the first bus communication port. Enable bus communication between connected bus devices.

Description

Bus station and bus communication system {BUS CONNECTION SYSTEM}

The present invention relates to a bus connection system, and more particularly, to a device used with an electronic device in a bus communication system to enable the electronic device to act as a host in the system.

Universal Serial Bus (USB) communication systems are widely used.

In a USB system, items of many electronic devices such as personal computers, scanners, cordless phones, printers, and the like can be interconnected. In any system, an item on one device is always designated as the USB host, controlling access to all other items or USB devices. Personal computers are usually provided with the hardware and software necessary to enable the role of a USB host, while other items are typically not provided with the necessary hardware and software, so they can only act as USB devices.

However, there may be situations where an item of device can be used that can act as a USB host without significantly modifying the device.

According to one aspect of the invention, there is provided a bus station, preferably in the form of a hardware dongle, which is connected to the bus communication port of the bus communication device, allowing the bus communication device to act as a bus host. . Although the present invention can be applied to other bus communication systems, in a preferred embodiment of the present invention the bus station operates in a USB system.

More specifically, one aspect of the present invention provides a bus station, which determines that the bus host is connected to its first bus communication port, and that the bus is connected to this bus host and its second bus communication port. The first bus device and the second bus device connected to the first bus communication port if it is determined that the bus device acting as a transceiver to enable prescribed bus communication between the devices and also driving appropriate software is connected to the first bus communication port. It acts as another host to enable bus communication between bus devices connected to the bus communication port.

1 is a schematic block diagram of a bus communication system;

2 is a block diagram illustrating hardware and software of the system of FIG. 1;

3 is a flow diagram illustrating a method according to one aspect of the present invention.

1 is a schematic block diagram of a bus communication system according to the present invention.

The system 2 comprises a first USB device 4 with a USB port 6, a second USB device 8 and a dongle 10.

In the embodiment shown, the first USB device 4 is a PDA, but it will be appreciated that the invention can be applied to any USB device such as a mobile communication device, a digital camera or an electronic organizer.

The second USB device 8 can be any USB device, including a printer, mouse, hard disk or modem.

The dongle 10 includes an embedded USB host / device controller 12 having a first host port H1 and a second host port H2 and a low power microcontroller device (MCU) 14.

The first host port H1 of the dongle 10 is connected to the USB port 6 of the PDA 4 as shown in FIG. When the first host port H1 of the dongle 10 is connected to the USB port 6 of the PDA 4, the PDA can efficiently perform the role of a USB host, and the second host of the dongle 10 can be used. The port H2 effectively serves as a host port of the PDA 4. Thus, the PDA 4 can control communication with any USB device connected to the second host port H2 of the dongle 10 using the USB bus 15.

Although the first host port H1 and the second post port H2 are shown to be connected to the same USB host / device controller 12, the MCU 14 is connected to the first host via an independent USB host / device controller. It will be appreciated that it can communicate with port H1 and second host port H2, where the first host port is dedicated to communication with PDA 4 and the second host port is connected to a USB device or device 8. It will be understood that the communication is with only.

When the PDA 4 is connected to the dongle 10, the PDA 4 needs a driver update in order to be able to act as a USB host.

The driver update is specific to the particular USB device used, and serves to add a Virtual Hardware Abstraction Layer (HAL) software driver running on top of the current USB device hardware in the PDA 4.

2 is a block diagram of hardware and software of the system of FIG.

As is conventional, the USB device 4 includes an operating system 18, a host stack 20, a device stack, and device hardware 22. In order to be able to act as a USB host, the PDA 4 also drives the virtual HAL driver software 16. When the USB device 4 is driving the virtual HAL driver software 16, it is represented as a HostOnDevice.

The dongle 10 includes host hardware 12 (ie, a USB host controller), an MCU 14, and a softhost firmware 24.

The softhost protocol layer, which will be described in more detail below, controls the communication between the device 4 and the dongle 10 on the dongle connector 28.

3 is a flowchart showing the operation of the dongle 10 under the control of the MCU 14. In step 32 of FIG. 3, when the power goes up, the MCU examines the first host port H1 in step 34 to determine which connection there is. If nothing is connected, the process goes to step 36 and the process ends.

If something is connected, in step 38 the MCU measures whether the USB host is connected to the first host port H1. If the USB host is connected to the first host port H1, processing proceeds to step 40 where the dongle 10 serves as a USB transceiver. That is, it communicates directly between the first host port H1 and the second host port H2, such that any USB device (or device in which the connected USB host is connected to the second host port H2 in a conventional manner). To control communication with

If the MCU determines in step 38 that a USB device other than the USB host is connected to the first host port H1, the process proceeds to step 41 where the USB host is connected to the second host port H2. Determine if there is any. If connected, in step 42, the USB device core is operated in the USB host / device controller 12 to connect the USB device connected to the first host port H1 and the second host port H2. Enables conventional USB communication between USB hosts.

If the USB device is connected to the second host port H2, the MCU 14 counts the number of USB devices connected to the first host port in step 43 and checks if this is the device driving the virtual HAL. If the MCU determines in step 43 that the connected device 4 is not a driving virtual HAL, then in step 44 the device 4 is disabled, for example by triggering a flashing LED to connect the connected device 4 to the virtual. Signals that HAL is not supported.

If at step 42 the MCU determines that the connected device 4 is a driving virtual HAL (i.e. it has a virtual HAL driver 16), then the MCU 14 enters the operating mode at step 46 The dongle 10 (along with device 4) will be able to act as another USB host. In this mode, the dongle 10 can control communication with any USB device (or device) connected to the second host port H2, which will be described in more detail below.

In a conventional system where a personal computer is a USB host, the host stack accesses the underlying USB hardware through the host HAL. Similarly, in a conventional PDA USB device, the device stack accesses the underlying USB hardware through the device HAL.

However, in accordance with the present invention, in a software host system, if the host stack (or host station driver software 20) attempts to access the host hardware 12, it sends details of the access operation to the virtual HAL driver 16. . The virtual HAL driver 16 wraps the details of these access operations into a predetermined soft host protocol. Soft host protocol packets are transmitted through the current USB device hardware 22 when the soft host dongle 10 examines them to outstand itself.

Thus, the virtual HAL driver software 16 emulates the presence of the host controller for the host station driver software. In other words, the communication with the virtual HAL driver 16 from the viewpoint of the host stack 20 is no different from the communication with the host HAL in a conventional system. The host stack 20 will see the real host hardware through the virtual HAL driver 16.

In contrast, the virtual HAL driver software 16 emulates the presence of a device controller for the device controller (or device stack 22). Thus, the virtual HAL driver software 16 translates the communication between the host station driver software 20 and the device controller.

The soft host protocol provides the following access functions.

The ability to read registers from the dongle host hardware (12).

The ability to write registers to the dongle host hardware (12).

A function that reads the buffer memory in the dongle host hardware 12.

Write to buffer memory in dongle host hardware 12.

For example, more advanced features, such as AND / OR with certain values or rewriting the modified values into registers, can improve system performance.

The soft host protocol defines how the host stack 20 running on the virtual HAL can access the hardware of the host controller 12 using the device controller hardware. The soft host protocol is described in detail below. In this description, the term "host dongle" is used to refer to the dongle 10, where the term "host on device" refers to USB device hardware that implements the host stack 20 on the device 4, ie the virtual HAL 16. It is used to represent an embedded system with 22.

The soft host protocol begins at the end of FIG. 3, where the host dongle 10 counts the number of connected devices 4, and it is confirmed that the connected device 4 is a host on device.

In the operating mode, the MCU 14 sets up an interrupt pipe and checks the virtual HAL driver 16 for data every few milliseconds. Data transmitted between the device 4 and the dongle 10 is transmitted in the form of soft host packets via the soft host protocol. If the host stack 20 on the PDA 4 has sent a hardware access request through the virtual HAL driver 16, when the first host port H1 of the dongle 10 examines it through the interrupt pipe, the virtual HAL Driver 16 will send the request in a soft host packet.

MCU 14 will retrieve this soft host packet from the buffer memory of embedded USB host controller 12, thus performing hardware access. If there is data to be returned (read operation), MCU 14 will send the corresponding data through host 1.

traffic

The host dongle 10 and the host on device 4 communicate using a dedicated bidirectional bulk pipe. There are four types of payloads.

HRU (Host Dongle Request Unit)

Sent by host dongle 10

Bulk packet with 8 byte payload

Used to investigate host on device (4)

May contain interrupt information (HRU_IRQ)

The host dongle 10 always sends a 64-byte bulk-in after sending the HRU.

The host on device 4 will respond with NOB or CRP through this bulk in.

NOB (Not Outstanding Business)

Sent by Host On Device (4)

Bulk packet with 8 byte payload

Sent when there are no outstanding transactions

CRP (Common Request Packet)

Sent by Host On Device (4)

Bulk packet of 16-64 bytes

Contains the results of previously received CRP commands and optimal data sets

APR (as requested)

Sent by host dongle 10

Bulk packet of 16-64 bytes

Flow

As with all USB systems, the transfer begins with action by the host. In the case of a soft host protocol, the soft host dongle 10 is always the host. The soft host transmission cycle begins with the HRU as described above. The current transmission cycle must be completed before the host dongle 10 starts the next transmission cycle.

Poll-nothing cycle: HRU-NOB

The host dongle 10 examines the host on device 4 for an outstand command set. If there is no outstand command set, the host on device 4 responds with a NOB.

transaction

The host dongle 10 sends a BULK-OUT.

The host dongle 10 transmits DATA (HRU).

The host on device 4 sends an ACK.

The host dongle 10 transmits BUKL-IN.

The host on device 4 sends DATA (NOB).

The host dongle 10 sends an ACK.

Poll-something cycle: HRU-CRP-APR

The host dongle 10 examines a set of outstanding commands to the host on device 4.

The host on device 4 sends a set of outstanding commands by CRP. The host dongle 10 performs a command and returns a result by the APR.

transaction

The host dongle 10 transmits a BULK-OUT.

The host dongle 10 transmits DATA (HRU).

The host on device 4 sends an ACK.

The host dongle 10 sends a BULK-IN.

The host on device 4 transmits DATA (CRP).

The host dongle 10 sends an ACK.

The host dongle 10 transmits a BULK-OUT.

The host dongle 10 transmits DATA (ARP).

The host on device 4 sends an ACK.

Interrupt cycle: HRU_IRQ-CRP-APR

The host dongle 10 warns the host on device 4 upon outstanding hardware interrupts.

The host on device 4 determines the appropriate command set and sends it by the CRP.

The host dongle 10 performs a command and returns a result by the APR.

The host on device 4 should either remove the outstanding interrupt or disable the generation of the HRU_IRQ, or the host dongle 10 will continue to transmit the HRU_IRQ.

transaction

The host dongle 10 transmits a BULK-OUT.

The host dongle 10 transmits DATA (HRU_IRQ).

The host on device 4 sends an ACK.

The host dongle 10 sends a BULK-IN.

The host on device 4 transmits DATA (CRP).

The host dongle 10 sends an ACK.

The host dongle 10 transmits a BULK-OUT.

The host dongle 10 transmits DATA (ARP).

The host on device 4 sends an ACK.

Packet format

HRU format

The HRU contains the following information.

The current frame number

HcInterruptStatus of the host controller 12 in the host dongle 10

Interrupt status of device controller 22

NOB format

No information required specifically

CRP and APR Formats

The active bit in the header is 1 for CRP and 0 for APR.

CRP can be 16-64 bytes in size. Overall size

The number of command sets (8 bytes each)

Optional data set

The maximum number of command sets in a CRP is eight.

The maximum size of the data set is 64- (number of 8 * command sets).

Multiple command sets in a single command request packet allow access of a set of hardware to be communicated within a single packet, thus reducing delayed transmission.

Command set format

The command set is an 8 byte data structure. This includes the following information:

Command Set Header (1 byte)

Command set index (2 bytes)

Command set data (4 bytes)

Command set auxiliary (1 byte)

Thus, the virtual hardware abstraction layer (virtual HAL) provides full access to the target hardware on the dongle connected using the USB device hardware. That is, current USB device hardware is used as an asynchronous microprocessor interface bus, allowing the USB host driver to access the target hardware.

The use of a virtual HAL eliminates the need for hardware dongle to handle USB software, thereby lowering the cost of the dongle and providing the advantage that the host software can be handled by an embedded system on a USB device.

Thus, in a preferred embodiment of the present invention, a hardware dongle is provided that enables a USB device to obtain the performance of a USB host without changing the current hardware. To achieve this, the USB device runs emulation software that can be processed by the embedded system on the USB device. This provides the advantage that the dongle is inexpensive because the hardware dongle does not have to handle USB software.

The present invention has been described with reference to a system in which virtual HAL driver software enables a USB device to function as a USB host in conjunction with the dongle 10. However, similarly structured virtual HAL driver software may be used to add multiple interfaces / functions to the system using USB device capabilities. Driver software, for example, allows USB devices to communicate over Bluetooth, IrDa, USB-OTG or other communication protocols.

Claims (6)

As a bus station used in bus communication systems, A first communication port and a second communication port, When the bus station detects the presence of a host station connected to the second communication port, the bus station operates in a first operation mode. The first mode of operation transmits communication between the host station connected to the second communication port and a first device station connected to the first communication port, The bus station also operates in a second mode of operation as an alternate host station if it detects that there is no host station connected to the second communication port. The bus station communicates with the first device station connected to the first communication port in accordance with a communication protocol in the second mode of operation, instead of another device station connected to the second communication port, the bus station initiates communication And the other device station appears as a host station for the first device station and performs an operation including communication with the first device station. Bus station. The method of claim 1, The bus station operates as a USB transceiver in the first mode of operation and operates as a USB host in the second mode of operation. Bus station. The method of claim 1, The bus station further comprises transceiver circuitry, in the first mode of operation, coupled to the first and second communication ports to transmit communication between the host station and the first device station connected to the second communication port. doing Bus station. As a bus station used in bus systems, Includes a device controller connected to a communications port, The communication port acts as a device station, The bus station operates under the control of an operating system and system software including host station driver software that communicates with and communicates with the host controller, The system software emulates the presence of a host controller for the host station driver software, emulates the presence of device station driver software for the device controller, and also from the host station driver software to the device controller or from the device controller. Further comprising host emulation software to convert communications to the host station driver software. Bus station. A bus communication system comprising a first bus station comprising a first bus communication port and a second bus station, comprising: The second bus station further comprises a second bus communication port, The second bus station operates in a first operation mode when detecting the presence of a host station connected to the second bus communication port, and when detecting that no host station connected to the second bus communication port exists, Operating in the operating mode, A device controller is connected to the second bus communication port, The device controller operates under the control of an operating system and system software including host station driver software that communicates with and communicates with the host controller, The system software emulates the presence of a host controller for the host station driver software, emulates the presence of device station driver software for the device controller, and also from the host station driver software to the device controller or from the device controller. Further comprising host emulation software to convert communications to the host station driver software. Bus communication system. delete

Images