Chapter 3 - Performing System Programming

i

Windows Embedded CE 6.0

Not for Resale.

Up to Date

with

R2

Content Self-Paced Training

MCTS Exam 70-571Preparation Kit 免责声明：资源来自互联网，严禁非法用途，本人不负有任何责任。

2first top-level entry

Contents at a Glance

1Customizing the Operating System Design

2Building and Deploying the Run-Time Image 3Performing System Programming

4Debugging and Testing the System

5Customizing a Board Support Package

6Developing Device Drivers

Chapter 3

Performing System Programming System performance is critical for user productivity. It directly influences the user’s perception of a device. In fact, it is not uncommon for users to judge the usefulness of

a device based on the performance of the system and the look and feel of the user

interface. By providing too complex of an interface, you can confuse users and open your device to potential security risks or unexpected user manipulations. By using the incorrect APIs, or incorrect applications architecture in a multithreaded environment, you may significantly impact performance. Performance optimization and system customization are real challenges for firmware providers. This chapter discusses the tools and highlights best practices to achieve optimal system response times on target devices.

Exam objectives in this chapter:

■Monitoring and optimizing system performance

■Implementing system applications

■Programming with threads and thread synchronization objects

■Implementing exception handling in drivers and applications

■Supporting power management at the system level

Before You Begin

To complete the lessons in this chapter, you must have the following:

■ A thorough understanding of real-time systems design concepts, such as scheduler functionality in an operating system, interrupts, and timers.

■Basic knowledge of multithreaded programming, including synchronization objects.

■ A development computer with Microsoft? Visual Studio? 2005 Service Pack 1 and Platform Builder for Microsoft Windows? Embedded CE 6.0 installed.

81

82Chapter 3Performing System Programming

Lesson 1: Monitoring and Optimizing

System Performance

Performance monitoring and optimization are important tasks in the development of small-footprint devices. The need for optimized system performance remains critical because of an ever-growing number of increasingly complex applications and the requirement for intuitive and therefore resource-intensive user interfaces.

Performance optimization requires firmware architects and software developers to constrain resource consumption within their system components and applications so that other components and applications can use the available resources. Whether developing device drivers or user applications, optimized processing algorithms can help to save processor cycles, and efficient data structures can preserve memory.

Tools exist at all system levels to identify performance issues within and between drivers, applications, and other components.

After this lesson, you will be able to:

■Identify the latency of an interrupt service routine (ISR).

■Improve the performance of a Windows Embedded CE system.

■Log and analyze system performance information.

Estimated lesson time: 20 minutes.

Real-Time Performance

Drivers, applications, and OEM adaptation layer (OAL) code impact system and real-time performance. Although Windows Embedded CE may be used in real-time and non-real-time configurations, it is important to note that using non-real-time components and applications can decrease system performance in a real-time operating system (OS) configuration. For example, you should keep in mind that demand paging, device input/output (I/O), and power management are not designed for real-time devices. Use these features carefully.

Demand Paging

Demand paging facilitates memory sharing between multiple processes on devices with limited RAM capacity. When demand paging is enabled, Windows Embedded CE discards and removes memory pages from active processes under low-memory conditions. However, to keep the code of all active processes in memory, disable

Lesson 1: Monitoring and Optimizing System Performance83 demand paging for the entire operating system or for a specific module, such as a dynamic-link library (DLL) or device driver.

You can disable demand paging by using the following methods:

■Operating system Edit the Config.bib file and set the ROMFLAGS option in the CONFIG section.

■DLLs Use the LoadDriver function instead of the LoadLibrary function to load the DLL into memory.

■Device drivers Add the DEVFLAGS_LOADLIBRARY flag to the Flags registry entry for the driver. This flag causes Device Manager to use the LoadLibrary function instead of the LoadDriver function to load the driver.

Windows Embedded CE allocates and uses memory as usual, but does not discard it automatically when you disable demand paging.

System Timer

The system timer is a hardware timer that generates system ticks at a frequency of one tick per millisecond. The system scheduler uses this timer to determine which threads should run at what time on the system. A thread is the smallest executable unit within a process that is allocated processor time to execute instructions in the operating system. You can stop a thread for an amount of time by using the Sleep function. The minimum value that you can pass to the Sleep function is 1 (Sleep(1)), which stops the thread for approximately 1 millisecond. However, the sleep time is not exactly 1 millisecond because the sleep time includes the current system timer tick plus the remainder of the previous tick. The sleep time is also linked to the priority of the thread. The thread priority determines the order in which the operating system schedules the threads to run on the processor. For those reasons, you should not use the Sleep function if you need accurate timers for real-time applications. Use dedicated timers with interrupts or multimedia timers for real-time purposes. Power Management

Power management can affect system performance. When the processor enters the Idle power state, any interrupt generated by a peripheral or the system scheduler causes the processor to exit this state, restore the previous context, and invoke the scheduler. Power context switching is a time-consuming process. For detailed information about the power management features of Windows Embedded CE, see the section “Power Management” in the Windows Embedded CE 6.0 documentation

84Chapter 3Performing System Programming

available on the Microsoft MSDN? website at https://www.sodocs.net/doc/9915851342.html,/en-us/ library/aa923906.aspx.

System Memory

The kernel allocates and manages system memory for heaps, processes, critical sections, mutexes, events, and semaphores. Yet, the kernel does not completely free the system memory when releasing these kernel objects. Instead, the kernel holds on to the system memory to reuse it for the next allocation. Because it is faster to reuse allocated memory, the kernel initializes the system memory pool during the startup process and allocates further memory only if no more memory is available in the pool.

System performance can decrease depending how processes use virtual memory, heap objects, and the stack.

Non-Real-Time APIs

When calling system APIs, or Graphical Windows Event System (GWES) APIs, be aware that some APIs rely on non-real-time features, such as for window drawing.

Forwarding calls to non-real-time APIs may dramatically decrease system

performance. Consequently, you should make sure that your APIs in real-time applications are real-time compliant. Other APIs, such as ones used for accessing a file system or hardware, can have an impact on performance because these APIs may use blocking mechanisms, such as mutexes or critical sections, to protect resources.

Real-Time Performance Measurement Tools

Windows Embedded CE includes many per for mance monitoring and troubleshooting tools that can be used to measure the impact of Win32 APIs on system performance. These tools are helpful when identifying inefficient memory use, such as an application not releasing the system memory it allocates.

The following Windows Embedded CE tools are particularly useful to measure the real-time performance of your system components and applications:

Lesson 1: Monitoring and Optimizing System Performance85

■ILTiming Measures Interrupt Service Routine (ISR) and Interrupt Service Thread (IST) latencies.

■OSBench Measures system performance by tracking the time the kernel spends managing kernel objects.

■Remote Performance Monitor Measures system performance, including memory usage, network throughput, and other aspects.

Interrupt Latency Timing (ILTiming)

The ILTiming tool is particularly useful for Original Equipment Manufacturers (OEMs) who want to measure ISR and IST latencies. Specifically, ILTiming enables you to measure the time it takes to invoke an ISR after an interrupt occurred (ISR latency) and the time between when the ISR exits and the IST actually starts (IST latency). This tool uses a system hardware tick timer by default, but it is also possible to use alternative timers (high-performance counters).

The ILTiming tool relies on the OALTimerIntrHandler function in the OAL to implement the ISR for managing the system tick interrupt. The timer interrupt handler stores the current time and returns a SYSINTR_TIMING interrupt event, which an ILTiming application thread waits to receive. This thread is the IST. The time elapsed between the reception of the interrupt in the ISR and the reception of the SYSINTR_TIMING event in the IST is the IST latency that the ILTiming tool measures. You can find the ILTiming tool’s source code in the %_WINCEROOT%\Public \Common\Oak\Utils folder on your development computer if you have installed Microsoft Platform Builder for Windows Embedded CE 6.0 R2. The ILTiming tool supports several command-line parameters that you can use to set the IST priority and type according to the following syntax:

iltiming [-i0] [-i1] [-i2] [-i3] [-i4] [-p priority] [-ni] [-t interval] [-n interrupt] [-all] [-o file_name] [-h]

Table 3–1 describes the individual ILTiming command-line parameters in more detail.

86Chapter 3Performing System Programming

Table 3-1ILTiming parameters

Description

Command-Line

Parameter

-i0No idle thread. This is equivalent to using the -ni parameter.

-i1One thread spinning without performing any actual

processing.

-i2One thread spinning, calling SetThreadPriority

(THREAD_PRIORITY_IDLE).

-i3Two threads alternating SetEvent and WaitForSingleObject

with a 10-second timeout.

-i4Two threads alternating SetEvent and WaitForSingleObject

with an infinite timeout.

-i5One thread spinning, calling either VirtualAlloc (64 KB),

VirtualFree, or both. Designed to flush the cache and the

translation look-aside buffer (TLB).

-p priority Specifies the IST priority (zero through 255). The default

setting is zero for highest priority.

-ni Specifies no idle priority thread. The default setting is equal to

the number of idle priority thread spins. This is equivalent to

using the -i0 parameter.

-t interval Specifies the SYSINTR_TIMING timing interval, with clock

ticks in milliseconds. The default setting is five.

-n interrupt Specifies the number of interrupts. Using this parameter you

can specify how long the test will run. The default setting is 10.

-all Specifies to output all data. The default setting is to output the

summary only.

-o file_name Specifies to output to file. The default setting is to output to the

debugger message window.

Lesson 1: Monitoring and Optimizing System Performance87

Operating System Benchmark (OSBench)

The OSBench tool can help you measure system performance by identifying the time that the kernel spends managing kernel objects. Based on the scheduler, OSBench collects timing measurements by means of scheduler performance-timing tests. A scheduler performance-timing test measures how much time basic kernel operations, such as thread synchronization, require.

OSBench enables you to track timing information for the following kernel operations:

■Acquiring or releasing a critical section.

■Waiting for or signaling an event.

■Creating a semaphore or mutex.

■Yielding a thread.

■

The OSBench tool supports several command-line parameters that you can use according to the following syntax to collect timing samples for kernel operations: osbench [-all] [-t test_case] [-list] [-v] [-n number] [-m address] [-o file_name] [-h] Table 3–2 describes the individual OSBench command-line parameters in more detail.

Check out the OSBench source code to identify the test content. You can find the source code at the following locations:

■%_WINCEROOT%\Public\Common\Oak\Utils\Osbench

■%_WINCEROOT%\Public\Common\Oak\Utils\Ob_load

Test results are by default sent to the debug output, but can be redirected to a CSV file.

88Chapter 3Performing System Programming

Remote Performance Monitor

The Remote Performance Monitor application can track the real-time performance of the operating system as well as memory usage, network latencies, and other elements.Each system element is associated with a set of indicators that provide information on usage, queue length, and delays. Remote Performance Monitor can analyze log files generated on a target device.

Table 3-2OSBench parameters

Command-Line

Parameter

Description -all Run all tests (default: run only those specified by -t option):

TestId 0: CriticalSections.

TestId 1: Event set-wakeup.

TestId 2: Semaphore release-acquire.

TestId 3: Mutex.

TestId 4: Voluntary yield.

TestId 5: PSL API call overhead.

TestId 6: Interlocked API's (decrement, increment,

testexchange, exchange).

-t test_case ID of test to run (need separate -t for each test).

-list List test ID's with descriptions.

-v Verbose: show extra measurement details.

-n number Number of samples per test (default =100).

-m address Virtual address to write marker values to (default = ).

-o file_name

Output to comma-separated values (CSV) file

(default: output only to debug).

Lesson 1: Monitoring and Optimizing System Performance89 As the name suggests, the Remote Performance Monitor application is a remote tool. The application monitors devices both under development and out in the field, as long as you have a way to connect to the device and deploy the application.

The Remote Performance Monitor monitors the following objects:

■Remote Access Server (RAS).

■Internet Control Message Protocol (ICMP).

■Transport Control Protocol (TCP).

■Internet Protocol (IP).

■User Datagram Protocol (UDP).

■Memory.

■Battery.

■System.

■Process.

■Thread.

This list is extended by implementing your own Remote Performance Monitor extension DLL. For sample code, look in the % COMMONPROGRAMFILES% \Microsoft Shared\Windows CE Tools\Platman\Sdk\WCE600\Samples\CEPerf folder.

Figure 3-1 A performance chart in Remote Performance Monitor

90Chapter 3Performing System Programming

Similar to the Performance tool on a Windows workstation, Remote Performance Monitor can create performance charts, configure alerts triggered at specified

thresholds, write raw log files, and compile performance reports based on the performance objects available on the target device. Figure 3–1 shows a performance chart example.

Hardware Validation

ILTiming tool, OSBench, and Remote Performance Monitor cover most performance monitoring needs. However, some cases may require other methods of gathering system performance information. For example, if you want to obtain exact interrupt latency timings, or if your hardware platform does not provide the required timer support for the ILTiming tool, you must use hardware–based performance measuring methods based on the General Purpose Input/Output (GPIO) interface of the processor and a waveform generator.

By using a waveform generator on a GPIO, it is possible to generate interrupts that are handled through ISRs and ISTs. These ISRs and ISTs then use another GPIO to generate a waveform in response to the received interrupt. The time elapsed between the two waveforms—the input waveform from the generator and the output waveform from the ISR or IST—is the latency time of the interrupt.

Lesson Summary

Windows Embedded CE provides many tools that can be employed in a development environment to measure the system performance and validate real-time device performance. The ILTiming tool is useful for measuring interrupt latencies. The OSBench tool enables you to analyze how the kernel manages system objects. Remote Performance Monitor provides the means to gather performance and statistical data in charts, logs, as well as report on devices under development and out in the field.

Remote Performance Monitor has the ability to generate alerts based on configurable performance thresholds. Beyond the capabilities of these tools, you have the option to use hardware monitoring for latency and performance-measurement purposes.

Lesson 2: Implementing System Applications91

Lesson 2: Implementing System Applications

As discussed in Chapter 1 “Customizing the Operating System Design”, Windows Embedded CE acts as a componentized operating system and a development platform for a wide variety of small-footprint devices. These range from devices with restricted access for dedicated tasks, such as mission-critical industrial controllers, to open platforms offering access to the complete operating system, including all settings and applications, such as personal digital assistant (PDA). However, practically all Windows Embedded CE devices require system applications to provide an interface to the user.

After this lesson, you will be able to:

■Launch an application at startup.

■Replace the default shell.

■Customize the shell.

Estimated lesson time: 25 minutes.

System Application Overview

Developers distinguish between system applications and user applications to emphasize that these applications have different purposes. In the context of Windows Embedded CE devices, the term system application generally refers to an application that provides an interface between the user and the system. In contrast, a user application is a program that provides an interface between the user and application-specific logic and data. Like user applications, system applications can implement a graphical or command-line interface, but system applications are typically started automatically as part of the operating system.

Start an Application at Startup

You can configure applications to start automatically as part of the Windows Embedded CE initialization process. This feature can be set in several ways, depending on whether you want to run the applications before or after Windows Embedded CE loads the shell user interface (UI). One method is to manipulate several registry settings that control the application startup behavior. Another common method is to place a shortcut to the application in the Startup folder so that the standard shell can start the application.

92Chapter 3Performing System Programming

HKEY_LOCAL_MACHINE\INIT Registry Key

The Windows Embedded CE registry includes several registry entries to start operating system components and applications at startup time, such as Device Manager and Graphical Windows Event System (GWES). These registry entries are located under the HKEY_LOCAL_MACHINE\INIT registry key, as illustrated in Figure 3–2. You can create additional entries at this location to run your own applications included in the run-time image without having to load and run these applications manually on your target device. Among other things, automatically starting an application can facilitate debugging activities during software development.

Figure 3-2The HKEY_LOCAL_MACHINE\INIT registry key

Table 3–3 lists three examples of registry entries to start typical Windows Embedded CE components when the run-time image starts.

Table 3-3Startup registry parameter examples

Location HKEY_LOCAL_MACHINE\INIT

Component Device Manager GWES Explorer

Binary Launch20=

"Device.dll"Launch30=

"Gwes.dll"

Launch50=

"Explorer.exe"

Dependencies Depend20=

hex:0a,00Depend30=

hex:14,00

Depend50=

hex:14,00, 1e,00

Lesson 2: Implementing System Applications93

Table 3-3Startup registry parameter examples (Continued)

Location HKEY_LOCAL_MACHINE\INIT

Description The LaunchXX registry entry specifies the binary file of the

application and the DependXX registry entry defines the

dependencies between applications.

If you look at the Launch50 registry entry in Table 3–3, you can see that the Windows Embedded CE standard shell (Explorer.exe), will not run until process 0x14 (20) and process 0x1E (30) have started successfully, which happen to be Device Manager and GWES. The hexadecimal values in the DependXX entry refer to decimal launch numbers XX, specified in the name of the LaunchXX entries.

Implementing the SignalStarted API helps the kernel manage process dependencies between all applications registered under the HKEY_LOCAL_MACHINE\INIT registry key. The application can then use the SignalStarted function to inform the kernel that the application has started and initialization is complete, as illustrated in the following code snippet.

int WINAPI WinMain(HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPTSTR lpCmdLine,

int nCmdShow)

{

// Perform initialization here...

// Initialization complete,

// call SignalStarted...

SignalStarted(_wtol(lpCmdLine));

// Perform application work and eventually exit.

return 0;

}

Dependency handling is straightforward. The kernel determines the launch number from the Launch registry entry, uses it as a sequence identifier, and passes it as a startup parameter in lpCmdLine to the WinMain entry point. The application performs any required initialization work and then informs the kernel that it has finished this part by calling the SignalStarted function. The call to the _wtol function in the SignalStarted code line performs a conversion of the launch number from a string to a long integer value because the SignalStarted function expects a DWORD parameter. For example, Device Manager must pass a SignalStarted value of 20 and GWES must pass a value of 30 back to the kernel for the kernel to start Explorer.exe.

94Chapter 3Performing System Programming

The Startup Folder

If you are using the standard shell on your target device, you can drop the application or a shortcut to the application into the Windows\Startup folder of the device.

Explorer.exe examines this folder and starts all found applications.

The Windows Embedded CE standard shell can handle executable and shortcut files.

Windows Embedded CE shortcut files differ from the shortcut files of Windows XP, but provide similar functionality. CE shortcut files are text files with an .lnk file-name extension. They contain the command-line parameters for the linked target according to the following syntax:

nn# command [optional parameters]

The placeholder nn stands for the number of characters followed by a pound sign (#), and the actual command, such as 27#\Windows\iexplore.exe -home to start Internet Explorer? and open the home page. After creating and adding the desired .lnk file to the run-time image, edit the Platform.dat or Project.dat file to map the .lnk file to the Startup folder, similar to the following .dat file entry:

Directory("\Windows\Startup"):-File("Home Page.lnk", "\Windows\homepage.lnk")

Chapter 2 covers these configuration tasks in more detail.

Lesson 2: Implementing System Applications95

Delayed Startup

Another interesting option to start applications automatically is to leverage the services host process (Services.exe). Although Windows Embedded CE does not include a full-featured Service Control Manager (SCM), it does include built-in services and also comes with a sample service called Svcstart that can be used to start applications.

Svcstart is particularly useful for applications with dependencies on system components and services that are not immediately available after the startup process finishes. For example, it might take a few seconds to obtain an Internet Protocol (IP) address from a Dynamic Host Configuration Protocol (DHCP) server for a network interface card (NIC) or initialize a file system. To accommodate these scenarios, the Svcstart service supports a Delay parameter that specifies the time to wait before starting an application. You can find the Svcst art sample code in the %_WINCEROOT%\Public\Servers\SDK\Samples\Services\Svcstart folder. Compile the sample code into Svcstart.dll, add this DLL to your run-time image, and then run the sysgen -p servers svcstart command to register the Svcstart service with the operating system. Load it by using Services.exe.

Table 3–4 lists the registry settings that the Svcstart service supports to start applications.

Table 3-4Svcstart registry parameters

Location HKEY_LOCAL_MACHINE\Software\Microsoft\Svcstart\1 Application Path@="iexplore.exe"

Command-line

Args="-home"

Parameters

Delay Time Delay=dword:4000

Description Starts the application with the specified command-line

parameters after a delay time defined in milliseconds. See the

Svcstart.cpp file for more details.

96Chapter 3Performing System Programming

Windows Embedded CE Shell

By default, Platform Builder provides three shells to implement the interface between the target device and the user: the command processor shell, the standard shell, and

a thin client shell. Each shell supports different features to interact with the target

device.

Command Processor Shell

The command processor shell provides console input and output with a limited set of commands. This shell is available for both display-enabled devices and headless devices without keyboard and display screen. For display-enabled devices, include the Console Window component (Cmd.exe) so that the command processor shell can handle input and output through a command-prompt window. Headless devices, on the other hand, typically use a serial port for input and output.

Table 3–5 lists registry settings that you must configure on the target device to use a serial port in conjunction with the command processor shell.

Table 3-5Console registry parameters

Location HKEY_LOCAL_MACHINE\Drivers\Console

Registry Entry OutputTo COMSpeed

Type REG_DWORD REG_DWORD

Default Value None19600

Description Defines which serial port the command

processor shell uses for input and

output.

■Setting this value to -1 will redirect

input and output to a debug port.

■Setting this value to zero specifies

no redirection.

■Setting this value to a number

greater than zero and less than 10

will redirect input and output to a

serial port.Specifies the data transfer rate of the serial port in bits per second (bps).

Lesson 2: Implementing System Applications97

Windows Embedded CE Standard Shell

The standard shell provides a graphical user interface (GUI) similar to the Windows XP desktop. The primary purpose of the standard shell is to start and run user applications on the target device. This shell includes a desktop with Start menu and taskbar that enables the user to switch between applications, from one window to another. The standard shell also includes a system notification area to display additional information, such as the status of network interfaces and the current system time.

Windows Embedded CE Standard Shell is a required catalog item if you select the Enterprise Terminal design template when creating an OS design project in Visual Studio by using the OS Design Wizard. If you want to clone and customize this shell, you can find the source code in the %_WINCEROOT\Public\Shell\OAK\HPC folder. Chapter 1 explains how to clone catalog items and add them to an OS design.

Thin Client Shell

The thin client shell, also called the Windows–based Terminal (WBT) shell in the product documentation, is a GUI shell for thin-client devices that do not run user applications locally. You can add Internet Explorer to a thin-client OS design, yet all other user applications must run on a Terminal server in the network. The thin client shell uses the Remote Desktop Protocol (RDP) to connect to the server and display the remote Windows desktop. By default, the thin client shell displays the remote desktop in full-screen mode.

Taskman

You can also implement your own shell by cloning and customizing the Windows Task Manager (TaskMan) shell application. The source code in the %_WINCEROOT% \Public\Wceshellfe\Oak\Taskman folder is a good starting point.

Windows Embedded CE Control Panel

The Control Panel is a special repository for central access to system and application configuration tools. The product documentation refers to these configuration tools as applets, to indicate the fact that they are embedded in the Control Panel. Each applet serves a specific and targeted purpose and does not depend on other applets. You can customize the content of the Control Panel by adding your own applets or by removing existing Control Panel applets included with Windows Embedded CE.

98Chapter 3Performing System Programming

Control Panel Components

The Control Panel is a configuration system that relies on the following three key components:

■Front-End (Control.exe) This application displays the user interface and facilitates starting Control Panel applets.

■Host Application (Ctlpnl.exe) This application loads and runs the Control Panel applets.

■Applets These are the individual configuration tools, implemented in form of .cpl files listed with icon and name in the Control Panel user interface.

For details regarding the implementation of the Windows Embedded CE Control Panel, check out the source code in the %_WINCEROOT%\Public\Wceshellfe\Oak \Ctlpnl folder. You can clone the Control Panel code and customize it to implement your own Control Panel version

Implementing Control Panel Applets

As mentioned, a Control Panel applet is a configuration tool for a system component or user application implemented in form of a .cpl file and located in the Windows folder on the target device. Essentially, a .cpl file is a DLL that implements the CPlApplet API. A single .cpl file can contain multiple Control Panel applications, yet a single applet cannot span multiple .cpl files. Because all .cpl files implement the CPlApplet API, it is a straightforward process for Control.exe to obtain detailed info about the implemented applets at startup in order to display the set of available applets in the user interface. Control.exe only needs to enumerate all .cpl files in the Windows folder and to call the CPlApplet function in each file.

According to the DLL nature and CPlApplet API requirements, .cpl files must implement the following two public entry points:

■BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) Used to initialize the DLL. The system calls DllMain to

load the DLL. The DLL returns true if initialization succeeded or false if

initialization failed.

■LONG CALLBACK CPlApplet(HWND hwndCPL, UINT message, LPARAM lParam1, LPARAM lParam2) A callback function that serves as the entry point

for the Control Panel to perform actions on the applet.