Introduction to Windows CE driver

Chapter 1 Introduction to Windows CE driver

1.1 What is driver

Device Drivers are software that extracts physical or virtual devices from the operating system.

The device driver is the way for the operating system to interact with the hardware.

The Bridge of the operating system.

Category:

(1) classification by layer or not: single-layer drivers, stratified drivers, and hybrid drivers;

(2) classification by loading time: built-in drivers and stream drivers;

(3) classification by loaded location: User-mode driver and kernel-mode driver.

Driving model Glossary:

(1) DDI (Device Driver Interface) function: it is the interface protocol for the operating system to communicate with the driver;

(2) MDD (Model Device Driver) model device driver;

(3) PDD (platform dependence driver): Platform-related driver;

(4) ddsi (Device Driver Service Provider Interface) function: interface protocol for communication between MDD and PDD.

Layered drive: (MDD/PDD)

MDD is a common model driver for different platforms. It is both a source code and a library. It connects to the PDD layer and defines the functions it wants to call, provide pre-defined functions to the operating system to handle complex tasks such as interrupt processing. In general, MDD does not need to be modified.

Both PDD and MDD have hardware interfaces, which requires them to be suitable for the needs of the target platform. a PDD consists of hardware-specific functions that correspond to an mdd, however, such correspondence is not a direct one-to-one correspondence.

Single-layer driver:

A single-layer driver writes all the drivers together. It is an old driver programming method that requires a lot of programmers.

Built-in driver;

The built-in driver is not managed by the driver manager, and there is no need to export the same API interface as the common driver. The built-in driver is generally used only by the GWES (graphical windows and Event System) process and loaded by GWES. EXE. These drivers are generally I/O device drivers related to the graphic interface.

Stream drive:

A stream driver is short for a stream interface driver. Whether it is a physical device or a virtual device, as long as their drivers export the stream interface functions for the system or application, such a driver can be called a stream driver.

A Windows CE stream driver is used as a specific file system device. The Stream interface functions provided by Windows CE are closely related to the API functions of the common file system, such as openfile () and readfile () when using these API functions, you can change the specified file name to the corresponding device name.

The stream driver is loaded or managed through the Device Manager.

User Mode and Kernel Mode Driver

In the Win CE architecture, the driver can run both in user mode and in kernel mode. The kernel-mode driver runs in the kernel context, and the user-Mode Driver runs in one or more processes. The Device Manager (devmgr. dll) manages user mode and kernel mode drivers.

Kernel Mode Driver:

The Device Manager loads all drivers to the kernel space as kernel-mode drivers by default, unless the devflags_load_as_userproc flag is set in the registry. The kernel-mode driver can call the kernel API functions and directly use the kernel's coredll to call K. coredll. dll. Therefore, the execution efficiency is high because it can directly use the user's storage space. The kernel-mode driver does not limit the read/write memory.

User Mode Driver:

When the devflags_load_as_usermode flag is set in the Registry, the loaded driver is the user mode driver. In this case, udevice.exe will be used as the main driver of the user model. It will isolate other drivers, that is, this driver will not affect other drivers.

Steps for driver development:

The following six steps are required to develop a complete Windows CE driver.

(1) the working principle of hardware to be developed. The code of the device driver Directly Interacts with the hardware. Therefore, developers must fully understand the working principle, functional features, and working methods of the hardware to be developed. This usually requires developers to patiently read the data manual. This step is relatively simple, and you only need to understand the data manual.

(2) study the operating mechanism of the Windows CE driver.

Let's take a look at some points.

1) access peripherals.

2) handling of interruptions.

3) process DMA.

4) memory access method.

5) synchronous and asynchronous operations.

(3) select an appropriate driver model. Select an appropriate driver model based on actual project requirements.

(4) write the code. Compile your own Driver Based on the driver template Code provided by Microsoft.

(5) debugging. Debugging is also critical. If this step is skipped, the performance of the driver is not guaranteed. The worst case for this step is probably to redesign the driver from the first step.

After the above steps are completed, a complete driver development is complete.

Driver code shared by Windows CE

Path
Description
Wince600 \ platform \ % _ tgtplat %
Contains code related to the hardware platform. This directory mainly contains the oal, configuration file, and BSP driver. You can modify the driver wince600 \ platform \ % _ tgtplat % drivers dependent on the hardware platform in the following path.
Wince600 \ platform \ common \ SRC \ SOC
The SOC driver contains a driver that depends on a specific processor. The SOC driver includes the real-time clock, timer, debugging Nic, and other microprocessor-related oal drivers. The same SOC driver library can be used when the microprocessor is the same
Wince600 \ public \ common \ oak \ drivers
The general driver contains platform-independent driver code, which can be linked to platform-related code to create a hardware driver. The general driver does not specify the hardware platform and processor type. Any SDB (standard development board) card can use these drivers

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/guly699/archive/2009/10/06/4636005.aspx