第十四章 Windows CE.NET 系统开发

1. 第十四章 Windows CE.NET系统开发 §14.1 Windows CE.NET开发 §14.2 BSP开发概述 §14.3 驱动程序开发 §14.4 BootLoader开发 §14.5 OAL开发

2. 14.1 Windows CE.NET开发

3. 远程连接 Windows CE 外壳 WIN32 APIs COREDLL, WINSOCK, OLE, COMMCTRL, COMMDLG, WININET, TAPI Windows CE.NET开发 • 根据开发所处的层次以及工具的不同： • Windows CE.NET应用开发 • Windows CE.NET系统开发 基本 不可改动 ISV, OEM 可以定制 应用程序 嵌入式外壳 红外 内核 TCP/IP IPv6 GWES 文件管理 设备管理 文件驱动 驱动 设备驱动 OAL Bootloader OEM 硬件

4. 14.1.1 Windows CE.NET系统开发 • Windows CE.NET操作系统定制 • Windows CE.NET驱动程序开发 • Windows CE.NET操作系统移植（BSP开发）

5. （1） Windows CE.NET操作系统定制 • 操作系统定制的一般流程： • 得到并安装BSP （CEC文件） • PB自带 • 从OEM硬件厂商获得 • 自主开发 • 定制操作系统 • 生成操作系统镜像：NK.bin文件 • 下载调试 • 仿真 • CEPC • 下载到开发板调试

6. （2）Windows CE.NET驱动程序开发 • 普通操作系统的驱动模型，两种模式： • 静态链接：驱动代码编译成.LIB文件并与操作系统内核链接，形成一个整体，随操作系统一起启动加载。 • 动态链接：操作系统在启动后对硬件驱动延迟加载，但是依然加载到操作系统的内核空间中。 • Windows CE.NET驱动模型比较特殊 • 在Windows CE下，所有驱动都以用户态下的DLL文件形式存在。

7. BSP OEM抽象层 （OAL） 设备驱动程序 系统配置文件 引导程序 （Boot Loader） 标准开发板(Standard Development Board) （3） Windows CE.NET操作系统移植 • BSP（ Board Support Package ）：是介于主板硬件和操作系统之间的一层软件系统。 • 开发BSP的内容主要包括： • BootLoader开发 • OAL开发

8. 2. Windows CE.NET应用开发 • Windows CE.NET为应用程序开发人员提供了三种选择，分别是： • Win32应用程序编程接口（ Win32 API） • 微软基础类（Microsoft Foundation Class，MFC）和活动模板库（Active Template Library ，ATL） • .NET Framework精简版（ .NET Compact Framework ， .NET CF）

9. Windows CE.NET应用开发的选择

10. 三种API的特点比较

11. Device UnderDevelopment Device Emulation Development CycleFrom Platform to Applications Device Development Builds and Brings Up Device Application Development Builds Rich Applications Export SDK with Device Specific Win32 APIs or use Standard SDK Platform Builder eMbedded Visual C++ 4.0 C/C++ MFC/ATL Download Device Specific Windows CE OS and Applications Component Catalog incl. .NET CF Visual Studio .NET VB/C# via KITL via KITL Build DeviceImage Smart Device Programmability Debug Device

12. 14.1.2 Windows CE.NET开发过程 • 1. 迭代开发过程 • 基于Windows CE设备的开发过程是由不断修改、增加配置特征、构建、下载、调试等步骤所组成的一个迭代开发过程

13. 典型的平台开发周期 • 在一个典型的平台开发周期当中，为了构建一个基于Windows CE .NET的平台，应该包含以下几个步骤： • 开发人员必须首先选择一个适合于目标设备的Windows CE 的配置，即平台的定制（Customize Platform）。 • 然后，基于上述配置创建一个操作系统镜像，并且开发一个BootLoader，用于将镜像下载到目标设备（如CEPC，或者一个真正的目标板）。 • 在目标平台上，开发人员可以修改和调试操作系统（Debug Platform），使之更为适合于目标设备。 • 一旦完成操作系统配置，开发者就可以利用P1atform Builder提供的导出SDK工具。

14. 2. 串行开发和并行开发 • 一个完整的基于Windows CE的设备开发过程包括硬件开发调试（Port H/W）、Windows CE操作系统定制（Customize OS）和应用程序开发调试（Develop Apps）三个阶段。 • 由于后一阶段的工作必须依赖于前一阶段工作的完成，所以传统的开发设计过程是逐阶段的串行过程

15. 并行开发 • 为了能够缩短基于Windows CE设备的开发周期，充分调动开发人员，必须要能够减小或者消除上述三个阶段的相关性，使各个阶段的工作可以独立进行。

16. 并行开发过程 • 在硬件开发者开发调试定制的设备硬件的同时，操作系统开发者就可以先在模拟器或任意SDB上开始操作系统特征的定制，并按照设备定义为应用程序开发者导出SDK。 • 而应用程序开发者在硬件开发者开发硬件、操作系统开发者定制操作系统的同时，也可以先在模拟器上从事应用程序软件的开发调试，在得到操作系统开发者导出的SDK时，也可以在SDB上进行应用程序的开发调试。 • 在所有三个阶段的工作都分别完成后，定制的操作系统和开发的应用程序最终再移植到定制的设备硬件上进行综合测试和调试。

17. 3. 工程开发进度图 • 一个典型的Windows CE工程的开发进度图，图中展示了各个阶段要完成的主要开发任务及其时间线，主要包括四个任务：OS移植Porting、OS定制、应用开发Apps以及测试QA。

18. 14.2 BSP开发概述

19. 14.2.1 BSP概述 • Windows CE .NET的可移植性是通过BSP来实现的。Windows CE采用了分层的设计方法，将系统中与硬件直接相关的一层软件独立出来，称之为板级支持包（Board Support Package，即简称BSP）。 • BSP位于硬件平台与操作系统之间，属于操作系统的一部分。其主要功能在于配置系统硬件使其工作于正常的状态，完成硬件与软件之间的信息交互，为OS及上层应用程序提供一个与硬件无关的软件平台（包括操作系统的驱动及硬件驱动）。BSP能够支持众多的硬件平台。

20. BSP功能 • 其具体功能包括： • 硬件初始化，主要是CPU的初始化，为整个软件系统提供底层硬件支持； • 为操作系统提供设备驱动程序和系统中断服务程序； • 定制操作系统的功能，为软件系统提供一个实时多任务的运行环境； • 初始化操作系统，为操作系统的正常运行做好准备。

21. 2. BSP和PC机主板上的BIOS区别 • BIOS主要是负责在电脑开启时检测、初始化系统设备（设置栈指针，中断分配，内存初始化..）、装入操作系统并调度操作系统向硬件发出的指令，它的Firmware代码是在芯片生产过程中固化的，一般来说用户是无法修改。在OS正常运行后，BIOS的作用基本上也就完成了。 • PC机BIOS的作用更像嵌入式系统中的BootLoader（最底层的引导软件，初始化主板的基本设置，为接收外部程序做硬件上的准备）。与BootLoader不同的是，BIOS在装载OS系统的同时，还传递一些参数设置（中断端口定义等)，而BootLoader只是简单的装载系统。 • BSP是和操作系统绑在一起运行在主板上的，尽管BSP的开始部分和BIOS所做的工作类似，可是大部分和BIOS不同，作用也完全不同。此外BSP还包含和系统有关的基本驱动（串口，网口...)，此外程序员还可以编程修改BSP，在BSP中任意添加一些和系统无关的驱动或程序，甚至可以把上层开发的统统放到BSP中。而BIOS程序是用户不能更改，编译编程的，只能对参数进行修改设置。更不会包含一些基本的硬件驱动。

22. 14.2.2 BSP基本结构 • BSP主要由4部分构成：OEM抽象层、引导程序、设备驱动程序和配置文件

23. 1. BootLoader • 引导程序(BootLoader)是在硬件开发板上执行的一段代码。 • 它的主要功能是初始化硬件，加载操作系统镜像(OS Image)到内存，然后跳转到操作系统代码去执行。

24. 2. OAL • OEM抽象层简称OAL(OEM Abstraction Layer)。它是操作系统内核抽象出来的与硬件交互的接口，它的实现代码通常是与硬件高度相关的。 • OAL层主要负责Windows CE内核与硬件的通信。当引导程序引导操作系统结束后，由OAL层负责硬件平台初始化、中断服务例程ISR、实时时钟RTC、计时器Timer、内核调试、开关中断和内核性能监测等工作。

25. 3. Device Driver • 设备驱动程序(Device Driver)是BSP的一个重点。 • 对于某个特定的BSP来说，当中应该包含在这块开发板上的所有的设备驱动程序，这样才可以保证Windows CE操作系统能够发挥开发板的最大效能

26. 4. Configuration File • 配置文件(Configuration File)是一些包含配置信息的文本文件。这些配置信息通常与系统镜像或源代码有关。 • BSP中的配置文件包括：镜像配置文件BIB、DB、REG、DAT，源代码配置文件Sources和DIRS文件，以及将BSP与Platform Builder集成的CEC文件。

27. 14.2.3 BSP开发 • BSP开发思想 • 一般来说，BSP的开发并不是要求开发者从零开始 • 对常用类型的CPU和外围设备，Platform Builder都提供了BootLoader、OAL、Device Driver的源代码，只要使用Platform Builder对已有的BSP进行剪裁和稍做修改，再加上微软提供的内核，就能驱动大多数的硬件设备。 • 而且Platform Builder还提供了丰富的标准应用程序和服务程序，在开发好OEM层之后，再加上这些应用和服务，就能让用户的硬件平台工作起来。

28. BSP开发过程 • BSP的开发包括三个方面：BootLoader开发、OAL开发和驱动程序开发。一个BSP可以被定义为一个.cec文件，这个文件定义了可以添加到定制硬件平台的一组默认特征。 • BSP开发的步骤如下： • （1）硬件准备 • （2）克隆参考BSP • （3）开发BootLoader • （4）开发OAL • （5）开发驱动程序 • （6）发布BSP

29. 14.3 驱动程序开发

30. 14.3.1编写Windows CE.NET驱动的要素 • 要了解驱动程序所针对的硬件 • 阅读硬件规范和白皮书 • 要了解目标操作系统下驱动的工作机制 • 加载和卸载 • 初始化 • 访问外设I/O • 处理中断 • 处理DMA • 了解驱动程序模型 • 对于某一类外设，操作系统会提供特定的驱动模型

31. 驱动开发工具 • Windows CE 的驱动程序可以使用Platform Builder或者Visual Studio来进行开发。 • 平台开发人员通常使用Platform Builder开发设备驱动程序，驱动程序作为BSP（Board SupportPackage）的一部分进行整体编译开发； • 独立硬件供应商（Independent Hardware Vendor ，IHV）使用Platform Builder开发驱动程序，对于部分驱动也会使用Visual Studio开发； • 应用程序开发人员更多地使用Visual Studio开发驱动，某些情况下会使用PB。

32. 14.3.2 Windows CE.NET的驱动模型 • 驱动程序将操作系统和设备连接起来，使得操作系统能够识别设备并为应用程序提供设备服务。 • 驱动程序模型决定了驱动程序的软件接口，因此，不同的驱动模型只能通过它们支持的软件接口来区别，而不是它们所适用的设备。 • 按加载方式和接口类型分类，基于Windows CE的驱动程序主要分为两类

33. （1）本机驱动程序（Built-In Drivers） • 本机驱动程序又被称为native device drivers，它是由微软开发并由系统直接支持，适合于集成到CE 平台的设备，典型的包括电源驱动、显示驱动、鼠标键盘驱动、打印机驱动以及LED显示驱动。 • 这些驱动程序通常由GWES（图形窗口及事件子系统）统一管理和加载，成为GWES的一部分，不表现为单个的DLL 使用。

34. （2）流接口驱动程序（Stream Drivers） • 另外一个名称又称为可安装驱动（Installable Drivers）。它具有较好的可移植性和可扩展性，被设备管理器独立出来管理统筹。 • 流驱动程序是一般类型的设备驱动程序，支持几乎所有可连接在Winows CE平台上的外部设备，所以更常用。

35. 流接口驱动程序 • 流接口驱动程序是以用户模式的DLL文件形式出现，并且通常由设备管理器（Device Manager）动态加载。 • 驱动接口是标准的流式接口，尤其适用于IO操作。它实现了一组流接口函数（CreateFile、ReadFile、WriteFile、IOControl等），这些函数使得应用程序可以通过文件系统访问驱动程序，也就是将设备当作文件来进行操作。 • 典型的流接口驱动程序包括PCMCIA driver (PCMCIA.DLL)、Serial driver (SERIAL.DLL)、ATA/FLASH driver (ATA.DLL)、Ethernet driver (NE2000.DLL，SMSC100FD.DLL)。

36. 2. 按驱动层次分类 • 按驱动层次分类，驱动程序可以分为两类

37. （1）层次型驱动程序（Layered Driver） • 驱动采用分层结构，一般分为两层： • 上层是模型设备驱动程序MDD（Model Device Driver），与硬件无关，面向上层应用程序，一般由微软建立统一框架； • 而下层是依赖平台的驱动程序PDD(Platform Dependent Driver)，是针对具体硬件平台的操作代码，一般由驱动开发商实现。 • MDD和PDD之间通过标准的设备驱动服务供应商接口DDSI连接。

38. （2）独立型驱动程序（Monolithic Driver） • 独立型驱动程序基于单个硬件，直接把硬件设备的功能性通过设备驱动程序接口（DDI）传递给操作系统。 • 独立驱动程序包含了MDD面向上层应用和PDD面向硬件平台两方面的代码，适用于操作不复杂的驱动。这样减少了MDD和PDD传递之间传递信息的开销，实时性更强。

39. 3. 驱动模型 • Windows CE.NET的驱动模型就是基于驱动层次的分类所构建的，大多数 Windows CE 设备驱动程序都由一个平台相关驱动程序 (PDD) 和一个模型设备驱动程序 (MDD) 组成。

40. （1）模型设备驱动程序（MDD） • 微软为链接驱动程序提供了模型设备驱动程序（Model Device Driver，MDD）。对平台和函数来讲模型设备驱动程序是通用的，既是源代码也是库。 • 模型设备驱动程序执行下列任务： • 链接PDD层并定义它希望调用的函数，通常这些函数叫做设备驱动程序服务器提供接口（DDSI）。 • 把不同的函数集提供给操作系统，通常这些函数叫做设备驱动程序接口（DDI ）. • 负责与GWES模块和内核通信，包含一些复杂的操作，例如中断处理等。

41. （2）平台依赖驱动程序（PDD） • 平台依赖驱动程序（Platform Dependence Driver，PDD）完成真正的硬件访问操作： • 包含与某款硬件相关的代码 • 对于不同的硬件产品或者标准，有不同的实现 • 只能与某一类MDD协同工作 • 实现MDD所需要的DDSI函数

42. （3）MDD与PDD关系 • 在编写驱动程序时，通常PB中会自带此类型驱动的MDD代码，所以MDD代码是无需更改，我们只需要修改PDD层的代码。 • 通常，MDD层的代码与PDD层的代码会被编译成独立的静态Lib库，然后进行链接，形成可执行的驱动程序。 • 所以，MDD和PDD的划分只是在源代码逻辑层面，在驱动程序的二进制可执行代码中不会存在MDD和PDD的分层。

43. （4）驱动模型接口 • 设备驱动程序接口（ＤＤＩ）：是在ＭＤＤ中实现的函数集，ＧＷＥＳ模块通过这个接口调用设备驱动程序。 • 设备驱动程序服务器提供接口（ＤＤＳＩ）：是在ＰＤＤ中实现的函数集并由ＭＤＤ调用。 • 当操作系统访问硬件时，首先通过使用DDI函数与驱动程序交互，然后在驱动程序内部，MDD再通过DDSI函数与PDD交互，最后由PDD完成真正的硬件访问操作。

44. 14.3.3 Windows CE.NET驱动程序的中断机制 • 与其他计算机结构一样，当设备需要驱动程序的服务时，基于WinCE.NET的平台要使用中断通知操作系统 • 在有些情况下，可以说中断是外部硬件对系统服务的请求，而中断服务程序 I/O地址就是操作系统对硬件服务的响应 • WinCE.NET把中断处理分为两部分： • 中断服务例行程序（Interrupt Service Routine，ISR） • 中断服务线程（Interrupt Service Thread，IST）

45. 1. ISR • 中断服务例程(Interrupt Service Routine，ISR) 属于内核模式的服务，其主要功能是响应设备中断请求并确定把哪个中断标识返回给核心中断处理器。 • 一般情况下ISR不会做太多的工作，而是依靠一个特定的中断服务线程(Interrupt Service Thread，IST)完成大量必要的中断处理。 • 当需要更多的处理时，ISR通过返回一个非SYSINTR_NOP的逻辑中断值让内核知道。

46. 两种类型的ISR • Windows CE支持两种类型的ISR： • 静态ISR：只能被静态编译进内核，运行时不能改变。与IST通信是单向的，只能是ISR到IST。静态ISR支持中断嵌套，并使用核心堆栈。 • 可安装ISR：由内核管理程序从DLL中动态加载，双向通信，多个ISR可以和一个中断请求相关联，系统按照加载驱动程序顺序依次调度。

47. 2. IST • 在Windows CE的中断机制中，由IST具体处理中断的事务性工作。 • 当内核接到ISR传来的中断标识之后，发出一个中断事件，激活一个正等待在该事件的事件队列上的IST，一段时间之后，调度器将调度这个线程工作，处理中断的事务。

48. IST的特点 • IST是进行绝大多数中断处理的一个用户模式的线程。 • IST在大部分时间里是空闲的，当需要它执行一些处理时依靠操作系统去唤醒它，这是通过将一个事件对象与一个中断标识符进行关联来完成的。 • IST执行的第一个操作是产生一个事件对象并将它与一个逻辑中断关联。 • 当硬件中断发生时，内核触发代表ISR的事件，然后IST使设备完成必要的I／O 操作来采集数据或者处理数据。当中断处理完成时，IST应该通知内核再次开启硬件中断。 • 通常IST在正常的优先级之上运行，驱动程序可以通过使用CeSetThreadPriority 函数改变IST的优先级。

49. 3. Interrupt Architecture中断机制 • OEM Hardware层为硬件和中断控制器的状态；Kernel层是中断服务过程中的内核交互；OAL层描述了主板支持软件包 (BSP) 的职责；应用层阐述了中断服务所需的应用程序或驱动程序线程交互。

50. 中断处理过程 • 当一个硬件中断发生时，它被发送到内核的异常处理器(Exception Handler)，由内核处理这个异常。 • 内核的中断支持处理器(Interrupt Support Handler)调用OAL函数OEMInterupt_Disable与硬件交互。 • 内核调用ISR(中断服务例程)来决定应该怎样处理这个中断。 • ISR将中断映射并设置相应的核心中断标识。 • 内核触发它的中断支持处理器(Interrupt Support Handler)来触发唤醒IST并完成它的工作。 • 当IST被唤醒后，它做处理中断要做的所有工作。 • 内核在接收到 SYSINTR 值的 InterruptDone 时，调用OEMInterruptDone完成这个中断所有的处理，OAL函数(OAL Routine)通知硬件重新开启这个中断。只有从这时开始，才能接收该设备的其他中断。