1. Introduction With the continuous improvement of digital signal processor (DSP) performance and the significant decrease in its cost and price, the application fields of digital signal processing have expanded rapidly, and signal processing has entered a new stage of development. Simultaneously, with the continuous development of computer technology and internet technology, more and more data needs to be processed, stored, transmitted, and manipulated by computers. Computer applications have permeated every corner of our lives. Due to the inherent characteristics of computers, general-purpose computers are usually only responsible for tasks without real-time requirements and are not suitable for digital signal processing with high real-time requirements. Organically combining computers and DSPs, and fully utilizing their respective advantages, will complement each other and meet the increasingly higher requirements for real-time data processing capabilities, data transmission capabilities, and data management capabilities in practical applications. The PCI bus, with its numerous advantages, plays an irreplaceable role in computers. Using the PCI bus allows DSPs to communicate with computers, which can well meet their requirements for high-speed data transmission. This paper takes a practical development system as the background and TI's TMS320VC5402 and PLX's PCI9052 as the foundation. It discusses in detail the hardware and software design scheme and implementation method of a data acquisition system based on a DSP PCI bus structure. 2 Hardware Design of Data Acquisition System 2.1 System Structure and Principle The structure of the high-speed data acquisition system based on DSP PCI bus is shown in Figure 1. It mainly consists of an A/D converter, DSP data reading and processing, PCI communication interface and PC. The analog signal is sampled by the A/D converter and then read by the DSP through parallel I/O. The processed data is sent to the general computer for further processing through the PCI bus [1]. The A/D converter uses TI's TLC5510. The TLC5510 is an 8-bit, 20 MS/s high-speed parallel A/D converter. The TLC5510 samples at the falling edge of each clock. The converted data of the sample point is output at the rising edge of the clock after a delay of 2.5. That is, the conversion time of each point is 2.5 clock cycles. Once the conversion pipeline is started, there is a converted data output at the rising edge of each clock. The communication between the DSP and the computer is realized by the interface circuit PCI9052. PCI9052 is a simple and efficient PCI slave device interface launched by PLX. It can realize the interconnection of various peripheral local buses and PCI bus. According to the PCI specification, the division between master and slave devices is essentially to determine the access and access capabilities and relationships between the two parties in data transmission. Here, the PCI9052 can only be read and written by the host or other devices with bus master control capabilities. However, due to its internal 64-byte write FIFO and 32-byte read FIFO, the local bus and PCI bus of the PCI9052 can work independently of each other, and can support burst transmission with a transmission speed of 132 Mb/s [2]. The DSP uses TI's TMS320VC5402, which has a processing capacity of 100 Mb/s, an improved 8-bit HPI interface, 16 K * 16 Bit DARAM, and 4 K * 16 Bit ROM storage space. It has a high cost performance [3]. 2.2 Interface between PCI9052 and TMS320VC5402 The local bus of PCI9052 is set to an 8-bit local bus, using address-data non-multiplexed mode. The interface circuit between PCI9052 and TMS320VC5402 is shown in Figure 2 [4,5]. At this time, LBE1 is LA1, and LBE0 is LA0. Connect LBE0 of PCI9052 to HBIL of HPI to distinguish between the first and second bytes. Connect LA17 of PCI9052 to HCNTL1 of TMS320VC5402, and LA16 to HC-NTL0 to select the HPI register. Connect LAD[0:7] of PCI9052 to HD[7:0] of TMS320VC5402. The inverted HINT of TMS320VC5402 is connected to LINT1 of PCI9052. The inversion is because HINT is active low, while LINT1 is active high. The LW/R pin of the PCI9052 is inverted and then connected to the HR/W pin of the TMS320VC5402. A high level on LW/R indicates a write operation, and a low level indicates a read operation; similarly, a high level on HR/W indicates the host is reading from the HPI, and a low level indicates the host is writing to the HPI. The CS0 and CS1 pins of the PCI9052 are ORed and then connected to the HCS pin. The RD and WR pins are connected to the HDS1 and HDS2 pins, respectively. The LRDY pin of the TMS320VC5402 is connected to the LRDY pin of the PCI9052 via a specific logic combination and a D flip-flop to achieve synchronization between the PCI9052 and the HPI. The PCI9052 local clock is 40MHz. The CPLD used is an EPM7128, designed using MAX+PLUSⅡ. The HPI host interface uses the access register method to read and write data inside the DSP. Simply mapping the HPI port to the I/O space or memory space of the PCI has unavoidable drawbacks. Therefore, this interface circuit adopts a dual mapping method, using mapping to access the control, address register and single data port, and using memory mapping to access continuous data ports. This is to achieve convenient and efficient data communication between TMS320VC5402 and PCI9052 [6]. 3 Design of Data Acquisition System Software The software design of the data acquisition system includes three parts: the acquisition program and response program on the DSP, the driver of the data acquisition card, and the application built on the driver. The driver is the key to realizing communication between the DSP and the computer. This paper mainly introduces the device driver model and its initialization design method. 3.1 Driver Model Win2000 does not support direct access to hardware. The virtual driver depends on the real driver running in kernel mode. Kernel mode drivers are written using system-level code and run in kernel mode because kernel mode allows direct hardware access. Kernel drivers can be further divided into legacy mode drivers and Windows driver mode drivers (WDM). The Windows driver model (WDM) is shown in Figure 3. The left side of the diagram shows a device object stack. Device objects are data structures created by the system to help software manage hardware. The device object at the bottom of the stack is called a Physical Device Object (PDO). Somewhere in the middle of the device object stack is a Functional Device Object (FDO). Above and below the FDO are filter device objects. Filter device objects above the FDO are called upper-level filters, and those below are called lower-level filters. One of the tasks of the bus driver is to enumerate the devices on the bus and create a PDO for each device. Once the bus driver program detects new hardware, the PnP manager creates a PDO. After creating the PDO, the PnP manager refers to information in the registry to find the filter and function drivers associated with this PDO. The system installer is responsible for these registry entries, while the INF file in the driver package that controls hardware installation is responsible for adding other entries. These entries define the order of filter and function drivers in the stack. 3.2 Driver Initialization The PnP manager first loads the drivers required by the hardware and then calls the AddDevice function in the driver. A driver can be used by multiple similar hardware devices. However, some global initialization operations of a driver can only be performed once during the first load. The DriverEntry routine is used for this purpose. DriverEntry is a common name for the main entry point of a kernel-mode driver. The I/O manager calls this routine as follows: The first parameter of DriverEntry is a pointer to an initialized driver object, which represents the user's driver. The second parameter of DriverEntry is the device service key name, whose main task is to fill various function pointers into the driver object. These pointers indicate to the operating system the location of various subroutines in the driver container. The PnP manager first loads the lowest-level filter driver and calls its AddDevice function. This function creates a FiDO, thus establishing a horizontal connection between the filter driver and the FiDO. Then AddDevice connects the PDO to the FiDO. The PnP manager continues execution from bottom to top, loading and calling each low-level filter, function driver, and high-level filter until the stack is complete. The prototype of this function is as follows: The DriverObject parameter points to a driver object, which is the driver object initialized in the DriverEntry routine. The PDO parameter points to the physical device object at the bottom of the device stack. The basic task of the `AddDevice` function is to create a device object and connect it to the device stack based on the PDO. After the `AddDevice` function creates and connects the FDO and FiDO, the PnP manager allocates resources and sends `PRP_MN_START_DEVICE`. The function driver needs to do a lot of work on this IRP, including allocating and configuring additional software resources and preparing for device operation. This IRP is mainly handled by the `PnPStartDevice` function. The `PnPStartDevice` function first passes the IRP to the underlying driver. After waiting for completion, it calls the `IoGetCurrentIrpStackLocation` function to obtain its current stack location. The parameters of the I/O stack location are associated with a substructure called `StarDevice`, which contains resource allocation information. In `StarDevice`, the allocated resources are populated into the PDO's device extension field, and the `IoConnectInterrupt` function is called to connect the interrupt. This hierarchical structure makes the I/O request process clearer. Each operation affecting the device uses an I/O request packet. Typically, IRPs are first sent to the top-level driver in the device stack, and then gradually filtered down to the drivers below. The kernel usually executes the code in the driver by sending I/O request packets (IRPs). 4. Conclusion The DSP-based PCI bus data acquisition system fully utilizes the rich internal resources of the DSP, its powerful digital signal processing capabilities, and the high transmission speed of the PCI bus. It can easily develop new functional signals such as data compression and voice compression storage, and perform preprocessing and analysis. Data transmission via the PCI bus can greatly improve the transmission speed. This system is suitable for high-speed data acquisition and processing, as well as applications requiring large-scale data transmission.