WDF-based Pci/pcie interface card Windows drivers (5)-How to migrate drivers for hardware

Original address: http://www.cnblogs.com/jacklu/p/6139347.html

As the previous blogs have said, developing PCIe drivers with WDF is the main work of my undergraduate design. During the two years of research and development, I also transplanted my own driver for the project group, and the PXI, PXIe, PCI and PCIe boards under Windows 32-bit and 64-bit platforms were verified separately.

This article is based on your latest driver code (source code, please ask the blogger), mainly on how to transplant the driver for your own hardware board, and briefly describe how to configure the PCI IP core using the Altera series FPGA, and then the INF file briefly described, Finally, it describes how to use QT to write the host computer software call the underlying driver.

Ready to go to the Bo, this one will be the end of this series, then will put more energy into machine learning.

1 overview

The driver Code program is composed of 7 source code files, namely Device.h, Driver.h, Public.h, Trace.h, Device.c,driver.c, queue.c. Where Device.h defines the address offsets associated with the hardware, PUBLIC.H defines the user-defined command word used by DeviceIoControl, which is used by the upper-level application and driver, and QUEUE.C defines the I/O callback routines, using the Read , write, and I/O Control three queues. In addition to these three files, it is not recommended to change the code for the other 4 files. The list of three source file functions is shown in 1-1, 1-2, 1-3, respectively:

2 Driver Porting Instructions 2.1 Public.h description

• The GUID value is defined in the code, and the developer can use the tool GUIDGen.exe under VS2013 to generate the GUID value, which identifies the driver and the application finds the corresponding driver based on the GUID value.
• The ctl_code is defined in the code, and the second parameter of the I/O processing routine DeviceIoControl dwiocontrolcode is defined by the Ctl_code macro. Ctl_code is a macro for creating a unique 32-bit system I/O control code that consists of 4 parts: DeviceType (device type, high 16-bit (16-31-bit)), access (access limit, 14-15-bit), function (2-13 bits), method (I/O access memory usage). The Ctl_code definition has a method field that defines how the driver obtains the address of the application data buffer. The description of the Ctl_code command word that has been defined is shown in table 2-1, and users can customize the Ctl_code according to the format to achieve different functions.

What is a CRA register group? Open Quartus Sopc Builder, you can see SOPC schema 2-1, in the PCI IP Core column has the Control Register Access Register Group, the address range 0x00000000-0x00003fff. Inside the key register address 2-2 is shown. By reading the registers of the yellow flag, the PCI core can be verified by driver debugging. The configuration instructions for the CRA Register group are described in detail in section 2.3.

2.2 Device.h Description

• The Code defines the offset address of the hardware resource on the FPGA, which is also called the Avalon address in the Altera series FPGA, where Sopc Builder can customize the assignment, as shown in base and end 2-1, the "small lock" flag represents the address Lock, you can customize the cheap address after you click the flag to unlock it. These addresses must correspond to the address one by one used in the driver;
• The code defines the device object structure, commenting on several important member variables as follows:

• Code for some event callback routines are described, generally do not require the user to make two changes;

2.3 queue.c Description

• Code is the code that the user needs to develop for the feature. To write the offset address from the application to the driver, for example, the original code XX-XX line, first defined in the Public.h file IoControlCode for qd41_ioctl_write_offsetaddress, 第48-53 behavior to get application input slow A pointer to the data (Inbuffer in the code), inbuffer the data content pointed to by the assignment statement to the member variable Offseaddressfromapp of the device object, which completes the function;
• The code defines the write queue function, and the Write function configuration of the DMA is done in this function. Altera's DMA IP Core has a total of 5 registers, as shown in 2-3.

• Before configuring the DMA, you need to configure the PCI CRA register to enable PCI interrupts and configure the AVALON-PCI address Translation table, as shown in the code;
• Why do I need to configure the AVALON-PCI address translation table? Because the PCI IP core is a PCI bus, one end is the Avalon bus, the address conversion process is shown in Figure 2-4, similar to the MMU address translation principle, do not repeat, at this time need to get a PC to the DMA transfer cache physical address of the high 16-bit address to write the address translation table;

• After configuring PCI, the DMA control register can be configured, and the status register and the control register are zeroed, as shown in the code.
• Read and write addresses are then written to read and write registers, note that the memory address on the PC is low 16 bits, and the high 16 bits to be configured in the AVALON-PCI address translation table, as shown in the code, where 0x20000 is the PCI IP core of the Avalon address, 2-1 is shown;
• Writes the DMA transfer length (in bytes) to the length register, as shown in the code;
• Write to the control register the DMA control word 0x8c, that is, the length register is reduced to 0 o'clock transmission is completed, enabling the DMA,32 bit-word transmission, as shown in the code;

3 How the application calls the Driver 3.1 GUID description

The GUID (globally unique Identifier) is a globally unique identifier introduced by Microsoft to identify an entity, such as a picture on a hard disk, by generating a set of 128-bit binary numbers using a particular algorithm, such as information based on time or location. GUIDs are widely used in Microsoft products to identify objects such as interfaces, files, and so on. Developers can use the tools under VS2013 to generate the GUID value, which identifies the driver and the application finds the corresponding driver based on the GUID value of the GUIDGen.exe.

The overall application process is designed to first open the device through the WIN32API function CreateFile and then call the DeviceIoControl function to communicate with the driver, i.e. read and write data, and invoke the CloseHandle function to shut down the device when the application exits.

The application obtains the device path based on the GUID of the underlying setting to establish a connection to the specified device: First call the Setupdigetclassdevs function to obtain a collection of device information conforming to the passed-in parameter GUID Hdevinfo; and then based on the device information collection Hdevinfo and GUID Call the Setupdienumdeviceinterfaces function to enumerate the devices in the device information collection and output the device interface data information Deviceinterfacedata, and then call Se according to Hdevinfo and Deviceinterfacedata. The Tupdigetdeviceinterfacedetail function gets the buffer size of the deviceinterfacedetaildata that holds the details of the device interface, then opens up space for it. Finally, the Setupdigetdeviceinterfacedetail function is called again to obtain the device interface details Pdeviceinterfacedetaildata; Device interface path based on device interface details Pdeviceinterfacedetaildata->devicepath calls the CreateFile function to create a device handle.

3.2 How applications open devices

In the code 第62-70 line of the test program source.c, complete opening the device handle function, no user changes are required.

3.3 How applications Read devices

After the device is successfully opened, call DeviceIoControl to communicate with the driver via the IOControl queue, read the 32bit data for example, first write to the driver the address of the storage unit that needs to be read, as shown in the Code 第257-272 line, and then pass in the read data cache to the driver O Utbuffer, as shown in code 第274-289, can obtain data for the corresponding offset address on the FPGA.

3.4 How Applications Write devices

After successfully opening the device, call DeviceIoControl to communicate with the driver via the IOControl queue and write the 32bit data as an example, first write the address of the storage unit that needs to be written to the driver, as shown in the Code 第303-317 line, and then pass the abbreviated data cache to the driver Inbuffer, as shown in code 第322-336, can write data to a memory unit on the FPGA that corresponds to the offset address.

3.5 How applications perform DMA transfers to devices

Through the Win32API function ReadFile and WriteFile to the device handle file read and write operations, in the kernel driver will call the driver Qd41evtioread and Qd41evtiowrite, the actual DMA configuration is implemented in both driver callback routines, ReadFile and WriteFile just completed the handling of data from the user layer to the kernel layer. Detailed code in 第340-378 line, no longer repeat.

4 INF file with how to call Qt to write a host computer software call to the underlying driver

I compiled the C language application every single control command into an executable file, so that QT can invoke the C program in the new process to write a command word read and write program. Using the QT encapsulated Process class qprocess, use its member function start to invoke an external program.

WDF-based Pci/pcie interface card Windows drivers (5)-How to migrate drivers for hardware