6. Verify that Visual Studio automatically opens the DeviceEmulatorClone.pbcxml catalog file. Close the catalog editor without making any changes.
Figure 5-10 BSP cloning information
► Create a Run-Time Image
1. In order to validate our cloned BSP, create a new OS design based on the DeviceEmulatorClone BSP. Call the OS design DeviceEmulatorCloneTest, as illustrated in Figure 5-11 (see also Lab 1 in Chapter 1 for details on how to accomplish this step).
2. Choose Industrial Device in the Design Templates and Industrial Controller in the Design Template Variants. Accept the default options in the subsequent steps of the wizard.
3. After Platform Builder generates the DeviceEmulatorCloneTest project, verify the OS design by examining the catalog items in Catalog Items View.
4. Verify that the Debug build configuration is enabled by opening Configuration Manager on the Build menu and seeing if the Active Solution Configuration list box displays DeviceEmulatorClone ARMV4I Debug.
5. On the Build menu, click Build Solution.
6. After the build is completed, configure the Connectivity Options to use the Device Emulator.
7. Open the Target menu and click Attach Device to download the run-time image to the Device Emulator and start Windows Embedded CE. Notice the debug messages in the Output window of Visual Studio 2005. Wait until the device has started up completely.
Figure 5-11 A new OS design based on the DeviceEmulatorClone BSP
Device Emulator emulates the same hardware platform for both the reference BSP and the cloned BSP. For this reason, the new run-time image runs on Device Emulator without further adaption. In practice, however, the underlying hardware is different in most cases, requiring BSP adaptations to start CE successfully.
► Customize the BSP
1. Detach from the target device and close Device Emulator.
2. In Visual Studio, open the init.c source code file that you can find in the %_PLATFORMROOT%\DeviceEmulatorClone\Src\Oal\Oallib folder, as illustrated in Figure 5-12.
3. Search for the OAL function OEMGetExtensionDRAM and add the following line of code to print a debug message in the Output window of Visual Studio during system startup.
BOOL OEMGetExtensionDRAM(LPDWORD lpMemStart, LPDWORD lpMemLen) {
...
OALMSG(OAL_FUNC, L"++OEMGetExtensionDRAM\r\n"));
// Test message to confirm that our modifications are part of run-time image.
OALMSG(1,(TEXT("This modification is part of the run-time image.\r\n")));
...
}
4. Rebuild the run-time image to includes the changes, and then attach to the device again in order to download and start the new run-time image in Device Emulator. Verify that Windows Embedded CE prints the debug message in the Output window.
Figure 5-12 DeviceEmulatorClone BSP customization
Chapter Review
The adaptation of a BSP is one of the most complicated and critical development tasks that OEMs face when porting Windows Embedded CE 6.0 to a new hardware platform. To facilitate this undertaking, Microsoft provides reference BSPs with Platform Builder and encourages OEMs to start the development process by cloning the most suitable BSP. The PQOAL-based BSPs follow a well-organized folder and file structure to separate platform-agnostic and platform-specific code by processor type and OAL function so that OEMs can focus on platform-specific implementation details without getting side tracked by general aspects of the kernel or operating system.
OEM developers should consider the following recommendations to ensure a successful adaptation of a BSP:
■ Study the Windows Embedded CE reference BSPs Windows Embedded CE BSPs follow a well-defined architecture with close relationships to the kernel. This makes it necessary to implement numerous APIs that the kernel requires to run the operating system. Knowing these APIs and their purpose is very important. The PQOAL-based architecture is continually evolving.
■ Clone a BSP Avoid writing a new BSP completely from scratch. Instead, clone a BSP to jump start the adaptation process. By reusing as much code as possible from a reference BSP, you not only shorten development time, but also increase the quality of your solution and provide a solid foundation for efficient handling of future upgrades.
■ Boot loader and BLCOMMON Use BLCOMMON and related libraries when implementing a boot loader because these libraries provide useful hardware-independent features for downloading run-time images and enabling users to interact with the target device during the startup process.
■ Memory and BSPs Make sure you thoroughly understand how Windows Embedded CE 6.0 deals with physical and virtual memory. Configure <Boot loader>.bib and Config.bib files to provide accurate information about available memory to the operating system and adjust the entries in the OEMAddressTable, if necessary. Keep in mind that you cannot directly access physical memory in Windows Embedded CE. Use the correct memory-mapping APIs to map physical memory addresses to virtual memory addresses.
■ Implement power management Implement the OEMIdle function to enable the system to switch the CPU into Idle mode. Consider implementing OEMPowerOff as well, if your platform supports power state transitions into Suspend mode in response to user actions or critical battery levels.
Key Terms
Do you know what these key terms mean? You can check your answers by looking up the terms in the glossary at the end of the book.
■ PQOAL
■ Boot loader
■ KernelIoControl
■ Driver globals
Suggested Practices
To help you successfully master the exam objectives presented in this chapter, complete the following tasks.
Access the Hardware Registers of a Peripheral Device
Implement a device driver for peripheral hardware and access the hardware registers by using the MmMapIoSpace API to interact with the device. Note that it is not possible to call MmMapIoSpace from an application.
Because Device Emulator emulates an ARM processor in software, you cannot access hardware devices. You must use a genuine hardware platform to perform this suggested practice.
Reorganize Platform Memory Mappings
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.