following locations:
¦ %_WINCEROOT%PublicCommonOakUtilsOsbench
¦ %_WINCEROOT%PublicCommonOakUtilsOb_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 SharedWindows CE ToolsPlatmanSdk WCE600SamplesCEPerf 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
