KITL is also a requirement if you want to centralize system testing based on the CETK Test application, although it is also possible to run CETK tests in standalone mode. If you are developing a custom BSP for a target device, you can use the CETK to perform automated or semi-automated component tests based on custom Tux DLLs. Platform Builder includes a WCE TUX DLL template to create a skeleton Tux module that you can extend to meet your specific testing needs. You can integrate the custom Tux DLL in the CETK test application and run tests individually or as part of a larger test suite. Because all CETK tests use the same logging engine and log file format, you can use the same parser tool to analyze the results of default and user-defined tests.
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.
■ Debug Zones
■ KITL
■ Hardware debugger
■ dpCurSettings
■ DebugX
■ Target Control
■ Tux
■ Kato
Suggested Practices
To help you successfully master the exam objectives presented in this chapter, complete the following tasks.
Detect Memory Leaks
Add a subproject to the OS design for a console application that generates memory leaks by allocating memory blocks and never freeing them. Using the tools discussed in this chapter, isolate the issue and fix it.
Custom CETK Test
Add a subproject to the OS design for a WCE TUX DLL. Build the Tux DLL and register it in the Windows Embedded CE Test Kit application. Run a CETK test and verify the test results. Set breakpoints in your Tux DLL and debug the code by running a CETK test in standalone mode.
Chapter 5
Customizing a Board Support Package
Application developers do not often need to create a Board Support Package (BSP). However, Original Equipment Manufacturers (OEMs) face this requirement when porting Microsoft® Windows® Embedded CE 6.0 R2 to a new hardware platform. To help OEMs accomplish this task efficiently, Windows Embedded CE features a production-quality OEM adaptation layer (PQOAL) architecture that promotes code reuse based on a collection of OAL libraries organized by processor model and OAL function. Microsoft encourages OEM developers to clone and customize an existing BSP to meet their specific requirements and take full advantage of tested and proven production features for power management, performance optimizations, and input/ output controls (IOCTL). This chapter covers the PQOAL architecture, explains how to clone BSPs, and lists the functions that OEM developers must implement in order to adapt Windows Embedded CE to new hardware architectures and models. It is advantageous to understand the various aspects of customizing a BSP even if you do not intend to develop your own. This chapter will provide an overview of the aspects of BSP customization, ranging from modifications of the startup process and implementing kernel initialization routines, to adding device drivers, power management capabilities, and support for performance optimization.
Exam objectives in this chapter:
■ Understanding the BSP architecture of Windows Embedded CE
■ Modifying and adapting BSPs and boot loaders for specific target devices
■ Understanding memory management and layout
■ Enabling power management in a BSP
To complete the lessons in this chapter, you must have the following:
■ At least some basic knowledge about Windows Embedded CE software development.
■ A thorough understanding of hardware architectures for embedded devices.
■ Basic knowledge about power management and how to implement it in drivers and applications.
■ A development computer with Microsoft Visual Studio® 2005 Service Pack 1 and Platform Builder for Windows Embedded CE 6.0 R2 installed.
Lesson 1: Adapting and Configuring a Board Support Package
The BSP development process for a new hardware platform typically begins after performing functional tests of the hardware by using a ROM monitor, by cloning an appropriate reference BSP, followed by implementing a boot loader and the core OAL functions to support the kernel. The goal is to create a bootable system with the least possible amount of custom code. You can then add device drivers to the BSP to support integrated and peripheral hardware and expand the system by implementing power management and other advanced operating system (OS) features according to the capabilities of the target device.
After this lesson, you will be able to:
■ Identify and locate the content of a PQOAL-based Board Support Package.
■ Identify hardware-specific and common-code libraries.
■ Understand how to clone a BSP.
■ Adapt a boot loader, OAL, and device drivers.
Estimated lesson time: 40 minutes.
Board Support Package Overview
A BSP contains all the source code for the boot loader, OAL, and device drivers for a given platform. In addition to these components, the BSP also contains build and system configuration files, as illustrated in Figure 5-1. The configuration files are not included in the actual run-time image, yet they are part of the BSP package to specify source code files, memory layout, registry settings, and other aspects to compile and build the run-time image, as explained in Chapter 2, "Building and Deploying a Run-Time Image."
Figure 5-1 Components of a BSP in relationship to the remaining elements of Windows Embedded CE 6.0
According to Figure 5-1, BSP development includes the following main components:
■ Boot loader Runs when powering up or resetting the device. The boot loader is responsible for initializing the hardware platform and passing execution to the operating system.
■ OEM adaptation layer (OAL) Represents the core of the BSP and is the interface between the kernel and the hardware. Because it is linked directly to the kernel, it becomes part of the kernel in a CE run-time image. Some of the core kernel components are directly dependent on the OAL for hardware initialization, such as the interrupt handling and timer handling for the thread scheduler.
■ Device drivers Manage the functionality of a particular peripheral and provide an interface between the device hardware and the operating system. Windows Embedded CE supports a variety of driver architectures based on the interfaces they expose, as explained in Chapter 6, "Developing Device Drivers."
■ Configuration files Provide the necessary information to control the build process and plays a key role in the design of a platform's operating system. Typical configuration files included in BSPs are Sources files, Dirs files, Config.bib, Platform.bib, Platform.reg, Platform.db, Platform.dat, and catalog files (*.pbcxml).