回复【51楼】haozi007  
来跟大家汇报一下今天晚上的测试结果，貌似准确了。
方法就是受48楼的朋友启发，重装th0时考虑已有的计数进位，只是我没有关计数器。
我很惊讶，为什么中断跳转过程难道需要这么长时间？
下面是刚刚出炉的测试数据：

-----------------------------------------------------------------------

这个数据现在只能说定时看起来准确了，其实问题很严重：看你在50楼发上来的数据就知道了，每两次收到数据的时间都比5分钟略长一点（头两行间隔的4秒多认为是上位机的问题，其他时间间隔最长的也有2.156秒，2156ms/300s≈72ms/s，快到1%了）。

不是说“中断跳转过程”有这么长，而在于在中断跳转之前还有“中断响应时间”存在（比如有很长一段关中断的时间、比如更高优先级或同级的中断服务程序在运行）。



如果一定要时间很准确，就一定要解决上面两个问题：

1、要减小关中断引起的中断响应延迟，就要尽量减少关中断、及时要关也尽量晚关并尽量早开（关中断过程中只处理临界区代码）。

2、要解决更高级中断服务程序或同优先级中断服务程序引起的中断响应延迟，就只能把T0的中断单独设为高优先级。这时候就只剩低优先级可以用了，如果其余中断服务程序还要区分优先级怎么办呢？
　　这时候可以通过类似Linux中对中断服务程序的“上半段+下半段”处理方式给最低优先级的中断服务程序加个“壳”，让它们在主程序优先级上运行。
　　具体的实现方式就是，把“中优先级”中断跟“低优先级”中断在IP中的对应位都设为0，但在“低优先级”中断服务程序中只把
实际的中断服务程序的入口地址给压入堆栈就返回，实际的中断服务程序写成一般子程序的形式（函数头部后面不带“interrupt N”），最后禁止这个子程序与其他子程序进行覆盖分析就好（或者把它的局部变量都定义成static的）。
　　原理在于，“低优先级”中断服务程序中把实际入口压入堆栈后返回，编译器生成的是RETI指令，这时候就把51的“优先级锁”给复位了，CPU运行在主程序级别上，可以响应任何新的中断请求，但由于我们的压栈操作，这里的“返回”并没有回到主程序中的“断点”，而是“返回”到了实际的中断服务程序入口，在实际的中断服务程序返回的时候才真正返回到原来“断点”——这样就实现了在主程序级别上运行的“低优先级”中断服务程序，当然了，实际的中断服务程序中还是要保护“现场”。