WINDOWSCE Development process

I. Overview

WindowsCE is an embedded system launched by Mirosoft, and Platform Builder development tools and CETK testing tools, plus MS Other development and management tools, make technology development and project management WindowsCE project very simple. At present, WindowsCE with its good Man-machine interface, rich and reliable application gradually accepted by manufacturers, in wireless communications, industrial control, electronic consumer products, occupy more and more market share. For developers, MS for the development of convenience, for different CPU platform, provide a different reference model, and to some extent, open the source code, so that developers can more control of the operating system, and can quickly make personalized products. In particular, MS development tools and testing tools, greatly reducing the threshold, improve work efficiency, shorten the product development cycle, reduce the product after-sales service costs. Taking into account the licensing costs of WINDOWSCE, in small batch production of products, the combination of the above factors, the use of windowsce costs, is not higher than the use of other operating systems.

The best textbook for developing WINDOWSCE products is MSDN. This article simply describes the WindowsCE of a basic development and testing process, so that the development of WINDOWSCE and testing, have a general understanding.

Second, the use of Platform Builder development BSP

Platform Builder is a Microsoft-produced integrated development environment for the development of WINDOWSCE embedded operating systems. In this environment, developers can use a wealth of tools to create, trim, and debug the target operating system. The development process of WINDOWSCE can be divided into: OAL, driver, application development three steps. This article is just a general introduction to the OAL and drive development process, and the development of the application is not discussed.

A, WINDOWSCE structure Introduction

Before developing an operating system, you must have an understanding of the hierarchy of the operating system. The following figure is an WINDOWSCE architecture diagram.

On top of the hardware, it's the operating system. Kernel is the library provided by MS, for memory management, process, thread scheduling, etc., is no source code. While the OEM layer is a reference model and source code, Platform Builder is mainly used to develop OEM layer. which

Bootloader: The main responsibility is to put the compiled image file into memory;

OEM adaptation Layer (OAL): is responsible for the hardware initialization and connection kernel part;

Driver: Responsible for the peripheral equipment drive.

Platform Builder provides a BSP (board support package) for some standard hardware development boards, which use the industry's common CPU and peripherals. In other words: for common types of CPU and peripherals, Platform Builder provides bootloader, OAL, driver source code, as long as the use of Platform Builder to the existing BSP to trim and slightly modify, Combined with the core provided by MS, it can drive most hardware devices. and Platform Builder also provides a wealth of standard application and service procedures, after the development of the OEM layer, coupled with these applications and services, can make the user's hardware platform to work.

Of course, if users use their own design of the CPU or peripheral hardware devices, the development process is much more complex. However, there are strict definitions of MS for OAL, driver, bootloader development steps and interfaces. So with the help of MSDN, and then the reference model, this process is often much simpler than expected.

B, the development of BSP

Here, assuming that there is a development board, using the MIPSII CPU, you can use Platform Builder provided by the MIPSII Development Board of the BSP prototype, rapid generation of its own BSP.

In Platform Builder, in the menu platform select BSP Wizard, pop-up the following Figure dialog box.

Select "Clone an existing BSP" because the AMD DBAu1500 architecture is mipsii, so select AMD DBAu1500 in the Drop-down list, then click Next. The following illustration shows the dialog box.

Each BSP corresponds to an CEC file. Information about the development wrench is documented in the file. For example, CPU type, what peripherals are on the Development Board, the names, GUIDs, global variables, etc. that are used by the system. Therefore, it is also necessary to give a name to the CEC file generated by the new BSP. This is named NEWBSP. Click ' Next '.

The Catalog Information dialog box appears. In this dialog box, fill in the display name, publisher name, and BSP description of the BSP. Click ' Next '.

In the directory and CPU dialog box, select the path and the specified CPU type for the newly generated BSP. Click ' Next '. The customization dialog box pops up, as shown in the following figure.

Here, according to their own development Board on the peripheral equipment, the BSP in the driver adjustment, such as whether the need for bootloader. The driver list corresponds to a piece of DBAu1500 Development Board peripheral device. If you do not have these devices on your development Board, you can delete them. If the device models and types on your development Board do not match those in the list, you can choose to add (if a third-party-supplied driver is available), or you can choose to edit the existing drive method. Because now the same type of equipment is similar, so the driving structure is basically the same, then why not take advantage of the existing drivers, carry forward the spirit of copycat. Click "Next" to initially complete a new BSP.

The task below is to modify the already generated BSP to make it more consistent with the actual Development Board. The approach is simple, choose "New Platform" in the Platform Builder's File menu to create a new project. Note in the third step of creation, when selecting BSP, select the newbsp that you just generated. The other steps are available on cue.

In Platform Builder, according to the actual situation of the development Board, refer to the hardware instruction, the corresponding device driver and OAL layer are modified. After the modification, compile and generate the image file, you can download to the hardware platform for debugging and modify the work of the bug.

Third, the use of CETK for testing

While providing development tools, MS also provides a suite of test tools to test the user-created WINDOWSCE operating system, which is MICROSOFT®WINDOWS®CE Test Kit (CETK). The tool graphically uses a series of command-line test tools to verify that each driver is correct.

The CETK tool consists of two parts, one for server applications on the development Platform (PC) and one for client applications on the target platform. Therefore, when using CETK, you must first download the client application to the target machine. There are many ways to download it, such as using the remote File Viewer in Pb, or downloading from the client using the FTP service, or using the CETK connection tool. This article describes the scenario is out of the BSP development process, directly facing an already developed target platform, how to use CETK for testing.

A, testing process

For an already developed target platform for CETK testing, first of all to understand a few:

How many Windows CE version numbers are running on the target platform;

What is the CPU structure of the target platform;

Whether the CETK client is installed in the target platform;

What hardware devices are available on the target platform, and what features they support respectively;

Because different versions of Windows CE use a different CETK version, different CPU types use different clients. In particular, CETK is a complete collection of hardware features, some of the hardware features may not have the existing hardware platform, it is necessary to understand the characteristics of the existing target platform and then test, so as not to cause unnecessary trouble. After you know the above points, you can conduct the CETK test.

1. Prepare test environment:

Now that the CETK has servers and clients, there should be at least one technical way to connect them. At present, for most embedded devices, there is at least one network device. So this assumes that the server side and the client are connected over the LAN. Before the test begins, you need to set up the server-side and the client's network Setup program to be within the same network segment to access each other.

2, start Windows CE. NET Test Kit from the Microsoft Windows CE Group in the Start menu.

3, download and run the client software:

If the existing hardware platform does not contain the CETK client software Clientside.exe, it must be downloaded to the hardware platform in some way. The client software is in the Windows CE installation directory. After understanding the CPU type of the target machine, download/WINCEROOT/OTHERS/WCETK/CPU Type/clientside.exe to the target platform. Since both the server and the target platform are in the same LAN, they can be copied to the target computer through file sharing or FTP.

After downloading, open a console (SHELL) of the target machine, enter the directory of Clientside.exe, and enter on the command line: clientside.exe/n= server IP address/p=5555.

4, set the test project:

After the client has run clientside, a few seconds later, the name of the target device and the detectable unit will be displayed in the server's Windows CE. NET Test Kit. As shown in the following figure.

CETK automatically obtains device information on the target device by connecting to the client program, and automatically determines which items can be tested. As you can see from the image above, this hardware device does not contain sound cards, infrared, mouse devices, and so on. Items that can be tested include graphics cards, modems, and so on. Because of the wide variety of hardware devices, the hardware scan is not accurate in detail. For example, the display card can not be tested if the Direct3D feature is not supported. This is why the user must know the specific hardware information of the target device beforehand.

Each individual device has some optional test items, and testers can select or cancel some of the project's tests by using the current box.

5, set the test command line

If you want to test an item, first select the item with the mouse, then right-click, and a menu pops up. The "View Results" option in the menu is grayed out until the test is complete. When Edit Command line is selected, the dialog box shown in the following illustration appears.

CETK is essentially a set of complete test cases, and each test case is an application. During the testing process, the hardware characteristics you want to test are actually corresponding to some function calls in the driver. So the test case is to call the function in the relevant driver and determine if the driver is correct by running the result of the test function. MS provides a complete set of test cases while providing a CETK tool. If a developer uses a device that he or she does not have in its BSP, when testing the device, it requires the tester to write the test case on its own according to the characteristics of the device and the driver.

The following illustration shows a dialog box that is the command line that tests the NIC.

Tux is a 32-bit client/server program that is responsible for testing the functional modules in the dynamic link library. For different dynamic link libraries and the modules in them, of course, use a different command line. As a result, testers must have the Help documentation for Windows CE. NET Test Kit to understand the command lines for different modules and functions, before they can work on them.

6. Start testing:

If you are testing only one of the selected items, select Quick Start in the menu. If you want to test all selected items, select Tests->start/stop tests in the Windows CE. NET Test Kit menu.

Some tests do not require manual intervention and the program completes automatically. But some tests (such as mice, keyboards, etc.) include the human-computer interaction part in the testing process. Therefore, during the testing process, the tester needs to follow the prompts on the target device screen to perform the corresponding action.

7, view the test report:

After the test is complete, the view results in the menu is automatically allowed and checked to see the test results for that module.

The display area of the Cetkparser is divided into three windows, the topmost window shows the comprehensive parameters for this module detection, and the middle window displays all use cases and final results for this module test. When one of the use cases is selected, the test details for this use case are displayed in the bottom window. As discussed above, test cases are actually calling certain functions in the driver, so by analyzing the code of the failed test case, you can initially determine which function the failure is in the driver. Once the information is available to the developer, the developer can quickly locate and troubleshoot the problem in the program by using the debugging tools provided by PB.

B, stress test

Stress tests can also be performed using CETK. The so-called stress test is a test method that lets the target platform work in the limit state. Through the stress test, can discover the target platform some single test cannot discover, the hidden very deep question. Select other Test->modular Stress test on the menu of Windows CE. NET Test Kit to perform a stress test.

The stress test project is also optional. The project for the stress test is defined in the/program files/windows CE Platform builder/version/cepb/wcetk/ddtk/armv4/oemstress.ini file. The format and content of the file are clear, and by modifying the file, the modules and projects for stress testing can be identified.

After the stress test, the View results display interface is different from the other results, is a table, due to the layout and length of the relationship, here does not show the picture completely, only a part of it. In the table, the most significant for developers is the "System Health", "Modules Status" two tables, as shown in the following figure. As you can see from "System Health", memory usage is 20% before the stress test, and memory usage is 33% after the test, which indicates a memory leak before and after the stress test. It is therefore possible to further determine that the memory leak is in the function used in the stress test.

The "Modules Status" is the use case statistics for stress testing of each module.