Plan Your Device Driver (Compact 2013)
3/26/2014
Before you begin the implementation of a new device driver, you must understand the requirements of your device driver and how to select from Windows Embedded Compact features to satisfy these requirements. Because Windows Embedded Compact supports a variety of hardware platforms and peripheral devices, its device driver subsystem uses multiple device driver models and supports many different device driver types.
The specific character and internal definition of your device driver can vary greatly from other device drivers, depending on the following factors:
- The complexity of the hardware that your device driver supports
- How your device driver interfaces to the OS and applications
- Whether your device driver implementation reuses existing functionality
- Where your device driver runs: in kernel memory space or user memory space
These factors depend, in turn, on the product requirements and your development priorities. To start a device driver project that is customized specifically to your device hardware and your target platform, first you must understand which of these options are relevant to your requirements, and then select the options that are the most appropriate for your device driver needs. With your device driver options defined, you can concentrate only on the Windows Embedded Compact functionality that is relevant to your project.
Characterize Your Device Driver
Before selecting from the various device driver options provided by Windows Embedded Compact, determine your device driver’s required characteristics, and then select the interface type, device driver model, and run environment that offer these characteristics. Use the following steps to determine your device driver’s requirements:
- Identify the interface between your device driver and the device.
If your device driver communicates directly with device hardware, this interface consists of the memory ranges, registers, and ports that the device driver uses to control and move data to and from the device. An example of this kind of driver is a graphics adapter. If your device driver communicates with its device through an intermediate device (such as a bus), this interface is whatever API that is exposed by the intermediate device. An example of this kind of driver is a driver that communicates with a device through a USB connection. For more information about device drivers that communicate through an intermediate bus device, see Bus Drivers and Bus-Agnostic Drivers. - Identify the APIs that the device driver must expose.
If the device driver is intended to provide services to a specific application or a component of the operating system that already has a defined interface, your device driver must expose that interface. For example, if you are writing a new audio device driver, your device driver must expose the same interface as that exposed by other audio device drivers in the system. If your driver has no predefined interface to expose to the operating system or to applications, you must design an "upper interface" (to the OS and applications) for your driver. In this case, we encourage you to use the stream interface. For more information about the stream interface, see Stream Drivers. - Select a device driver interface type that supports the APIs that your device driver must expose.
This can be a stream interface or a native interface. For more information about device driver interface types, see Stream Drivers and Native Drivers. - Determine an appropriate mapping between the upper and lower interfaces.
This maps the application-level interface (the functions that applications or the operating system call in the device driver) to the functionality provided by the device. For example, an application-level ReadFile call or an XXX_Read (Device Manager) call into a storage device driver typically maps to a block-read operation on a storage device. - Identify any additional architectural factors that are relevant to your device driver.
For example, consider the following aspects:- Whether your driver must be componentized into separate, reusable modules.
- What parts of your driver, if any, can run outside the kernel for enhanced system robustness or security.
- Which functions are likely to have the most time or memory constraints.
For more information about selecting an appropriate architectural model for your device driver, see Layered and Monolithic Drivers. For more information about selecting an appropriate run-time environment for your device driver, see Kernel-Mode and User-Mode Drivers.
- Identify any remaining requirements and tradeoffs that go into the design of your device driver.
For example, consider the following questions:- Must your device driver emphasize performance over resource optimization?
- Are you reusing code from an existing device driver to speed your development time?
- Is development time more important than performance, CPU usage, and memory footprint?
- Can your device be powered on and off, and can it be power-managed?
This preliminary analysis helps you to make tradeoffs between performance, robustness, security, resource usage, and ease of development. When you have completed the steps listed earlier in this section, you can make informed choices from among the many device driver design options, depending on this preliminary characterization of your device driver.
Select Your Loading Strategy and Driver Access Name
After you have characterized your device driver’s requirements and you have identified the device driver model that best meets those requirements, you must decide how your device driver will be loaded and started. Also, you must choose the device driver name that applications and the OS will use to access your device driver. Use the following steps to determine how your device driver will be loaded and accessed:
- Select a device driver loading strategy
Depending on when your device driver is needed by the operating system, your driver can be loaded automatically during system start or it can be loaded on demand after system start. Depending on the kind of driver you implement, your driver is loaded and started by the Device Manager, GWES, or the file system. For more information about how to load and start your device driver, see Device Driver Loading. - Select a device driver access name
Applications and OS components can access your device driver through a legacy driver name, a device-based driver name, or a bus-based driver name. For more information about how to choose the appropriate access name that applications and the OS use to access your device driver, see Device Driver Access.