|
| 出处： 时间： 2007-11-01 |
|
作为一嵌入式的的软件开发者，你可能最关心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内核的特性使有可能按习惯定制中断时序和优先级，以满足特定应用程序
的需要。 Windows CE和其使用的时间临界、实时应用程序在另一篇文章中包括比本文更
详细的内容，文章名为《 Real-time Systems with Microsoft Windows CE》。
内存管理
果你为使用Windows CE开发一个新的硬件平台 ，Windows CE的面向Visual C++ 的嵌入
式软件包包括资源可以帮助你做出这些决策，并且从而构成操作系统。
无论你的系统内存的配置如何，ROM(只读内存)将占用十分重要的地位。不同于其它的3
2位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 是标准WI
N32 文件系统的子集函数。
对于数据库应用程序，由Windows CE 数据库API来存储被管理存储。这API 对Windows
CE是唯一的 ，并且在其它的WIN32 平台中没有。
程序内存被用于系统和非系统程序的堆栈存储。 非系统应用程序从存储内存(或者或许
PC卡)被取得，非压缩的并且被装入要执行程序内存中。
意外情况处理
的意外情况处理是强大的编程技术，相应一套的WIN32 API 起函数能容易的发现未预料
到的错误状况，并且使之恢复。结构化的意外情况处理，允许危险的段的代码可能由于
硬件资源的问题、设备的冲突和微小的编码错误而导致失败，以使这部分程序与其余的
应用程序分开。这保护了应用程序，使之免于过早的终止或者产生敏感的系统问题。
结构化的意外情况处理包括定义一系列声明作为保护，并且为第一套的声明定义了另一
个套声明作为意外情况句柄。 意外情况句柄定义了一个或多个声明来保障系统的运行，
而不管保护声明的现有的状态。
在大多数32 位Windows平台上应用WIN32 API 的程序员在运用意外情况句柄的时候通常
有两种选择，用C或 C++ 编写应用程序，并且利用WIN32提供的处理意外情况的宏，或者
利用C++ 编写应用程序，并且使用C++ 语言定义的意外情况处理函数。
对于这种程序的编写，Windows CE的开发者因无法访问C++的（面向Windows CE的Visua
l 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的一般的特点和优点。有许多其它的细节你需要在第一次使用W
indows CE嵌入式产品之前来学习掌握；幸运的是，有很多的WIN32 API 的信息的资源。
这些资源包括Microsoft开发网络(MSDN )，文章(诸如本文)和报纸，以及大量出版的书
来源：嵌入式技术网 |
| 【关闭】 【打印】 |
|
|
|
|
