How to apply USB to the embedded field? How to realize USB point-to-point communication?

USBOn-The-Go expands the application field of USB, extending USB from the traditional PC and peripheral communication mode to the mobile electronics and embedded fields, leaving the host PC aside, and realizing the usual peripherals and peripherals. Point-to-point (PointtoPoint) data transmission mode.

1 What is USBOn-The-Go

Let us first review the history of the development of Universal Serial Bus (UniversalSerialBus, referred to as USB):

i) In November 1994, 7 companies headed by Intel (Intel, Compaq, Microsoft, IBM, DEC, Northern Telecom, and NEC) introduced the first draft of the USB protocol. USB, as a new type of serial bus, revealed A new round of USB bus revolution has been opened, but at this time, USB is not well known to computer technicians;

ii) In February 1996, the USB protocol specification version 1.0 was released. The copyright belongs to 4 companies including Compaq, Intel, Microsoft and NEC, and it is agreed that anyone can use it for free. Since then, USB has gradually been recognized by the majority of technicians and users, and has gradually become a standard interface on PC motherboards;

iii) In October 1998, the USB1.1 version was released, which concentratedly revised the problems in USB1.0 and further highlighted the advantages of USB. Up to now, USB1.1 is still the standard version for developing USB low-speed (1.5Mbps, Low-Speed) and full-speed (12Mbps, Full-Speed) devices. The advantages of USB, such as low power consumption, high speed, low cost, support for plug and play, and convenient maintenance, are more stable. USB has begun to become almost all kinds of PCs such as mice, keyboards, joysticks, printers, optical drives, hard disks, monitors, and digital cameras. One of the standard protocols for connecting peripherals and PCs. Various USB peripheral products have sprung up, such as USBFlash card readers, USB mobile hard drives, USB digital cameras, USB keyboards, etc. Almost all PC peripherals have corresponding USB interface products. For a time, USB became the most popular PC interface standard, and embedded software and hardware engineers also applied USB to their designs;

iv) In April 2000, 7 companies including Compaq, HP, Intel, Lucent, Microsoft, NEC and Philips jointly released the USB2.0 protocol specification version. The biggest change in the new version is that the bus speed of USB has been increased to 480Mbps at once, that is, it has begun to support High-Speed ​​devices. As a result, USB turned a new page, completely broke the speed bottleneck of USB applications in high-speed transmission fields such as video, and greatly expanded the USB application field. From low-speed mouse and keyboard, to full-speed hard disk, to high-speed video transmission, USB is almost omnipotent and can be applied to any kind of PC peripherals. It is only a matter of time before USB replaces traditional PC interfaces such as serial ports and parallel ports.

From the advent to the 2.0 version of the protocol specification, USB continues to improve itself and mature. From ordinary computer users, computer engineers, to hardware chip manufacturers, all have fully recognized USB. Manufacturers are becoming more and more complete with USB hardware and software support. Now the cost and time required to develop a USB peripheral product have been greatly reduced. There was no way to do this a few years ago. However, with the gradual expansion of the USB application field, people’s expectations for USB are also getting higher and higher. It is hoped that USB can be used in various computer fields, especially in the field of mobile communications. It is hoped that it can be directly used by mobile devices such as PDAs. Communication with USB peripherals enables USB to be used in areas where there is no PC. Non-PC application field? This is a fatal weakness of USB. The core position in the USB topology is the Host. Any USB data transmission must be initiated and controlled by the Host. All USB peripherals can only be connected to the Host, between any two peripherals or between two There is no direct communication between Hosts. At present, a large number of people who play the role of Host are

People computer PC. Therefore, "how to apply USB to the embedded field? How to realize USB point-to-point communication?" and other issues, began to enter the discussion agenda of USB developers. It is under this new demand that USBOn-The-Go came into being. In December 2001, USBOn-The-Go version protocol 1.0 was officially released (abbreviated as OTG1.0).

USBOn-The-Go, as the name suggests, is a USB application in the field of portable mobile devices. Therefore, we tentatively translate it as "portable USB" (or "mobile USB"), abbreviated as USBOTG. As a supplementary protocol of USB2.0, OTG1.0 basically conforms to the USB2.0 specification. However, the difference is that the USBOTG-compliant device completely ignores the PC, and can be used as a Host or as a peripheral device, and directly realizes Point-to-Point (PeartoPear) communication with another OTG device. Therefore, this type of OTG device is also called a dual-role device (Dual-Role Device, referred to as DRD), and can automatically switch to a host or a peripheral device according to the characteristics of the access device and the situation during data transmission. For example, an OTG digital camera can be directly connected to an OTG printer to print pictures; two OTGMP3 players can be connected together to realize the sharing of music files. It should be noted that the USBOTG device retains the function as a normal USB2.0 peripheral device and can be directly connected to the PCHost as a peripheral device.

2 Function of USBOTG device

USBOTG defines two device types: dual-role device DRD and single external device (Peripheral-Only Device, referred to as POD for short). DRD has two functions of Host and peripherals. POD is basically similar to peripheral functions. Therefore, we focus on DRD here.

To become a USBHost, it must have the ability to store peripheral drivers, provide sufficient USB port current and A-type Host socket. And the basic function to be realized includes 3 parts:

i) Management and control of the bus, including providing USB port power management;

ii) Detect the access and disconnection of peripherals, and enumerate (Enumerate) devices;

iii) Initialize all data packet transmission and other activities on the bus.

Similarly, USB peripherals also have specific functions:

i) In response to USBHost's commands, perform activities such as sending device descriptors and transferring data initiated by Host;

ii) Remotely wake up the host in the Suspend state;

iii) Provide self-powered (Self-Powered) power supply (select this option if the required current is greater than the limit that the bus can provide).

DRD has dual functions of USBHost and peripherals. However, because it has dual roles and tasks, DRD must have new tasks and functions such as switching roles. Therefore, we can use formula (1) to simply define the functions of OTGDRD :

DRD=Host+Peripheral+OtherLL(1)

It can be seen from the formula (1) that a complete USBOTGDRD must also have some functions besides the usual Host and peripherals. Of course, the Host function of DRD is limited, and it is not required to fully realize the function of PCHost. However, this is in line with the embedded function. The requirements for flexibility and portability of USB in the field:

i) As a peripheral, it supports 12Mbps full-speed mode (or 480Mbps high-speed mode);

ii) As a Host, it also supports full-speed mode (or low-speed and high-speed mode);

iii) Generate a list of target peripherals (TargetedPeripheralList, abbreviated as TPL);

iv) Session Request Protocol (SessionRequestProtocol, abbreviated as SRP);

v) Host Communication Protocol (HostNegotiationProtocol, abbreviated as HNP);

vi) There is only one Mini-AB socket;

vii) Provide at least 8mA for the bus;

viii) The device user can be notified of the bus activity status in time.

3USBOTG system software description

3.1OTG configuration descriptor

When the OTG system is in the enumeration process, the A device will send the GetDescriptor command to the B device (the device that is in the peripheral state at the beginning), and the B device will be required to send the OTG configuration descriptor. The configuration descriptor includes 3 bytes, which are bLength, bDescriptorType, and bmAttributes.

3.2 Session Request Protocol (SessionRequestProtocol, abbreviated as SRP)

SRP is used by device B to request device A to establish a session and use the bus.

Generally, the A devices in the OTG system are powered by batteries, because these devices are portable and movable, which determines that the power management of the OTG system is a very important topic. Therefore, in order to save the power consumption of the OTG system, OTG2.0 stipulates that the A device can turn off the power on the VBus when there is no bus activity. In this way, when a B device is connected to the A device, it must initialize the SRP and send it to the A device, requesting the A device to provide current support on the VBus, and then communicate. In OTG, DRD can be used as A device or B device. Therefore, DRD must support initializing SRP and responding to SRP; POD can only be used as B device, so it can only initialize SRP. In SRP, there are two ways for device B to send a request to device A to establish SRP: one is Data-Line Pulse (Data-Line Pulsing) and the other is VBus Pulse (VBusPulsing). The specific pulse method is described in detail in OTG2.0. Any A device only needs to be able to respond to one SRP mode, while the B device must be able to initialize two SRP modes. In this way, when the B device initializes one SRP first, and the A device cannot respond, the B device will use another SRP method.

3.3 Host Negotiation Protocol (HostNegotiationProtocol, abbreviated as HNP)

HNP is used to switch the Host role between the initial B device and the initial A device.

OTGDRD has MiniAB type socket, therefore, DRD can be used as Host or peripheral. In a certain OTG connection, whether the DRD is used as a Host (ie A device) or a peripheral (ie B device) depends on the other OTG device connected. If the access is OTGPOD, then there is no doubt that this DRD must be used as an A device. However, if it is connected to another DRD, then between the two DRDs, HNP can be used to switch the Host role at any time.

A complete HNP process is as follows: Device B wants to control the bus and become a Host; after device A sends the SetFeature command, device B can request control of the bus; device A suspends the bus and informs device B that it can control the bus; B The device sends a signal and disconnects from the A device; the A device starts the pull-up resistor on the D+ signal line and sets D+ high; in this way, the A device starts to act as a peripheral, giving up control of the bus, and the B device becomes Host; After the B device completes the control of the bus, it needs to pull up the D+ resistance on it to give up the bus control. Of course, this series of HNP activities are not only realized by level changes on the signal line. The level change is just a sign, and the real change of the internal control of the bus must be realized through software.

3.4 The software structure of OTG

The software structure of OTG includes 3 parts:

i) OTG system hardware driver: including SRP and HNP;

ii) OTG system peripheral software: implement standard USB classes to achieve specific USB peripheral functions;

iii) OTG system Host software: including Host driver, operating system support software, and class library supporting peripherals.