I. Overview
Windowsce is a embedded system launched by Mirosoft, and also introduced Platform Builder Development Tools and CETK test tools, coupled with other development and management tools, making technology development and project management WindowsCe projects very easily. Currently, Windowsce has gradually been accepted by the manufacturer in its good human-machine interface, and has more and more market share in wireless communication, industrial control, electronic consumer products. For developers, MS provides different reference models for different CPU platforms, and open source code to a certain extent, enabling developers to more control the operating system, and can do quickly Personalized products. In particular, MS development tools and test tools greatly reduce the threshold, improve work efficiency, shorten the product development cycle, and reduce the expenditure brought about product after-sales service. Considering the authorization fees of WindowsCE, in small batches of products, integrated factors, using Windows Cost, is not allowed to use other operating systems.
The best textbook for developing Windows C products is MSDN. This article is simply described with a basic development and testing of Windowsce, so that everyone has a probably understanding of WindowsCE development and testing.
Second, develop BSP using Platform Builder
Platform Builder is Microsoft, which is specifically an integrated development environment for developing a WindowsCE embedded operating system. In this environment, developers can use rich tools, creation, cut, and debug the target operating system. The development process of WindowsCE can probably be divided into: oal, driver, application development three steps. This article is only a probably introduced for the development process of OAL and drivers, and the development of applications is not discussed with discussion.
A, WindowsCe Structure Introduction
Before developing an operating system, you must have an understanding of the hierarchies of the operating system. The figure below is the architecture of Windowsce.
On the hardware, it is the operating system. The kernel is the library provided by the MS, used for memory management, process, thread scheduling, etc., is no source code. Oem Layer is a reference model and source code, and Platform Builder is also mainly used to develop an OEM layer. among them:
BootLoader: Mainly responsible for putting compiled image files into memory;
OEM Adaptation Layer (OAL): Respiring hardware and connects to the kernel section;
Driver: Responsible for the driver of peripheral devices.
Platform Builder provides BSP (Board Support Package) for Some Standard Hardware Development Boards, and these standard boards use the industry's commonly used CPUs and peripherals. In other words: Both the CPU and peripherals of common types, Platform Builder provides source code for bootloader, oal, and driver. Just use Platform Builder to cut and make changes to the existing BSP, plus MS provided. The kernel can drive most hardware devices. And Platform Builder also provides a wealth of standard applications and service programs. After developing OEM layers, add these applications and services, you can make users' hardware platforms work.
Of course, if the user uses the CPU or peripheral hardware device you designed, the development process is more complicated. But MS has strict definitions on the development steps and interfaces of OAL, drive, bootloader. Therefore, with the help of MSDN, the reference model is again, this process is often more simple than imagination. B, BSP development
Here, it is assumed that there is a development board, using MIPSII's CPU, then use the BSP prototype of the MIPSII development board provided by Platform Builder, quickly generates its own BSP.
In Platform Builder, select BSP Wizard in the menu Platform, popup down the chart dialog.
Select "Clone An EXISTING BSP" because the architecture of the AMD DBAU 1500 is MIPSII, so select AMD DBAU1500 in the drop-down list, then click "Next". The dialog box shown below appears.
Each BSP corresponds to a CEC file. Information about the development wrench is recorded in this file. For example, a CPU type, which peripherals are available on the development board, which are used in the system, GUID, global variables, etc. Therefore, you must also give a name to the new BSP. This is named NewBSP here. Click "Next".
The Catalog Information dialog box appears. In this dialog box, you can fill in the display name, distribution of the BSP, and the BSP description. Click "Next".
In the Directory and CPU dialog, the path to the newly generated BSP and the specified CPU type. Click "Next". The Customization dialog pops up, as shown below.
Here, according to the peripherals on its own development board, the drive in the BSP is adjusted, such as whether bootloader is required. The drive list is peripheral for a block DBAU1500 development board. If you don't have these devices on your own development board, you can delete it. If the device model and type on your own development board are not in line with the list, you can choose to add (if there is a third-party driver), you can also choose to edit an existing drive. Since the same type of equipment is similar, the drive structure is basically the same, then why do not use the existing driver, carry forward the spirit of bid? Click "Next" and start a new BSP.
The following tasks are to modify the generated BSP to make it more in line with the actual development board. The way is simple, select "New Platform" in the File menu of Platform Builder, create a new project. Note that when you create the third step, choose BSP, choose NewBSP just generated. Other steps can be made according to the prompt.
In Platform Builder, according to the actual situation of the development board, refer to the hardware manual, modify the corresponding device driver and the OAL layer. After the modification is completed, the image file is compiled and generated, you can download it on the hardware platform for debugging and modifying bugs.
Third, use CETK to test
While providing development tools, MS also provides a set of test tools to test the WindowsCe operating system created by the user, which is the Microsoft® Windows® CE Test Kit (CETK). This tool graphs a range of command line test tools to verify that each driver is correct.
CETK tools include two parts, part of the server applications on the development platform (PC), part of the client application on the target platform. Therefore, when using CETK, you must first download the client application to the target. How to download a lot, such as using Remote File View in PB, or using FTP services from the client download, or use CETK's own Connection Tool, etc. The scene described herein is to detach the BSP development process, and directly face a target platform that has been developed, how to test it with CETK. A, test process
For a CETK test for a developed target platform, you first have to understand a few points:
What is the Windows CE version number running on this target platform;
What is the CPU structure of this target platform;
Whether the CETK client is installed in this target platform;
Which hardware devices have this target platform, which features they support;
Because different Windows CE versions use different CETK versions; other different CPU types use different clients. In particular, CETK is a complete set of hardware features, some of which may not have existing hardware platforms, so it is necessary to understand the characteristics of the existing target platform to avoid unnecessary trouble. After understanding the above points, you can test CETK test.
1. Prepare the test environment:
Since CETK has server-side and clients, then at least through a certain technical means and connect them. At present, there are at least one network device for most embedded devices. Therefore, it is assumed here that the server side and the client are connected via a local area network. Before the test begins, you need to set them within the same network segment through the server side and the client, you can access each other.
2. Start Windows CE .NET TEST KIT in the Microsoft Windows CE group from the Start menu.
3, download and run the client software:
If there is no CETK client software clientside.exe, there is no download to a hardware platform in some way. The client software is in the Windows CE installation directory. After you understand the CPU type of the target machine, download the / winceroot / Others / Wcetk / CPU Type / ClientSide.exe to the target platform. Since both the server and the target platform are in the same LAN, it can be copied to the target by file sharing or FTP.
After the download is complete, open a console (shell) of the target machine, enter the directory where the clientside.exe is located, type it on the command line: clientside.exe / n = server IP address / P = 5555.
4, set test items:
After the client runs the clientside, after a few seconds, the name and the detectable unit of the target device are displayed in the server's Windows CE .NET TEST KIT. As shown below.
CETK automatically obtains device information on the target device by connecting to the client program, and automatically determines the items that can be tested. From the above figure, you can know that the hardware device does not include sound cards, infrared, mouse devices, etc. Items that can be tested include graphics cards, modems, and the like. Because the hardware device has a wide variety, the hardware scan is not necessarily accurate on the specific details. For example, if the Direct3D function is not supported, it cannot be tested. This is why users must know the specific hardware information of the target device in advance.
Each individual device has some optional test items, testers can select or cancel some project tests through a box.
5, set the test command line
If you want to test a project, first select the item with the mouse, then right click, a menu will pop up. Before the test is finished, the "View Results" option in the menu is gray. Select "Edit Command Line" and the dialog box shown will appear. CETK is essentially, in fact, is a collection of complete test cases, and each test case is an application. During the test, the hardware features to be tested are actually called some of the function calls in the driver. Therefore, the test case is the function in calling the relevant driver and determines whether the driver is correct by detecting the function of the function. MS provides a CETK tool, and it also provides such a complete test case. If the developer uses its own design, or the device has not available in the BSP, when testing the equipment, you need to write test cases according to the characteristics and drivers of the device.
The dialog shown below is the command line for testing the NIC.
Where TUX is a 32-bit client / server program, which is responsible for testing the function modules in the dynamic link library. For different dynamic link libraries and modules, of course, different command lines are used. Therefore, the tester must have a help documentation for Windows CE .NET Test Kit before working, and understand the command lines corresponding to different modules and different features.
6, start testing:
If you only test one of the selected items, "Quick Start" in the menu is selected. If you want to test all selected items, you should choose Tests-> Start / Stop Tests in the menus of Windows CE .NET TEST KIT.
Some tests do not require manual intervention, and the program will be automated. However, some tests (such as mouse, keyboard, etc.) are included in the test process. Therefore, during the test process, the tester needs to perform the corresponding action according to the prompt on the target device screen.
7. View test report:
After the test is completed, the View results in the menu will be automatically allowed to check the test results of the module.
The display area of CETKPARS is divided into three windows, and the uppermost window shows the integrated parameters detected by this module, and the intermediate window displays all the use cases and final results for this module test. When one of the cases is selected, the test details of this use case are displayed in the bottom window. The above discusses, the test case is actually called some functions in the driver, so by analyzing the code of the failed test case, it can initially determine which function of the failure is driven. After providing information to the developer, the developer uses the debugging tool provided by the PB to quickly locate and resolve the issues in the program.
B, pressure test
Stress testing can also be performed using CETK. The so-called pressure test is a test method for working on the target platform in the limit state. Through pressure testing, some single tests that can be found in the target platform cannot be found, hidden problems. In the menu of Windows CE .NET TEST KIT, select the Other Test-> Modular Stress Test, you can perform a pressure test.
The project of the pressure test is also optional. The project definition of the pressure test is defined in the / program files / windows celatform builder / version / cepb / wcetk / ddtk / armv4 / optress.ini file. The format and content of the file will be able to determine modules and items for pressure testing by modifying the file.
After performing the pressure test, the View Results display interface is different from the other results. It is a table. Due to the relationship between layout and space, this is not completely displayed, only part of it is displayed. In the table, the developer is more significant is "System Health", "Modules Status", as shown below. As can be seen from "System Health", 20% in the pressure test, after the test, the memory usage is 33%, which means that there is memory leak before and after the pressure test. Therefore, it is possible to further determine that the disclosure of the memory is in the function used in the pressure test. In "Modules Status", the use case statistics for pressure testing of each module.
