拥有微软Windows CE的实时系统

　　确保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支持一个可预测的线程同步机理，包括等待对象，如互斥体关键部分，命名或未命名的事件对象，它基于线程优先权排序。

　

上一页  [1] [2] [3] [4] 下一页