quote:以下是引用eaglesky在2008-12-18 08:08:16的发言：
昨晚回去用模拟器研究了一下。做了部分实验，前面的实验就不说了，因为后面的实验推翻了我前面的分析。
根据 老兵 的提示，我在原程序的N2和N3之间增加了一段类似Harry_dong 提出的功能的程序，就是增加一段延时，不过我用是通过间接的调用中断OB35完成的。
实验结果是，M10.2完全有机会被置位！ 并且，延时的时间越长，机会越大。
不过和Harry_dong 的结论，我的想法不完全相同。
我记得以前用315－2DP的实体CPU试过，即时在中断中调用timer，timer一旦触发之后，计时就开始了，并在“后台”计时，也就是说，和扫描周期以及timer被调用的周期没有直接关系。
在原程序中，由于程序及其简单，只有这三条语句，并且N2和N3紧紧相连，中间的语句执行间隔时间及其的短，加上有N2这句可以对T3复位的语句，且复位是“即时”生效的，Timer的动作条件能刚好赶在N2和N3之间的几率实在是太小了。这些条件导致N3这句能够捕捉到T3动作的几率变得非常非常的小。而加上了延时之后，在延时期间内，T3完成了动作条件的满足以及动作执行的时间，导致了原来的N3这句能够捕捉到T3动作的几率变的很大。并且可以进一步实验：修改T3的时间和N2、N3之间的延时时间，让延时时间大于T3时间，实验结果是M10.2必然会被置位。逐步增大T3时间或者减小延时时间或者两者同时进行，则逐渐开始出现M10.2不能被置位的情况，时差越大，被置位的几率越低。实际上，在原程序中，如果把N1和N2的位置颠倒，也就是让T3滞后一个周期被复位，或者将N3语句提前，争取在T3被复位前捕捉动作，捕捉的成功率就会比原程序大了不少。
和Harry_dong 结论不同的是在timer的动作上。是不是timer的时间到了就有动作，我的观点是，动作和时间到还是没到不是必然的结果，而是在于程序的调用上，时间是动作的前提而已。也就是说，如果时间没到，则一定不会有动作，如果时间到了，而程序还没有执行到对timer动作的调用时，还谈不上timer的动作，只有执行到对timer动作的调用程序才体会到timer的动作。换句话说，timer从被触发开始，在没有被复位之前，脱离了程序和扫描周期在计时，计时到了之后，才在相应的程序语句中体现出动作。

---