Pci/pcie interface card Windows Driver (3)-Driver code (header file)

In the PCIe driver for WDF, there are four. h files (Public.h Driver.h Device.h Trace.h). This article will explain the four file source code in detail separately.

Public.h

1 #ifndef _user_h2 #define_user_h3 //4 //Define an Interface a Guid so this app can find the device and talk to it.5 //6#include <initguid.h>7 //{49fa63a7-c525-4409-8dd5-eff37a7375f8}8 Define_guid (Guid_devinterface_spw_pcie,9     0x49fa63a7,0xc525,0x4409,0x8d,0xd5,0xEF,0xf3,0x7a,0x73,0x75,0xf8);Ten #defineSpw_pcie_ioctl_in_buffered Ctl_code (File_device_unknown, 0x800, method_buffered, file_any_access)//The least value is 0x800 One #defineSpw_pcie_ioctl_out_buffered Ctl_code (File_device_unknown, 0x801, method_buffered, file_any_access) A #defineSpw_pcie_ioctl_read_paddress Ctl_code (File_device_unknown, 0x802, method_buffered, FILE_ANY_ACCESS) - #defineSpw_pcie_ioctl_write_offsetaddress Ctl_code (File_device_unknown, 0x803, method_buffered, FILE_ANY_ACCESS) - #endif

The code file is named public because the file is used by both the driver and the application . In the comments in line 4th, it is stated that the main purpose of this file is to provide a GUID interface for driver and application communication. The control of the hardware device under the Windows platform requires that the application be able to communicate with the underlying driver, and there are two important concepts in the design of the application and the driver communication, the GUID value and the Ctl_code macro .

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. Note Use the DEFINE_GUID macro to include the Initguid.h file, or you will report an unrecognized error.

The second parameter of the I/O processing routines DeviceIoControl (which is described in detail in the next article) 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 application data buffer address is obtained in the driver.

10-13 lines of code for user-defined 4 I/O control commands, respectively, read the data, write the data, read the mapped BAR0 physical start address, write offset address (used to read and write data).

The first parameter is the device type, usually a custom board selection File_device_unknown;

Note that the second number is to be taken from 0x800, and the previous one has been occupied by Microsoft ;

The third parameter has four options (method_buffered, Method_in_direct, Method_out_direct, method_neither), BUFFERED mode: i/ The O Manager creates a system buffer that is exactly the same as the application data buffer, the driver works in this buffer, and the I/O Manager completes the copy data task; Direct: the I/O Manager locks the physical memory page of the application buffer and creates an MDL (memory descriptor) to describe the page. The driver will work with MDL, neither: the I/O Manager passes the virtual address of the application buffer to the driver, which is generally not the way it is used.

The fourth parameter is used to set the file read and write permissions, there are three options (File_any_access,file_read_access,file_write_access ），Microsoft's official statement is that "theFile_access_any is generally the correct value."So we are still honest choice of file_access bar.

Driver.h

1 #defineInitguid2 #pragmaWarning (disable:4200)//3 #pragmaWarning (disable:4201)//Nameless struct/union4 #pragmaWarning (disable:4214)//bit field types other than int5 6#include <ntddk.h>7#include <wdf.h>8 9#include"Public.h"Ten#include"device.h" One#include"trace.h"

This file will be based on the WDF PCIe driver required for the header files are included together, and disable some warnings, due to driver development very attention to warnning processing, VS2013 is the default warnning when not compiled, Developers need to set it up manually. For some innocuous warnning, we can also disable it in a preprocessing way.

Device.h

1#include"public.h"2 3 #definePcie_write_memory_offset 0x20000//Memory1 ' s offset address to BAR0 in FPGA4 #definePcie_read_memory_offset 0x22000//Memory2 ' s offset address to BAR0 in FPGA5 6 #defineMaxnlen 1024//define the largest length7 //8 //device context is same as device extension in WDM9 //Tentypedefstruct_device_context One { AULONG Counter_i;//counter for Wdfcmresourcelistgetcount (resourcelisttranslated) -PVOID membaseaddress;//When i = = 5,it gets BAR2 start virtual address -PVOID bar0_virtualaddress;//BAR0 start virtual address theULONG Physicaladdressregister;//Store the BAR0 start physical address -ULONG memlength;//It records the length of menmory on hardware -ULONG Offsetaddressfromapp;//Get offset address that's given by application -} device_context, *Pdevice_context; +  - // + //This macro would generate an inline function called Devicegetcontext A //which'll be used to get a pointer to the device context memory at //In a type safe manner. - // - //wdf_declare_context_type_with_name (Device_context, Devicegetcontext) -Wdf_declare_context_type_with_name (Device_context, Getdevicecontext)//very important! -  - // in //wdfdriver Events including "EVT" - // to driver_initialize DriverEntry; + Evt_wdf_driver_device_add Spw_pcieevtdeviceadd; - Evt_wdf_object_context_cleanup Spw_pcieevtdrivercontextcleanup; the  * evt_wdf_device_d0_entry spw_pcieevtdeviced0entry; $ evt_wdf_device_d0_exit spw_pcieevtdeviced0exit;Panax Notoginseng Evt_wdf_device_prepare_hardware Spw_pcieevtdevicepreparehardware; - Evt_wdf_device_release_hardware Spw_pcieevtdevicereleasehardware; the  +Evt_wdf_io_queue_io_device_control Spw_pcieevtiodevicecontrol;

This file defines something that is closely related to the device and the driver, which is very important.

The 3-4 row defines two macros, which are offset addresses 0x20000 and 0x22000 that have BAR0 mappings in two blocks, which are related to the PCIe hardware board. In the read and write operation, the physical address of the BAR0 must be offset address, otherwise it will be written to the unknown memory unit resulting in a blue screen and other consequences.

6 rows define the maximum size of the transfer, which is used later in the DMA operation.

10-18 rows Define device-dependent variables, encapsulate these variable parameters in a struct, and embody the idea of an "object encapsulation" in WDF. several parameters represent the resource counter (which records the number of resources that the WDF framework assigns to the device), the starting address of the record BAR2 (when the resource counter i = = 0 o'clock), the BAR0 's converted virtual address (which can be used by the application), the starting address of the BAR0 map (physical address, Same as the results obtained in Device Manager), memory size, offset address (passed by the application for I/O read use). In WDF, this struct is called the device context (Device_context), which is called device_extension in WDM

The 26-line macro is very important, and the effect will be explained in detail in the next article about the source file.

31-40 lines declare some WDF event callback routines, and we can use the custom callback function name directly, which acts only as a developer's convenience to write programs.

DriverEntry is the driver entry function;

Spw_pcieevtdeviceadd to add functions to the device, it is very important to say three times yourself;

Spw_pcieevtdrivercontextcleanup is a resource cleanup function, because the operating system is more intelligent, when the device is unplugged, the operating system will automatically reclaim some resources, so this function seems to be in the PCIe driver and no eggs, even if I made a statement here, In the next introduction to the source code, we will also find that its function definition also only "hit a soy sauce";

Spw_pcieevtdeviced0entry and Spw_pcieevtdeviced0exit are two functions related to power management, and WDF has done a good job of encapsulating power management, usually without the driver developers working on it, so they are both "soy sauce" Of

Spw_pcieevtdevicepreparehardware and Spw_pcieevtdevicereleasehardware are very important!!! I say three times, respectively, for the equipment to obtain resources and release resources;

Spw_pcieevtiodevicecontrol is a function that implements communication between the application and the driver, which specifies different control codes for different operations.

In this section, a brief overview of these routines is provided, and a detailed explanation will be given in the next article.

There is also the last header file for debugging and tracing, because I also useless to debug and trace the driver, so directly to the vs2013+wdk8.1 automatically generated code files, do not explain.

Trace.h

1 /*++2 3 Module Name:4 5 Trace.h6 7 Abstract:8 9 Header file for the debug tracing related function defintions and macros.Ten  One Environment: A  - Kernel Mode -  the --*/ -  - // - //Define The tracing flags. + // - //Tracing Guid-ad7b826c-e901-457e-a559-a221404519c6 + // A  at #defineWpp_control_guids - Wpp_define_control_guid ( - Spw_pcietraceguid, (AD7B826C,E901,457E,A559,A221404519C6), -                                                                              - wpp_define_bit (mydriver_all_info) - wpp_define_bit (trace_driver) in wpp_define_bit (Trace_device) - wpp_define_bit (trace_queue) to         )                              +  - #defineWpp_flag_level_logger (FLAG, level) the wpp_level_logger (flag) *  $ #defineWpp_flag_level_enabled (FLAG, level)Panax Notoginseng(wpp_level_enabled (flag) &&                                              -Wpp_control (Wpp_bit_ # # flag). Level >=Level ) the  + #defineWpp_level_flags_logger (Lvl,flags) A Wpp_level_logger (Flags) the                 + #definewpp_level_flags_enabled (LVL, FLAGS) -(Wpp_level_enabled (Flags) && Wpp_control (Wpp_bit_ # # Flags). Level >=LVL) $  $ // - //This comment block was scanned by the trace preprocessor to define our - //Trace function. the // - //BEGIN_WPP configWuyi //FUNC Trace{flag=mydriver_all_info} (Level, MSG, ...); the //FUNC traceevents (level, FLAGS, MSG, ...); - //END_WPP Wu //

Pci/pcie interface card Windows Driver (3)-Driver code (header file)