By modifying the Config.bib file of the cloned Device Emulator BSB, you can increasingly reduce the available RAM on the system and study the impact in terms of available memory on the system by using the memory information APIs or Platform Builder tools.
Chapter 6
Developing Device Drivers
Device drivers are components that enable the operating system (OS) and user applications to interact with peripheral hardware that is integrated or attached to a target device, such as the Peripheral Component Interconnect (PCI) bus, keyboard, mouse, serial ports, display, network adapter, and storage devices. Rather than accessing the hardware directly, the operating system loads the corresponding device drivers, and then uses the functions and input/output (I/O) services that these drivers provide to carry out actions on the device. In this way, the Microsoft® Windows® Embedded CE 6.0 R2 architecture remains flexible, extensible, and independent of the underlying hardware details. The device drivers contain the hardware-specific code, and you can implement custom drivers in addition to the standard drivers that ship with CE to support additional peripherals. In fact, device drivers are the largest part of the Board Support Package (BSP) for an OS design. However, it is also important to keep in mind that poorly implemented drivers can ruin an otherwise reliable system. When developing device drivers, it is imperative to follow strict coding practices and test the components thoroughly in various system configurations. This chapter discusses best practices for writing device drivers with proper code structures, developing a secure and well-designed configuration user interface, ensuring reliability even after prolonged use, and supporting multiple power management features.
Exam objectives in this chapter:
¦ Loading and using device drivers on Windows Embedded CE
¦ Managing interrupts on the system
¦ Understanding memory access and memory handling
¦ Enhancing driver portability and system integration
¦ To complete the lessons in this chapter, you must have the following:
¦ At least some basic knowledge about Windows Embedded CE software development, including fundamental concepts related to driver development, such as I/O control (IOCTL) and Direct Memory Access (DMA).
¦ An understanding of interrupt handling and how to respond to interrupts in a device driver.
¦ Familiarity with memory management in C and C++, as well as and knowledge of how to avoid memory leaks.
¦ A development computer with Microsoft Visual Studio® 2005 Service Pack 1 and Platform Builder for Windows Embedded CE 6.0 R2 installed.
Lesson 1: Understanding Device Driver Basics
On Windows Embedded CE, a device driver is a dynamic-link library (DLL) that provides a layer of abstraction between the underlying hardware, OS, and applications running on the target device. The driver exposes a set of known functions and provides the logic to initialize and communicate with the hardware. Software developers can then call the driver's functions in their applications to interact with the hardware. If a device driver adheres to a well-known application programming interface (API) such as Device Driver Interface (DDI), you can load the driver as part of the operating system, such as a display driver or a driver for a storage device. Without having to know details about the physical hardware, applications can then call standard Windows API functions, such as ReadFile or WriteFile, to use the peripheral device. You can support different types of peripherals by adding different drivers to the OS design without having to reprogram your applications.
After this lesson, you will be able to:
¦ Differentiate between native and stream drivers.
¦ Describe the advantages and disadvantages of monolithic and layered driver architectures.
Estimated lesson time: 15 minutes.
Native and Stream Drivers
A Windows Embedded CE device driver is a DLL that exposes the standard DllMain function as the entry point, so that a parent process can load the driver by calling LoadLibrary or LoadDriver. Drivers loaded by means of LoadLibrary can be paged out, but the operating system does not page out drivers loaded through LoadDriver.
While all drivers expose the DllMain entry point, Windows Embedded CE supports two different types of drivers: native drivers and stream drivers. Native CE drivers typically support input and output peripherals, such as display drivers, keyboard drivers, and touchscreen drivers. The Graphics, Windowing, and Events Subsystem (GWES) loads and manages these drivers directly. Native drivers implement specific functions according to their purpose, which GWES can determine by calling the GetProcAddress API. GetProcAddress returns a pointer to the desired function or NULL if the driver does not support the function.
Stream drivers, on the other hand, expose a well-known set of functions that enable Device Manager to load and manage these drivers. For Device Manager to interact with a stream driver, the driver must implement the Init, Deinit, Open, Close, Read, Write, Seek, and IOControl functions. In many stream drivers, the Read, Write, and Seek functions provide access to the stream content, yet not all peripherals are stream devices. If the device has special requirements beyond Read, Write, and Seek, you can use the IOControl function to implement the required functionality. The IOControl function is a universal function that can accommodate any special needs of a stream device driver. For example, you can extend a driver's functionality by passing a custom IOCTL command code and input and output buffers.
Native drivers must implement different types of interfaces depending on the nature of the driver. For complete information about the supported driver types, see the section 'Windows Embedded CE Drivers' in the Windows Embedded CE 6.0 Documentation, available on the Microsoft MSDN® Web site at
Monolithic vs. Layered Driver Architecture
