怎么让WinCE快速响应中断

如何让WinCE快速响应中断
WinCE 6.0. 我的中断每3ms发生一次，现在采用的是中断处理的经典方法：
创建一个event，通过KernelIoControl()获取逻辑中断号，然后通过InterruptInitialize（）把event与逻辑中断号联系起来。在IST线程中等待该event并处理。

我的IST中断处理需要大约0.3ms。由于使用了ping-pong buffer，我允许该处理比硬件中断发生延迟不超过4.5ms。

这篇文章(http://embed.chinaitlab.com/WinCE/785312.html)在s3c2410平台上测试的debug版驱动程序中断延迟( ISR + IST )约2ms，release版驱动程序中断延迟约22us。

另一篇文章（http://www.c-cnc.com/dz/news/news.asp?id=24409）在 Xsacele平台测试Wince.Net的中断响应时间平均值为2.8ms。

我目前将IST的线程优先级设为0（最高），并将IST线程的时间片设为0（一旦进入就执行完毕，不被轮转）。
另外还有一个办法就是将处理代码转移到ISR中，但这样做很危险也很麻烦，因为我的数据还要交给应用程序处理。

问题：
1. 上述两篇文章测试的延迟时间有数量级上的差别（我相信第二篇文章也用了release版），根据各位的经验，哪一个比较靠谱？
2. 除了上述方式，还有什么办法让IST被快速响应？
3. ISR捕捉到硬件中断并处理完毕后，是回去执行刚被中断的线程，还是在就绪队列中重新找优先级最高的线程？

[解决办法]

探讨

引用:
引用:

第3个问题，这个文章我看过。ISR结束后并不能保证立即调用本IST的，我的意思是ISR执行后（即内核触发事件后）重新在就绪线程中找优先级最高的线程（候选线程当然包括IST），还是先回去执行被ISR中断的线程。

这个也是顺序的吧。。。没太懂你的意思。。
比如说我现在是等了2个事件，一个用来响应deinit，一个用来处理实际的。这个在Deinit和实际处理的事件中去激活，优先级好像并没有涉及到。。。


举个例子，Thread1优先级251，IST优先级0。IST已运行到等待Event的地方处于阻塞状态，在Thread1正在执行的过程中（属于Thread1的时间片还没用完），IRQ来了，操作系统转去执行ISR，并触发我创建的Event，使IST处于就绪状态。接下来操作系统会立即回去执行Thread1呢，还是把包括Thread1、IST在内的所有就绪线程拿来比较优先级，转去执行优先级最高的线程？

[解决办法]

探讨

问题：
1. 上述两篇文章测试的延迟时间有数量级上的差别（我相信第二篇文章也用了release版），根据各位的经验，哪一个比较靠谱？
2. 除了上述方式，还有什么办法让IST被快速响应？
3. ISR捕捉到硬件中断并处理完毕后，是回去执行刚被中断的线程，还是在就绪队列中重新找优先级最高的线程？

[解决办法]
报告应该都对

WinCE.NET (V4.x) 与 WinCE 6.0 的 Kernel 不同, 在 6.0 的 kernel 中, 己经对中断的处理做了一番修正, 所以在 5.0 版之前, WinCE 是号称 Soft-RealTime, 在 6.0 版时, 已经号称是 Hard-RealTime 了. 也就是其 Interrupt Latency is predictable.

Paul, Chao @ Techware

[解决办法]
WinCE是实时内核，但不一定是实时系统，它的实时性取决于你添加了什么系统组件，底层驱动处理是否合理。如果你的中断频率过高，可能会导致整个系统性能下降的。
要提高中断的响应速度，可以考虑把简单的处理放在ISR中，让多个硬件中断后执行一次IST。
[解决办法]
建议还是从软件角度去优化吧.
你的中断是不是每次产生都要进行复杂的运算?
能否将多个中断收集起来集中处理?
--------------------------------------
如果无法通过优化软件解决,或者说你的系统对性能要求很高,建议单独加一块MCU来处理吧.

查看更多 下一篇