编驱动时，发现。一般情况下，中断ISR到IST的响应时间很快，几十个US足够了。但是偶有这么一两次，响应速度极慢。大概有几十个MS。这个是由于有更高优先级中断抢先了，还是由于系统调度产生的原因？ 我要是想做到，中断ISR到IST的响应时间无论在什么情况下都小于某一个值，比如200US，如何能做到，把中断优先级提高，能解决这一问题吗？
我记得MSDN有帮助说这个的。你找找。我现在也找不到了 。(*^__^*) 嘻嘻……。
在ist和isr中加一条写GPIO的指令，先置高，再拉低。用示波器看高电平时间！在这里面调试信息是万万不能加，不然
速度极慢！
几十个MS也很正常，因为wince不是实时操作系统，不适用工控的。
上次我提高键盘驱动的优先级也是没有用。你现在不妨试试。哈哈，告诉我提高到驱动最高优先级97看看能快多少。
我概念不清，从ISR响应IST应该是线程优先级的问题。从硬件中断响应ISR才需考虑中断优先级。现在情况是每次中断ISR响应正常的，所以应该修改IST优先级！
把IST的优先级设置为0，也就是最高，几率小多了（但还是有，说明没根除！）。但是疑问来了，因为硬件中断优先级和中断线程优先级不是同一个东西。
我给高优先级的硬件中断，设置一个低优先级的中断线程。然后再给一个低优先级的硬件中断设置一个高优先级的中断线程，当两个中断同时发生的时候，最终是谁先响应呢？
Microsoft 從來沒保證 IST latency, WinCE 的 realtime, 指的是 ISR latency 是可預估的, 若是你有應用需要保證 IST latency, 你可能要考慮
1. 換一個 OS => 不在 WinCE 版討論.
2. 將該 IST 的功能, 放在 ISR 內, 優雅一點的寫一個 Installable ISR, 不用動到 kernel code, 暴力一點地就直接把 OEMInterruptHandler 改掉.
雖然你沒描述你是用哪一個 CPU, 但能簡單地用 GPIO, 應該是 ARM (or other RISC), 其實, ARM 的 IRQ 只有一個, 所以沒有 Nested IRQ 的觀念, 所以連 ISR latency 都沒辦法絕對地保證.
當然, 你改了 ISR, 你自己要小心 side effect.
Paul, Chao @ Techware
我看了一下PB的帮助，ISR latency指的是CPU从响应硬件中断到开始执行相应ISR的时间。由于这个任务是由，KERNEL执行的所以MS可以保证。
而IST latency是指从ISR结束提交SYSINTR_XXX,到响应IST的时间间隔。因为这里涉及到线程的调度，而WINCE采用的是基于优先级的时间片算法对线程进行调度的。这里面有两点导致MS保证不了IST latency，一个是MS不知道某个特定系统有多少个更高优先级的线程来抢占内核时间；二是单个IST的执行时间未知。说白了，WINCE是可以订制的！
但我想这两点订制内核的人可以保证，首先我可以确定我这个系统要执行哪些IST。而且每个IST的优先级是有可能设置或者得知的，线程执行时间也可以测量出来。那么问题就可以解决了。简单的莱，比如：我把我这个中断IST的优先级设为0，也就是最高，保证整个系统就它的优先级最高，也就是说每次都是先响应它，这样IST latency就可以控制在一个很小的值了。
请教，paul_chao，我这样的理解正确吗？
1. Thread 執行次序是根據 priority, 但同一 priority 則是 round robin, 所以你要先確定你的機器上不會出現相同或是更高 priority 的 thread.
2. Kernel 大部份是 MS 寫的, 但裡面一堆東西 (OEM or OAL 開頭的) 是在你的 bsp 內, 若是你在 OEMInterruptHandler 裡面做一些耗時間的事, 系統還是會動, 但是下一個中斷被 acknowledge 的時間就會被拖延, 因為 ARM core 只有一個中斷, 所以 MS 是沒辦法保證 ARM 下的 ISR latency.
3. Interrupt Controller 通常可以設定硬體的 priority, 記得要先設好.
你說的非常好, WINCE 某些地方是可以訂制的.
所以, 你用這些方法, 或許可以測出中斷發生時有 99.999% 的 200 us 達成率, 但是沒人可以跟你保證 100% 的達成率, 除非你能保證你所提供的每一段 code 的執行時間.
通常, us 等級的東西, 用 wince 那麼大的系統來做, 是有一些風險的.
Paul, Chao @ Techware
京公网安备 11010802033920号
