Windows CE 5.0实时系统介绍

目前，Windows CE已从一款基本操作系统升级到体积小巧、组件化的硬实时嵌入式操作系统。尽管Windows CE具有与Win32相同的应用编程接口（API），而且微软台式机和服务器操作系统也配备了此类接口，但Windows CE的底层操作系统架构和台式机的操作系统完全不同。Windows CE既支持包括Win32、MFC、ATL等在内的台式机应用开发结构，也支持使用.NET Compact Framework的管理应用开发，还支持当前实时嵌入式系统设计，提供操作系统必要之需的实时内核。本文中，我们主要讨论用于验证Windows CE 5.0实时功效的操作系统工具。

众所周知，实时系统并不通过单一分析进行测试，即使单一分析可以证明实时系统的正确性。实时系统的测试是详尽讨论此问题的依据。您的工作就是建立起用户对解决方案的信任感。下文介绍的工具可以完整、实时地解释应用程序和操作系统之间的交互作用，它们有助于您加深对实时系统的了解。

尽管关于实时的定义还存在诸多争议，我们还是来了解一下对它的定义。这里，我引用comp.realtime FAQ的定义。实时系统的权威定义（Donald Gillies）如下：

 “实时系统是这样一种系统，即其计算正确与否，不仅取决于计算逻辑是否正确，还取决于计算结果所花费的时间。如果不能满足系统的时间限制，就会出现系统失败的情况。”

因为集高速I/O、机器人技术和机械控制于一身的工业自动化应用对时间的要求最为苛刻。微软开始了解实时嵌入式操作系统的特殊社会要求。自1986年以来，通用汽车动力公司（GMPTG）在制造应用中实施OMAC技术方面一直处于领先地位，并且在后来促成了OMAC用户群的形成。他们一起对数百种应用进行评估后发现，大多数系统（95%）需要一毫秒或稍长的周期。一毫秒周期允许的变化幅度为10%，或是100微秒（µs）。这是基于200 MHz X86系统的Windows CE的设计目标，其在该平台上的平均响应时间为50 µs。Windows CE达到或超过了95%的被评估的硬实时应用OMAC的要求。

大部分满足要求的工业自动化应用是由从一台机器发出的外部信号驱动的。此信号以中断形式发送给硬实时应用。微软鼓励Windows CE的开发人员，尽可能在中断服务线程（IST）中置入更多的应用代码。这使OMAC抖动定义变为针对不超过100 µs的IST延迟的时间限制。其余被评估的应用使用计时器创建其周期。这就需要一台延迟或抖动不超过100 µs的1毫秒计时器。总之，OMAC定义提出以下设计和测试要求：

·                     Interrupt Service Thread (IST) latencies of no more than 100 µs latency.

·                     1 millisecond timers with maximum of 100 µs latency.

·                     中断服务线程（IST）延迟不超过100 µs。

·                     1毫秒计时器的延迟最长为100 µs。

在了解了OMAC的设计和测试要求后，接下来让我们看看Windows CE中安装的工具。这些工具的用途是确定中断定时、应用执行动作、操作系统功能定时和时序安排定时。

 

区分实时系统和实时操作系统也很重要。实时系统包含硬件、操作系统和应用等所有元素。实时操作系统仅仅是构成实时系统的其中一个元素。如需了解更多信息，请参阅微软Windows CE实时性能设计和优化。

 

我们将介绍诸多工具和用途：

·                     ILTiming。该工具用于确定平台的中断服务例程（ISR）和中断服务线程（IST）延迟。ISR延迟是指从硬件中断到第一次中断服务例程指令之间的时间间隔。而IST延迟是指从现有ISR到中断服务线程开始之间的时间间隔。

内核实时性能最重要的特性之一，就是可以在指定的时间内实施中断。中断延迟主要指软件中断处理延迟，即从外部中断到达处理器直到中断处理开始之间的时间间隔。

 

如果不发生分页操作，Windows CE中断延迟时间被限制于内存中锁定的线程。这样就可以计算最糟糕情况下的延迟时间 — 到ISR的启动和到IST的启动的总用时。通过计算ISR和IST所需时间，可以确定中断处理以前的总用时。

ISR延迟

ISR延迟是指从IRQ在CUP中被设置到ISR开始运行时的时间。以下三个与时间相关的变量会影响ISR的启动：

 

A = 中断在内核中关闭的最长时间。内核很少关闭中断，但如果将它们关闭，则关闭的时间长度会受到限制。

B = 在内核调度中断和ISR被实际调用之间的时间。内核使用该时间确定要运行什么ISR，并保存在继续之前必须保存的任何寄存器。

C = 在 ISR 返回到内核和内核实际停止处理中断之间的时间。这是内核通过还原在ISR被调用之前被保存的任何状态（例如寄存器）来完成ISR操作的时间。

 

正在测量的ISR的启动时间可以基于系统中其他中断的当前状态进行计算。如果中断正在进行，则计算要测量的新 ISR 的启动时间必须考虑到两个因素：所关注的中断已经发生之后将发生的较高优先级中断的数量，以及执行ISR所占用的时间。

 

Windows CE和原始设备制造商（OEM）都会影响执行ISR的时间。Windows CE的控制变量A、B和C都受到限制。

IST延迟

IST延迟是指从完成执行ISR即（通知线程）到IST开始执行的时间。以下四个与时间相关的变量会影响IST的启动：

 

B = 内核调度中断和真正调用ISR的时间间隔。内核利用这一时间决定将要运行什么ISR，并保存在继续之前必须保存的任何寄存器。

C = 在ISR返回到内核和内核实际停止处理中断之间的时间。这是内核通过还原在ISR被调用之前保存的任何状态（例如寄存器）来完成ISR操作的时间。

L = Kcall（内核调用）中的最长时间。

M = 调度线程的时间。

 

在ISR返回到内核并且内核执行某些工作来开始执行IST之后最高优先级IST开始的启动时间。在ISR返回并通知IST开始运行之后，IST启动时间受所有ISR的总计时间的影响。下面的示例说明了所得到的启动时间：

最高优先级IST启动时间 =

 

   

Windows CE和OEM都会影响执行IST所需的时间。Windows CE控制变量B、C、L和M都是受限制的。OEM控制NISR和TISR(N)，它们可以影响IST延迟。

 

Windows CE还对IST添加了以下限制：链接ISR和IST的事件处理只能用在WaitForSingleObject函数中。Windows CE防止ISR-IST事件处理被用在WaitForMultipleObjects函数中，这意味着内核可以担保触发事件的时间和释放IST的时间有一个上限。

 

·                     计划程序计时分析（OSBench）：该工具允许您收集计时样本，通过执行调度性能定时测试，测量内核的性能。

·                     内核跟踪程序（Kernel Tracker）：此工具可以直观显示Windows CE .NET操作系统在目标设备上的执行状况。该工具可用于在实时环境下查看线程交互、内部关联以及系统状态信息。本文目的是检验线程和进程间的交互作用。

·                     调用评测程序（Call Profiler）：此工具可用于确定代码的算法瓶颈。

设备中存在许多影响实时性能的因素，如硬件、驱动程序和应用。在本例中，我们从应用级开始。运行于实时环境中的应用启动时就应该分配所有资源。所有内核对象（进程、线程、互斥锁、临界段、信号和事件）都按照需要分配到虚拟内存中。按需分配内存是不确定的，因此，不能对操作系统完成操作的时间进行限制，所以它不能用于应用的实时执行中。

远程调用评测程序

实时系统不仅包括硬件和操作系统，日益增多的应用逻辑也运行于相同的硬件之上。因此，嵌入式设计中的应用代码可能存在失败风险。Windows CE不会强行命令IST在设备驱动程序环境中运行，IST仅是一个特殊的线程，因此在应用环境中可以运行IST线程。既然如此，该如何检验应用代码的瓶颈呢？当然，这可能会影响设备的整体性能。答案是：这正是Windows CE安装的工具 － 远程调用评测程序的功能。该工具可解答下列问题：何时执行何种代码？何谓软件组件的交互？应用程序运行时，CPU在做什么？

为了证明这一点，我采用构建、运行在Windows CE上的“哲学家就餐问题”应用。以下是解决过程：现在，五位哲学家（线程）围坐在圆桌前。每人面前放着一碗食物。哲学家们用一支筷子开始吃饭。哲学家就餐的前提是他必须有两支筷子（因此，五位哲学家中必须有一人奉献出一支筷子）。这时，哲学家就必须找到一种能够共享筷子的方法，以保证大家都能吃到碗中的食物。

同样地，当多线程程序中有一个以上的线程（哲学家）竞争资源（食物）时，就有可能发生死锁或争执，当然这要取决于哲学家的饥饿程度！如果多个线程都在等待使用稀缺资源，就会造成等待时间的不确定性，进而冻结所有应用。对实时应用而言，这并不是个难题，您可以选择远程调用评测程序运行应用就可以解决该问题。

远程调用评测程序可以在不同视图中显示调用信息，包括直观的调用图表。它会显示应用运行每个函数时花费的时间。显而易见，这是处理视频/音频流的实时压缩/解压缩问题的最为有效的工具。下表显示的是远程调用评测程序应用中的视图。

 

表1. 远程调用评测程序中的视图

视图	描述
顶端视图（Top X View）	显示花费时间最长的函数或基于指定的定时标准计算的值。
模块概要视图	统计列出载入模块的数据以及进入每一个功能模块的情况。
调用树视图	显示函数调用路径的分级描述。
蝴蝶型视图	以列表格式显示反映主调用与被调用函数之间关系的数据。
调用图表视图	显示函数间的总的从属关系。
调用跟踪与函数跟踪视图	显示数据栅格，以反映函数进入和退出事件的实际与计算的定时值。

下图显示的是哲学家应用的调用图表视图。此图显示，35%的应用时间花费在函数Eat( ) 上。也许应该了解一下函数的内容！

 

图1. 远程调用评测程序

您也许会问，要运行远程调用评测程序，需要向应用代码中添加什么。实际上，您根本无需更改所有代码，而仅需要用其它标志函数（WINCECALLCAP=1）进行编译。

调用评测库为应用开发人员提供了一幅独特的应用逻辑执行过程细节图。将该工具用于低速测试过程，以培养客户对应用代码的信任感。

内核跟踪程序（Kernel Tracker）：

远程内核跟踪程序可用于检测运行设备上的进程、线程和中断之间的交互作用关系。下面是一些内核跟踪程序中集成的样本代码。实例中的应用运行的是Windows CE设备的文件系统，其中一个文件夹在台式机放置释放文件，此应用为驻留在台式机中的每个文件生成了一个KITL（内核独立传输层）中断。因此，我们可以在运行的操作系统镜像中清晰地观察应用与中断间的交互作用，也可以确定应用线程运行与KITL中断处理间的时间增量。

作为一个用户界面 ， 内核跟踪程序被划分为三个区域 ， 左窗格显示中断和进程 ， 中窗格显示线程 / 进程间的交互作用 ， 右窗格 （ 未显示字 ）中的内容 是对中窗格使用的符号的解释。我们可以在镜像底部清楚地看到 W alkTree 应用正在运行 ， 但看不到在应用和内核环境中花费的时间。