Introduction of PDIUSBD12 chip
Before developing USB, the appropriate USB interface chip should be selected according to the cost and performance. At present, there are three kinds of USB controller chips
The first chip is specially designed for USB. The main sources of this kind of chip are M8 series of cypress and sl11r series of scanlogic. This kind of chip is specially designed to use in the USB application device, rather than in the old structure, so the realization of its function can achieve the optimization, but it is difficult to develop, so we need to learn a new instruction set, and the price is relatively high.
The second is compatible with existing chips. Most of them are compatible with 8051 series chips, such as AMD am186t and Motorola 68hc05 / 8. The advantage of this kind of chip is that the developer is familiar with the structure and instruction set of the existing chip, so it will be easier to develop.
The third is USB chip which needs external microprocessor interface. This kind of chip is only responsible for processing USB communication, it has to work with another MCU chip. The typical ones are usbn9603 of NS company, net2888 of netchip company and pdiusbd11 / 12 of Philip company. The biggest advantage of using such a chip is that the hardware structure has great flexibility, which is easy to play the excellent performance of single chip microcomputer, and the price is cheap.
After considering the above chips, this project decided to choose the PDIUSBD12 chip of Philip company. In this way, we can make use of the advantage of being familiar with DSP to speed up the product development process, at the same time, we can also improve the scalability of the system, and it is convenient to choose high-performance single-chip microcomputer. The chip only supports USB1.1 protocol. For the system with high speed requirements, the signal conversion board supporting USB2.0 protocol mentioned in the following article can be used.
The structure of PDIUSBD12 chip of Philip company based on USB1.1 is relatively simple, and it must cooperate with MCU to complete USB communication function. The single chip microcomputer executes the communication function command of PDIUSBD12 chip by reading and writing external memory. Chip manufacturers will give their specific USB operation commands. The pin diagram is shown in Figure 1
Figure 1 pin diagram of PDIUSBD12
Design of usb-pc104 conversion board
Because the embedded motherboard is expensive, it can be replaced by a low-cost USB peripheral in many applications. The USB peripheral here means that the embedded system itself can not run independently and needs the support of PC software and hardware. The first problem to be solved in such embedded system is to develop a usb-pc104 signal conversion board to replace the embedded motherboard. The reason why the signal of USB bus and PC104 bus needs to be converted is that the system can have both the advantages of USB device and the high reliability of PC104 bus device. DSP chip can improve the speed of the system and meet the requirements of embedded motherboard bus.
The main block diagram of hardware design is shown in Figure 2
Figure 2 hardware block diagram of conversion board
Its main working principle is: the command to access PC-104 bus device sent from the host application program is converted into corresponding USB device standard requirements by the underlying USB driver and sent to the USB interface chip PDIUSBD12 (hereinafter referred to as D12). When the firmware program running on DSP receives this requirement, it will execute the corresponding command to PC104 bus, so as to control PC-104 The purpose of bus hardware.
Development of firmware program
The firmware program runs in the MCU of USB peripheral device, which responds to the USB requests and data transmission sent by the host. There are two main parts of firmware, ISR (interrupt program) and main program. Interrupt program runs in the background, responsible for USB chip and MCU MPU USB request interrupt response and data transmission, interrupt program receives the USB request and data sent by the host, then transfers it to the main program and sets the corresponding flag bit. The main program runs in the foreground. It performs the actual hardware actions according to the data and flag bits sent to it by the interrupt program. The data exchange between ISR interrupt service program and main program loop is realized by event flag and data buffer. For example, the batch output endpoint of PDIUSBD12 can use circular data buffer. When PDIUSBD12 receives a packet from USB, it will generate an interrupt request to the MPU, and the MPU will respond to the interrupt immediately. In ISR, the firmware moves packets from the PDIUSBD12 internal buffer to the circular data buffer, and then empties the PDIUSBD12 internal buffer to receive new packets. The MPU can continue its current foreground task until it finishes and returns to the main loop. At the same time, check whether there is new data in the loop buffer and start other foreground tasks. The firmware program can be written in assembly language or C language, and the C language must be supported by keil c compiler. But on the whole, their program framework is the same. The main program framework is shown in Figure 3
Figure 3 firmware Master Program Framework
3 driver development
Because modern operating system has taken measures to protect memory, port and other resources. General applications can not directly access the hardware, must be through the device driver. Device drivers deal with hardware directly, and run in the kernel state of the operating system. It has the highest operating authority like the operating system kernel, so it can directly access the hardware.
USB devices must use WDM (Win32 driver model) driver model, which is defined by Microsoft. WDM is a new driver model developed from operating system to now, and it has become the mainstream of Windows operating system driver.
In Windows system, there are five models to deal with applications: hardware layer, hardware abstraction layer, driver, IO management layer and user application program. Requests are sent from the application layer down. USB driver is also divided into client driver, root hub driver and bus driver. Users can mainly develop customer drivers, Zhen other lower level operating system has been prepared for users. The client driver consists of a series of routines (i.e. functions of general programs), and it has no main () function entry point. Therefore, the interaction between USB device and driver must be participated by IO management layer of operating system. It uses a global quantity called IO request packet, or IRP. The main working principles are as follows:
(1) At the beginning, the user application sends a request to the driver (Windows API function), and packages the relevant data into IRP. The IO manager captures the IRP package and processes it accordingly.
(2) IO manager sends IRP request package to client driver and requests client driver to deal with it.
(3) After the client driver processes the received IRP, it sends it to the lower level driver after setting the relevant environment. Finally, the bus driver completes the hardware operation and returns the result.
What the user has to do is develop the client driver. In this paper, we use DriverWorks driver development tool based on WIN2000 DDK and VC + + 6.0 compiling environment. This tool can generate driver framework, users can modify and add their own functions to achieve, greatly reducing the development time.
4 user applications
Application program is the embodiment of hardware function. But the application can not directly access the USB device, it must first communicate with the driver, through the driver to access the USB device. Its work is to send data or commands to the hardware. These data and commands are processed by the driver layer by layer, and finally sent to the hardware to realize the relevant actions. Applications and drivers deal with each other mainly through the API function of the operating system.
Its working principle is as follows:
(1) The application program obtains the handle of USB device by calling the CreateFile API function. The symbolic link contains a globally unique identifier (GUID). A GUID is a 128 bit number that windows uses to uniquely identify a device object.
(2) Through this handle, the application program reads and writes the USB device by calling the readfile and WriteFile API functions, and returns the data to the user buffer.
(3) Through this handle, the application program sends control commands to USB devices by calling the DeviceIoControl API function to achieve specific requirements. This function may also have corresponding data transmission.
(4) The application program processes the data received from the USB device. If there is an error, it will give the corresponding warning. If it is successful, it will close the handle of the device after processing.