Go to: wince6.0 driver development (excerpt)

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.

Port. 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

Perform operations on hardware devices like normal files. 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 the hardware I/O specification cannot be executed

. 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,

You can access any memory area.

5) The hardware system resources are naked in front of the driver. The driver can use all system resources. We must

Be extremely careful when driving code boundary conditions to ensure that 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. However, in the WinCE system, due to limited hardware resources and the characteristics of embedded systems, it is highly supported.

Limits.

3. WinCE system driver introduction:

1) after all, WinCE is an embedded system with its own particularity. To improve operation efficiency, all drivers are dynamic link libraries,

All standard APIs can be called in the driver implementation. In other Windows systems, the possible driver files include. vxd,. sys, and dynamic link.

Connect to the database.
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 set 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 flow interface driver calls from the Device Manager and

Use a program to receive commands. 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. And local

Compared with the driver, all stream interface drivers use the same set of interface functions, including: XXX_Init, XXX_Deinit,

XXX_Open, XXX_Close, XXX_Read, XXX_Write, XXX_PowerUp, XXX_PowerDown, XXX_Seek,

XXX_IOControl: These functions work with hardware. User functions: CreateFile, DeviceIoControl, ReadFile,

WriteFile. These functions allow you to easily use the driver.

3) The driver Loading Method under WinCE:

-- Using GWES (Graphics, drawing wing, and Events Subsystem): Mainly loads drivers related to display and input,

Such as mouse and keyboard driver. These drivers are generally local drivers.
-- Device manager: drivers of both structures are loaded. The local driver is mainly loaded by PCMCIA Host Controller and USB

Host Controller driver, mainly bus drivers; stream interface drivers mainly include audio drivers and serial port drivers.
-- Dynamic Loading: the first two are loaded when the system starts. Dynamic Loading allows the device to mount the driver to the kernel when it is mounted to the system.

An external board driver and a USB device driver are required.

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. By

ActiveDeviceEx is called through the Device Manager. The returned value is generally a Data Structure pointer, which is passed to other streams as function parameters.

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. Returns TRUE if the call is successful.

.

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. Indirectly called by applications 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.

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

Build the same command between the layer and the driver, and implement the CTL_CODE (DeviceType, Function, Method, Access

Now. 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

All support this feature.

5. Stream interface driver loading and registry settings:

Start the device management program when the system starts. The device management program reads the content of the HKEY_LOCAL_MACHINE "Drivers" BuiltIn key and adds

Contains 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 is required.

Must be consistent with them.

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, in x: "Wince420

Create an IOCtrol directory under the "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

Generally, we need LocalAlloc in the driver to reserve a bucket, and then map the I/O port to the address using LocalCopy. Then we can access the reserved address.
The handling of interruptions varies with various devices. If it is a built-in device (Built In), a new interrupt is generally defined In the oalintr. h file, and the OAL layer is added to handle the interrupt. Create an event with CreateEvent in the driver's Init function, call InterruptInitialize to associate the defined interrupt with the created event, and create a thread, in this thread, WaitforSingleObject is called to wait for this event. when the device is interrupted, this event is triggered. WaitforSingleOjbect returns and the thread is running, so that we can handle this interruption.
The newly added processing of the interrupt in OAL is the so-called ISR content, and this thread is called IST.

Others

1. The number of devices with the same name under CE cannot exceed 10

This problem is no longer found in CE5.0,
Previous versions can do this:
Only one device is output to the upper layer,
Then, use IOCTL to open physical devices.
In this way, no restrictions are imposed.

2. MDD and PDD

A driver is usually divided into two parts: hardware-related (PDD) and hardware-independent (MDD) layers.
Of course, this layering is not necessary, but you can write much less code after adopting this hierarchy, because Microsoft provides a lot of driver MDD. Even if CE does not have an example of the driver we have written, after adopting this structure, when you need to write a second program, you can reuse its code to improve development efficiency.

MDD provides functions that can be used by devices of the same type (such as serial ports), so that PDD only supports register operations.
For example, most of the code of the serial port interrupt processing and Read/Write functions is implemented in MDD,
In implementation of different serial ports, you only need to provide some functions of the actual operation register.

The MDD and PDD interfaces of different drivers are different,
Therefore, when we face a specific driver, we need to find out which functions need to be provided.

3 XXX_Init function return handle

Generally, this handle is a pointer for the driver to save data,
We will tell the upper-layer program when Init returns, and when other upper-layer functions (such as Open) are called later,
This value is passed in, so that we can access some of our own private data.

Of course, an arbitrary non-0 value can also be returned.

For a device driver, the layers not used by the system have different handles.
The handle returned in XXX_Init is saved in the Device Manager, which cannot be seen in other programs,
Using CreateFile will also get a file handle, which I don't know where to save,
But it is different from the former.

That is to say, the handles of software at different layers will be different.

4. Differences between DEBUGMSG and RETAILMSG

They are used to output debugging information,
The difference is:
DEBUGMSG is valid only in the DEBUG version. In the RELEASE version, it is defined as NULL.
RETAILMSG can be output in both DEBUG and RELEASE versions,
In addition, DEBUGMSG can be used to control whether to output information at runtime.

During ship build, both RETAILMSG and DEBUGMSG are invalid.

5. Two desktops are displayed on the video screen, which should be:

The screen size is set to only half of the actual size (height ).

That is to say, the screen height is 600, and the height set in your driver is 300.

Of course, you can also modify the program to make the lower half of it output black.

Address Allocation:

For ARM, there are virtual addresses and physical addresses. For WINCE, there are also virtual addresses and physical addresses. In this case, the virtual address of ARM is the physical address of the WINCE system.
32-bit OS has a total of 4 GB virtual address space, and WINCE is no exception. 0x00000000 ~ 0x80000000 is Application Space; 0x80000000 ~ 0xffffffff is System Reserved. the physical address of the System is in the System Reserved segment and can only be accessed in the kernel mode. so what if APPLICATION and DRIVER (both running in user mode) want to access these hardware registers or MEMORY in the System Reserved address segment? I had to create another ing relationship, allocate a Space in Application Space, and map it to the address in System Reserved. This is what VirtualAlloc/Copy and MmMapIoSpace do.

This article from the CSDN blog, reproduced please indicate the source: http://blog.csdn.net/loongdao777/archive/2008/05/22/2470066.aspx