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.
The OSBench tool uses system timers. The OAL must therefore support the QueryPerformanceCounter and QueryPerformanceFrequency functions initialized in the OEMInit function.
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.
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.
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.
Figure 3-1 A performance chart in Remote Performance Monitor
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 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.
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-2 The 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.