为一个新的硬件设备定制WinCE6.0操作系统，一般需要完成以下几个主要步骤：

1.       针对特定的硬件设备创建板级支持包(Board Support Package缩写为BSP)，BSP必须包括BOOTLOADER、OEM适配层(OEM Adaptation Layer缩写为OAL)和一些必要的驱动。

2.       利用创建的BSP，定制一个系统设计(OS Design)。即通过VS2005创建一个Platform Builder的工程。该工程可编译产生最终的运行时映像文件（Rum-time Image）。

3.       针对板上的外围设备创建相关驱动，并添加到BSP中。

4.       通过创建子工程和Catalog Items的方式，修改OS Design。

5.       编译OS Design，下载编译得到的运行时映像文件到目标设备。此时，可通过远程调试工具进行调试。

6.       在完成所有的调试工作之后，导出该运行时映像对应的SDK(Software Development Kit)，应用程序的开发人员可基于此SDK编写该设备的应用程序。

       可以看出，在整个WinCE操作系统的移植过程中，BSP的移植是最基础也是最关键的一步。而创建BSP的过程主要包括以下几个内容：

1.       创建BOOTLOADER。BOOTLOADER在开发的过程中用于下载操作系统映像文件。

2.       创建OAL。OAL最终被链接到内核映像文件，它主要完成硬件的初始化和管理。

3.       创建设备驱动。设备驱动是板上外围设备的软件支持。

4.       修改运行时映像的配置文件。配置文件主要包括BIB、REG等文件。

BOOTLOADER的主要作用是将操作系统运行时映像加载到内存，并跳转到OS的启动程序处。它的这一作用跟前一篇介绍的NBOOT的作用完全一致。BOOTLOADER获取运行时映像（一般对应的文件名为NK）一般有两种方法。它可以通过有线连接的方式象网络(Ethernet)、USB或串口从外部下载NK。它也可以从本地的存储器(Flash、Hard Disk)中加载NK。通常，BOOTLOADER通过Ethernet下载操作系统映像故将其称为EBOOT。在开发的过程中使用EBOOT，可以提高开发效率。通过使用EBOOT，你可以很快速的下载NK到目标设备中。而利用Flash编程工具或者是通过JTAG下载则很慢。在一些产品最终发布时，EBOOT是可以去掉的，但也有一些则必须包括BOOTLOADER，像X86的平台就是如此。

至此，我们已经了解了EBOOT的主要功能，为了实现这些功能，EBOOT必须完成以下工作：

1.       初始化MCU。包括初始化MCU的相关寄存器、中断、看门狗、系统时钟、内存和MMU。前面几项跟NBOOT基本一致，但这里增加了对MMU的初始化。

2.       在完成所有的初始化工作之后，调用BootloaderMain()。这个函数的定义在WinCE6.0中对应的文件是C:"WINCE600"PLATFORM"COMMON"SRC"COMMON"BOOT"BLCOMMON"blcommon.c

3.       BootloaderMain()主要依次调用以下几个函数，OEMDebugInit()、OEMPlatformInit（）、OEMPreDownload（）、OEMLaunch（），而这些函数必须由EBOOT的代码来实现。

4.       最终跳转到OAL.exe的StartUp处，进而启动WinCE操作系统。

整个流程如下图所示：           

     EBOOT的代码可参考C:"WINCE600"PLATFORM"DEVICEEMULATOR"SRC"BOOTLOADER"EBOOT目录。这里针对S3C2410的EBOOT做几点说明。前一篇介绍NBOOT加载EBOOT的方法时提到，NBOOT必须将EBOOT放在内存中指定的位置，这个位置是由EBOOT的来决定的。具体的，在EBOOT中的体现是boot.bib里的内存配置，如下图所示。

     NBOOT加载EBOOT到内存的地址必须与此地址对应。由于在NBOOT中没有使用MMU，所以NBOOT使用的实际地址应该为0x30021000，否则系统将不能正常启动。第二点，如果没有采用NBOOT加载EBOOT的方法，而是将EBOOT直接存储在NOR Flash中，此时必须在EBOOT的代码中实现自加载的过程，即将NOR Flash中的EBOOT全部加载到RAM中，并执行，实现代码如下:

Code
;------------------------------------------------------------------------------
;   Copy boot loader to memory

        ands    r9, pc, #0xFF000000     ; see if we are in flash or in ram
        bne     %f20                    ; go ahead if we are already in ram

        ; This is the loop that perform copying.
        ldr     r0, = 0x21000           ; offset into the RAM 
        add     r0, r0, #PHYBASE        ; add physical base
        mov     r1, r0                  ; (r1) copy destination
        ldr     r2, =0x0                ; (r2) flash started at physical address 0
        ldr     r3, =0x10000            ; counter (0x40000/4)
10      ldr     r4, [r2], #4
        str     r4, [r1], #4
        subs    r3, r3, #1
        bne     %b10

        ; Restart from the RAM position after copying.
        mov pc, r0
        nop
        nop
        nop

        ; Shouldn't get here.
        b       .

1. 如果copy的物理地址在512M范围内，那么由于静态映射的存在，lpvSrc可以为静态映射的虚拟地址，也可以为物理地址。采用后者需要指定page_physical，同时lpvSrc右移8位。
2. 如果copy的物理地址在512M范围外，那么由于微软的如下规定“
VirtualCopy also supports the PAGE_PHYSICAL flag. You must set this flag when you are mapping physical memory that resides beyond 512 MB, that is, physical memory with an address above 0x1FFFFFFF.”
lpvSrc只能为物理地址，同时需要右移

只要设置了PAGE_PHYSICAL 为真，那么就需要把lpvSrc右移8位

嵌入式设备与桌面PC的一个显著不同是它的应用程序中通常需要直接访问某一段物理内存，这在驱动程序中对物理内存的访问尤为重要，尤其是像ARM体系结构下，I/O端口也被映射成某一个物理内存地址。因此，与桌面版本Windows相比，Windows CE提供了相对简单的物理内存访问方式。无论是驱动程序还是应用程序都可以通过API访问某一段物理内存。

Windows CE的有些函数中需要用到物理内存结构体PHYSICAL_ADDRESS， Windows CE在ceddk.h中定义了PHYSICAL_ADDRESS，它其实是LARGE_INTEGER类型，其定义如下：

// in ceddk.h

typedef LARGE_INTEGER PHYSICAL_ADDRESS, *PPHYSICAL_ADDRESS;

// in winnt.h

typedef union _LARGE_INTEGER{

 struct{

    DWORD LowPart;

    LONG HighPart;

 };

 LONGLONG QuadPart;

} LARGE_INTEGER;

可见，Windows CE中用64个Bit来代表物理地址，对于大多数32位的CPU而言，只需要把它的HighPart设置为0就可以了。

如果要直接访问某一个地址的物理内存，Windows CE提供了VirtualAlloc()和VirtualCopy()函数，VirtualAlloc负责在虚拟内存空间内保留一段虚拟内存，而VirtualCopy负责把一段物理内存和虚拟内存绑定，这样，最终对物理内存的访问还是通过虚拟地址进行。它们的声明如下：

// 申请虚拟内存

LPVOID VirtualAlloc(

 LPVOID lpAddress,     // 希望的虚拟内存起始地址

 DWORD dwSize,             // 以字节为单位的大小

 DWORD flAllocationType,  // 申请类型，分为Reserve和Commit

 DWORD flProtect           // 访问权限

);

// 把物理内存绑定到虚拟地址空间

BOOL VirtualCopy(

 LPVOID lpvDest,           // 虚拟内存的目标地址

 LPVOID lpvSrc,            // 物理内存地址

 DWORD cbSize,             // 要绑定的大小

 DWORD fdwProtect          // 访问权限

);

VirtualAlloc对虚拟内存的申请分为两步，保留MEM_RESERVE和提交MEM_COMMIT。其中MEM_RESERVE只是在进程的虚拟地址空间内保留一段，并不分配实际的物理内存，因此保留的虚拟内存并不能被应用程序直接使用。MEM_COMMIT阶段才真正的为虚拟内存分配物理内存。

下面的代码显示了如何使用VirtualAlloc和VirtualCopy来访问物理内存。因为VirtualCopy负责把一段物理内存和虚拟内存绑定，所以VirtualAlloc的时候只需要对内存保留，没有必要提交。

FpDriverGlobals =

(PDRIVER_GLOBALS) VirtualAlloc(

    0,

    DRIVER_GLOBALS_PHYSICAL_MEMORY_SIZE,

    MEM_RESERVE,

    PAGE_NOACCESS);

 if (FpDriverGlobals == NULL) {

    ERRORMSG(DRIVER_ERROR_MSG, (TEXT(" VirtualAlloc failed!\r\n")));

    return;

 }

 else {

    if (!VirtualCopy(

    (PVOID)FpDriverGlobals,

    (PVOID)(DRIVER_GLOBALS_PHYSICAL_MEMORY_START),

    DRIVER_GLOBALS_PHYSICAL_MEMORY_SIZE,

    (PAGE_READWRITE | PAGE_NOCACHE))) {

       ERRORMSG(DRIVER_ERROR_MSG, (TEXT("VirtualCopy failed!\r\n")));

       return;

    }

 }

CEDDK还提供了函数MmMapIoSpace用来把一段物理内存直接映射到虚拟内存。此函数的原形如下：

PVOID MmMapIoSpace(

 PHYSICAL_ADDRESS PhysicalAddress, // 起始物理地址

 ULONG NumberOfBytes,                  // 要映射的字节数

 BOOLEAN CacheEnable                   // 是否缓存

);

其实，MmMapIoSpace函数内部也是调用VirtualAlloc和VirtualCopy函数来实现物理地址到虚拟地址的映射的。MmMapIoSpace函数的原代码是公开的，我们可以从%_WINCEROOT%\PUBLIC\COMMON\OAK\DRIVERS\CEDDK\DDK_MAP\ddk_map.c得到。从MmMapIoSpace的实现我们也可以看出VirtualAlloc和VirtualCopy的用法：

PVOID MmMapIoSpace (

    IN PHYSICAL_ADDRESS PhysicalAddress,

    IN ULONG NumberOfBytes,

    IN BOOLEAN CacheEnable

    )

{

PVOID pVirtualAddress; ULONGLONG SourcePhys;

ULONG SourceSize; BOOL bSuccess;

    SourcePhys = PhysicalAddress.QuadPart & ~(PAGE_SIZE - 1);

    SourceSize = NumberOfBytes + (PhysicalAddress.LowPart & (PAGE_SIZE - 1));

    pVirtualAddress = VirtualAlloc(0, SourceSize, MEM_RESERVE, PAGE_NOACCESS);

    if (pVirtualAddress != NULL)

    {

        bSuccess = VirtualCopy(

            pVirtualAddress, (PVOID)(SourcePhys >> 8), SourceSize,

            PAGE_PHYSICAL | PAGE_READWRITE | (CacheEnable ? 0 : PAGE_NOCACHE));

        if (bSuccess) {

            (ULONG)pVirtualAddress += PhysicalAddress.LowPart & (PAGE_SIZE - 1);

        }

        else {

            VirtualFree(pVirtualAddress, 0, MEM_RELEASE);

            pVirtualAddress = NULL;

        }

    }

    return pVirtualAddress;

}

此外，Windows CE还供了AllocPhysMem函数和FreePhysMem函数，用来申请和释放一段连续的物理内存。函数可以保证申请的物理内存是连续的，如果函数成功，会返回虚拟内存的句柄和物理内存的起始地址。这对于DMA设备尤为有用。在这里就不详细介绍了，读者可以参考Windows CE的联机文档。

过程如图：

从图中可以看出，整个编译都是通过调用Blddemo.bat来实现的，实际上也是这样，编译WinCE就是用Blddemo.bat，只不过后面可以跟不同的参数。编译阶段和系统产生阶段由Cebuild.bat完成，文件拷贝阶段由Buildrel.bat完成，最后的生成映像阶段由Makeimg.exe完成。下面介绍一下各个阶段。

1. 编译阶段(Compile phase)

这个过程指对WinCE路径下的Private和Public目录进行编译，将里面的源代码编译成库文件等，这个过程可能会花费几个小时。除非改动了Private或Public目录下的源码，否则是不需要编译的。一般我们编译自己的工程的时候，不需要这个步骤。

2. 系统产生阶段(Sysgen phase)

在这个过程中，系统会根据你在PB中Catalog中的选项，删除和设置相应的SYSGEN环境变量，链接相应的静态库，过滤头文件，为SDK创建所需的导入库，同时还会为WinCE系统创建一些配置文件。最后会编译当前的BSP和应用程序。

3. 文件拷贝阶段(Release Copy phase)

拷贝所有所需的文件到工程的release目录下面，主要是前面系统产生阶段所产生的所有文件。

4. 生成映像阶段(Make run-time image phase)

该过程首先调用cenlscmp.exe根据国际语系与地区设定生成wince.nls文件。然后调用Fmerge.exe合并一些配置文件，合并所有bib文件为ce.bib，合并所有的reg文件为Reginit.ini，合并所有的dat文件为Initobj.dat，合并所有的db文件为Initdb.ini。之后调用Regcomp.exe压缩reginit.ini为default.fdf。根据LOCAL环境变量的设置调用Res2exe.exe更新所有的dll，exe和cpl文件中的资源文件，主要是更新其中的语言部分。再调用Txt2ucde.exe转换所有ASCII码字符串为UNICODE。最后调用Romimage.exe合并所有文件为NK.bin。

在整个编译过程中有时会遇到编译错误，这个可以通过察看Build.log，Build.err和Build.wrn文件来分析问题，这三个文件应该是位于”\WINCE600”目录下面。编译错误可能在不同的编译阶段产生，我们也可以根据这一点来分析问题。

一般在系统产生阶段(Sysgen phase)出现错误很可能是由于丢失组件或文件造成的，这时候Build.log会提供更多信息帮助分析问题。在这个阶段产生错误，很可能是由于在当前工程中添加或者删除WinCE组件造成的，其中有些组件的更改是需要进行”clean sysgen”的，而不能只使用”sysgen”命令。所以我的建议是每次添加或删除组件都做”clean sysgen”。

如上面介绍系统产生阶段(Sysgen phase)也会编译BSP和部分应用。所以如果错误出现在系统产生阶段的编译过程中，一般一种可能就是你的代码有语法错误，当然这种错误很好查。还有一种可能出现的错误是连接错误，有可能是丢失了lib库文件或者链接错了库文件，也有可能是调用了错误的API函数，还有就是设置了错误的环境变量，这些查起来相对困难一点。

如果错误产生在文件拷贝阶段(Release copy phase)，一种常见的问题就是和硬盘驱动器有关，检查一下release目录所在磁盘的磁盘空间。

如果问题出现在生成映像阶段(Make run-time image phase)，根据编译的输出窗口的输出信息判断问题出在哪个子阶段。一种可能是你的bib文件或者reg文件中存在语法错误导致合并文件时出错，还有就是注意你的image的大小是否超过了config.bib文件中的设定，还有就是可能丢失了某个或者某些文件，这些丢失的文件很可能是由于在前面的编译过程中出现错误导致的。

当然，也有时候会遇到一些奇怪的问题，这些问题可能是由于没有正确的安装WinCE造成的，比如在安装WinCE的时候，路径中不要有中文或者空格或者其他比较奇怪的字符。补丁要按照顺序来打，要不也可能会出现问题。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/FLandY1982/archive/2009/12/04/4941120.aspx

    WinCE中的GWES模块负责加载和管理Touch Panel驱动，Touch Panel的MDD层向上提供DDI接口，PDD层是针对硬件的实现，对MDD层提供DDSI接口。

  WinCE中的GWES模块负责加载和管理Touch Panel驱动，Touch Panel的MDD层向上提供DDI接口，PDD层是针对硬件的实现，对MDD层提供DDSI接口。

1 Touch Panel驱动中的数据结构

(1) TOUCH_PANEL_SAMPLE_FLAGS

用于描述一个采样点的信息，这些信息被定义在一个枚举结构中：

               enum enumTouchPanelSampleFlags {

                 TouchSampleValidFlag = 0x01,

                 TouchSampleDownFlag = 0x02,

                 TouchSampleIsCalibratedFlag = 0x04,

                 TouchSamplePreviousDownFlag = 0x08,

                 TouchSampleIgnore = 0x10,

                 TouchSampleMouse = 0x40000000

               };

               TouchSampleValidFlag：一个有效的采样值

               TouchSampleDownFlag：第一次按触摸屏时，返回该flag

               TouchSampleIsCalibratedFlag：采样的x和y坐标值不需要再被校验了

               TouchSamplePreviousDownFlag：表示上一次采样状态是按在触摸屏上

               TouchSampleIgnore：忽略这次采样值

               TouchSampleMouse：预留

(2) TPDC_CALIBRATION_POINT

用于描述一个校验点的相关信息，结构如下：

               struct TPDC_CALIBRATION_POINT {

                 INT PointNumber;

                 INT cDisplayWidth;

                 INT cDisplayHeight;

                 INT CalibrationX;

                 INT CalibrationY;

               };

               PointNumber：校验点索引值，用于描述校验点在LCD上的位置

                                                0：中间

                                                1：左上

                                                2：左下

                                                3：右下

                                                4：右上

               cDisplayWidth：显示的宽度

               cDisplayHeight：显示的高度

               CalibrationX：校验点的x坐标值

               CalibrationY：校验点的y坐标值

(3) TPDC_CALIBRATION_POINT_COUNT

用于描述需要校验的点的个数，结构如下：

               struct TPDC_CALIBRATION_POINT_COUNT {

                  DDI_TOUCH_PANEL_CALIBRATION_FLAGS flags;

                  INT cCalibrationPoints;

               };

               flags：一般为0

               cCalibrationPoints：需要校验的点的个数，一般是5

(4) gIntrTouch和gIntrTouchChanged

这是两个被MDD层用到的中断，需要在PDD层中定义，如下：

                        DWORD gIntrTouch        = SYSINTR_NOP;

DWORD gIntrTouchChanged = SYSINTR_NOP;

gIntrTouch用于描述触摸屏中断，要和硬件的触摸屏中断相关联。

gIntrTouchChanged用于在触摸屏按下后，每隔一段时间进行一次采样，应该和硬件的一个定时器中断相关联。

这两个值应该在DdsiTouchPanelEnable(..)函数中和硬件中断关联，并在函数DdsiTouchPanelGetPoint(..)中根据情况清除相应的中断。

2 MDD层API

        MDD为上层导出所需的Touch Panel驱动接口函数，上层通过这些函数可以完成对Touch Panel的操作，下面会介绍这些函数的功能。

(1) BOOL TouchPanelEnable(PFN_TOUCH_PANEL_CALLBACK pfnCallback):

使能Touch Panel设备，用于初始化Touch Panel。

       pfnCallback：指向处理Touch Panel事件的回调函数

(2) Void TouchPanelDisable(void):

禁用Touch Panel设备。

(3) BOOL TouchPanelGetDeviceCaps(INT iIndex, LPVOID lpOutput )：

获得Touch Panel设备的相关信息。

       iIndex：索引值

                        TPDC_SAMPLE_RATE_ID：采样率信息

                        TPDC_CALIBRATION_POINT_COUNT_ID：采样点个数信息

                        TPDC_CALIBRATION_POINT_ID：采样点坐标信息

            lpOutput：指向一个内存区域，用于存放获得的相关信息

(4) VOID TouchPanelCalibrateAPoint(INT32 UncalX, INT32 UncalY, INT32* pCalX, INT32* pCalY)：

将输入的未经过校验的坐标信息转换成校验后的坐标信息。

       UncalX：输入的X坐标

               UncalY：输入的Y坐标

       pCalX：校验后的X坐标

       pCalY： 校验后的Y坐标

(5) VOID TouchPanelPowerHandler(BOOL bOff)：

Touch Panel的电源控制函数。

       bOff：TRUE表示关闭电源，FALSE表示打开电源

(6) BOOL TouchPanelReadCalibrationPoint(INT* pRawX, INT* pRawY)：

获得Touch Panel的坐标。

       pRawX：触摸屏的X坐标

       PRawY：触摸屏的Y坐标

(7) VOID TouchPanelReadCalibrationAbort(void)：

终止当前的校验。

(8) VOID TouchPanelSetCalibration(INT32 cCalibrationPoints, INT32* pScreenXBuffer, INT32* pScreenYBuffer, INT32* pUncalXBuffer, INT32* pUncalYBuffer)：

校验函数。通过一组实际的触摸屏上采集的点坐标和相应的屏幕坐标计算校验系数。具体公式如下：

        Sx =  A1*Tx + B1*Ty + C1

      Sy =  A2*Tx + B2*Ty + C2

   这里就是通过显示屏坐标和采样的触摸屏坐标计算A1,B1,C1,A2,B2,C2。

       cCalibrationPoints：校验点的个数

       pScreenXBuffer：一组显示屏上的X坐标

               pScreenYBuffer：一组显示屏上的Y坐标

               pUncalXBuffer：一组触摸屏上采样的X坐标

               pUncalYBuffer：一组触摸屏上采样的Y坐标

(9) BOOL TouchPanelSetMode(INT iIndex, LPVOID lpInput)：

设置Touch Panel的工作模式。

               iIndex：索引模式

                                    TPSM_SAMPLERATE_HIGH：设置高采样率

                                    TPSM_SAMPLERATE_LOW：设置低采样率

                                    TPSM_PRIORITY_HIGH_ID：设置触摸屏的IST为高优先级

                                    TPSM_PRIORITY_NORMAL_ID：设置IST为正常优先级

               lpInput：指向一块内存，其中包含相关信息。

3 PDD层API

(1) LONG DdsiTouchPanelAttach(void)：

该函数在Touch Panel驱动的Dll被加载的时候调用

(2) LONG DdsiTouchPanelDettach(void)：

该函数在Touch Panel驱动的Dll被卸载的时候调用

(3) BOOL DdsiTouchPanelEnable(void)：

打开Touch Panel电源并做初始化。一般会在这里初始化一些信息，打开Touch Panel设备电源并做初始化。

(4) VOID DdsiTouchPanelDisable(void)：

关闭Touch Panel设备。关闭Touch Panel电源并释放资源。

(5) BOOL DdsiTouchPanelGetDeviceCaps(ULONG iIndex, LPVOID lpOutput)：

查询Touch Panel设备的相关信息

               iIndex：查询的索引值

                   TPDC_SAMPLE_RATE_ID：查询采样率信息

                   TPDC_CALIBRATION_POINT_ID：查询需要校验的点的坐标

                   TPDC_CALIBRATION_POINT_COUNT_ID：查询用于校验的点的个数

          lpOutput：根据iIndex值分别指向相关的信息

(6) void DdsiTouchPanelGetPoint(TOUCH_PANEL_SAMPLE_FLAGS pTipState, PLONG pUnCalX, PLONG pUnCalY)：

获得Touch Panel上被按下的点的状态和坐标。

               pTipState：当前触摸点的状态，比如无效点，有效点，被按下的点等。

               pUnCalX：触摸点的X坐标

               pUnCalY：触摸点的Y坐标

(7) VOID DdsiTouchPanelPowerHandler(BOOL bOff)：

设置Touch Panel的电源状态。

               bOff：TRUE表示关闭电源，FALSE表示打开电源

(8) BOOL DdsiTouchPanelSetMode(ULONG iIndex, LPVOID lpInput)：

设置Touch Panel工作模式。

               iIndex：模式索引

                        TPSM_SAMPLERATE_HIGH_ID：高采样率

                        TPSM_SAMPLERATE_LOW_ID：低采样率

               lpInput：指向包含相关信息的内存

4 注册表设置

对于Touch Panel驱动来说，有些注册表项是需要配置的。具体如下：

“InputConfig”：WinCE系统输入配置。

Bit0表示键盘输入

Bit1表示Touch Panel输入

                                    Bit2表示硬件按键输入

“DeviceName”：Touch Panel驱动的名字。

“MaxCalError”：Touch Panel的精确度配置。

“CalibrationData”：Touch Panel的校验值。第一次启动WinCE后，需要通过WinCE的触摸屏校验程序对Touch Panel进行校验。校验完成后，校验值会被写入注册表里面。

下面是关于Touch Panel的注册表配置的例子：

[HKEY_LOCAL_MACHINE\ControlPanel]

                "InputConfig"=dword:3    ;3 => keybd and touch screen

[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]

                "DriverName"="touch.dll"

                "MaxCalError"=dword:8

                "CalibrationData"="446,671 36,191 38,1179 856,1161 862,169 "

个人觉得，要想更好的理解Touch Panel驱动，还是需要去读读代码，基于WinCE6.0下，可以参考"\WINCE600\PLATFORM\H4SAMPLE\SRC\DRIVERS\TOUCH"下面的驱动，基于这个驱动开发自己的驱动会比较方便。

Windows CE下触摸屏驱动实现的分析
Analysis of Touch Panel Driver Realization Based on Windows CE OS

刘林辉1    张 芬2

Liu,LinHui1    Zhang,Fen2

（1 长沙理工大学能源与动力工程学院，湖南 长沙，410077；2 华中科技大学机械科学与工程学院，湖北 武汉，430074）

摘要：本文介绍了Windows CE操作系统的触摸屏驱动程序模型，详细阐述嵌入式系统中电阻式触摸屏的Windows CE驱动程序的设计和实现方法。

关键词：触摸屏，Windows CE

中图分类号：TP316

文献标识码：A

Abstract：This article introduced touch panel driver model of Windows CE operating system, and elaborated the driver design and the realization method of resistance-type touch panel based on an embedded system which take Windows CE as operating system.

Keyword：Touch Panel，Windows CE

1. 前言
触摸屏是嵌入式设备中常用的计算机输入设备，它可使操作简单直观，人人都会使用，这一点无论是键盘还是鼠标都无法与其相比。在手机、PDA等手持产品及公共服务设备中大量采用触摸屏。触摸屏分为电阻式、电容式、表面声波式等多种，电阻式触摸屏是目前应用比较广泛的一种，有四线、五线、七线等几种。本文将分析Windows CE操作系统下的触摸屏驱动程序模型及实现方法。

2. Windows CE触摸屏驱动程序模型
在Windows CE操作系统中触摸屏驱动是一种分层驱动。其驱动模型如图1所示。上层是模型设备驱动程序（Model Device Driver, MDD），下层是依赖平台的驱动程序（Platform Dependent Driver, PDD）。MDD通常无需修改直接使用，MDD链接PDD层并定义它希望调用的函数接口：设备驱动程序提供器接口（Device Driver Service Provider Interface, DDSI）。同时MDD把不同的函数集提供给操作系统，这些函数叫做设备驱动程序接口（Device Driver Interface, DDI），这部分为也就是我们通常驱动需要实现的部分。

3 Windows CE的触摸屏驱动程序接口

Windows CE的触摸屏驱动链接了tch_cal.lib和tchmdd.lib两个静态链接库。触摸屏驱动由GWES加载，GWES通过DDI调用驱动程序获取设备状态，设置驱动功能等，而驱动本身通过DDSI直接获得硬件信息来确定当前触摸屏的状态。

Windows CE触摸屏驱动要求的DDI接口包括：TouchPanelGetDeviceCaps、TouchPanelEnable、TouchPanelDisable、TouchPanelSetMode、TouchPanelReadCalibrationPoint、TouchPanelReadCalibrationAbort、TouchPanelSetCalibration、TouchPanelCalibrateAPoint、TouchPanelPowerHandler。

Windows CE触摸屏驱动要求的DDSI接口包括：DdsiTouchPanelAttach、DdsiTouchPanelDetach、DdsiTouchPanelDisable、DdsiTouchPanelEnable、DdsiTouchPanelGetDeviceCaps、DdsiTouchPanelGetPoint、DdsiTouchPanelPowerHandler。

4 Windows CE的触摸屏数据采集
Windows CE触摸屏驱动程序采用中断方式对触摸笔的按下状态进行检测，如果检测到触摸笔按下将产生中断并触发一个事件通知一个工作线程开始采集数据。同时，驱动将打开一个硬件定时器，只要检测到触摸笔仍然在按下状态将定时触发同一个事件通知工作线程采集数据，直到触摸笔抬起后关闭该定时器，并重新检测按下状态。驱动中采用了触摸屏中断以及定时器中断两个中断源，不仅可以监控触摸笔按下和抬起状态，而且可以检测触摸笔按下时的拖动轨迹。

触摸屏驱动在初始化过程调用TouchPanelEnable函数使能触摸屏。该函数调用的DDSI函数为：DdsiTouchPanelEnable和DdsiTouchPanelDisable。该函数实现如下 内容：

1) 创建事件hTouchPanelEvent和hCalibrationSampleAvailable。hTouchPanelEvent事件在正常状态下当有触摸笔按下或者按下后需要定时采集数据时被触发。而hCalibrationSampleAvailable事件在校准状态下当有校准数据输入时被触发；

2) 检查并初始化所需的中断gIntrTouch（触摸屏中断）和gIntrTouchChanged（定时器中断），并将中断gIntrTouch、gIntrTouchChanged关联到事件hTouchPanelEvent。当gIntrTouch，gIntrTouchChanged中断产生时将触发hTouchPanelEvent事件；

3) 创建一个ISR线程TouchPanelpISR。TouchPanelpISR用于等待和处理触摸屏事件hTouchPanelEvent，它是整个驱动程序中唯一的事件源。

TouchPanelpISR函数是实现触摸屏数据采集关键函数，它实现的内容为：

1) 等待循环，用于接收hTouchPanelEvent事件，并构成函数的主体；

2) 通过调用DdsiTouchPanelGetPoint函数获取当前触摸屏位置和状态信息；

3) 在获取有效数据且在校准状态下，收集并提交按下的位置信息；

4) 在正常状态下，校准数据，并检查校准后数据的有效性；

5) 最后调用由GWES传入的回调函数，提交位置信息和状态信息。

因此，在触摸屏驱动程序中DdsiTouchPanelEnable、DdsiTouchPanelDisable和DdsiTouchPanelGetPoint三个DDSI接口函数是驱动实现的关键所在。

在DdsiTouchPanelEnable和DdsiTouchPanelDisable函数中分别打开和关闭触摸屏硬件，这两个函数其实可以不真正操作硬件，而只是实现软件上的控制，但是为了降低功耗最好在DdsiTouchPanelDisable中将触摸屏控制器电源关闭并在DdsiTouchPanelEnable函数中打开。

在DdsiTouchPanelGetPoint函数中实现对触摸屏数据的采样。从上面的分析得知MDD通过检测hTouchPanelEvent和hCalibrationSampleAvailable事件控制采样，这两个事件被触发都将调用该函数。而这两个事件触发条件有两个：

1) 触摸笔按下时产生触摸屏中断gIntrTouch时触发；

2) 触摸笔按下后，定时器被打开，定时器将定时产生中断gIntrTouchChanged，并触发事件，直到触摸笔抬起为止。

因此该函数不仅需要对触摸屏数据采样，而且需要对触发条件进行状态控制，其流程如图2所示。图中定义了三个变量，它们分别为：

1) TouchIrq为静态变量或全局变量，且初始值为TRUE，该变量必须在触摸屏按下并产生触摸屏中断时设置为FALSE；

2) InterruptType为静态变量或全局变量，且初始值为SYSINTR_NOP，当在处理触摸屏中断时设置为SYSINTR_TOUCH，在处理定时器中断时设置为SYSINTR_TOUCH_CHANGED，其余设置为SYSINTR_NOP，且在处理完毕后必须将其作为参数传入InterruptDone函数以清除中断；

3) g_NextExpectedInterrupt为静态变量或全局变量，该变量表示下一个希望产生的中断，初始状态为PEN_DOWN，也就是触摸笔在抬起状态，因此希望下一个产生的中断为PEN_DOWN。当触摸屏中断产生以及定时器中断产生时该变量为PEN_UP_OR_TIMER，也就是下一个可能产生的状态为触摸笔抬起状态或者触摸笔按下但定时器中断产生。

DdsiTouchPanelGetPoint函数一开始从触摸笔抬起状态开始执行，此时TouchIrq等于TRUE。如果此时触摸笔按下，将设置TouchIrq为FALSE，表示本次采样是由于触摸屏中断产生并设置下一次调用由定时器产生。然后设置InterruptType状态为SYSINTR_TOUCH，接着开始采集数据并设置g_NextExpectedInterrupt变量为PEN_UP_OR_TIMER，表示下一次产生的中断为定时器中断。接着判断在触摸笔按下状态（g_NextExpectedInterrupt等于PEN_UP_OR_TIMER）下触摸笔是否抬起，如果抬起则设置g_NextExpectedInterrupt为PEN_DOWN恢复到抬起状态。最后通过将InterruptType作为参数传入InterruptDone函数以清除中断。当触摸笔按下，并产生定时器中断时，TouchIrq等于FALSE，此时InterruptType被设置为SYSINTR_TOUCH_CHANGED，其余的动作基本和上面的流程一致。

5 Windows CE下的触摸屏校准
电阻触摸屏需要校准。应用程序需要一些参考值，以便将接收到的触摸屏坐标数据转换成高层软件所需的屏幕坐标。理想情况下校准程序只要在产品初次加电测试过程中运行一次就可以了，参考值被存储在非易失性存储器中。在理想情况下只需两组原始数据，即在屏幕对角读取的最小和最大值。而在实际应用中，因为许多电阻触摸屏存在显著的非线性，因此如果在最小和最大值之间简单的插入位置数值会导致驱动程序非常的不精确。

在Windows CE中通过在函数DdsiTouchPanelGetDeviceCaps 中设置校准点的个数，在TouchDriverCalibrationPointGet中获取每个校准点的屏幕坐标。常用的校准点数量为5。校准UI将在校准点坐标处相应显示一个十字叉，用户需要精确地在该十字叉位置按下触摸屏，驱动通过TouchPanelReadCalibrationPoint函数读取相应的触摸屏坐标值，然后开始下一个校准点。循环设定的次数后，将采集到的触摸屏坐标值和校准点屏幕坐标送到TouchPanelSetCalibration函数中进行处理。该函数将产生校准基准参数。

TouchPanelSetCalibration函数执行的动作是一套数学算法，具体内容为:

在触摸屏数据与其位置偏移关系且屏幕像素与其位置偏移关系同为线性关系假设情况下，触摸屏返回的位置信息与像素位置信息之间成2D坐标变换关系。则对于触摸屏按下点的触摸屏坐标(Tx,Ty)与其在显示设备位置关系上匹配的点的屏幕坐标(Sx,Sy)之间的转换关系，可以通过下述坐标变换表示：

Sx =  A1*Tx + B1*Ty + C1

Sy =  A2*Tx + B2*Ty + C2

TouchPanelSetCalibration的具体工作就是通过校准的动作获取的屏幕坐标和触摸屏坐标TouchCoordinate来确定A1，B1，C1和A2, B2, C2。

6. 结束语
本文作者的创新点：从分析嵌入式Windows CE操作系统中触摸屏驱动程序的模型及实现方法的角度深入剖析了Windows CE中触摸屏数据采集和校准的执行流程，对于类似系统的驱动开发具有一定的借鉴性。

参考文献：

[1] Paul Kovitz. 电阻式触摸屏结构和实现原理，夏普公司，2003

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhongnanjun_3/archive/2008/11/11/3274020.aspx

转载请注明出处

前段时间移植 6.0 BSP，目前已移植到触摸屏部分了. 移植过程中学到了不少东西. 由其是关于触摸屏这部分, 掌握了很多以前不会的东西. 觉得有必要把这些知识点整理一下. 

一 硬件部分

硬件上的原理不是本文的重点，只讲一下大概的原理(主要是我也只知道大概的原理, 毕竟咱不是搞硬件的. 嘻嘻!)

我移植用的这个屏是320*240 的TFT屏, 四线电阻式触屏. 这种触屏的原理是由两个电阻层组成, 一个实现X位置的测量，一个用于Y位置上的测量. 简单来说，就是当用触笔按下屏幕时，两个电阻层接触, 电阻发生变化，然后在X Y方向上产生信号, 这个信号是电压信号， 再经过CPU内部分AD转换为坐标值. 这个原理有点像高中物理课用的滑动电阻，有一个最大上限，滑动到不同的地方，阻值不同. 2410本身集成了touch的控制器，通过简单的配置和读取相关的寄存器，就可以实现触摸屏的操作. 

二 驱动部分

Wince下的touch驱动跟很多其它的驱动一样, 是分层的, 有MDD 和PDD两层. MDD层被系统隐藏起来, 一般不用我们来修改. 而我们真正关心的是PDD 层. 也就是要由开发者来修改的这一层. 

分析touch驱动时，以我最近刚刚移植到一个基于2410的板子上的6.0的BSP包的触屏驱动为例.到C:\WINCE600\PLATFORM\DEVICEEMULATOR\SRC\DRIVERS\TOUCH下. 找到s3c2410x_touch.cpp文件. 这里面正是PDD层的实现代码. 容易发现这里面的函数分为两类，一类是以TSP开头的函数，一类是以DDSI开头的函数. TSP开头的函数为内部私有的函数，是被DDSI调用的, 而DDSI开头的函数则是对外的接口, 也就是被MDD层的函数调用的接口. 

DdsiTouchPanelEnable是首先被调用的一个外部接口, 它的实现可参见源程序,  它主

要做了下面几个事情:

1 通过调用TSP_VirtualAlloc函数为驱动所用的IO,中断等硬件中断分配内存空间. 

2 通过调用KernelIoControl向系统申请两个中断，如果申请成功，赋予相应的逻辑中断号. KernelIoControl向底层是调用OEMIoControl函数, OEMIoControl根据KernelIoControl传进来的IOCTL代码，做相应的操作,比如这里, IOCTL是IOCTL_HAL_REQUEST_SYSINTR， 它是向内核申请一个物理中断和逻辑中断的映射. 

3 通过调用TSP_PowerOn来初始化中断控制器，ADC寄存器，定时器等, 在TSP_PowerOn的实现中，有几点要说明一下:

ADCDLY 这个值在不同的模式下意义不同, 因为前面通过ADCTSC已经配置为wait for interrupt mode, 所以这个值的意义和你的触笔按下时,  从产生中断信号到开始自动转换X,Y时的时间间隔是相关的，它的单位是ms

v_pPWMregs->TCNTB3  = g_timer3_sampleticks

TCNTB3是timer3的count buffer, 当定时器启动时, 0，这个值以一个设置好的频率递减，直到减到0， 这时会产生一个定时器中断. 这个有什么用呢. 要理解它，得知道触摸屏在中断模式下是如何工作的. 

当我们按下的触摸屏时，会产生一个ADC的中断, 同时我们的驱动还会启动一个定时器, 这个定时器触发一个事件做数据采集, 在我们的手或触笔抬起来前，这个定时器不断的触发采集事件，直到它被关闭, 而它什么时候会被关闭呢，就是在触笔的抬起来时. 下面截取的代码很好的说明的这个原理:

if ( (v_pADCregs->ADCDAT0 & (1 << 15)) |(v_pADCregs->ADCDAT1 & (1 << 15)) )

{

bTSP_DownFlag = FALSE;

DEBUGMSG(ZONE_TIPSTATE, (TEXT("up\r\n")));

v_pADCregs->ADCTSC &= 0xff;

        *pUncalX = x;

*pUncalY = y;

TSP_SampleStop();

            ……

}

上面的代码，if判断的正是是否抬起. 

而g_timer3_sampleticks的值是这样计算出来的. 

g_timer3_freq        = (g_s3c2410_pclk / TIMER3_DIVIDER);

g_timer3_sampleticks = (g_timer3_freq / TSP_SAMPLE_RATE_LOW); 

TIMER3_DIVIDER 的值是2, TSP_SAMPLE_RATE_LOW的值是100, 由

v_pPWMregs->TCFG1  &= ~(0xf << 12);  

v_pPWMregs->TCFG1  |=  (0   << 12); 

可知定时器1/2分频, 所以，很容易计算出，所设置的定时器是每10ms产生一次定时器中断

而触摸屏中断是在你按下和抬起时产生的. 

DdsiTouchPanelGetPoint是采样的主要实现函数，当MDD检测到中断事件发生时，该函数会被调用. 触摸屏的中断是SYSINTR_TOUCH, 而定时器的中断是SYSINTR_TOUCH_CHANGED 

该函数用if else分别处理两种中断, 如下:

if (v_pINTregs->SUBSRCPND & (1<<IRQ_SUB_TC))      /* 触摸屏中断*/

{

    ……

}

else        /*定时器中断 */

{

}

DdsiTouchPanelGetPoint函数的实现代码中，调用了两个很重要的函数TSP_TransXY和TSP_GetXY

需要说明的是，这两个函数的实现跟LCD本身的分辨率是没有关系的.

TSP_GetXY用来获到AD采样值，TSP_TransXY把它转化为屏上的坐标. 我移植touch驱动时，遇到过点屏幕上面，下面有反应，或者点左上角，右上角有反应等类似的问题, 都是因为这两个函数没实现好.

先来看TSP_GetXY函数.它的实现如下:

TSP_GetXY(INT *px, INT *py)

{

INT i;

INT xsum, ysum;

INT x, y;

INT dx, dy;

xsum = ysum = 0;

for (i = 0; i < TSP_SAMPLE_NUM; i++)

{

v_pADCregs->ADCTSC =   (0      <<  8) |        /* UD_Sen*/

(1      <<  7) |        /* YMON  1 (YM = GND)*/

(1      <<  6) |        /* nYPON 1 (YP Connected AIN[n])*/

(0      <<  5) |        /* XMON  0 (XM = Z)*/

(1      <<  4) |        /* nXPON 1 (XP = AIN[7])*/

(1      <<  3) |        /* Pull Up Enable*/

(1      <<  2) |        /* Auto ADC Conversion Mode*/

(0      <<  0);         /* No Operation Mode*/

v_pADCregs->ADCCON |= (1 << 0);  /* Start Auto conversion*/

while (v_pADCregs->ADCCON & 0x1);               /* check if Enable_start is low*/

while (!(v_pADCregs->ADCCON & (1 << 15)));      /* Check ECFLG*/

y = (0x3ff & v_pADCregs->ADCDAT1);

x = (0x3ff & v_pADCregs->ADCDAT0);

xsum += x;

ysum += y;

}

*px = xsum / TSP_SAMPLE_NUM;

*py = ysum / TSP_SAMPLE_NUM;

v_pADCregs->ADCTSC =    (1      <<  8) |            /* UD_Sen*/

(1      <<  7) |            /* YMON  1 (YM = GND)*/

(1      <<  6) |            /* nYPON 1 (YP Connected AIN[n])*/

(0      <<  5) |            /* XMON  0 (XM = Z)*/

(1      <<  4) |            /* nXPON 1 (XP = AIN[7])*/

(0      <<  3) |            /* Pull Up Disable*/

(0      <<  2) |            /* Normal ADC Conversion Mode*/

(3      <<  0);             /* Waiting Interrupt*/

dx = (*px > x) ? (*px - x) : (x - *px);

dy = (*py > y) ? (*py - y) : (y - *py);

return((dx > TSP_INVALIDLIMIT || dy > TSP_INVALIDLIMIT) ? FALSE : TRUE);

}

关于这个函数有几点要说明. 

根据2410的手册, ADCDAT0 保存是X方向上采样的结果,  ADCDAT1 保存是Y方向上采样的结果,  所以, 我们看到下面的两行代码

y = (0x3ff & v_pADCregs->ADCDAT1);

x = (0x3ff & v_pADCregs->ADCDAT0);

与上0x3ff, 是因为, ADCDAT寄存器只用了前面 10位来保存AD采样的结果, 而这和2410内部的AD模块只有10位精度是相一致的.所以，AD转换后的最大值不会超过1024-1. 

当然上在那种计算方法并不是绝对的 ， 根据硬件构造的不同, 比如有可能你x方向的坐标值和采样值成反比，就要按下面的方式计算:

x = 0x3ff - (0x3ff & v_pADCregs->ADCDAT0);

再看TSP_TransXY函数. 我移植的版本的实现如下:

PRIVATE void

TSP_TransXY(INT *px, INT *py)

{

*px = (*px >= TSP_MAXX) ? (TSP_MAXX) : *px;

*py = (*py >= TSP_MAXY) ? (TSP_MAXY) : *py;

*px = (*px - TSP_MINX);

*py = (*py - TSP_MINY);

*px = (*px >= 0) ? *px : 0;

*py = (*py >= 0) ? *py : 0;

*px = *px * TSP_LCDY / (TSP_MAXX - TSP_MINX);

*py = *py * TSP_LCDX / (TSP_MAXY - TSP_MINY);

*px = (*px >= TSP_LCDY)? (TSP_LCDY - 1) : *px;

*py = (*py >= TSP_LCDX)? (TSP_LCDX - 1) : *py;

*px = TSP_LCDY - *px - 1;

*py = TSP_LCDX - *py - 1;

}

这个实现是我在模拟器的实现代码基础上修改的. 这个函数计算X,Y的坐标用的是一个公式，至于这个公式是怎么来的，我就不太清楚了. 只说明一点.

#define TSP_MINX 88

#define TSP_MINY 84

#define TSP_MAXX 952

#define TSP_MAXY 996

上面四个值是定义X+, X-, Y+, Y-四个有效的采样值, 理论上应该是0和1023(10 bit ADC), 但实际肯定有偏差，准确来讲, 换了不同的硬件平台，这四个值应该是要重新测过的. 我就直接沿用原BSP中的值了. 

int x=1;
　　但你从没用到过 x。也许这一行是你以前使用 x 时留下来的，只删除了使用它的代码，而忘了删除这个变量。Warning Level 4 能找到这些小麻烦。所以，为什么不让编译器帮助你完成可能是最高级别的专业化呢？用Level 4 编译是展示你工作态度的一种方式。如果你为公众使用者编写库，Level 4 则是社交礼节上需要的。你不想强迫你的开发人员使用低级选项清洁地编译他们的代码。
　　问题是，Level 4 实在是太过于注意细节，在 Level 4 上，编译器连未引用参数这样无伤大雅的事情也要抱怨（当然，除非你真的有意使用这个参数，这时便相安无事）。假设你有一个函数带来两个参数，但你只使用其中一个：

int SomeFunction(int arg1, int arg2){     return arg1+5;}
使用 /W4，编译器抱怨：

“warning C4100: ''arg2'' : unreferenced formal parameter.”
为了骗过编译器，你可以加上 UNREFERENCED_PARAMETER(arg2)。现在编译器在编译你的引用 arg2 的函数时便会住口。并且由于语句：

arg2;
实际上不做任何事情，编译器不会为之产生任何代码，所以在空间和性能上不会有任何损失。

　　细心的人可能会问：既然你不使用 arg2，那当初为何要声明它呢？通常是因为你实现某个函数以满足某些API固有的署名需要，例如，MFC的 OnSize 处理例程的署名必须要像下面这样：

void OnSize(UINT nType, int cx, int cy);
　　这里 cx/cy 是窗口新的宽/高，nType 是一个类似 SIZE_MAXIMIZED 或 SIZE_RESTORED 这样的编码，表示窗口是否最大化或是常规大小。一般你不会在意 nType，只会关注 cx 和 xy。所以如果你想用 /W4，则必须使用 UNREFERENCED_PARAMETER(nType)。OnSize 只是上千个 MFC 和 Windows 函数之一。编写一个基于 Windows 的程序，几乎不可能不碰到未引用参数。
　　说了这么多关于 UNREFERENCED_PARAMETER 内容。Judy 在她的问题中还提到了另一个 C++ 程序员常用的并且其作用与 UNREFERENCED_PARAMETER 相同的诀窍，那就是注释函数署名中的参数名：

void CMyWnd::OnSize(UINT /* nType */, int cx, int cy){}
　　现在 nType 是未命名参数，其效果就像你敲入 OnSize(UINT, int cx, int cy)一样。那么现在的关键问题是：你应该使用哪种方法——未命名参数，还是 UNREFERENCED_PARAMETER？
　　大多数情况下，两者没什么区别，使用哪一个纯粹是风格问题。（你喜欢你的 java 咖啡是黑色还是奶油的颜色？）但我认为至少有一种情况必须使用 UNREFERENCED_PARAMETER。假设你决定窗口不允许最大化。那么你便禁用 Maximize 按钮，从系统菜单中删除，同时阻止每一个用户能够最大化窗口的操作。因为你是偏执狂（大多数好的程序员都是偏执狂），你添加一个 ASSERT （断言）以确保代码按照你的意图运行：

void CMyWnd::OnSize(UINT nType, int cx, int cy){     ASSERT(nType != SIZE_MAXIMIZE);     ... // use cx, cy}
　　质检团队竭尽所能以各种方式运行你的程序，ASSERT 从没有弹出过，于是你认为编译生成 Release 版本是安全的。但是此时 _DEBUG 定义没有了，ASSERT(nType != SIZE_MAXIMIZE)展开为 ((void)0)，并且 nType 一下子成了一个未引用参数！这样进入你干净的编译。你无法注释掉参数表中的 nType，因为你要在 ASSERT 中使用它。于是在这种情况下——你唯一使用参数的地方是在 ASSERT 中或其它 _DEBUG 条件代码中——只有 UNREFERENCED_PARAMETER 会保持编译器在 Debug 和 Release 生成模式下都没有问题。知道了吗？
　　结束讨论之前，我想还有一个问题我没有提及，就是你可以象下面这样用 pragma 指令抑制单一的编译器警告：

#pragma warning( disable : 4100 )
4100 是未引用参数的出错代码。pragma 抑制其余文件/模块的该警告。用下面方法可以重新启用这个警告：

#pragma warning( default : 4100 )
　　不管怎样，较好的方法是在禁用特定的警告之前保存所有的警告状态，然后，等你做完之后再回到以前的配置。那样，你便回到的以前的状态，这个状态不一定是编译器的默认状态。
　　所以你能象下面这样在代码的前后用 pragma 指令抑制单个函数的未引用参数警告：

#pragma warning( push ) #pragma warning( disable : 4100 )void SomeFunction(...){}#pragma warning( pop )
　　当然，对于未引用参数而言，这种方法未免冗长，但对于其它类型的警告来说可能就不是这样了。库生成者都是用 #pragma warning 来阻塞警告，这样他们的代码可以用 /W4 进行清洁编译。MFC 中充满了这样的 pragmas 指令。还有好多的 #pragma warning 选项我没有在本文讨论。有关它们的信息请参考相关文档。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/apunix/archive/2008/01/14/2043945.aspx

DBGPARAM dpCurSettings =

{
    TEXT("PCIBUS"), {
    TEXT("Errors"),TEXT("Warnings"),TEXT("Functions"),TEXT("Initialization"),
    TEXT("Enumeration"),TEXT("Load Order"),TEXT("Resource"),TEXT("Undefined"),
    TEXT("Undefined"),TEXT("Undefined"),TEXT("Undefined"),TEXT("Undefined"),
    TEXT("Undefined"),TEXT("Undefined"),TEXT("Undefined"),TEXT("Undefined") },
    0x20

};

先来解释一下DBGPARAM结构，该结构在Dbgapi.h中定义，所以在定义dpCurSettings的时候还需要包含这个头文件，该结构定义如下：

typedef struct _DBGPARAM {

    WCHAR  lpszName[32];                    //模块的名字

    WCHAR  rglpszZones[16][32];            //调试域的名字

    ULONG  ulZoneMask;                        //调试域的掩码

}DBGPARAM, *LPDBGPARAM;

在上面的例子中可以看到，第一个是模块的名字，叫PCIBUS。而后定义了16个域的名字，其中只用到了7个域，剩下的都定义为Undefined了。最后一个数字为域的掩码，表示当前哪个域是被激活的，0x20表示只有第6个域是被激活的。从上面的例子还可以看出，前7个域是有意义的，而且按照顺序分别对应1到7。下面针对这些域需要定义相应Debug调试的宏定义：

#define DBGZONE_ERROR                           1

#define DBGZONE_WARNING                     2

#define DBGZONE_FUNCTION                    3

#define DBGZONE_INIT                                4

#define DBGZONE_ENUM                            5

#define DBGZONE_LOADORDER                6

#define DBGZONE_RESOURCE                    7

上述宏定义对应在dpCurSettings中的7个域，然后就可以在打印信息的时候，通过这些宏定义来对应相应的调试域了。例如：

在一个模块中定义了调试域，如果想在系统中去使用还必须注册该调试域，需要用到的函数叫DEBUGREGISTER(..)，其中要把该调试模块的句柄作为参数传给它。例如：

DllMain(..)

{

    switch(op)

    {

        case DLL_PROCESS_ATTACH:

            DEBUGREGISTER(hPCIBUS);

            break;

        ….

    }

}

完成了上述工作以后，就可以重新编译调试的模块，然后运行系统来调试了。调试域的一个好处就是在Debug的过程中，不需要终止系统可以动态的改变调试域，方便我们分析问题。首先，我们可以基于Platform. Builder中的CE Debug Zones来调试，在VS2005的菜单中选择Target，然后选择CE Debug Zones，如图：

然后会出现一个Debug Zones的窗口，在窗口弹出以后，它可能会花一点时间来收集当前支持Debug Zone的模块，如下图：

该图只是一个例子，左边显示了可调试的模块，选择serial_SMDK2410.dll这个模块，就是S3C2410的串口驱动模块。在右侧可以看到各个调试域及名字，用户可以根据需要来选择打开和关闭相应的调试域，最后点击Apply和OK就可以了。

当然，还有其他的方法来修改调试域，一种方法是使用Target Control中的zo命令来修改，Target Control将在以后介绍。还有一种方法就是通过SetDbgZone(..)函数来修改。定义如下：

BOOL SetDbgZone(DWORDdwProcid, LPVOIDlpvMod, LPVOIDbaseptr, DWORDzone, LPDBGPARAMlpdbgTgt)