如何让WinCE快速响应中断

xw0326

如何让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捕捉到硬件中断并处理完毕后，是回去执行刚被中断的线程，还是在就绪队列中重新找优先级最高的线程？

akpor

捕捉都很快。但是处理可能会慢一些。最近都在弄中断呢。呵呵
优先级不用开那么高吗。。。。

一凡

1. 上述两篇文章测试的延迟时间有数量级上的差别（我相信第二篇文章也用了release版），根据各位的经验，哪一个比较靠谱？
没仔细读。所以不好说。。。汗

2. 除了上述方式，还有什么办法让IST被快速响应？
用信号量代替事件来处理会提高响应速度，也就是用CreateSemaphore代替CreateEvent，某些处理的时候。比如说有信号量要传递的时候。


3. ISR捕捉到硬件中断并处理完毕后，是回去执行刚被中断的线程，还是在就绪队列中重新找优先级最高的线程？
ISR->IST...这个顺序的。
请读
http://www.cnblogs.com/we-hjb/archive/2009/05/26/1490461.html

这个文章又摆出来先看看这个文章。。。里面介绍的很清楚了中断流程。

evenles

学习

jt4117

帮顶下，

MARK,学习下

dise2a

引用 2 楼 xumercury 的回复:
1. 上述两篇文章测试的延迟时间有数量级上的差别（我相信第二篇文章也用了release版），根据各位的经验，哪一个比较靠谱？
没仔细读。所以不好说。。。汗

2. 除了上述方式，还有什么办法让IST被快速响应？
用信号量代替事件来处理会提高响应速度，也就是用CreateSemaphore代替CreateEvent，某些处理的时候。比如说有信号量要传递的时候。


3. ISR捕捉到硬件中断并处理完毕后，是回去执行刚被中断的线程，还是在就绪队列中重新找优先级最高的线程？
ISR->IST...这个顺序的。
请读
http://www.cnblogs.com/we-hjb/archive/2009/05/26/1490461.html

这个文章又摆出来先看看这个文章。。。里面介绍的很清楚了中断流程。

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

辛蒂

设中断优先级 .

设中断时间片好像WinCE 中可以设置.

chenquan

引用 5 楼 oncancel 的回复:

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

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

leijun203

给出例子。

1. 
   
2.     CeSetThreadPriority(GetCurrentThread(), pMcuCtl->dwPriority256);
   
3.     //在进入等待之前就获取了当前线程的优先级。并设置，我这里设置的很低100多后面了。。。
   
4.     //Sleep(1);        //等待信号量
   
5.     while (1)
   
6.     {   //第一阶段: 等待信号量出现
   
7.         dwRet = WaitForMultipleObjects(2, rghEvents, FALSE, INFINITE);
   
8.         if(pMcuCtl->bDeinit)
   
9.         {
   
10.             return 0;//如果检测到反初始化事件，退出等待信号量       
    
11.         }
    
12.         //第二阶段: 判断实际信号量类型
    
13.         switch(dwRet)
    
14.         {
    
15.         case WAIT_OBJECT_0:
    
16.             RETAILMSG(1, (TEXT("mcu_DetectThread Wait deinit\r\n")));
    
17.             //deinit event
    
18.             //判断是deinit线程既退出
    
19.             return 0;
    
20.         break;
    
21.         case WAIT_OBJECT_0+1:
    
22.             //gpio interrupted event       
    
23.             //检测到GPIO中断进程事件
    
24.             //建议第一次调试的时候请打开try进行预先测试
    
25.                         {
    
26.                            //RETAILMSG(1, (TEXT("mcu_DetectThread Wait gio\r\n")));
    
27.                         //__try
    
28.                         //{
    
29.                         //第三阶段: 读写的工作
    
30.                                     OperationCS8953(READ, &sendOut[0], 2);        //产生中断即进行读写MCU的工作
    
31.                         #if 1
    
32.                                 RETAILMSG(1,(TEXT("the %d number  SentOut Value for point variable is %x\r\n"),i,sendOut[i]));
    
33.                         //Skill:xxxxx
    
34.                          // sndPlaySound(_T("question.wav"),SND_FILENAME|SND_NODEFAULT);
    
35.                         #endif       
    
36.                         //完成try的出错抛出处理
    
37.                         //}
    
38.                         //__except (GetExceptionCode() == STATUS_ACCESS_VIOLATION ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
    
39.                         //{
    
40.                         //        RETAILMSG(1, (TEXT("Emcu_DetectThread MCU_gio!!!!\r\n")));
    
41.                         //        SetLastError(E_FAIL);
    
42.                         //}
    
43.                         //SetEvent(gReadKeyEvent[0]); //这里我们建议采用采集信号量来代替采集事件，
    
44.                        
    
45.                                     if (!ReleaseSemaphore(
    
46.                                            gReadKeyEvent[0], // 要增加的信号量。
    
47.                                           1,           // 增加1.
    
48.                                            NULL) )      // 不想返回前一次信号量。
    
49.                                              {
    
50.                                              //do noting.
    
51.                                              }
    
52.                                 }
    
53.         break;
    
54.         default:
    
55.             //error
    
56.             //出错处理
    
57.             dwAction = 0x00;//MCU_STAT_NOCHANGE;
    
58.         break;
    
59.         }
    
60. 
    

复制代码

hezongquan

我做的速度也很快，基本上是毫秒级别的响应。很流畅

xzhy

引用 7 楼 xumercury 的回复:
引用 5 楼 oncancel 的回复:

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

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

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

qiyelian

多用到的中断没那么快，没测试过，帮顶一下吧！

jhpotter

引用 10 楼 oncancel 的回复:
引用 7 楼 xumercury 的回复:
引用 5 楼 oncancel 的回复:

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

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


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

这样的话我大概清楚。。。你的意思是IST中运行的时候ISR又来了。。。。
这样的话只能是说你的IST占用的时间太长了。。。IST里面不建议做太多的数据处理，为了防止在IST中无限的执行下去，你进IST的前提是来了ISR，你IST就该做的就是设定一个标识去处理ISR所需要处理的事情，然后马上释放等待下一个ISR。如果你还是一直在IST里面没出来的话这个只能说你IST里面处理的部分需要简化一下了。。。
另外。。。你Thread1的优先级不就是你的IST的优先级吗？
我给你的参考实例我就是在Thread1获取当前的优先级设置为IST优先级。。。。这个怎么可能产生两个。。
难道是我理解错了。。。

dnvtaje

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

1.第一个比较靠谱，起码应该是微秒级的。
2.不清楚，实时性本来就是Wince的弱项。
3.我觉得应该是重新找优先级最高的线程。

hsdzcf

一直对wince的中断 实时性表示怀疑，以前还真的经常发现他扑捉不到快的中断。

x700xt

以前键盘的中断就出过很奇怪的问题。

ilovedrv

看到一个评测报告，WinCE6.0 R2， x86平台（Pentium 200MHz MMX）
IRQ到ISR时间(5.0us,6.3us,10.2us) （min,ave,max下同）
ISR到IST时间(5.7us,6.3us,19.9us)
以24us周期产生10^9次中断，完全被IST捕捉到。

汗，这么彪悍，真的假的。

报告地址：
http://download.microsoft.com/download/D/A/C/DAC6D6D0-07EC-4954-95D3-55273C1524D7/Independent%20Real-Time%20Report%20for%20Windows%20Embedded.pdf

aabbccddee2

报告应该都对

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

cwyun

WinCE是实时内核，但不一定是实时系统，它的实时性取决于你添加了什么系统组件，底层驱动处理是否合理。如果你的中断频率过高，可能会导致整个系统性能下降的。
要提高中断的响应速度，可以考虑把简单的处理放在ISR中，让多个硬件中断后执行一次IST。

wufeng_495

引用 18 楼 sunrain_hjb 的回复:
WinCE是实时内核，但不一定是实时系统，它的实时性取决于你添加了什么系统组件，底层驱动处理是否合理。如果你的中断频率过高，可能会导致整个系统性能下降的。
要提高中断的响应速度，可以考虑把简单的处理放在ISR中，让多个硬件中断后执行一次IST。

这个我深有感触，呵呵