EP9315内部串口驱动结构： EP9315内部串口采用分层的驱动结构。对内核层的接口函数，在 E:\WINCE500\PUBLIC\COMMON\OAK\DRIVERS\SERIAL文件夹中的Mdd.c文件中。他的目的是建立驱动的结构， COM_Init COM_Deinit COM_Open COM_Close COM_Read COM_Write COM_Seek COM_PowerDown COM_PowerUp COM_IOControl 其中还有中断的处理进程。然后一层是最底层的硬件操作层 COM层函数通过一个结构体调用这一层函数。在E:\WINCE500\PLATFORM\Eac0921\Src\Drivers\Serial文件夹中的p1010com.c文件定义。 Const HW_VTBL IoVTbl = { SerInit, SL_PostInit, SerDeinit, SerOpen, SerClose, SL_GetInterruptType, SL_RxIntr, SL_TxIntrEx, SL_ModemIntr, SL_LineIntr, SL_GetRxBufferSize, SerPowerOff, SerPowerOn, SL_ClearDTR, SL_SetDTR, SL_ClearRTS, SL_SetRTS, SerEnableIR, SerDisableIR, SL_ClearBreak, SL_SetBreak, SL_XmitComChar, SL_GetStatus, SL_Reset, SL_GetModemStatus, SerGetCommProperties, SL_PurgeComm, SL_SetDCB, SL_SetCommTimeouts, }; 调用方法如下： PHWOBJ GetSerialObject(DWORD DeviceArrayIndex) { PHWOBJ pSerObj; // Unlike many other serial samples, we do not have a statically allocated // array of HWObjs. Instead, we allocate a new HWObj for each instance // of the driver. The MDD will always call GetSerialObj/HWInit/HWDeinit in // that order, so we can do the alloc here and do any subsequent free in // HWDeInit. // Allocate space for the HWOBJ. pSerObj = (PHWOBJ)LocalAlloc( LMEM_ZEROINITLMEM_FIXED ,sizeof(HWOBJ) ); if ( !pSerObj ) return (NULL); // Fill in the HWObj structure that we just allocated. pSerObj->BindFlags = THREAD_AT_OPEN; // Have MDD create thread when device is first opened. pSerObj->dwIntID = 0; // SysIntr is filled in at init time pSerObj->pFuncTbl = (HW_VTBL *) &IoVTbl; // Return pointer to appropriate functions // Now return this structure to the MDD. return (pSerObj); } 其中的SL开头的函数都是在p1010ser.c文件中定义。 EP9315外扩串口的驱动结构。 EP9315外部串口也采用分层的驱动结构。不同的是EP9315外扩串口将所有的代码都在 E:\WINCE500\PLATFORM\Eac0921\Src\Drivers\Ext_uart文件夹中。其驱动结构如下：对内核层的接口函数，在Mdd.c文件中。 COM_Init COM_Deinit COM_Open COM_Close COM_Read COM_Write COM_Seek COM_PowerDown COM_PowerUp COM_IOControl 其中还有中断的处理进程。然后一层是最底层的硬件操作层 COM层函数通过一个结构体调用这一层函数。在CCSer_pdd.c文件中。 Const HW_VTBL SerIoVTbl= { CCSerInit, SL_PostInit, CCSerDeinit, CCSerOpen, CCSerClose, SL_GetInterruptType, SL_RxIntr, SL_TxIntrEx, SL_ModemIntr, SL_LineIntr, SL_GetRxBufferSize, CCSerPowerOff, CCSerPowerOn, SL_ClearDTR, SL_SetDTR, SL_ClearRTS, SL_SetRTS, CCSerEnableIR, CCSerDisableIR, SL_ClearBreak, SL_SetBreak, SL_XmitComChar, SL_GetStatus, SL_Reset, SL_GetModemStatus, CCSerGetCommProperties, SL_PurgeComm, SL_SetDCB, SL_SetCommTimeouts, SL_Ioctl }; 调用方法如下： //HWOBJ for EXT_UART1 product serial HWOBJ SerObj4 = { THREAD_AT_OPEN, 0, (PHW_VTBL) &SerIoVTbl }; //HWOBJ for EXT_UART2 product serial HWOBJ SerObj5 = { THREAD_AT_OPEN, 0, (PHW_VTBL) &SerIoVTbl }; //HWOBJ for EXT_UART3 product serial HWOBJ SerObj6 = { THREAD_AT_OPEN, 0, (PHW_VTBL) &SerIoVTbl }; //HWOBJ for EXT_UART4 product serial HWOBJ SerObj7 = { THREAD_AT_OPEN, 0, (PHW_VTBL) &SerIoVTbl }; 其中的SL开头的函数都是在Ser16550.c文件中定义。 扩展串口驱动从EP9315移植到AT92SAM9263下： 1、直接将驱动代码文件夹Ext_uart拷贝到AT92SAM9263的driver下。 2、修改Ext_uart文件夹中的sources文件 !if 0 Copyright (c) Microsoft Corporation. All rights reserved. !endif !if 0 Use of this source code is subject to the terms of the Microsoft end-user license agreement (EULA) under which you licensed this SOFTWARE PRODUCT. If you did not accept the terms of the EULA, you are not authorized to use this source code. For a copy of the EULA, please see the LICENSE.RTF on your install media. !endif !IF ("$(BSP_NOEXTSERIAL)" == "1") && ("$(BSP_BIN)" != "1") SKIPBUILD=1 !ENDIF RELEASETYPE=PLATFORM TARGETNAME=at91sam9263ek_extserial TARGETTYPE=DYNLINK TARGETLIBS= \ $(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib \ $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ceddk.lib \ SOURCELIBS= \ $(_PLATCOMMONLIB)\$(_CPUDEPPATH)\at91sam926x_serial.lib \ SOURCES= \ mdd.c \ ccser_pdd.c \ ser16550.c DLLENTRY=DllMain DEFFILE=at91sam9263ek_extserial.def FILE_VIEW_RESOURCE_FOLDER= \ at91sam9263ek_extserial.def \ at91sam9263ek_serial_extusart.reg \ FILE_VIEW_INCLUDES_FOLDER= \ serial.h \ WINCETARGETFILES= \ $(WINCETARGETFILES) \ CopyFilesToSDK \ SDK_H_FILES= SDK_LIB_FILES= 3、建立一注册表文件，名为at91sam9263ek_serial_extusart.reg 4、修改注册表文件内容。 [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial_4] "SysIntr"=dword:2b ; "Irq"=dword:3 "MemBase"=dword:10000070 "MemLen"=dword:8 "Index"=dword:3 "DeviceArrayIndex"=dword:4 "Prefix"="COM" "Dll"="ext_uart.dll" "Order"=dword:0 ; "Priority256"=dword:fa ; "IsrDll"="isr16550.dll" ; "IsrHandler"="ISRHandler" "FriendlyName"="Serial Cable on COM4:" [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial_5] "SysIntr"=dword:2c ; "Irq"=dword:3 "MemBase"=dword:10000068 "MemLen"=dword:8 "Index"=dword:4 "DeviceArrayIndex"=dword:5 "Prefix"="COM" "Dll"="ext_uart.dll" "Order"=dword:0 ; "Priority256"=dword:fa ; "IsrDll"="isr16550.dll" ; "IsrHandler"="ISRHandler" "FriendlyName"="Serial Cable on COM5:" [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial_6] "SysIntr"=dword:2d ; "Irq"=dword:3 "MemBase"=dword:10000058 "MemLen"=dword:8 "Index"=dword:5 "DeviceArrayIndex"=dword:6 "Prefix"="COM" "Dll"="ext_uart.dll" "Order"=dword:0 ; "Priority256"=dword:fa ; "IsrDll"="isr16550.dll" ; "IsrHandler"="ISRHandler" "FriendlyName"="Serial Cable on COM6:" [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial_7] "SysIntr"=dword:2e ; "Irq"=dword:3 "MemBase"=dword:10000038 "MemLen"=dword:8 "Index"=dword:6 "DeviceArrayIndex"=dword:7 "Prefix"="COM" "Dll"="ext_uart.dll" "Order"=dword:0 ; "Priority256"=dword:fa ; "IsrDll"="isr16550.dll" ; "IsrHandler"="ISRHandler" "FriendlyName"="Serial Cable on COM7:" 5、将Ext_uart文件夹下mdd.def文件名改为at91sam9263ek_extserial.def 6、在别的驱动文件夹下拷贝文件 makefile.inc文件到Ext_uart文件夹下 7、修改BSP包的CEC文件，添加一扩展串口项 AT91SAM9263 EXTSERIAL BSP_ AT91SAM9263_EXTSERIAL BSP_NOEXTSERIAL 8、在PB中加入扩展串口的BSP包，编译，调试。

大家仔细看英文. One thing I’ve neglected to tell in my original post: I’m building my platform from the command prompt, using the environment generated by platform builder. The main point here is that the release directory is not located under \Wince500, it's located under a deep stack of 12 folders. The total path length including the release directory itself is 124 characters. Changing my release directory to a shorter path solved my problem. My guess is that makeimg has internal buffers that are limited to a certain size and that were the source of the "Out of buffer space" error. What is really suspicious is that the same configuration was working fine before I started installing the QFEs. Maybe Microsoft has fixed a bug in makeimg and I was just lucky to get my platform to compile... who knows 如果英文看不懂.. 其实: 说白了就是我的release目录路径太长了。。。

MicrosoftWindows CE是紧凑的、高效的和可升级的操作系统，它被广泛的应用在各种嵌入式式的产品中，从手持电脑到专门的工业控制器和消费用电子产品中。Windows CE已经通过了其自身的能力证明：它能够满足32位嵌入式程序开发的需求。同样重要的是： Windows CE使嵌入式式系统的设计者得以充分利用Microsoft的32位基于Windows的开发工具的全部的函数。 嵌入式的应用软件选择Windows CE的首要原因之一是Microsoft Win32应用编程接口（API）的广泛应用。从运行在Microsoft WindowsNT操作系统下的高端服务器到最小的台式机和内嵌式的应用中，WIN32 API几乎是所有为面向Windows开发32位应用软件的内核。 本文的目的是向那些开发基于Windows CE的新的嵌入式式系统的开发者介绍WIN32 事件驱动编写程序。 本文将： 概述32位Windows操作系统和WIN32编程模型。 介绍线程，事件和消息是如何操作的。 给出Win32如何管理Windows CE的内存。 解释 Win32意外操作的概念。 比较同步和不同步设备的界面的不同的方法。 总结明确定义的API的优位。 本文并不是刻意要完全做Win32的编程指南，而是要介绍用Win32作为嵌入式式应用程序的开发工具。 简介 对于全世界的成千上万的程序开发者来说，Win32程序模式很常见。WIN32是台式机或企业广泛应用的强大目标，而且随着Windows CE的涌现，它也成了嵌入式式系统的理想的程序界面形式。WIN32为Windows CE操作系统提供了一致的，文档完备的并且函数强大的程序界面。 用WIN32在Windows CE平台开发的程序同其他的WIN32程序差不多；这意味着程序开发者在开发新的面向Windows CE操作系统的应用程序的时候，能够应用这些大量的WIN32的程序资源、第三代工具和外部的专门的技术。具有WIN32编程经验的程序员会发现创建新的（维护已有的）面向Windows CE设备（如手持电脑）的应用程序远比创建类似的面向特殊的平台或其他应用不广的嵌入式式的操作系统的应用程序简单。 嵌入式式系统的设计者们很快意识到Windows CE的强大，并且以惊人的快速使这个操作系统与它们的新产品一体化。可是，许多嵌入式式软件的开发者对Windows的事件驱动程序的一般技术不熟悉。对于这些软件开发者来说，在他们开始他们第一次的基于Windows CE的项目之前，了解一些WIN32的基础的知识是有好处的。 什么是WIN32？ “WIN32”表示对于所有的Microsoft 32位平台的一种普通的应用编程接口（API）。这些平台通常指： Windows 95， Windows 98 ，Windows NT，Windows CE 本文我们主要关注Windows CE操作系统，可是需要弄清楚的是大多数 Win32的应用编程接口对上面所有三种平台都适用。这种同用的应用编程接口的优位有很多：容易登录到应用程序中，有大量的已有程序的知识，范例和第三代软件的资源。 平台的差别 WIN32的应用编程接口定义了你作为一个程序员有用的Windows平台。WIN32应用编程接口的目的是提供了一个常用的界面的设置，可是虚拟，不同的平台由于不同的特性及硬件的约束，其应用编程接口也不同。WIN32平台家族的一些成员支持全部的WIN32的应用编程接口（下简称API），而其他的只支持一部分的API。 为紧凑的、嵌入式式的应用软件和小型设备而设计的Windows CE，WIN32的API最受限制。尽管如此， Windows CE 的API也是足够完善的，能够处理实际的大量的高级的嵌入式式应用程序。 WIN32与Microsoft基本类库（MFC） 用WIN32界面设计并不是创建32位基于 Windows的应用程序的唯一的途径。另一种重要的途径是可在WIN32与 Microsoft Visual C++开发环境使用的Microsoft基本类库（MFC）。MFC为许多（不是所有）的WIN32的API进行了高度的封装（图1）。通常，MFC提供了代表重要的WINDOWS的用户界面对象的类，象窗口，对话框，画刷，画笔，和字体。MFC也为没有任何用户界面要求的嵌入式式应用软件提供了相应的类。MFC类的成员函数调用WIN32API的函数，可以使复杂的应用程序的设计巧妙的简化。 作为WIN32的程序员，你可以自由的选取使用C或C＋＋和WIN32 API， 或者用C＋＋与MFC。VISUAL C＋＋开发系统对于所有的，包括 Windows CE 的WIN32的目标操作系统都支持以上的两种开发系统。 本文直接介绍WIN32 API。应用 Windows CE下的MFC的详细的消息，参阅 Windows CE SDK文档。 WIN32程序模型 WIN32是超越所有32位WINDOWS平台的常用和一致的（尽管并不全部相同）API。为了对WIN32 API有一个透彻的了解，以便高效的使用它的函数，了解一些底层操作系统的基础十分重要。本节总结了32位操作系统和 Win32 API的最重要的概念，为你更深入的学习提供基础。要得到更多更详细的关于32位WINDOWS的体系结构、 Win32 API、以及其他的程序设计的主题，你可以读一本关于那个主题出版的书。Microsoft出版社能提供一些这样的书籍；在本文的最后，列着部分这些书的条目。 Windows CE的内核和 Win32 API 那些对WINDOWS CE的人可能会有一个错觉，认为它仅仅是现有的操作系统（如WINDOWS95）降级版。但事实上Windows CE是以小型的、高度用户化的面向嵌入式式应用程序的操作系统开发起来的。在WINDOWS CE排除（或代替）了一些基于WINDOWS CE的应用软件所不需要的操作系统特性的同时，它的内核也具有大量的其他Microsoft 32位的操作系统的最精华的东西。例如在Windows NT下， 所有的在Windows CE下运行所应用软件都运行在有优先权的多任务处理环境下，在被全保护的内存空间里。还有，象 Windows NT一样，Windows CE支持本地统一的字符编码标准码字符串，使它更适于国际推广。可是，不象其他的32位WINDOWS平台，， Windows CE是十分紧凑和用户化的，仅仅占用小于200K的内存。 Windows CE的WIN32 API比其他的32位的Windows操作系统的WIN32 API要小；它只包括大约相当于Windows NT的半数的API。但是 Windows CE的WIN32 API也有其他系统所没有的特性。例如：通知API，它能够操作系统的层次，而不是在运行的应用程序的层次上处理通知事件（如时钟）。触屏的API和对Windows CE的数据库的内置的支持是其他的操作系统所没有的。触屏的API使用于触觉敏感显示器的屏幕校正和用户交互的管理容易实现，而数据库的API提供了快速简捷的访问紧凑的、一般用途的数据库的工具。另一个关于Windows CE的鲜为人知的方面是它的高度的模块化；嵌入式式系统开发者（用Microsoft Windows CE内含的面向Visual C++的软件包）能够创建一个对于它们的独特的硬件平台和应用软件用户化了的Windows CE的版本。 Windows CE操作系统为设计提供了全新的设计环境。Windows CE的开发者几乎不需要支持原有的应用程序或设备，所以操作系统在设计时可以考虑到应用一些最新的思想和应用程序，并且应用最先进的嵌入式式的32位微处理器产品作为它的硬件目标平台。 这对于一个使用Windows CE平台的WIN32 API的用户来说意味着什么呢？这意味着对于现代的、32位的嵌入式式系统，它是一种更简单的API，更加优化的目标操作系统。下面，我们将研究一些重要 的WIN32 API和Windows CE操作系统的内部的内容。 程序和线索 了解WIN32 API和Windows CE操作系统的底层内容的第一步就是了解多任务和多线索索应用程序是如何组织的。WIN32术语中，程序被定义成一个正在运行中的程序实例。象其他的32位Windows 平台一样，Windows CE是一个多任务的操作系统，在一个运行中的程序里，它支持执行多个线索所。 对于嵌入式式的应用程序，Windows CE的多线索索执行能力是它函数的重要的体现。这样就使WIN32嵌入式式程序开发者优先考虑WIN32的线索索的创立与同步。 WIN32的线索索的处理同其他常用的嵌入式式的操作系统是有区别的。不象Unix或其派生的系统，32位Windows平台从一开始设计就支持多线索索应用程序。线索索管理（时序安排，同步和资源管理）由内核来完成，程序开发者利用函数装入内核（通过WIN32 API访问）来建立和管理他们应用程序中的线索索。 例如，如果一个嵌入式式应用程序必须监视多个输入设备并且在监视到一个或多个设备上不同步发生的事件的时候要作出恰当的反映。更进一步，如果这样一个程序也需要更新一些共享的资源（如全局数据结构，磁盘上的文件，或其他设备）来作为与相关设备事件的反映。象这样的一个程序需要一个可靠的线索索管理系统。这恰恰是WIN32 API能够提供的函数：多个线索索能够快捷并且容易的用WIN32 API线索索创建界面建立；同步线索索（多个线索索同时访问一个数据）可以通过不同的方式完成，包括关键的段，有名称和没有名称事件，以及互斥的目标。 Windows CE 被设计成在执行这些同步时占用最少的程序资源。这位对那些函数不强大的开发者来说十分重要；因为内核来负责线索索的管理，不需要使用另外的处理器来循环检测程序或线索索完成，以及执行其他的无用的应用程序层次上的线索索管理。内核已构建好如何管理若干的线索索并且使程序高效地进行的程序。 对于包括若干个程序的应用程序，WIN32 向用于线索索、程序管理和同步提供了一套的完备的处理方法。这些线索索管理特性非常适于嵌入式式应用程序软件，并且对Windows CE开发者是容易得到的。 消息 在32位windows平台上运行的程序更专门化，程序的线索依赖于消息来初始化程序，控制系统资源并且与操作系统和用户通信。 windows消息有各种各样来源 ，包括操作系统，用户活动诸如键盘输入、鼠标、触到屏幕，以及其它运行的程序或者线索。 当消息被送到线索时，这条消息被放置在消息队列中等待最后处理(图3)。每一条线索拥有完全不独立于其它线索所拥有的消息队列的消息队列。线索一般有不断运行的消息循环，恢复和处理消息。当队列地没有消息，并且线索不从事于其它任何活动，系统挂起线索，以节省中央控制器资源。 消息也能用于控制目的，初始化你的应用程序中各种类型的程序，并且他们能利用消息参数传递数据。例如，线索可能收到触屏被激活的消息，消息参数可以表明X和Y为用户行动的坐标。 在另一种类型的消息中，参数可以包括指针或者指向数据结构、窗口或其他对象的句柄。 中断处理 作为一嵌入式的的软件开发者，你可能最关心windows CE消息的处理规则是如何影响你的外部系统接口的时序的。windows CE通过细心设计和准确的衡量以保证其中断时序以及其它相关的特位与嵌入式式的系统设计是适用的。 嵌入式应用程序经常有时间临界的设备接口需要，需要发现并且在一最小的规定的时间之内对设备和系统事件作出反应。为了支持这样应用程序， windows CE包括高度优化中断传送，优先级和服务系统。 在windows CE内核中 ，中断处理分成两个明显的部分:中断服务程序(ISR )以及中断服务线索(IST )。这个系统的目的是使ISR 尽可能小和快。在硬件的层次上，每一中断要求(IRQ )线索路与一特定的软件ISR联系。当被触发时，给定的ISR除了通知内核IST的位置外，还做少量的工作。一旦IST 被初始化(尽管没必要完成)，系统便准备好接受下一中断并且处理下一中断。 每一个中断有一个优先级与他们相联系。 windows CE为确定的线索时时序，利用基于优先级的时间片段算法。与每一ISR 被联系的IST 是正常的线索，因此为IST设置优先级以满足应用程序的时序需要是应用程序软件开发者的责任。 这种将ISR 和IST在中断程序中分开处理最终结果是，典型的中断等待时间被大大地减少了，在中断程序中发生不可接受的延迟的可能性也大大减少。此外， 嵌入式式软件包 和windows CE内核的特性使有可能按习惯定制中断时序和优先级，以满足特定应用程序的需要。 Windows CE和其使用的时间临界、实时应用程序在另一篇文章中包括比本文更详细的内容，文章名为《 Real-time Systems with Microsoft Windows CE》。 内存管理 WIN32 API为向开发者提供了一套完备的和一致的接口。 当开发绝大部分应用程序的时候，软件开发者不需要考虑特定内存结构。 然而对于许多嵌入式应用程序，特别是那些有严格的内存资源约束或者临界时序的要求的，对内存被管理的方法有好的理解是重要的。 Windows的内存的一般结构对于不同的32 位Windows平台是不同的，并且特殊的细节结构在同一32 位Windows操作系统下不同的处理机之间也不同。 (例如，Windows NT的内存结构在X86 平台上与在DEC Alpha 平台上的用法十分不同 。) 对于这段的讨论，我们将专门集中在Windows CE操作系统的部分中进行。 Windows CE的存储结构 像其它的32 位Windows平台一样，Windows CE操作系统也有虚拟内存的特性。内存总在某一时间被分配给应用程序一页，页的大小由系统设计者决定(并在操作系统为目标硬件平台创建时被指定)。例如 在手持电脑，内存页大小是典型的1KB 或者4KB 。 在初始化期间(导入)，Windows CE创造一个独立的被所有程序共享的4GB 虚拟地址空间。当程序引用一个虚拟的地址时，它被内核记录在物理的内存上。 这使得应用程序软件开发者不必去考虑目标系统内存的物理的布局。虽然所有程序共享单一地址空间，应用程序仍然可避免相互误用。Windows CE 通过改变每页的保护来保护程序内存，而不是分配给每一程序不同地址空间。 作为应用程序开发者，你可能不会太在乎目标系统的内存的物理的结构。 内存可以全部是随机存取内存，或者它可能包括闪存卡或者硬盘驱动器。Windows CE操作系统为你管理内存资源，同时WIN32 API 向你提供必要的分配、使用和释放的内存的接口。 然而，作为一个嵌入式的系统的设计者，你将需要细心考虑将在你新的硬件平台上执行的应用程序的内存需要，并且全面考虑成本、速度和可靠性，平衡各种目标的冲突。 如果你为使用Windows CE开发一个新的硬件平台 ，Windows CE的面向Visual C++ 的嵌入式软件包包括资源可以帮助你做出这些决策，并且从而构成操作系统。 无论你的系统内存的配置如何，ROM(只读内存)将占用十分重要的地位。不同于其它的32位Windows操作系统，Windows CE操作系统的代码在只读内存中，并且在那个只读内存中原地执行。 依据你的产品需要，你也能选择在只读内存中放置应用程序代码。 例如，Pocket Word，Pocket Excel和其它应用程序程序，包括在手持电脑只读内存中被提供的。 存储在ROM中的程序组在Windows CE下当地执行，所以嵌入式系统的设计者能够只占用很少的RAM用于堆栈存储的需要。相应地，你的嵌入式应用程序可以利用RAM既作为程序的内存又可作临时存储空间。 为了进一步的增加应用程序软件的性能， Windows CE采用按需求将内存分叶；操作系统仅仅需要解压缩并且装入基于RAM的一小部分程序准备执行。ROM和 基于RAM的程序的灵活性与速度意味着基于Windows CE的设备能够被构造成各种内存结构形式。 手持电脑的内存结构 典型的Windows CE的硬件平台的内存结构是与基于 Windows系统的台式电脑的内存结构十分不同的。 为了知道内存通常如何在Windows中被处理的 ，考查基于Windows CE的最普通的代表性的设备－手持电脑，是很有用的。 在手持电脑中，RAM被分割成两个主要的部分：存储内存和程序内存。 向两部分分配的RAM的量能被手持电脑用户修改(在限制范围内)。 这个RAM的划分图如图4所示。 在手持电脑中的存储内存类似于台式电脑的硬盘RAM。 它被用来存储数据和非系统应用程序。它的三段中每一段被不同的一套WIN32 API 访问函数： Windows CE系统寄存器类似于Windows NT和Windows 95的操作系统的寄存器。你能利用WIN32 寄存器函数来操纵寄存器中键和数值。 被用户安装的应用程序和数据在一般文件存储段中。Windows CE文件系统API 是标准WIN32 文件系统的子集函数。 对于数据库应用程序，由Windows CE 数据库API来存储被管理存储。这API 对Windows CE是唯一的 ，并且在其它的WIN32 平台中没有。 程序内存被用于系统和非系统程序的堆栈存储。 非系统应用程序从存储内存(或者或许PC卡)被取得，非压缩的并且被装入要执行程序内存中。 意外情况处理 的意外情况处理是强大的编程技术，相应一套的WIN32 API 起函数能容易的发现未预料到的错误状况，并且使之恢复。结构化的意外情况处理，允许危险的段的代码可能由于硬件资源的问题、设备的冲突和微小的编码错误而导致失败，以使这部分程序与其余的应用程序分开。这保护了应用程序，使之免于过早的终止或者产生敏感的系统问题。 结构化的意外情况处理包括定义一系列声明作为保护，并且为第一套的声明定义了另一个套声明作为意外情况句柄。 意外情况句柄定义了一个或多个声明来保障系统的运行，而不管保护声明的现有的状态。 在大多数32 位Windows平台上应用WIN32 API 的程序员在运用意外情况句柄的时候通常有两种选择，用C或 C++ 编写应用程序，并且利用WIN32提供的处理意外情况的宏，或者利用C++ 编写应用程序，并且使用C++ 语言定义的意外情况处理函数。 对于这种程序的编写，Windows CE的开发者因无法访问C++的（面向Windows CE的Visual C++ 目前还不支持意外情况处理，所以必须使用WIN32 API的意外情况处理宏。 为了应用WIN32意外情况处理，你将使用一套在WIN32 API 中被定义的宏。 下面一段代码显示其基本概念： __try { // The statements in here have a possibility of failure // and so are guarded. } __finally { // This is the exception handler. This code will execute // after the guarded statements, no matter what happened // in the guarded block of code above. } // This code will execute normally if the program flow allows // it (no goto, exit, etc.) __try 以及__finally 宏产生了使用意外情况句柄的所必要的底层代码。 意外情况的处理对诸如在嵌入式的应用程序中的那些普通的多线程序是有用的。WIN32结构化意外情况处理宏 是一种容易并且强大的保护应用程序使之免受未预料到的失败的方法。 设备处理 有无数硬件设备(外围设备)与应用Windows的平台(Windows NT以及 Windows 95)台式机是兼容的，并且每一年都有更多的东西在市场上涌现。而Windows CE的平台，通常不支持台式计算机支持的设备的很多品种的外围硬件。 然而，为一嵌入式的的系统创造可靠的设备接口在嵌入式的程序设计的过程中，是比较富有挑战性的部分。 这部分地因为典型的嵌入式的系统接口的时序与其它可操作性的需要远比台式电脑计算系统和应用程序的更难。 幸运地，WIN32 API 提供了一套丰富使设备接口方法，使得设备接口程序写起来更容易并适合于特定嵌入式的系统的需要。 WIN32 API是如何帮助的 WIN32 API在你的硬件平台为你提供一套一致的基于流的接口。 为了使用设备，你首先利用适合于设备类型的函数打开它。 对于大多数设备，你利用的函数是在下列例子中的CreateFile 函数： HANDLE hPort = CreateFile("COM1"); // Open the serial port CreateFile函数打开规定的设备(串口)并且返回用于以后在该种设备上的操作(例如读和写)的句柄。 各种各样函数的(包括ReadFile ，WriteFile ，LockFile 和其他)接受这个句柄为参数，并且允许你(例如)读写数据，检查设备状态，并且将从其它程序的存取被锁住的设备或者文件列入清单。 文件输入输出操作被处理成与其它设备类型利用同样的API 函数，并且在文件之内包括随机的访问的函数。 被若干程序或线索同时访问的设备和文件可以分区域地利用LockFile 函数锁定。 在你的应用程序已完成设备或者文件之后，它将调用CloseFile 函数关闭设备，并且进行必要的清除设备的工作。 同步和异步的设备的处理 嵌入式系统的经常有关键的设备有时序需要。 对于这个理由，对底层的操作系统的软件接口必须能够在软件层次上管理同时(或者几乎同时)的系统中不同类型的设备的事件。 WIN32 API 支持对设备的同步和异步的访问，并且用复杂的设备接口设计。 同步的接口是那些在软件需要从设备得到动作的要求，然后等候结果。在同步的设备接口中，最常用的是前面已经提到的ReadFile 以及WriteFile函数。当在同步I/O中使用的时候，不论你与磁盘上的文件、并口或是串口、一个通道或其它类型的设备接口时，都是公用的并且是兼容的。 异步的接口是那些设备要求应用程序为之服务的接口。一个异步的设备的好的例子是键盘。适当和适时的处理异步事件，对于许多嵌入式应用程序是至关紧要的。幸运的是，为Windows CE编写的设备驱动程序能支持同时的多线索访问驱动器。这大大地简化异步输入设备的处理。 你所访问的给定的设备的方法，取决于那个设备的特性和你开发的特定的应用程序的要求。如果你在基于你的Windows CE的硬件平台上创建一个全新的设备(和设备驱动程序)，你可以既从你的硬件设备和驱动器的层次，又可以从应用程序的层次有许多选择。 定制设备和WIN32 尽管嵌入式系统可以支持较小数量的设备，嵌入式系统能形成唯一的和挑战型的设备接口问题。当你开发一个新的硬件平台并且它支持输入输出设备，在模你设计的不同层次上，你将不得不作出决策和折衷方案。例如，除非你只使用通常的off-the-shelf硬件，你必然套写用户设备驱动程序支持你的新外围设备。 你也能需要配置你的Windows CE来包含一些设备处理必要的组件。同时从应用程序的层次，为满足新的设备的需要，你将需要写接口代码。在有如此多变量的情况下，你如何保持你的设备的一定程度的一致行呢?答案就在WIN32 API 中。在WIN32 API环境下，写你的目标驱动程序，你有理由自信的认为那些新设备的接口的应用程序开发者能够创造可信的，可检验和可维护的基本代码。Windows CE设备驱动程序开发工具包，或者简称DDK ，提供了如何创造WIN32功能强大的设备驱动程序信息和范例。 设备的类型 Windows CE支持两种基本类型的设备驱动程序，内置固化的驱动程序和可安装的驱动程序。 如同名字所暗示的，内置固化的驱动程序是被指定用于一个给定的Windows CE的硬件平台的设备。Windows CE的嵌入式系统设计者有责任提供一个内置固化的驱动程序来驱动系统所包括的设备。例如，许多Windows CE平台有一个LCD 触摸屏。这些平台的制造厂为他们的设备提供设备驱动程序，使此硬件可以用于Windows CE操作系统。在完备的系统中，这些内置固化的驱动程序位于Windows CE只读内存中内核的周围。 可安装的设备驱动程序是被设定为为了任何与Windows CE 硬件平台临时连接的外围的设备。这个类型的设备包括：调制解调器，打印机，数字的照相机，PC卡，以及任何数量的其它外部的设备。 可安装的设备驱动程序可能位于只读内存中，但是更典型与临时性的设备的接口的应用程序软件一同装载。 总结 本文已为概略地介绍了面向Windows CE的WIN32 API，其目的是为了突出这种被广广泛应用的并且十分重要的API的一般的特点和优点。有许多其它的细节你需要在第一次使用Windows CE嵌入式产品之前来学习掌握；幸运的是，有很多的WIN32 API 的信息的资源。 这些资源包括Microsoft开发网络(MSDN )，文章(诸如本文)和报纸，以及大量出版的书

在安装wince 4.x 模拟器后需要在你的电脑上安装 Microsoft windows xp sp2的补丁包。很多情况下你可能会得到以下的错误信息。 Devices or applications disabled 'Virtual PC/Windows CE Emulator' will cause Windows to become unstable. Windows has prevented these drivers from loading. 同时你还可能收以下的错误信息： One or more files from the Emulator for Windows CE installation is missing. Please reinstall Emulator for Windows CE and try again. To resolve this problem and to run Window CE 4.x Emulator, disable hardware-based DEP on your computer that is running Windows XP SP2. To do this, follow these steps: 解决这些问题的办法如下： 对于第一个问题： １，点击“开始”按钮，点击“运行”　输入“sysdm.cpl” 按确定。或者在空中面板中选择系统。 ２，在系统属性对话框中，点击“高级”。 ３，在启动和故障恢复后点击“设置”。 ４，然后单击编辑。 ５，如果里面有 /pae 选项，/noexecute　去掉两个，然后添加/execute选项，点击保存退出。点击ok.

//使用imgdecmp.lib做图片浏览时的问题 //===================================================================================================== //TITLE: //  imgdecmp.lib库的link //AUTHOR: //  norains //DATE: //  Friday 25-July-2006 //=====================================================================================================   为求开发的快捷,在做图片浏览器时使用广泛流传的VOIMAGE类,而此类编译时需要连接imgdecmp.lib。在PB的安装目录下搜索,发现位于"..\PUBLIC\WCESHELLFE\OAK\LIB\ARMV4I\RETAIL"文件夹中有imgdecmp.lib。在EVC编译环境中选择此.lib路径，但无奈总编译不成功，提示连接imgdecmp.lib出错。但把相同的代码给朋友编译，他却成功编译。于是把朋友的imgdecmp.lib和PB下的相比较，发现朋友的lib只有区区的2.35kB，而PB下的却有555kB！   查找pb的帮助文档，关于imgdecmp.lib的描述如下：   Module ：    imgdecmp   Description ：  Image decompression for .NET Compact Framework applications   Note ：     Included with .NET Compact Framework.   Library ：    Imgdecmp.lib   于是在工程中添加.NET Compact Framework特性，编译完毕在工程的目录下可以发现有Imgdecmp.lib，大小和朋友的一样也是2.35k。在EVC选择此lib，顺利编译通过！   添加.NET Compact Framework特性后，pb工程下还会出现连接完毕的imgdecmp.dll。即使最后的WinCE系统没有.NET Compact Framework组件，此dll依然可用。由此可见imgdecmp.dll并不是基于.net，但却需要添加.net才会编译，倒是让人有点费解。

如何让系统加载自己写的驱动程序？    两种办法：   1、在[HKEY_LOCAL_MACHINE\Drivers\BuiltIn]下添加注册键。   2、在应用程序中调用ActivateDeviceEx。      在一些文件中用分号来表示注释，例如下面的内容    ; @CESYSGEN IF SERVERS_MODULES_HTTPD   ; @CESYSGEN ENDIF   在“CESYSGEN...”前加了“@”，有没有什么特别的含义？   在WINCE的一些文件中，用“;”作为注释并在注释文字中用@CESYSGEN作为标记，后面接条件语句。Cefilter.exe工具负责按照条件来筛选文件内容，所以不要轻易地删除包含@CESYSGEN的注释语句。      通过串口建立ActiveSync联接,串口线用三线的可以吗?    不可以，因为用串口同步时要用到其余口的状态。  

例子代码如下（前提是显示驱动程序支持旋转）：   DEVMODE  devmode = {0};   devmode.dmSize = sizeof(DEVMODE);   devmode.dmDisplayOrientation = DMDO_90;       ///垂直模式   devmode.dmFields = DM_DISPLAYORIENTATION;   ChangeDisplaySettingsEx(NULL, &devmode, NULL, 0, NULL);  ///改变显示的设置   CRect  rcWorkArea(0, 0, 320, 240);    ///整个屏幕尺寸   ///设置客户区大小并广播消息，这样所有软件也就随之更改显示   SystemParametersInfo(SPI_SETWORKAREA, 0, (void*)&rcWorkArea, SPIF_SENDCHANGE);   

使用VirtualAlloc和VirtualCopy的时候需要注意哪些事项？   1、VirtualAlloc的作用是申请虚拟地址空间，这肯定不是最终的目的，最终目的可能是申请物理内存、映射寄存器、提交文件等。没有一个目的会在意虚拟地址空间的位置，所以尽量传递参数1为0，也就是让WINCE自动分配虚拟地址空间。VirtualAlloc分配地址空间实际上是以64KB为单位，所以要指定申请的虚拟空间的首地址的话，参数1应该为64KB的整数倍，申请的长度也应该为64KB的整数倍，即使你不需要那么大。   2、VirtualCopy的主要作用是映射物理地址空间，如果参数2为物理地址，那么最后一个参数要添加PAGE_PHYSICAL，参数2必须是256的整数倍。如果参数2为虚拟地址（0x80000000以上），那么最后一个参数就不要添加PAGE_PHYSICAL，WINCE内核会根据这个虚拟地址找到对应的物理地址。      驱动程序和应用程序之间传递数据时何时调用MapPtrToProcess？   因为设备管理器负责加载驱动程序DLL，这意味着当应用程序调用驱动程序接口函数的时候，WINCE内核会将调用驱动程序接口函数的线程转移到设备管理器的进程空间然后执行具体的驱动程序代码，应用程序和设备管理器处于两个进程空间，这就造成设备管理器无法访问应用程序传递的指针（虚拟地址），所以当我们在应用程序中传递指针给流驱动程序接口函数时，WINCE内核从中作了一个地址映射，例如ReadFile、WriteFile、DeviceIoControl函数的参数凡是指针都经过了映射才传递给驱动程序，所以很多驱动程序开发者并不了解其中的奥秘就可以编程了。但是如果参数是一个指向一个结构体的指针，而结构体里包括一个或多个指针，那么WINCE内核并不负责映射，所以就需要开发者在驱动程序接口函数中调用API函数MapPtrToProcess来映射地址。例如：pPointer_retval = MapPtrToProcess(pPointer, GetCallerProcess());