Search

Stream device drivers are accessed by applications using the file system API. This really limits the interface capabilities of device drivers. All that the file system interface allows the developer to perform are read, write, or seek operations. This is fine for real file I/O, but stream device drivers, though regarded as files are completely different. To allow the device driver to communicate custom operations it can perform on the peripheral device it controls, a special mode of operation was created. This method is not unique to Windows Embedded Compact 7 or Windows CE, it is part of the Win32 API and it has been part of UNIX and UNIX like systems since 1979, and allows stream device drivers to communicate custom operations to an application by calling the DeviceIoControl function. This function is implemented by Device Manager and exposed by it so it can be called from within user mode applications.

Any discussion about device drivers should provide some perspective of what device drivers are and why we need them. Practically, a device driver is an executable piece of software dedicated to access a specific peripheral hardware device in order to control it and to perform input/output (I/O) operations. Figuratively, you can think of a device driver as a negotiator between the operating system software and the hardware it uses. To understand this analogy we need to look at how multitasking operating systems, such as Windows Embedded Compact, handle peripheral hardware devices to provide a unified generic access method for their higher-level applications and processes.

The Network Driver Interface Specification (NDIS) is the specification for network driver architecture that allows transport protocols such as TCP/IP, Native ATM, IPX, and NetBEUI to communicate with an underlying network adapter. The implementation of this specification is an applicative framework for developing network device drivers. Network device drivers provide access for Windows Embedded Compact 7 based devices to local and wide area networks. The Windows Embedded Compact-based communications architecture supports network device drivers’ implemented using Network Driver Interface Specification (NDIS) framework as well as technologies such as Remote NDIS (RNDIS), NDISWAN, Token Ring, Wi-Fi, IrDA, and Bluetooth.

Testing is the final phase of the development cycle before being able to release any product, software or hardware. The aim of testing is to assure the finished product is of the highest quality. Quality software products are a must in the twenty-first century when reliance on high-quality software has bearing on almost any facet in our lives. Developers seem to sneer at this process and QA people are often regarded as second rate to the designers and coders. However the ISO standards of software development force software vendors and OEMs to take notice and enforce strict testing for quality assurance. Pro Windows Embedded

The essence of any computer system is to accept input data, process it, and produce output. How the system accepts input data is critical for real-time embedded systems. Because it needs to process the input data and output a response within a determined time interval. The most accurate way to achieve this would be to poll an input source constantly for data. This however puts a heavy burden on the CPU, limiting the system to just one task. Waiting for input data to arrive and react on it alleviates this burden and frees CPU resources. To be able to wait and react, we need hardware support for getting CPU attention away from its flow of processing.

I know that most readers at this point feel the itch at their fingertips to just start hitting the keyboard and implement a device driver. Device drivers, unlike applications, are fairly straightforward units of software so why not get to the point. My answer to this valid question is twofold; it eliminates costly mistakes and saves time. It eliminates mistakes because it forces you to research and understand the hardware. Select the right model for your design. Plan the device driver structure; think through how the device driver will access memory. Think through and plan the device driver interrupt handling. You save time by avoiding ad hoc development and the information you gather for the design helps even if using a third-party tool like the device driver wizard to generate a jumpstart device driver skeleton more efficient. This chapter is designed to highlight the points you should consider when planning and designing your device driver.

Stream interface device driver are the most frequently developed device drivers for Windows Embedded Compact 7 as it is for earlier versions of Windows CE. Stream device drivers are loaded and managed by Device Manager and provide a well-known unified interface. Therefore, it allows user mode applications to access stream interface device drivers’ services. User mode applications use file system APIs such as CreateFile to open an instance of a stream interface device driver and file I/O APIs to read or write data from and to the device. The stream interface can be found in kernel mode device drivers as well as user mode device drivers and in this latest version of the operating system in filter device drivers.

“Tools of trade” is a term utilized in bankruptcy law to establish what assets a person would commonly use for the purpose of making a living. To make a living as device driver developers, our “Tools of trade” are VS2008, Platform Builder (PB), and third-party tools.

The device driver developer community is a mixed bag of either hardware-predominant developers or software-predominant developers. If you belong to the latter you need to keep it in mind that it is impossible to write device driver interface code for the hardware, without understanding the hardware. This chapter is beneficial to developers of both backgrounds as the former will find useful programming tips and the later useful hardware specification tips.

Can youname a developer that can develop a bug-free software unit excluding “Hello World” program? I thought not. The main reason that the development cycle of software is such a lengthy process is errors in the code implementation, better known as “bugs” (with “debugging” becoming the word to describe the process of sieving these bugs out of the software). The end result of the existence of bugs in software is that the executable will fail at one time or another. The complexity of developing software that manages hardware is directly accountable for bugs that are manifold more complex and hard to fix. The most difficult bugs to fix are bugs that occur infrequently and cannot be easily reproduced. These are usually the logical bugs rather than the coding bugs. Kernel mode device drivers present the added danger of crashing the system if failure occurs in their code.

This chapter is all about the Windows Embedded Compact 7 registry and how it relates to device drivers. A general discussion about the registry and its role in the system is followed by a thorough discussion of all device driver related registry topics, including how the OS loads device drivers; naming conventions of device drivers, so that applications can interact with device drivers via the file system; which keys are required to set by the developer of a device driver and which keys are optional; and how to setup registry entries for user mode device drivers, and how to put it all together in practical terms.

Device driver type is really an ambiguous term. Windows Embedded Compact 7 views two basic types of device drivers; Native and Stream device drivers. A third (which is really a combination of the two) is called a hybrid device driver. A native device driver is a built-in device driver that is loaded and called by GWES at boot time and exposes a custom API set that is unique to the device driver class. A device driver that manages an IO device built into the hardware platform and is managed by Device Manager and exposes a stream interface is regarded as a stream device driver. Hybrid device drivers expose both a custom-purpose interface and a stream interface to the rest of the system.