Summary of Wince driver Compilation

Summary of Wince driver Compilation

Http://tb.blog.csdn.net/TrackBack.aspx? Postid = 1334401

1. Basic Knowledge:

1) system calls are interfaces between the operating system kernel and applications, and device drivers are interfaces between the operating system kernel and machine hardware. The device driver shields the application from hardware details. In the application's view, the hardware is just a device file, and the application can operate the hardware device like a common file. The device driver is part of the kernel.

2) the driver completes the following functions:

-- Initialize and release the device;

-- Transfers data from the kernel to the hardware and reads data from the hardware;

-- Read the data transmitted by the application to the device and the data requested by the application;

-- Detect and handle device errors.

3) The upper-layer applications run in user mode (non-Permission mode, ring 3) and the code is strictly restricted for execution. If you cannot execute hardware I/O commands. All these blocked operations must request the operating system kernel through the trap gate to run.

4) the operating system kernel runs in kernel mode (privileged mode, ring 0) and can execute all valid CPU commands. Including Io operations to access any memory zone.

5) The hardware system resources are naked in front of the driver, and the driver can use all system resources. When writing the driver, we must be extremely careful about the boundary conditions for driving the code, make sure they do not damage the entire operating system.

2. Drivers supported by Windows:

1) Virtual Device Driver: windows3.1 (Windows95/98/me)

2) Kernel Mode Driver: Windows NT

3) Win32 driver mode: It is used from Windows98.

Among them, WDM is currently the mainstream, but in the wince system, due to limited hardware resources and the characteristics of embedded systems, its support is very limited.

3. wince system driver introduction:

1) wince is an embedded system with its own particularity. To improve the running efficiency, all drivers are dynamic link libraries, and all standard APIs can be called in the driver implementation. In other Windows systems, drivers may include. VxD,. sys, and dynamic link libraries.

2) The wince driver is structured into Native driver and stream driver ).

-- Local drivers are mainly used for low-level and built-in devices. Their interfaces are not uniform, but are designed for different types of devices. Therefore, the development process is relatively complex and there is no fixed mode. The general practice is to port and customize the existing driver samples.

-- The Stream interface driver is the most basic driver structure. Its interface is a set of fixed stream interface functions and has high universality, all drivers of Wince can be implemented in this way. The stream interface driver receives commands from the Device Manager and application through a file system call. The driver encapsulates all the information needed to convert these commands to the appropriate actions on the device it controls.

A stream interface driver is a dynamic link library that is loaded, managed, and detached by a special application called a device management program. Compared with local drivers, all stream interface drivers use the same set of interface functions, including implementation functions: xxx_init, xxx_deinit, xxx_open, xxx_close, xxx_read, xxx_write, xxx_powerup, xxx_powerdown, xxx_seek, and xxx_iocontrol. These functions work with hardware. User functions: createfile, deviceiocontrol,
Readfile, writefile, these functions are convenient for users to use the driver.

3) The driver Loading Method under wince:

-- Use GWES (graphics, drawing wing, and events subsystem) to load drivers related to display and input, such as mouse and keyboard drivers. These drivers are generally local drivers.

-- Device manager: drivers of both structures are loaded. The local drivers are mainly PCMCIA host controller, USB host controller driver, and bus drivers; stream interface drivers are mainly audio drivers and serial parallel port drivers.

-- Dynamic Loading: the first two are loaded when the system starts. Dynamic Loading allows devices to mount the driver to the kernel when mounting the system, including external board drivers and USB device drivers.

4. Introduction to stream interface-driven functions:

1) DWORD xxx_init (lpctstr pcontext, lpcvoid lpvbuscontext );

Pcontext: point to a string that contains the path of the activity key value of the stream interface in the registry.

Lpvbuscontext:

This function is the first to be executed after the driver is mounted. Performs device initialization and driver security checks. It is called by activedeviceex through the Device Manager. The returned value is generally a Data Structure pointer, which is passed as a function parameter to other stream interface functions.

2) bool xxx_deinit (DWORD hdevicecontext );

The return value of hdevicecontext: xxx_init.

The final execution of the entire driver. Used to stop and uninstall a device. The Device Manager call is triggered by deactivatedevice. Success returns true.

3) DWORD xxx_open (DWORD hdevicecontext, DWORD accesscode, DWORD reply mode );

The return value of hdevicecontext: xxx_init.

Accesscode: Access Mode flag, read, write, or other.

Sharing Mode: indicates the sharing mode of the driver.

Open the device and initialize data for subsequent operations to prepare resources. The application is called indirectly through the createfile function. Returns a structure pointer to identify which application calls the driver. This value is also passed as a parameter to other interface functions, such as xxx_read, xxx_write, xxx_seek, and xxx_iocontrol.

4) bool xxx_close (DWORD hopencontext );

Hopencontext: xxx_open return value.

Close the device and release resources. Indirectly called by the closehandle function.

5) DWORD xxx_read (DWORD hopencontext, lpvoid pbuffer, DWORD count );

Hopencontext: xxx_open return value.

Pbuffer: buffer pointer to receive data.

Count: the length of the buffer.

The readfile function is called indirectly to read data on the device. Returns the actual number of bytes of data read.

6) DWORD xxx_write (DWORD hopencontext, lpcvoid pbuffer, DWORD count );

Hopencontext: xxx_open return value.

Pbuffer: buffer pointer to receive data.

Count: the length of the buffer.

Indirectly called by the writefile function, data is written to the device, and the actual number of data written is returned.

7) bool xxx_iocontrol (DWORD hopencontext, DWORD dwcode, pbyte pbufin, DWORD dwlenin, pbyte pbufout, DWORD dwlenout, pdword pdwactualout );

Hopencontext: xxx_open return value.

Dwcode: Control Command word.

Pdwactualout: the actual length of output data.

This function is used to send commands to devices. Applications call deviceiocontrol to implement this function. To call this interface, you also need to create an identical command between the application layer and the driver, which is implemented by defining ctl_code (devicetype, function, method, access) using a macro. For example:

# Define ioctl_init_ports \ ctl_code (file_device_unknown, 0x801, method_buffered, file_any_access)

8) void xxx_powerdown (DWORD hdevicecontext );

The return value of hdevicecontext: xxx_init.

Controls power-on of devices.

9) void xxx_powerup (DWORD hdevicecontext );

The return value of hdevicecontext: xxx_init.

Responsible for device power failure Control

10) DWORD ioc_seek (DWORD hopencontext, long amount, Word type)

Hopencontext: xxx_open return value.

Amount: the offset of the pointer.

Type: pointer offset.

Point the Data Pointer of the device to a specific location, which is indirectly called by the application through the setfilepointer function. Not all device properties support this feature.

5. Stream interface driver loading and registry settings:

When the system starts, start the device management program. The device management program reads the HKEY_LOCAL_MACHINE \ drivers \ builtin key and loads the listed stream interface drivers. Therefore, the registry plays a key role in driver loading. The following is an example:

[HKEY_LOCAL_MACHINE \ drivers \ builti \ iocontroler]

"Prefix" = "xxx"

"DLL" = "drivername. dll"

The XXX in "prefix" = "XXX" must be the same as that in functions such as xxx_init. The prefix of the driver name created by createfile must be the same as those of the driver name.

6. Write and compile the driver and its related directories, and modify the format and configuration file:

1) First, the Directory of the driver to be created must be created under the driver directory of the Pb-based platform. For example, create an ioctrol directory under the X: \ wince420 \ platform \ smdk2410 \ DRIVERS directory.

2) modify the dirs file in the DRIVERS directory.

3) Create the driver source file XXX. C, and implement the preceding stream interface function in the file. And add the DLL entry function:

Bool dllentry (hinstance hinstdll,/* @ parm instance pointer .*/

DWORD dwreason,/* @ parm reason routine is called .*/

Lpvoid lpreserved/* @ parm system parameter .*/

)

4) Create makefile, sources, and. Def files to control compilation.

5) use the CEC editor to modify the CEC file and compile the new features.

6) copy the four newly generated files to the release directory and modify the registry files platform. Reg and platform. bib.

7) make image.

8) download image.