Author: Fu Linlin Source: vckbase.com this article mainly on the use of remote debugging tools, and the use of simulators in PB (Microsoft Platform Builder) to test. 1. Simulator Simulator (Emulator) is part of the PB. Dedicated to debug the kernel and application created under PB. The simulator can simulate the physical platform of Windows CE under the PC. But in fact it is just a user program running at the CPU Ring 3 level. So it is slower than the normal physical platform. The simulator only supports the x86 platform, which can only debug the "Emulator: x86" kernel and a program compiled with the X86 instruction set. The simulator has a large limit that allows it to run simple applications. But one thing is good, most of the API of the operating system is the same for any CPU. Considering a simple program that is not affected by the CPU type, you can also debug on the simulator. In actual development, I only use the simulator to debug software interface. If you want to learn PB, use it to create the kernel and there is no actual physical platform to debug, then the simulator is very suitable. However, the simulator has a lot of restrictions, so even if you tried all the kernel features that you can debug, you can master the corner of the Iceberg in the simulator. By the way, it will be gossip: PB includes the knowledge of the PB and the knowledge of the Windows Ce itself adds a lot than the vast ocean, which is much larger than the knowledge of EVC development software. So if you only develop a few software with EVC, you are still a first-year student in Windows CE. Figure A simulator's hardware restrictions on the simulator: (taken from Windows CE Help)
Only simulate the DEC 2114x network card driver to provide network support, other network card drivers are not supported.
Only the FLAT display driver can only be simulated, and other display drivers are not supported.
USB device does not support
Do not support PC cards, hard drives, CF cards.
FAT, CDFS, DVD file formats are not supported.
IEEE1394 devices are not supported.
Microsoft recommends the use of simulator's development platform:
1 GHz CPU
384 MB system memory
500 MB available hard disk space
Second, create the core and download it to the simulator to test the remote debugging tool, we must first create a kernel using PB V4.1:
Create the kernel using the new kernel Wizard: Click "New Platform" in PB, select "Emulator: X86" in "STEP 2" "Available BSPS", then select a predefined predefined in "STEP 3" "Available Configurations" The kernel configuration, these predefined kernel configurations have targeted. Here we choose "Internet Appliance". Note: Some predefined kernel configurations come with a shell program, some have no band. After selecting, fill in the engineering name (such as Internet) and the project saving path. The default "STEP 4" option is removed in "Step 5". Because we only need the kernel and the shell. Also remove all check boxes in "Step 6". The last step click on the "DONE" button. Compile this new kernel: In the menu "Platform" - "Settings" - "Environment", click "New", add the variable name "IMGRAM64" and value "1" in the pop-up dialog. Then click "Build" - "Build Platform" to start compiling. Time to compile and have a big relationship with your machine configuration. Configuring the simulator: After the compilation is successful, click "Target" - "Configure Remote Connection", find the "Download" drop-down box in the pop-up dialog box, select "Emulator", click "Configure", in the pop-up conversation Set the resolution in the box 800 x 600 or 640 x 480. The system memory is set to 64MB. After clicking "OK", select "Emulator" in the "Kernel" drop-down box. Click OK. Start the simulator: Click Target - "Download Initialize". Waiting for a while, the simulator will come out. You can see the interface of the standard shell, that is, the desktop. Write an app in the PB and download it to the simulator:
Under the premise of opening the kernel engineering (if you just open the PB, open a kernel project). Click the PB menu "File" - "New Project Or File". I don't have to say more about the rest. Like EVC, you can encode an engineering name. Just no support for MFC, ATL. Select a SDK program that displays "Hello World". Then click "Build" - "Build All" compiler. I usually do not develop software under PB. trouble! Under the premise of the simulator, click "Target" - "Run Program", find your program name, then click "Run". You can see your program on the simulator. Close operation: Turn off the simulator first. Click Target - "Disconnect". Third, the remote debugging tool remote debugging tool is used to perform some debugging work between the development platform and the actual platform. With the remote debugging tool, you can run in the development platform, get files on the actual platform, monitor the status of the process or thread on the actual platform, and test the performance of the application on the actual platform. Part of the remote debugging tool is usually used when we develop applications, and some are often used when developing kernels. For non-common remote debugging tools, I only give a simple introduction here.
Remote Call PROFILER Remote Call Evaluation includes evaluation and analysis tools. Use graphic images to display the efficiency of your code in your code or occupy resources. The Remote Call Evaluation includes a range of interface functions. These interface functions are called in the code you want to evaluate and then run the program you have written. Remote Call Evaluation Programs can receive the data of the program you written and record it. Finally, the graph is displayed. Obviously this tool is not often used. Especially developing non-real-time cores and software, plus the current embedded microprocessor processing speed is so fast, and the demand for a software performance is diluted. Of course, if you are willing, I feel that it is necessary to study its interface function and then test it. I haven't currently doing this time. Microsoft provides example "Hello". If you install Windows CE in the C drive, the path is: "C: / Program Files / Common Files / Microsoft Shared / Windows CEOOLS / Platman / SDK / WCE410 / Samples / Hello". I compiled this program and tested it. The graphic displayed by the remote call evaluation program is shown in Figure 2. Figure 2 Evaluation Image Screenshot Remote File Viewer Remote File Browse Program is one of the most common and easierable tools. Its role is to import or export files to the actual platform. If I am debugging a program that displays a bitmap. The bitmap allows the user to choose from. Then you want to debug under the simulator, you must first import the bitmap file into the simulator. After the simulator is opened, run the Remote File Browse program, first pop up a dialog, you want to access which platform. As shown in Figure 3. Figure 3 Platform Selection dialog box Select "Default Device". The main window is displayed. As shown in Figure 4. The left directory number is listed in all directories of the kernel running the simulator. On the right is the file in the specified directory. The top right side of the toolbar is the import and export button. The import and export here are relative to the development platform. In the above example, you want to pass a bitmap file into the simulator. First click the Export button (on an arrow), select a bitmap file in the pop-up dialog box, then after confirming, this file appears in the right file window of the remote file browsing program. Import is also simple, first select one file, then click the Import button, then select the path, save it. Figure 4 Remote File Browsing Program Screenshot 3, Remote Heap Walker apparently "Walker" cannot be translated into "View". How are you willing to translate it? Here I am calling, so it is easy to understand. From the name, it can be seen that it is used to see the stacks used in each process in the operating system. What is a pile, don't have to say it! Heap everyone knows, but the knowledge about the pile is also worth mentioning under CE. In the future, I will have a special article published under the CE process, thread, and memory management, and it will be very detailed. Using the "Remote Heap View Programs" can be found: the name, ID, and all of the stacks used in the kernel running process. As shown in Figure 1
The first address, end address, and flag in a heap of the process (Fixed, Free)
Pile in the actual content of each block
Figure 1 The process list view and use this tool is very simple. But the premise is that you have a great understanding of the stack. Let me talk about the knowledge related to this tool involved. When each process is started under the CE, the system will automatically assign a local pile of 192KB to this process. If you are not enough, you will allocate the stack of custom size by calling the heap management function. The heap you allocate, including the system that is assigned to you, is identified by the ID. The HEAP ID shown in the figure. The process ID and process name don't say it. The "Flag" behind only has a value "HF32_DEFAULT" indicating the heap of the default assignment of the system. "Device.exe" in the figure, there are four. However, from the process ID, you can see that this is a process instead of four instances of an application. Because the list is in a heap, "Device.exe" is assigned four stacks, it shows four. Double-click any of the list, pop up a list of included blocks of this stack. List the first address, size, and logo of the block. We assigned a heap to allocate arrays, structures, etc. in the heap. This block refers to each assigned element. The "fixed" in the flag indicates that the memory space occupied by this block cannot be released. The "Free" is the opposite, indicating that the memory space occupied by this block can be released. See this, maybe you have questions, who is the sign? Who is released? This involves the management of memory, the OOM components of the kernel. I will explain in a detailed explanation in future articles. Click Each block, you can see the specific data of this block in the pop-up list (represented by ASCII). 4. Remote Kernel Tracker Remote Core Tracking Program is used to track the implementation of the actual platform kernel, usually use it to track the start of the kernel, collect the relevant data and display it on the development platform. as shown in picture 2. This program can track all threads in all processes and processes. From the start of running, the time of tracking the end is determined by the data receiving buffer size. The size of the buffer is set from 1MB to 100MB and is set by the user. Tracking content is running, not running, running, blocking, sleeping. There is also a synchronization event that occurs in the thread. There is an icon that can be tracked in the right side of this program. To track the start of a kernel (you can use this program to track all processes, threads after startup), first make the kernel you want to track with several features. Reselect "Enable Event Tracking During Boot" and "Enable Profiling" in the PB menu "Platform" - "Settings" - "Build Options". Then recompile the entire kernel. (Note that PB may prompt when compiling, if this happens, then reconstruct the kernel) After the completion of the completion, first open the remote kernel tracking program, in the pop-up platform selection dialog (including this picture) Press "OK", immediately click the PB's "Download / Initialize" to call up the simulator. Wait a remote kernel trace program to record all the situation that occurs during the startup process and display it. Which time period runs or sleeps or blocks, including which interrupts have been recorded. The disadvantage is that the amount of data is too large. This program provides a lookup function and filtering. The lookup feature can find the event you want, and the filtering function allows this program only records the event you want. Finally, these recorded data can be saved. Save to the extension ".clg" file. I can only talk so much this tool, usually used. Figure 2 Tracking Screenshot 5, Remote Performance Monitor This program is very familiar. The performance monitor interface included in the other Windows operating system is very similar. As shown in Figure 3. Operation is almost the same.
Figure 3 Performance monitor screenshot It can monitor Remote Access Server (RAS), Internet Control Message Protocol (ICMP), TCP / IP, User DataGram Protocol (UDP), Memory, Battery, System, Process, Thread. 6, Remote Process Viewer This program has a total of three windows that displays all processes in the current core, threads in the process, and all loaded DLLs in the process. In the window of the display process, the process name, process ID, basic priority level, the total number of threads, base sites, access key values, and main window names are displayed. In the window displaying the thread, the thread ID, the current process ID, the thread priority, and the access key are displayed separately. In the window that displays the DLL module, the module name, module ID, the current process is displayed, and the global use count, base address, size, module handle, path. Here, it will be described here that "current process ID" in the thread window. When the current process ID will be different, weird! The thread window should display all threads under the current specified process, how can there be different process IDs? Because I didn't say anything in CE, please allow me to imagine: For example, "Explorer.exe", it contains two threads there are shown in "Current Process ID" as the process "gwes.exe", "GWES "As the graphics, windows, event subsystems. It is responsible for graphics and windows and window messages. "Explorer.exe" thread calls "coredll.dll" when the message is displayed, and will be specifically explained in the DLL to call the graphics, windows, and event modules. These modules are actually drivers (DLL), loaded by gwes.exe, manage these DLLs. So the current process is "gwes.exe". It can only be explained so far. Figure 4 Process Browsing Program Screenshot 7, Remote Registry Editor This program is very similar to the registry editor under other Windows operating systems. But it can display, compile the registry under the development platform and the registry under the actual platform. As shown in Figure 5. I don't have much to say the specific operation. I have also said that the restriction of the registry under CE. Figure 5 Registry Editor Screenshot 8, Remote SPY This program is very similar to the tool spy attached to the VC. Ability to list windows and window messages under all actual platforms. I don't want to say this program. Be familiar with tools under VC can operate this tool. The interface is shown in Figure 6. Figure 6 Message Monitor Interface Screenshot 9, Remote System Information This tool can view system information of the actual platform, including hardware and software information. Figure 7 System Information Screenshot 10, Remote Zoom-IN This tool can intercept the actual platform screen image. This tool is best suited to write a manual. If a product is to be pushed to the market, that manual or demo program must be ready. Put it in this program screenshot to the manual or presentation. Screenshot Click "File" - "New Bitmap". I will not give it the interface of this program. Summary 10 remote tools provide a great help for our development kernel and applications. Obviously some tools are rare, some tools are commonly used. For registry editors, some embedded websites have source and program downloadable. Run the registry editor to the kernel is more efficient, saving time. In these 10 tools, the most handsome is the kernel tracking program, through the kernel trace program, the entire kernel start process is clearly visible. You can also use it to monitor your application. One thing to explain: These 10 remote debugging tools I was tested on the simulator. If you want to debug the actual platform, you must first connect the development platform and the actual platform first through the serial port.
