Detailed description of the wince configuration file (II)-CEC File

Detailed explanation of the CEC File
After previous studies, we have mastered the CE generation process and several phases of compilation, this time, let's take a look at the management methods of component packages provided by platform builder and how to manage our own components.
There is a "catalog" window on the right side of platform Builder (PB), which lists all the components available for use. We can see that there is a lot of content, now the question arises. How does Pb manage these groups? How can I put the driver components of a new device in this package window? If I develop a device driver for other people to use, how can I publish my driver? Next, we will solve these problems.
In Pb, the management of these components can be achieved through a component file (. CEC file. In Ce4, the system's built-in CEC files are located in the CEC folder under the Pb installation folder, where we can easily find them, but in ce5, its location has changed, you can:
Find them under wince500/public/common/oak/CATALOG/CEC.
If you develop oal, device drivers, or other components, you can add them to Pb through the CEC file. By importing the CEC file in the Pb environment, other platform developers can use these components. The CEC file is a text file used to describe component information. It includes a list of some blocks, including the following four types of information blocks:
-- Cecinfo block,
Used to describe the information of the CEC file. Each CEC file can contain only one information block. You can see the name, guid, version, supplier, and brief description of the CEC.
-- Componenttype Block
It describes the highest level of component type. An CEC file can contain multiple information blocks. It describes the group of the component through entries such as group, requiredcemodules, excludewhenset, and maxresolvedimplsallowed, required ce components, excluded components, and quantities that can exist in a CE platform.
-- Implementation Block
It is used to describe the various information required by this component during compilation. Each CEC file can also contain multiple information blocks, which are part of the componenttype block.
The specific meanings of bspplatformdir, children, optionalchildren, defaultdrivers, excludewhenset, featurevariable, and implsize can be found in the Pb help document.
-- Buildmethod Block
The compilation method is described as part of the componenttype block. to deepen the understanding of the previous compilation phase, we will detail the two entries step and action in this block.
Step indicates the step in which the component will be compiled. The value of step is cesysgen, BSP, buildrel, and makeimg. Therefore, if you develop components such as oal or driver, you need to decide at what stage Pb will compile it, and you need to describe it in step in CEC. In fact, in the specific compilation process, each of the above stages has two sub-stages: Pre and post. That is to say, each stage has three steps, namely
Precesysgen, cesysgen, postcesysgen, prebsp, BSP, postbsp ......
Generally, you do not need to specify such details.
Action describes the compilation behaviors of components. The relationship between valid behaviors and the compilation phase is shown in the following table:
Action cesysgen BSP buildrel makeimg
# Build (Dir,...) No Yes No
# Build (sources) No Yes No
# Build (Mak,...) No Yes No
# Custom (...,...) No Yes No
# Copy (...,...) Yes No
# ENV (...,...) No Yes
# Srccode (...) No no
The meanings of these actions are as follows:
-- # Build (): Use the dirsfile, sourcesfile, or makefile to call build.exe, which is used when the platform is fully compiled;
-- # Custom (): run the batch processing file or executable file during compilation;
-- # Copy (): copy a file from one location to another;
-- # ENV (): sets environment variables;
-- # Srccode (): Specifies the folder containing the source program file, which is used only when the selected component is compiled.
For the specific usage of each of the preceding entries, see the Pb help document. In order to get a sense of understanding, we 'd better open several CEC files in notepad. For example, open serial. CEC to see how the serial driver component is implemented.
Now that we understand the CEC file, let's solve the following problem: assume that I have obtained a device driver from another vendor and it carries the CEC file, so how can I add this component to the Pb package? This problem is actually very simple. You only need to use the "manage catalog items" command under the Pb file menu. In this pop-up dialog box, you don't need to talk about the content and usage.
To solve the next problem, how can I compile the CEC file for the components I have developed? You can use the "CEC Editor" command under the Tools menu. If you do not want to write it, open an existing CEC file to see how it is organized, then write your own copy of it. Don't forget to save it after writing it, and pay attention to the guid.
At the end of this article, let's take a look at BSP. What is BSP? In fact, it is a device-Driven Software Package for a development board. It contains source program files, binary files, oal adapter layer, and bootloader.
And other related configuration files. For example, the evaluation version of ce5 includes the x86 BSP, amd BSP, and emulator BSP.
Generally, operations on BSP are performed in the BSP wizard. It is located in the platform menu. You can use it to create your own BSP and copy the existing BSP, modify the existing BSP or create a global driver. If you have prepared what BSP needs, you can use it to generate your BSP. It will select the required ce kernel component.
This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/orangeman1982112/archive/2008/11/27/3393053.aspx