Application of USB bus in synchronous phasor measurement unit

　　The communication rate between the synchronous phasor measurement unit (PMU) measurement device and the host computer is generally low, and the measurement data cannot be transmitted to the host computer in time for analysis and processing. The communication interface has become a bottleneck for improving the performance of the entire system. Therefore, it is necessary to use a universal interface that can meet the transmission rate, delay, and stability of synchronous phasor measurement data transmission.

　　These problems can be solved by using the USB interface as the communication interface between the upper computer and the lower computer. The USB interface has the characteristics of high interrupt transmission rate, low delay and extremely low error rate to complete the transmission of real-time phasor data. In the actual application of the USB interface, the development of the driver is the most difficult part. Since the USB interface was born relatively late, it has not yet become a standard device for most single-chip microcomputers. It also needs to use a special interface chip for connection. The user must write the corresponding driver to convert the data into a format that conforms to the USB system protocol for transmission.

　　This article describes the process of using the PDIUSBD12 interface chip to complete USB interface data communication using the ATMAGE128 microcontroller. The operation of related hardware devices is completed through the driver. The driver completes the interrupt transmission function of the USB interface. Users can use the USB interface chip like a normal memory by calling general commands. The interface realizes the low-latency upload function of each sampling point, and can complete the transmission of all sampling values ​​of a power frequency cycle within 1ms.

　　2 Introduction to USB system and its device selection

　　2.1 USB System Overview

　　USB (Universal Serial Bus) is a universal serial bus. In order to achieve bus consistency in the entire computer system, it is a new, fast, bidirectional, synchronous and hot-swappable data transmission bus jointly developed by COMPAQ/INTEL/MICRSOFT and NEC and other companies. It is referred to as USB bus. The USB bus consists of the following four main parts: ① Host and device: refers to the main components in the USB system. ② Physical composition: refers to the connection method of USB components. ③ Logical composition: the roles and responsibilities of different USB components, and the structure of the USB bus from the perspective of the host and device. ④ The relationship between the client software and the device function interface.

　　The USB bus has four data transmission modes: ① Control transmission: mainly used for the host to send commands to the device and the device to return the status to the host. ② Interrupt transmission: used to support devices that occasionally need a small amount of data communication but have limited service time. ③ Batch transmission: used to transmit large amounts of data on devices without cycles and transmission rates. The batch transmission method cannot guarantee the transmission rate, but it can guarantee the reliability of the transmission. When an error occurs, the sender will be required to resend. ④ Synchronous transmission: Transmit at a constant rate. The sender and receiver of the synchronous transmission method must ensure that the transmission rate matches, otherwise data loss will occur.

　　2.2 Introduction and Application of USB Devices

　　There are two main methods to achieve USB transmission: using interface conversion chips and dedicated interface chips. The former converts the USB interface into a standard RS232 interface, which is exactly the same as the RS232 interface in terms of operation mode and transmission speed. The latter can achieve true USB transmission. Using USB1.1 standard interface chips such as PDIUSBD12 can achieve a maximum transmission rate of 12Mb/s, and using USB2.0 standard interface chips such as ISP1581 can achieve a transmission rate of 480Mb/s. If you want to use a dedicated USB interface chip, you must write the corresponding lower and upper computer drivers. Since USB transmission is different from serial port transmission, the USB transmission method is completed through data packets specified by the protocol, so the lower computer software must implement the hardware management function of the interface device and respond to various requests issued by the protocol. The upper computer driver needs to complete the enumeration of the interface chip, address allocation, etc.

　　2.3 The role of USB interface in this system

　　The USB interface is used in this system to complete the communication between the lower computer and the upper computer. Specifically, it connects the AVR microcontroller and the PC, and transmits the data collected by the lower computer and some related information to the PC for processing. The transmitted data includes: ① Voltage value (64 points sampled per cycle, 12-bit data). ② Current value (64 points sampled per cycle, 12-bit data). ③ Synchronous time signal (taken from GPS).

　　After receiving this information, the host computer will process it by tracing points, recording faults, and remote transmission. The 12-bit voltage and current data must be converted into 16-bit data, occupying one byte. The data transmitted per channel in 1 second is more than 6KB. For multiple channels combined, the transmission rate of the interface must be at least 40KB/s, which exceeds the transmission rate that the RS232 interface can provide. If the CAN bus is used for transmission, the hardware equipment is more complicated. After comprehensive comparison, it is a more appropriate choice to use PDIUSBD12 as an interface chip for data transmission. The PDIUSBD12 with a very small plastic package can be easily placed on the circuit board. Moreover, the requirements for the host computer are relatively loose. As long as the computer has a USB interface, it can be used as the host computer of this system.

　　3 ATMAGE128 MCU

　　3.1 Introduction to ATMAGE128 MCU

　　The ATMAGE128 microcontroller is a high-performance, low-power 8-bit microcontroller produced by ATMEL, with a maximum clock frequency of 16MHz. It integrates 128KB of flash memory as program memory, 4KB of EEPROM, and 4KB of on-chip memory, and can support up to 64KB of off-chip memory.

　　3.2 Brief description of the development process

　　The development of TMAGE128 is usually completed by the free simulation tool avrstudio provided by ATMEL. It is slightly different from the commonly used 51 single-chip microcomputer. When using C language for development, the source code must be compiled with a third-party compiler before it can be run in the simulation environment. This time, icc is used as the compiler, and all the single-chip microcomputer programs in this article are run and debugged in this environment. The USB interface device uses bus control, and the data transmission form uses interrupt transmission. The USB interface device is the same as an ordinary external memory in use. All control and data transmission must be completed by reading and writing the corresponding registers in ATMAGE128.

　　4 USB driver MCU part

　　MCU is the device controller, which can be any type of single-chip microcomputer or PC. Their drivers are similar in structure, but the specific codes are quite different due to the different system environments used. The following is a detailed description of the USB driver structure and specific implementation code using the ATMAGE128 single-chip microcomputer as the device controller. [page]

　　4.1 Overall structure of the program

　　For the CPU, the PDIUSBD12 chip is exactly the same as an external memory. The CPU operates PDIUSBD12 through bus control. The transmission of the USB interface does not occupy many CPU resources. The CPU can perform foreground operations, while the USB interface transmission work is completed in the background. The two are connected through the interrupt service program. When PDIUSBD12 receives a data packet from the USB, it generates an interrupt request to the CPU, and the CPU responds to the interrupt immediately. In the ISR, the firmware moves the data packet from the internal buffer of PDIUSBD12 to the circular data buffer, and then clears the internal buffer of PDIUSBD12 to enable the reception of new data packets. The CPU can continue its current foreground task until it is completed, and then return to the main loop to check whether there is new data in the circular buffer, and start other foreground tasks. Whether uploading or downloading data, the data in the circular buffer is processed. The main loop only needs to check whether there is new data to be processed in the circular buffer. The overall structure diagram of the program is shown in Figure 1.

　　The division of labor of each module is as follows:

　　(1) Hardware abstraction layer: operates the MCU's I/O port, data bus and other hardware interfaces.

　　(2) PDIUSBD12 command interface: a set of module subroutines for operating the PDIUSBD12 device.

　　(3) Interrupt service routine: When PDIUSBD12 sends an interrupt request to the microcontroller, read the data transmitted by the interrupt of PDIUSBD12 and perform relevant processing.

　　(4) Standard request handler: processes USB standard device requests.

　　(5) Manufacturer request handler: processes manufacturer requests added by users.

　　(6) Main loop program: sending USB requests, processing USB bus events and user function processing, etc.

　　Figure 1 USB driver MCU overall structure diagram

　　4.2 Hardware Abstraction Layer Related Programs

　　The hardware abstraction layer performs operations on the microcontroller I/O port, data bus, etc., including subroutines for sending data or commands to PDIUSBD12 and subroutines for reading data from PDIUSBD12. This part of the code requires direct operations on the address bus and data bus. Any operation of PDIUSBD12 is completed by a combination of command instructions and data instructions. The switching of command mode/data mode can be completed by changing the level of the A0 pin.

　　4.3 Command Interface

　　This part is composed of a series of command interface subroutines, which include all the commands for accessing the functional interface given by PDIUSBD12. The subroutines in the hardware abstraction layer are called in the command interface. All functions of PDIUSBD12 must be completed by a similar method, first sending a command and then writing the specific parameters of the command. Some command parameters are multiple bytes, such as the command to set the mode. In this case, the instruction to write the data line must be called twice. The writing format of the command interface program is relatively fixed, and it can be written in sequence according to the command summary table given in the PDIUSBD12 manual.

　　4.4 Interrupt Service Routine

　　The interrupt service routine code handles the interrupt generated by PDIUSBD12. It takes the data out of the buffer inside PDIUSBD12, sets up the correct flag, and notifies the main loop to process. When PDIUSBD12 sends an interrupt request to the microcontroller, the microcontroller calls the standard command interface subroutine d12_readinterruptregister() to read the interrupt register to determine the interrupt source, and then jumps to the corresponding interrupt service subroutine for processing. The interrupt service routine collects data from PDIUSBD12, and the main loop program processes the data. When the interrupt service routine collects enough data, it notifies the main program that it is ready to be processed. For example, when setting up a packet in the data packet sending stage, the interrupt service routine stores both the setup packet and the data in the buffer, and then sends the setup_packet flag to the main loop, so that the main loop can save unnecessary service time.

　　4.5 Bus Reset and Suspend

　　When a bus reset or suspend request is received, the interrupt service routine sets the bus_set or suspends flag and then exits.

　　A control transfer always begins with a setup phase, followed by an optional data phase, and ends with a status phase. The microcontroller needs to determine whether the endpoint is full or empty by selecting the control output endpoint to extract the contents of the setup packet. If the control endpoint is full, the microcontroller will read the contents from the buffer and store them in memory. The microcontroller will then validate the master request from memory. If it is a valid request, the microcontroller needs to send an acknowledge setup command to the control endpoint to re-enable the next setup phase. Next, the microcontroller needs to confirm whether the transfer is a control read or write, which can be achieved by redirecting the request type bit of the setup packet.

　　After the establishment phase is completed, the host will execute the data phase. PDIUSBD12 waits to receive the control input packet. The microcontroller first needs to read the last transaction status register to clear the interrupt flag. After confirming that PDIUSBD12 is in the transmission mode, the data packet is sent.

　　When the next control input flag comes, the microcontroller will determine whether the remaining bytes are zero. If there is no data to send, the microcontroller needs to send an empty packet to indicate to the host that the data has been sent. If the packet is established for a get descriptor request, the control transfer in the establishment packet will indicate that this packet is a control write type. After executing the get descriptor request process, the microcontroller is in the waiting data stage. The host sends a control output flag, and the microcontroller subtracts data from the PDIUSBD12 buffer. At this time, the microcontroller confirms whether PDIUSBD12 is in USB receive mode, and then the microcontroller confirms whether the buffer is full by checking the selected control output endpoint and reads the data from the buffer.

　　4.6 Standard Request Handler

　　Standard device requests are determined by the USB protocol, issued by the host and transmitted to the microcontroller in the form of data packets. When the microcontroller receives these standard device requests, it will enter the corresponding processing program. The process includes: ① Get status. ② Clear characteristics. ③ Set characteristics. ④ Set address. ⑤ Get device descriptor. ⑥ Set configuration. ⑦ Get configuration information. ⑧ Get interface information. ⑨ Set interface. ⑩ Synchronous frame. The synchronous frame is used to set and report the synchronous frame of an endpoint. It is only used in synchronous transmission. If the device does not support this request, a stop sign is returned.

　　4.7 Main loop program

　　The main function of the main loop program is to set the initialization of the microcontroller and set the entry of each related subroutine. Due to the use of interrupt service routines and a series of command interface subroutines, the part of the main loop program involving the USB interface only sets the relevant registers.

　　5 USB driver host computer part

　　5.1 Basic Concepts of Driver

　　The function of the host driver is to connect the hardware with the user application. There are many ways to write it. You can directly connect to the hardware and directly read and write the system in the application, or you can let the operating system automatically complete the underlying work of exchanging data with the hardware. The application completes the operation of the hardware device like reading and writing ordinary files. The former method has less code overhead, but the workload of writing is very large and the portability is poor. The latter method requires a lot of library function support, but it is relatively simple to write and has good portability. Even a few modifications are needed to complete the support of another hardware. The driver used in this system is provided by the manufacturer. In order to fully explain the work of the USB system, it is still necessary to introduce the working method of the host driver.

　　From the perspective of the driver, each device is seen as a number of device objects. These device objects have different origins, and each object has a corresponding driver. They form a device object stack according to certain rules, which is the corresponding driver stack. At the bottom is the physical device object, which is generally generated by the bus. When the driver arrives here, the bus only needs to perform some actions according to the standard to complete the physical operation of the device. A device can only have one physical device object, but it can have several other device objects. The functional device object is generated by the written driver, and it is responsible for operating the device logically. Other hierarchical device objects can be above or below the functional device object. It is generated by other drivers or other system components and can record some device information, but hierarchical device objects are not necessary. Due to this hierarchical structure of the driver, when writing the driver, you don’t have to consider memory allocation, IO port configuration, DMA application, etc. Windows automates all resource applications and completes them by the bus. When writing the driver, you only need to consider controlling the device itself. [page]

　　5.2 Plug and Play Device States and Transitions Between Them

　　A notable feature of USB interface devices is that they can be directly plugged in or unplugged without shutting down the host or restarting the system. This is related to the hardware settings of the USB interface. The USB interface determines whether a device exists by detecting the pull-up resistor of the interface. Of course, there must also be a corresponding driver to support this function. The following will briefly describe the process of a device completing plug-and-play.

　　The user plugs the device into the computer, but the device has not yet been detected by the system. To begin software configuration of the device, the device must be enumerated by the Plug and Play Manager and the bus driver. The Plug and Play Manager, and sometimes the components in user mode, detect the device's driver, including the function driver and other layered drivers. If the driver has not yet been called in, the Plug and Play Manager calls the device insertion routine. After the driver completes initialization, the device must be initialized. The Plug and Play Manager calls the device add routine in the driver to initialize each device controlled by the driver. When a driver receives a request to start a device from the Plug and Play Manager, the driver starts the device and prepares to handle IO operations. In Windows 2000 and later operating systems, requests related to stop are only used when reallocating hardware resources. An unexpected uninstallation is when the hardware is physically uninstalled (hot unplugged), and the driver handles this request to minimize the loss of the system. When the hardware is uninstalled, the corresponding uninstall request is called, making the device unavailable in software. If the unexpected uninstallation is not handled, the hardware may no longer exist in the physical sense, but still exist in the system logic, causing errors when the system accesses the device. In severe cases, the processor may enter an infinite loop. When stopping the device in the software sense, it is necessary to wait until other requests are completed before proceeding.

　　5.3 Driver Structure

　　The USB driver can be divided into two parts in terms of structure, the driver entry and the routines for handling various events. The driver entry is a set of constants defined by the system. This part mainly completes two tasks: one is to copy the registry key to a global variable; the other is to indicate the processing routines for different device events. The remaining work is to write respective routines according to these device events. These device events mainly include the following parts:

　　(1) Open file: When the user opens the device in the name of opening a file to prepare for reading and writing, this routine is called to prepare.

　　(2) Close file: When the user closes the file (closes the device), this routine is called to clean up the system.

　　(3) Plug and Play processing: Processes plug and play related events. This part of the routine includes many hardware-related subroutines. The specific functions are described in Section 2.

　　(4) Processing read operations: When the user reads a file, this routine is called to return the information in the interface chip buffer to the host.

　　(5) Processing write operations: When the user writes a file, this routine is called to send the data in the form of a packet to the interface chip.

　　(6) Device operation: This part of the routine completes the control of the device hardware and generally contains IO control codes. These control codes are defined in the user header file. The routine completes various control tasks of the device based on different IO control codes.

　　(7) Driver initialization: This routine is called when the hardware is installed for the first time to create a physical device object and initialize all the variables involved. This part of the program is usually built into the operating system.

　　(8) Driver uninstallation: used to clear the traces left by the hardware in the system, release the memory occupied by the registry path string in the global variable, and return resources to the system.

　　(9) Power management: All routines related to power are issued from here. The request it issues can be to specify a new power state, or to query whether changing a state is reliable. This part is more important for bus-powered USB devices, involving operations such as device suspension and wake-up. This part has no effect in this system. All lower-level devices are self-powered and the devices are in a long-term working state.

　　5.4 USB device reading and writing

　　The read and write operations of USB devices are the main concerns of most users. Due to the role of device drivers, the read and write operations of user applications and USB devices have become very simple. Users open USB devices just like opening files. This is achieved by applying for a symbolic link in the add device and activating this link in the start device routine. There are four types of read and write operations in USB:

　　(1) Control type: Control type transmission is mainly for the configuration of the USB itself. The USB configuration described above is actually implemented through control transmission.

　　(2) Batch transmission: Batch transmission is used to process large amounts of data that are not time-sensitive. The underlying protocol guarantees error-free transmission, but does not guarantee transmission delay.

　　(3) Interruption type: Interruption type transmission has strict restrictions on service time, but the amount of data transmitted at one time is not large, mainly some messages that require real-time response.

　　(4) Synchronous type: Synchronous transmission can guarantee transmission delay, bandwidth and constant data transmission rate, but in the event of transmission failure, "retry" is not used to transmit data, so there may be a certain error probability.

　　The reading and writing of USB interface is done in the same way as the reading and writing of data files. The first step is to open the file, that is, to open the device. When the user opens the device in the name of opening the file, the device status must be checked first to see if the device is in working state and whether the interface information of the device is ready. Then check the legitimacy of the file object passed down from above (the pointer is not null). Then check the length of the file name. When it is 0, it means that only the device itself is opened; when it is not 0, it means that a certain pipe is opened. Call the pipe-related routine and convert the pipe name into a pointer to the corresponding pipe comprehensive information. Reading and writing USB devices actually calls the same transmission routine. The difference is that the transmission direction symbol is different. Since both parties in communication comply with the USB protocol, the format of all data packets is consistent, so there is no problem. The reading and writing process of the host computer controlled by the driver is similar to that of the microcontroller. The difference is that the interface chip used by the microcontroller puts the data into the hardware buffer, while the driver of the host computer will build a virtual buffer to complete the same work. When the data to be sent is larger than the capacity of the buffer, the data must be segmented as in the case of the microcontroller. When the data is sent, the routine returns a successful sending flag.

　　5.5 Introduction to USB Host Computer Application Design

　　After writing the driver, calling the USB device in the application is similar to calling the hardware. You can use the WIN32 API function to read and write the device like calling a program file, or you can use a control like the mscomm of the serial port to achieve it. Since the host computer program of this system is developed in VB, it is obvious that calling the finished dynamic link library can reduce a lot of workload. Here we call the dynamic link library called easyd12.dll developed by Guangzhou Zhou Ligong Single Chip Microcomputer Development Co., Ltd.

　　6 Conclusion

　　Writing the driver for the USB interface is a tedious task. Due to the limitation of hardware conditions, the above program can only be run on the simulator and cannot be debugged on the spot. There must be many loopholes and deficiencies. The USB interface itself is not developed for intelligent instruments. The USB bus used for bulk data transmission is somewhat complicated to use on intelligent instruments. Before the emergence of a higher-performance universal bus, using USB is still a cost-effective solution to achieve high-speed information transmission. This system only uses part of the functions of USB, but the cost of software and hardware resources is not much different from that of a fully functional USB transmission system. If a universal bus that is simpler and easier to use than the USB bus can be developed, it will definitely cause a revolution in intelligent instruments. In fact, the work done by the driver can be completely implemented in a pure hardware way, but at present, the cost is bound to be high. If a method can be found to directly control the level of each pin of the USB interface, then even medium-scale integrated circuits can complete the work of synchronous serial communication. Unfortunately, in the entire design process, I have never found this method, and the bottom-level content involving the USB protocol and the related controllers on the computer motherboard is still not insightful.