Abstract: This paper describes a design that utilizes a USB host controller to control a USB flash drive as a mobile storage device in a data acquisition system. Based on the CH375S USB host/slave controller chip, this design adheres to the BulkOnly and UFI sub-specifications of the Mass Storage Device (MSD) specification, supports the FAT16 file system, and enables data storage via USB flash drive in the data acquisition system, facilitating interaction with a computer. Combined with an LCD and external keyboard, it allows for real-time display of acquired data and viewing of data within a specified storage area, completely eliminating the need for a PC. Keywords: CH375S, USB-Host, Data Acquisition System, Mass Storage Class, FAT16 File System Introduction With the increasing expansion of the mobile data storage field, the need to implement USB host functionality in embedded systems to enable data storage using USB storage devices has become increasingly urgent. USB flash drives, as a new type of mobile storage device, are favored for their small size, high speed, shock resistance, and versatility. Therefore, developing an embedded USB host to control a USB flash drive as a data storage device in a data acquisition system has significant practical value and application prospects. 1 USB Mass Storage Device Protocol Analysis The design of a USB-based mass storage device data acquisition system mainly focuses on implementing an embedded USB host. To design an embedded USBHost that can directly read and write USB flash drives, it is necessary to understand the USB mass storage device protocol. The current software structure of USB mass storage devices is shown in Figure 1. In Figure 1, the part to the left of the dashed line is the host driver structure, which is also what the embedded USBHost needs to implement. The top layer on the left is the FAT file system layer API, which is used to provide users with methods to access storage devices. The data in the USB flash drive is stored in file format. FAT16 is widely used in mobile storage devices because of its high compatibility. Here is a brief analysis of the FAT16 file system structure and the organization principle of storage space. (1) FAT16 file system structure The FAT format disk can be roughly divided into 5 parts: MBR area, DBR area, FAT area, FDT area and DATA area. MBR area: also known as the master boot record, followed by a 64-byte DPT (Disk Partition Table). Since it is not necessary to boot from the USB flash drive and the USB flash drive has only one partition, there is no data area on the USB flash drive. DBR area: The operating system boot record area, usually occupying sector 0 of the partition, totaling 512 bytes, consisting of jump instructions, BPB, and end marker. FAT area: Stores the file allocation table. The file allocation table is a list that corresponds one-to-one with the cluster number of the data area, reflecting the usage of all clusters. The size of each table entry unit determines the type of FAT, for example, the table entry unit of FAT16 is 16 bits. FAT tables usually have a backup. FDT area: Stores the file directory table, located after the backup FAT table. The FDT is linearly composed of 32-bit directory entries, recording the starting unit, attributes, etc. of each file (subdirectory) under the root directory. The FDT size is 32 sectors, and can store up to 512 directory entries. DATA area: The actual data storage location, located after the FDT, occupying most of the data space on the hard disk. (2) FAT16 storage space organization principle When the disk space is formatted as a FAT partition, the FAT file system plans this partition as a whole allocatable area for data storage. FAT divides disk space into units of a certain number of sectors, called clusters. Typically, the principle of 512 bytes per sector remains constant. The cluster size is generally 2^n (n is an integer) sectors (the maximum storage space per cluster is 32 KB). Logical Block Addressing (LBA) is generally used. The UFI/ATA driver layer, located in the middle left of the dashed line in Figure 1, translates application access into UFI or ATA command/data formats, exchanging commands/status/data with external storage devices according to the definitions of the UFI or ATA sub-specifications. The lowest layer is the USB transfer driver, responsible for sending upper-layer UFI/ATA data to the USB bus and receiving status/data returned from storage devices. CBI/BulkOnly/ATA/UFI are abbreviations for four independent sub-specifications in the USB Mass Storage class specification. The first two sub-specifications define the methods for transmitting data/commands/status over USB. The BulkOnly transmission specification uses only the Bulk endpoint to transmit data/commands/status, while the CBI transmission specification uses three types of endpoints—Control/Bulk/Interrupt—for data/command/status transmission. The latter two sub-specifications define the operation commands for the storage medium. The ATA command specification is for hard drives, and the UFI command specification is designed for USB mobile storage. 2 Embedded USB-Host Design 2.1 Hardware Design The system uses the STC89C516RD+ microcontroller with an enhanced 8051 core as the central processing chip, and the CH375S from Nanjing Qinheng Electronics Co., Ltd. as the USB host control chip. The STC89C516RD+ has 64 KB of Flash program memory and 1280 bytes of RAM (256 bytes of internal RAM and 1 KB of external RAM), supporting in-system/in-application programmability (ISP, IAP); the CH375S is a general-purpose interface chip for the USB bus that conforms to the USB 1.1 protocol specification, supporting both USB Host mode and USB Device/Slave mode. The CH375S features an 8-bit data bus, read, write, chip select control lines, and interrupt outputs. Therefore, when used as a full-speed USB host interface, only a crystal oscillator and capacitors are needed for external components, allowing for easy connection to the system bus of microcontrollers/DSPs/MCUs/MPUs. Considering that reading/writing USB flash drives or external hard drives is generally done in sector mode, a disk data buffer and a file data buffer (both multiples of 512 bytes) are added. Larger buffers result in higher execution efficiency, so 32 KB of RAM is added externally. The USB-Host circuit is shown in Figure 2. In Figure 2, the CH375S chip's RD and WR pins can be connected to the microcontroller's read strobe output pin and write strobe output pin, respectively. CS can be directly driven by the microcontroller's I/O pin. The INT output interrupt request is active low and can be connected to the microcontroller's interrupt input pin or a general I/O pin; the microcontroller can detect interrupt requests using either interrupt or polling methods. Here, interrupt method is used, employing the microcontroller's INT0 pin. When WR is high and CS, RD, and A0 are all low, data in the CH375S is output through D7-D0; when RD is high and CS, WR, and A0 are all low, data on D7-D0 is written into the CH375S chip; when RD is high and CS and WR are low while A0 is high, data on D7-D0 is written as a command code into the CH375S chip. 2.2 Software Design The CH375S is not only a general-purpose USB Host hardware interface chip, but also has a built-in protocol processor for control transmission and dedicated communication protocol firmware for handling MassStorage devices. It supports Bulk-Only transmission protocols and USB storage devices with SCSI, UFI, RBC, or equivalent command sets, simplifying common control transmissions. Referring to Figure 1, the microcontroller program mainly constructs the FAT file system. Designing a file system involves selecting one or more data organization methods on a specified storage medium, implementing several commonly used file API functions, and ultimately achieving data access by name. Read 512 bytes from the starting sector position of the first partition data structure, which is the DBR, including a bootloader and a BPB parameter block. The BPB parameter block records important parameters such as the starting sector, ending sector, file storage format, media descriptor, number of root directory entries, number of FATs, number of reserved sectors, and allocation unit size of this partition. The location of the FAT table (partition starting sector number + number of reserved sectors) can be determined based on the number of reserved sectors. The location of the FDT can be calculated based on the number of FATs and the number of sectors occupied by each FAT table (FAT table location + number of FATs × number of sectors occupied by each FAT). The FDT stores directory entries, and the first cluster number of the file in the directory entry is the entry point for reading/writing files. Based on the above analysis, the following file operations can be designed: ① Create a file. Allocate a new directory entry in the FDT. ② Write a file. When writing a new file, search for an unused cluster in the FAT table and write the cluster number to the starting cluster number position in the corresponding directory data structure of the file. When the file length exceeds one cluster, the cluster number of the next available cluster must be entered into the corresponding starting cluster number position in the FAT table, until the last cluster of the file (FFFF is entered in the corresponding position in the FAT table). If there is a backup FAT on the disk, the correct content must be entered into the corresponding position in the backup FAT table. ③ Delete the file. In addition to setting the corresponding directory entry in the FDT to the appropriate flag, the FAT table and the backup FAT table must also be modified. Clear the cluster number position used by this file to 0, indicating that this cluster is currently not in use. Since subdirectories are treated as special files in FAT16, operations on them are similar to file operations, so they will not be described in detail. The constructed FAT16 file system provides users with file-level API functions, such as CH375_Create_File(), CH375_Write_File(), and CH375_Delete_File(). When executing a file-level API function, intermediate functions such as Seck_Empty_Cluster() to find an empty cluster, Link_Cluster_List() to establish a cluster chain, and Seck_Sector() to locate the file pointer are called. These intermediate functions then call commands specific to the CH375S mass storage device class, such as SET_USB_MODE, DISK_READ, and DISK_WRITE. The following example demonstrates the workflow of creating ADC.TXT and writing A/D sampling data into it, as shown in Figure 3. When storing files using the FAT16 file system, the smallest unit is a cluster. Even a very small file will occupy a cluster. Therefore, to save storage space, the creation of a file with the same name and writing data into it is transformed into appending data to the original file in Figure 3. 3. Design of a High-Capacity Data Acquisition System A high-capacity data acquisition system was built using a pre-designed embedded USB Host. The system block diagram is shown in Figure 4. The temperature sensor used is the DS18B20. It is a single-bus digital temperature sensor with a measurement range of -55 to +125℃, programmable 9-12 bit A/D conversion accuracy, and a temperature resolution of up to 0.0625℃. The LCD uses the TM320240ECCW, a 320×240 dot matrix LCD. The display control chip is SED1335, which can display the measured temperature data in text mode or in curve mode using a custom planar coordinate system. A 4×5 keypad is added for setting the acquisition time interval and duration; the system's allowed high and low temperature tolerances; setting the acquisition time; and inputting the storage area for the data to be viewed. The keypad is managed by an 8279 chip to reduce the burden on the microcontroller. Because the microcontroller already consumes time processing temperature acquisition and displaying the data on the LCD, coupled with the timed and untimed reading/writing of the USB drive, the load is already heavy. Therefore, keyboard scanning and processing are handled by the 8279 microcontroller. The microcontroller uses a polling method to query the 8279's interrupts. The driver programs include the LCD driver, DS18B20 driver, and 8279 driver. The main task is writing the LCD driver program. The LCD driver includes subroutines for initializing the LCD, reading and writing parameters, writing commands, establishing coordinates, drawing points, and writing Chinese characters. The LCD displays prompts during system initialization and USB drive initialization and enumeration. During the acquisition process, it displays temperature data in curve mode. Conclusion The USBHost interface implemented based on the CH375S has a hardware structure that is easy to expand on other development platforms. Its core file layer protocol stack is written in standard C language, exhibiting good portability. Similar USB-based high-capacity data acquisition solutions have been used in light rail and paperless recorder data storage systems. With the advent of the USB OTG era, USB-based high-capacity data acquisition will have a very broad application prospect.