Design of embedded system for reading and writing USB disk based on USB HOST technology
[Copy link]
This article takes USB HOST technology as the core and introduces the implementation of USB HOST technology on a single-chip microcomputer. It focuses on the application of USB HOST technology in reading and writing USB flash drives in embedded systems.
1. Introduction to USB HOST Technology
The communication of USB can be represented by Figure 1. In Figure 1, the left half is the USB host end. It can be seen that the USB host end consists of two parts, namely the software body and the hardware body. In fact, three software components constitute the USB HOST solution, namely the USB client driver, the USB driver and the USB host controller driver. When the transaction processing of the application is started by the USB client driver (device driver), the client driver regards the USB device as a set of endpoints that can be accessed, which can be controlled and communicate with its functional units. The USB system software includes the USB driver and the USB host controller driver. The USB driver is responsible for configuration management, user management, bus management and data transmission management; as well as data bit encoding, packaging, cycle checking, sending, error handling, etc.
2. Implementation principle of USB HOST based on ISP1161 controller
USB controllers are roughly divided into three categories: the first category is those that support the 1.0 protocol, which is rare; the second category is those that support the 1.1 protocol; and the third category is those that support the 2.0 protocol. Depending on the occasion, the latter two are more widely used. The 2.0 interface is mainly used on computers, relying on the operating system to achieve high-speed data transmission. In addition to being used on computers, a few chips that support the 1.1 protocol are designed for implementing USB HOST in embedded systems, such as Cypress's SL811, Philips' ISP1160, ISP1161, etc.
The hardware part of the USB host is composed of a processor, a USB-HOST controller and a root hub. Figure 2 shows the circuit principle of the USB HOST implemented by the microcontroller MSP430F149 and the USB controller ISP1161. Figure 2 is divided into four parts: microprocessor, USB controller, power management module and USB interface circuit. Conceptually, there should also be a USB root hub (USB Hub), and the actual root hub is integrated into the USB HOST controller.
ISP1161 is a USB host/device controller designed by Philips. It has 1 USB host controller and 1 device controller inside, which complies with USB2.0 protocol and supports full-speed and low-speed transmission. The host and device controllers share the same interface bus with 2 USB downstream ports and 1 USB upstream port. In Figure 2, interface 1 is used as the HOST downstream port. Each downstream port has its own overcurrent detection circuit. In Figure 2, PHP109 is used to detect the port power supply current.
Above 500mA the bus will be powered off.
The data transmission between MSP430 and ISP1161 can be carried out through PIO (Programmed Input Output) or DMA (Direct Memory Access). Before ISP1161 enters the working state, a series of initializations must be performed, including detectors, reset controllers, initialization of hardware configuration, setting interrupts, setting buffer size, etc. The host controller of ISP1161 is in working state, and the data actually used to be sent to the bus is placed in the buffer inside ISP1161.
At this point, it is worth mentioning the concept of "transmission descriptor", which is the core concept of ISP1161. The data placed in the buffer is in units of transmission descriptors, and the function of the transmission descriptor is to describe the tasks that need to be completed in this transmission. The descriptor is divided into a descriptor header and a descriptor payload data. The descriptor header represents the transmission type, maximum packet width, transmission speed, transmission object, transmission endpoint, and payload data length of this descriptor. Another role of the transmission descriptor is reflected after the transmission. After each transmission is completed, the content of the transmission descriptor will change accordingly, which is reflected in the transmission descriptor header, representing the result of this transmission, including how many bytes were transmitted, what errors occurred during the transmission, etc.
3. USB host enumeration of devices
There is a path from the time a USB device is plugged into an interface until the client driver can use the device. This path is called the device identification process, also known as the enumeration process. The enumeration process is a necessary process before any USB device can be used. The USB host needs to know whether it is a low-speed device or a full-speed device, and needs to know the capabilities of the device in order to load the corresponding device driver. The following is a detailed introduction to the implementation steps.
First, capture the insertion of the device. USB devices are plug-and-play devices. The system needs to capture this information the moment the device is inserted. ISP1161 completes this task through the internal Hub. Each of the two signal lines (D+ and D-) of the Hub port has a sub-15kΩ pull-down resistor, and a device has a 1.5kΩ pull-up resistor on D+ (full-speed device) or D- (low-speed device). When a device is inserted into a port, the upper resistance signal of the device is high. The Hub detects that a device has been connected and reports it to the host controller, and then generates an interrupt on the interface with the processor. After the host knows this, it can learn more information such as device speed by reading the Hub-related registers.
Then, the Hub resets the device. When the host knows there is a new device, the host writes commands to the Hub's related registers to let the Hub reset the port. The Hub puts the device's USB data line in the restart state (both D+ and D- are logic low) for at least 10ms. When the Hub releases the restart state, the device is in the default state (both D+ and D- are logic low) for at least 10ms. When the Hub releases the restart state, the device is in the default state (the device's USB registers are already in their default states). At this point, the device is ready to respond to the control flow through the default flow of Endpoint 0.
Finally, the host completes the enumeration of the device by controlling the transmission channel. The host first sends a Get_Descriptor request to know the default process maximum packet size. The host sends a request to the device address 0, endpoint 0. Then a single address is assigned to the device by sending a Set_Address request. The device reads this request, returns a confirmation and saves the new address. Knowing the capabilities of the device, the host sends a Get_Descriptor request to the new address to read the complete descriptor of the device, including the maximum packet size of Endpoint 0, the configuration number supported by the device, and other information about the device. The host uses this information for future communications. Then a (Set_configuration) configuration request is issued to configure the device with the configuration number. The device is completely and correctly in an operational state. The host can now load the corresponding client driver and operate the device.
4. Data transmission between storage devices and hosts
The following will introduce the application of USB HOST by taking the embedded system reading and writing USB flash disk as an example. First, the data transmission between the storage device and the host will be introduced.
In addition to the control transmission mentioned above, there are three other transmission modes: isochronous transmission, interrupt transmission, and bulk transmission. The host will decide which transmission mode to use based on the characteristics of the device. The transmission mode between the USB storage device and the USB host is bulk transmission. In order to explain the problem in more detail, let's first briefly explain the BULK-ONLY transmission protocol.
The transmission method used by USB storage devices is batch transmission. First, it is not limited by time; second, it can ensure the integrity of data. In this transmission mode, there are three types of data transmitted between USB and devices, CBW, CSW and ordinary data. Figure 3 describes the order of data transmission on the host side. CBW (command block packet) is a command sent from the USB host to the device. The USB device needs to extract the command from the CBW and perform the corresponding operation. After completion, a response is sent to the HOST side, that is, the CSW (command status packet) of the current command execution status. The host decides whether to continue to send the next CBW or data based on the CSW.
From Figure 3, we can see that the data segment is divided into two parts, one is data out, which means the host sends data to the device; the other is data in, which means the host gets data from the device. The typical example is reading data from the storage device and writing data to the device. The following describes how to implement this process in an embedded system based on ISP1161.
The host sends a CBW, which is the payload data of the transfer descriptor and is transmitted to the device. The CBW packet also consists of two parts, the packet header and the command block. The packet header represents the logical unit of data transmission and the length of the command block; the command block is the command that actually needs to be implemented. Depending on the device, the command cluster used by the command block is also different, which can be basically divided into two categories, one is the UFI instruction set, and the other uses the SCSI instruction set.
In the normal data phase, the data will occupy the entire payload data length of the transfer descriptor, and the data to be sent must be loaded into the buffer before sending. When reading, the data will be automatically placed in the payload data part after the transfer descriptor is executed.
The CSW stage reflects the completion status of the command, including the CSW flag, the length of data to be transmitted, the correct return flag, etc.
5. MCU reads and writes storage devices
Reading and writing USB storage devices requires a certain understanding of the storage format. Currently, most USB storage media are in FAT16 and FAT32 formats, and a very small number use FAT12 format. FAT16 is more common in USB flash drives, while FAT32 is more common in mobile hard drives. Here is a brief introduction to a file format commonly used by USB flash drives: FAT16. For a USB flash drive with only one partition in FAT16 format, its structure is, in order, the master boot area (BOOT SECTOR), hidden sector, logical disk boot area (BOOT SECTOR), FAT area, root directory area, and data area.
The master boot sector consists of three parts: MBR (Master Boot Record), DPT (Disk Partition Table) and Boot Record ID. MBR is also called the master boot record area, which stores the system master boot program; DPT is the master partition table, which records the basic partition information of the disk; Boot Record ID is the boot area mark. The Boot SECTOR of the logical partition consists of a jump instruction, a text character name of the hard disk partition type, a partition parameter block, an extended partition parameter block and a startup instruction block. FAT (File Allocation Table) records the usage of clusters. According to the directory area, the directory entries are stored. Each directory entry is 32 bytes and records the information of a file or directory (except for long file names). The data area records the file and directory data area, which is located after the last sector occupied by the directory entry. It is the location where file data or subdirectories are actually stored.
The reading and writing of files is actually the specific implementation of the USB BULK-ONLY Protocol and the file system protocol. The following takes a device with a FAT16 file system as an example to describe how to read a file named "read.txt" in the root directory and write a file named "write.txt" in the same directory.
Before reading and writing data, you need to know all the information of the storage device, including sector size, FAT table length, cluster size, etc. This information can be obtained by reading the master boot area and logical boot area.
When reading a file, it is roughly in the following order: read the root directory → read FAT1 → read the data area. The specific steps are as follows. First, find the location of the file name. The files and directories under the root directory are all in the root directory area. Each directory or file item occupies 32 bytes. Read a sector each time and compare the data. If there is no such file, continue to read the next sector until the file is found. Among these 32 bytes, the 26th to 27th bytes represent the file start cluster number, and the 28th to 31st bytes represent the file size. According to the start cluster number, search the FAT area, find the file cluster chain, read the corresponding clusters in sequence, and you can get the file data completely.
Writing "write.txt" is slightly different. It can be roughly written in this order: write FAT1→write FAT2→write root directory area→write data area. Specifically, read the FAT area first, search for available clusters, mark them as the starting cluster number of the file, continue searching, find the next available cluster, and write the cluster number at the previous available cluster mark (00 00), and continue in sequence until the cluster chain is completed, and the last cluster is marked as the end cluster of the file. It should be noted here that there are two copies of the FAT area with the same content. After writing FAT1, write the same data to the corresponding position of FAT2. The next step is to write the file name. Search for available root directory items in the root target area, and write the file name, time, starting sector, file size, etc. into the directory item. At this time, there is already a file named "write.txt" on the USB flash drive, but the inside of the file has not been written yet. The next step is to write the content of the file to the corresponding cluster in the cluster chain according to the starting cluster number of the file. At this point, the writing of the entire file is complete.
6. Summary
The functions that a USB HOST needs to complete are different due to different requirements, and the protocols used are also different. Some use interrupt transmission, and some use synchronous transmission. The application of USB host technology on microcontrollers is mainly for a certain USB device or several devices, so only certain protocols can be solidified on the microcontroller. The application of this technology can make it easy to connect USB peripherals to small instruments, expand the functions of the system, and improve the flexibility of instrument use. The application of USB host technology on microcontrollers will have a broader and better prospect.
|