拥有微软Windows CE的实时系统

testing

拥有微软Windows CE的实时系统

--------------------------------------------------------------------------------

介绍

Microsoft Windows CE

    快速反应的嵌入式应用常常管理严格的时间反应。例如，制造过程控制，高速的数据采集设备，电讯交换设备，医用设备，空中“有线”控制，武器发射装备，空间航行和导航，实验室，实验控制，汽车发动机控制，机器人系统。

    为保证这种功能，就意味着不仅需要计算精确性，还有结果的时间性，此种应用必须在指定的时间参数内做出反应。

    实时系统的广义定义是“对任何外部刺激，计算机做出及时反应是至关重要的系统”，标准定义在Internet newsgroup corp realtime group中 。实时定义为：一个实时系统它的计算正确性，不仅依靠于计算逻辑上的正确，还包括及时的产生结果。如果没有达到系统时间限制条件，系统也是失效的。

    搞清楚实时系统和实时操作系统（RTOS）的区别至关重要，实时系统代表所有系统组成设备——硬件，操作系统和应用——它需要达到系统的要求，实时操作系统(RTOS)只是整个实时系统的一个组成部分，它必须提供足够的功能以确保整个实时系统达到要求。

    同样，搞清快速操作系统和实时操作系统之间区别，也很重要，对于一个RTOS虽然达到全面要求十分有用，但并不是它自己达到这种要求。Internet neusgronp cornp.realtime列举了作为一个实时操作系统，必须达到的要求：

OS(操作系统)必须是多线程和优先级之分。
OS必须支持线程优先级。
一个优先级继承的系统必须存在。
OS必须支持可预测的线程，同步发送机理。
    另外，OS的行为必须是可预测的，这意味实时系统的开发者必须对系统中断级，系统调用和分时了如指掌：

必须知道OS和设备驱动器的中数据匹配最大时间。
设备驱动器用来处理一个中断最大时间和关于这些驱动器的中断申请信息必须清楚。
中断响应(从中断到运行时间)，必须可预测并满足功能要求。
    每次系统调用时间必须可以预测，并且独立于系统的对象数目。本篇论文论述了微软Windows CE 操作系统是如何达到一个实时系统的要求，更有意义的是，Windows CE 保证一个时间的上限，它在收到中断后开始一个实时的优先级线程。本论文论述了对特定参考平台的中数据响应时间，参考为有 Hinathi SH3 的微处理器的 “Odo” 平台。


Microsoft Windows CE

概论

    微软Windows CE 被设计成针对小型设备(它是典型的拥有有限内存的无磁盘系统)的通用操作系统。Windows CE 可以通过设计一层位于内核和硬件之间代码来用设定硬件平台，这即是众所周知的硬盘压缩层(HAL)，(在以前解释时，这被称为 OEMC （原始设备制造)适应层，即 OAL； 内核压缩层，即 KAL。 以免与微软的 Windows NT 操作系统 HAL 混淆)

    不象其它的微软 Windows 操作系统，Windows CE 并不是代表一个标准的相同的对所有平台适用的软件。为了足够灵活以达到适应广泛产品需求, Windows CE 采用标准模式，这就意味着，它能够由一系列软件模式做出选择，从而使产品定制。另外，一些可利用模式也可作为其组成部分，这意味着这些模式能够通过从一套可利用的组份做出选择，从而成为标准模式，通过选择，能够达到系统要求的最小模式， OEM 能够减少存储脚本和操作系统的运行。

    Windows CE 关于 VC++ 5.0 开发系统嵌入式工具包，提供系统库、工具、文本和样本代码，以使 OEMS 能够对特定的硬件平台使 Windows CE 标准定制。嵌入式工具包也包括设备驱动包(DDK)和软件开发包(SDK) ，DDK 提供了关于写驱动器的附加文本，SDK 提供库、头文件、样本代码、文本以允许，开发者对基于 Windows CE 的平台进行写操作。 Windows CE 提供了相同的程序界面，以用来为其它的视窗操作系统开发功能，例如，Windows CE 版本 1.01支持大约1000个微软的Win 32 API 函数的其中500个。这就意味着大量不同类的工具，第三方书籍，关于 Win 32 开发者训练教程，可以替代或为 Windows CE 系统的开发者所用。

    实时系统的开发者能够使用，关于VDFF 5.0 的嵌入式工具包，以把操作系统转移到特定的平台，并为这个平台开发附加设备驱动器和实时功能。

线程和线程优先权级

    Windows CE 是有优先级的多任务操作系统，它允许多重功能、进程，在相同时间系统中运行 Windows CE 支持最大的 32 位同步进程。一个进程包括一个或多个线程，每个线程代表进程的一个独立部分，一个线程被指定为进程的基本线程，进程也能创造一个未定数目的额外线程，额外线程实际数目，仅由可利用的系统资源限定。

    Windows CE 利用基于优先级的时间片演算法以安排线程的执行，Windows CE 支持八个不同的优先级，由0到7，0代表最高级，它在头文件 Winbasw.h中定义。

优先级 描述
0
(最高级) 关键的线程优先级
(最高优先等级)
1 最高线程优先级
2 高于通常的线程优先级
3 通常线程优先级
4 低于常规线程优先级
5 最低线程优先级
6 高于IDLE的线程优先级
7
(最低) IDLE线程优先级
(最低优先级)

    级别0和1通常做为实时过程和设备驱动器，级别2-4做为线程和通常功能，级别5-7做为是低于其它功能级别，注意级别6是目前状态并有稳定联接。

    优先权唯一的取决于线程优先级，拥有高级优先权的线程安排优先运行，同一优先级的线程，以循环优先先级方式运行，即每个线程接受定制的时间或时间片，定量时间默认值为25毫秒 (Windows CE 2.0 支持在 MIPS 平台更改定量时间)。较低优先权的线程，要直到较高级线程完成之后再运行，也即直到他们或者放弃或停止。一个重要的例外是最高优先级的线程(级别0，关键时间优先级)不与其它的线程共享时间片，这些线程连续执行直到他们完成。不象其它的微软窗操作系统，Windows CE 是固定不能改变，它不匹配基于这引进优先级的中断，他们能够暂时改动，但仅能通过 Windows CE 内核以避免所谓的的“优先权倒置”。

    优先权倒置指的是当它们同时竞争同一资源时，低优先级的线程，阻碍了高优先权线程对资源的利用。为了改正这种局面并解放较高优先权的线程，Windows CE 允许低级优先权继承，严格的线程优先权，并且运行较高优先级直到它释放所用资源。

    例如，如果一个线程在最高优先权运行试图莸取由低级优先权占有的互斥体，低级优先权的线程变成高级优先权，并且运行直到它释放互斥体。优先权倒置适用于系统的所有线程。例如，甚至在优先级别1运行的内核线程能转成级别0，如果优先级0线程运行内存分页代码，将引起块失误。

    基于优先级的多任务设计，保证运行在最低级的线程在一个预所知时间段执行。本论文在后面讨论设定响应，对于指定的平台和公式，并由其它的平台获取数字。在 DAK 和 SDK 的工具，显示了线程状态和优先级别，并描绘指定实时系统操作轮廓。

线程同步

    实时系统必须保证进程和线程同步，例如，如果实时应用的一部分在另一部分获得最多当前数据前即完成，此应用的管理进程可能不稳定，同步将确保在应用线程间交换正确。

    如同其它的 Windows 操作系统一样，Windows CE 为线程同步提供了一个丰富的“等待对象”，这包括关键部门、事件、互斥体，些等待对象，允许一个线程减缓它的运行并且等待直到指定事件发生。

    Windows CE 将互斥体、关键部分、事件请求按“先入先出，优先级（FIFO）”顺序排列：不同的先入先出顺序序列定义成八个不同的优先级，在给定的优称级的线程请求，将被放在优先级列表末尾，当优先级倒置出现时，调度程序调整这些序列。

    除了等待对象，Windows CE 支持标准的 Win 32 时间 API 函数，这些来自内核的应用，软件中断将获得时间间隔，它被用来管理实时应用。通过调用 GetTickCont 函数，它能够返回几毫秒，线程能够使用系统间隔时间。关于更详细的分时信息，Windows CE 内核也支持Win 32 API 函数QueryPerformanreCounter 和 QueryPerFormanteFrequency 。OEM 必须为这些调用提供硬件和软件支持，它提供一个较高的时间分辨力和 OAL 界面其它方面。

其它方面考虑

    Windows CE 提供了一个重要的存储系统，例如，当目前某些运行 Windows CE 的平台提供 4MB 的物理内存，Windows CE 支持一个重要的 2GB 的地址空间，每个进程联接在它自己的32MB 物理空间上，当它需要产生内存分页中断(这可能影响线程执行时间)，物理内存进行线程代码或数据内存分页。

    内存分页输入输出，将比实时进程优先级低。在实时进程中内存分页仍可自由出现，但这要确保后台的实际内存管理赢得实时系统优先权。
实时线程应该锁存在内存中，以防止这些无关紧要的内存分页阻碍其运行，它们可能会占用实际内存管理系统。

    Windows CE 允许映射，这将阴止多个进程共享同一物理内存，结果将会导致协同进程间或驱动器与映射快速的数据传送，内存映射能够戏剧性的增强实时操作。

中断处理： IRQS ISRS 和 ISTS

    实时应用被设立在指定的时间间隔内，对外部事件做出反应，实时应用使用中断做为一种确保外部事件由操作系统获知的方式。在 Windows 中，内核和 OEM 适应层 (OAL)被设定成使系统其它部分的中断和调度最优化。Windows CE 平衡操作，并通过把中断过程分成两部分而使执行更加容易：它分为中断服务程序(ISR)和中断服务线程(IST)两部分。

    每条硬件中断申请线(IRQ)，与一个ISR相连。当中断成立和中断出现时，内核为此调用寄存的 ISR， ISR 为中断处理的内核模式部分尽可能短的保存。它首先将内核放在适合的 IST 上。

    ISR 执行它的最小处理并返回一个 ID 号到内核，内核检查返回的中断 ID 号，并设置相关事件，中断服务线程等待事件。当内核设置事件时，IST 停止等待并开始执行，附加的中断进程，中断处理大部分实际上出现在 IST 中，两个最高的线程优先权 (级别0和1)，通常指定为 ISTS，保证这些线程运行得足够快。

    正如前面所说，处在最高级的 ISTS 不能被其它的线程占用，这些线程持续执行直到它们截止或放弃。

    Windows CE 不能支持群体中断，这就意味着当以前一个中断处理中，另一个不同接受服务，也就是当内核位于 ISR 时如果中断出现，在为新的 IRQ 开始 ISR 前它将一直执行直到ISR 结束，这将引起硬件中断和 ISR 开始之间的延迟，拖延和响应时间中断响应。

中断响应

    本论文中，Intervupt Latency 词组主要指的是较件中断，处理响应,也即是从处部中断到达处理器到中断开始处理间的时间。

    Windows CE 中断响应时间是针对锁存在内存上的线程 (当内存响应不存在时)。这使得计算最差事件响应成为可能——中断服务程序(ISR) 开始和中断服务线程（IST）开始D的总时间，直到中断处理的总时间能够通ISR 和 IST 中所需时间计算决定。

ISR 响应通用公式定义如下：

ISR开始时间 = value1 + dISR_Current + sum(dISR_Higher)

value1=由内核处理过程获得响应值

dISR_Current=中断到达时程序中 ISR 持续时间。这个值范围由0到系统中最长的 ISR 持续时间

sum(dISR_Higher)=所有在 ISR 开始前的较高级ISRS 持续时间总和，即在时间 vahe1+dISR-cumeneu间到达的中断

    例如，考虑一个拥有关键优先权 ISR 的嵌入式系统，因为 ISR 被设成最高级，这有样 ISRS dISR-Higher 值为0。当没有其它 ISRS 最低响应，在程序中，即为value1 最低响应即为value1加系统中最长 ISR 周期，当中断到达时，正是系统中最长的 ISR 开始执行。

IST 响应周期定义如下：

IST开始时间 = value2 + sum(dIST) + sum(dISR)

value2=由内核处理的响应值

sum(dIST)=所有的出现在 ISR 和 IST ，开始的优先级 ISTS 和线程上下文转换时间总和。

sum(dISR)=在中断(?) ISR 和它的 IST 之间运行的其它 ISRS 持续时间总和。

    最简单的例子——具有一个关键级 ISR 和一个关键级线程(无其它0优先级的线程)的嵌入式系统——没有其它的 ISTS 能够在ISR 和 IST 之间中断，然而在关键级的 ISR 和它相关的 IST 开始间其它的 ISRS 能被处理。

    因为 ISRS 一旦能够获得，即可被处理，很容易想象成病态情况，涉及产生一个持续的 ISRS 流，从而产生不确定的推迟。 IST 的开始不可能出现，因为 OEM对系统中的中断完成控制。因为 OEM (原始设备制造商)为特定操作系统设计传统 Windows CE 版本。 OCM 利用目标操作环境限制使系统设计最佳化。

    为减少响应时间，OEM 控制 ISR 和IST 处理时间中断优先级线程优先级。公式中的 value1 和 walue2 代表，Windows CE 内核中处理时间，这是 OEM 不能控制的目前的在分时，研究工作涉及这些确认值。

确保Windows CE的实时操作

    两种不同途径被用来确保Windows CE操作：

由Windows CE开发组进行内部的检查或分析内核代码，
OEM和ISV（独立软件销售商）利用一些将在未来的Windows CE版本嵌入式工具包（for VCFT）提供工具来确保特定配置。
Windows CE关于VC++的嵌入工具包包括以下工具：

(一个对于分时研究的内核的工具版本和Intrtinrt.ext应用软件来观察，中断过程的最大、最小、平均时间。
微软也能开发其它的针对顾客需要的分时工具。
Windows CE开发组，已经检查了内核代码以证实它能由最差的情况时间表征，它是独立于系统对象数目的。

    为了利用这个检查，内核被表征成一套KCALLS或系统调用，在内核关闭优先权是它们是内核程序，并且不允许其它的线程运行，最差事件时间，此时，实时进程、标止运行，它能在内核中表征成最差事件KCALL时间（注意：这些时间不影响ISRS，只影响线程，例如ISTS）。

    开发组通过检查发现这没有非持久的循环在KCALLS，这意味着：并所有的KCALLS能够表示成单向分支，代码路径，并确保通过KCALL并独立于输入参数发现最差事件时间成为可能。

    查找实际的最差事件时间包括使用In strum ented kemal，这仅是一个内核版本，它在设定应用环境后编辑使用，KCALL_PROFICE=1，以保证额外的分时功能，这个instrumented kemel 与debug kemel不同，Instrument ted是为一个零售的内核使用，它用来获得分时值，这常对于装运产品常常讳之莫深，在retail kernal和instrumented kernel唯一区别是它的装备。

    Instrumentted kernel记录所有的KCALL时间，这些值，包括最小、最大和平均时间，并能够通过调用专用的API函数Dum Pk call profile打印到调试接口，Instrumented kernel通常运行在强状态下，然后调用Dumpkcall prefile来获得时间。

    中断测试应用软件Intrtime.exe，在Windows CE标准版本收集中断分时延迟信息，应用软件在测试中控制系统时间。因此，当系统需要时间控制器时，是不合适使用的。例如，此应用程序不能与内核instrumented版本一起使用，因为它也需要时间控制。

在Windows CE 2版（Beta版）测试响应，

    Intertime应用软件在odoSH3参考平台上运行1000次中断测试，内部运行58.98Mhz，外部为14.745Mhz外部频率，这个测试在一个标准的H/PC配置，它包括Windows CE所有模式和组合。仅有主操作系统进程进行（NK.exe, Filesys.exe, Gwes.exe, Device. EXE, Shell.EXE和Explover.EXE），在测试中无用户初始中断（触摸屏、键盘或其它应用），应用软件可报告下面的ISR和IST开始、最小和最大时间：

响应 最大、最小值（1000次测试）
ISR开始 1.3-7.5微秒
IST开始 93-275微秒

    大多数测试结果，分布在最小值数值附近，当测试ISR开始时间时，最小值1.3和1.6微秒，出现了293和549次，共占测试的84%，类似的超过90%的（1000次中923）start-of-IST测试出最大响应为102微秒或少一些。

    Intertime应用软件也使用一个用户指定数目的系统对象来测试ISR和IST开始时间。虽然工作十分初级，但它验证了ISR开始时间与系统对象数目无关，测试设为1000次（除了特别更改）并且线程优先权为5或7。

ISR开始最大值 后台线程、数目（每个线程一个事件） 优先级
8.4 0 7
8.6 5(注：仅100次) 7
9.0 10(注：仅100次) 5
14.8 10 5
19.2 10 5
17.0 10 7
12.8 20 5
11.0 20（注：仅100次） 7
10.0 50 7
15.0 100 5
15.6 100 7

这数值不是系统对象数目的函数，不同的值可能由于中断出现时内核状态，开发组目前正在研究以鉴定ISR开始最差时间值。

    由这些结果向回推，假定ISR开始最小值代表最好情况。此时，dISR_Current和Sum(dISR_Htgbor)为0，最小的value 1=ISR开始值=1.3微秒，类似的设定最好情况时，Sum(dIST)和Sum(dISR)为0，Value最小值=.IST开始值=93微秒，单从测验结果看，它是不能确定，valume 1或value 2最大值。

    附加的分时信息能够由instrumented kernel 收集，对于一个最差情况在IST开始前花费时间valume2，能由下列公式计算：

Value2=dkCall+dNextThread

dKcall=.内核调用时间；当消除优先级时，花费在内核的一部分时间量。

DNextThread=Next.Thread内核调用时期。花费在IST中时间量。

实际上，在0级别线程调度要比Next Thread调用快，但此公式能估计出上限。

下面表格显示了用instrumented Kernel进行初步测试时最差事件结果，这些测试条件与Intrtime测试相同。


内核调用模型 最大值（ad-hoc.testing）
最大时间值（所用内核调用） 266微秒（Learecrite）
Next Thread 237微秒
总值 503微秒

    Instrumented kernel显示这些条件下value 2上限为500微秒。这个值为两个最差事件总时间，远远超过了由Intritime应用程序得到的结果，也大于实际最差事件时间。例如：通过Nextthread调度一个优先级为0的线程，不会导致最差事件，这意味着500微秒是一个高于实际的最差事件值的保守值。

    Intertime Utility对于从总体上观察最差事件值十分有用，Instrumentted Kemel对于获得可能最差事件的值，通过内核描绘出所有响应原因——一个IST在这些事件运行，但在内核非优先部分运行执行时，将受阻碍，系统的最差事件响应可由每一部分的最差事件总和计算。

    注意本论文中所有测试结果均基于内部Windows CE的beta版，目前存在的操作系统和应用将继续得到修正，并且进行附加测试以获得在不同操作条件下系统操作，这些数值将继续被更新并出版，以反思目前的操作系统版本。

总结

    微软Windows CE内核设计以达到RTOS最小要求，以使Windows CE用在许多不同类型的嵌入式和实时系统作为操作系统；

Windows CE的多线程和优先级，Windows CE支持个人线程优先级；
Windows CE支持优先权继承程序，以便调整优衔级别以修改优先权颠倒；
Windows CE支持一个可预测的线程同步机理，包括等待对象，如互斥体关键部分，命名或未命名的事件对象，它基于线程优先权排序。
Windows CE也支持与系统控制器的联连：
OEM能够控制类由系统支持的中断处理，即通过执行ISRS和ISTS，它可弥补中断处理软件；
OEM完成在所有映射到中断ID号的IRQS，并且它与中断处理软件相联系（ISR和IST），描绘工具和应用软件可以利用记录处理中断最大时间。
中断响应是可预测和有限制的，当优先权取消时，上限即为花费在内核中时间总量，匹配转化时间，和由OEM执行的ISRS和ISTS申请处理时间。
每个系统调用的时间是可预测的，并与系统对象数目无关，
    利用 instrumentted kernel系统调用时间能够保证Windows CE内核设计保证中断和它们相关线