昨天想着办法测试了许久，发现这个时间存在误差问题，感谢一楼给我的启示，本身也是一个初学者，昨天大概推算了下，也许是如下的原因造成的。废话不多说，如下：

1、首先解释下大致原理，因为定时器是所谓的异步刷新效果，意思就是假如在一个程序循环周期执行中，定时器可能在程序扫描到任何一行的时候定时的时间到了。现在就是有两种可能，一种是程序扫描到T0定时器之前的任何一行，再假如是第2行，此时系统会直接读取T0的状态为1，则系统执行时候此时就读取T0=1的状态往下执行，直至执行到第N行时候，运算结果在这一行又把T0给复位了。此时系统读取的T0的状态就变成了T0=0，所以第N行以后的程序永远无法接通了。但是还有一种情况就是系统读取到N行以后时候，此时定时器时间走完，此时T0=1了，从执行到的程序段开始往后的程序段均是RLO=1，继而到下一个周期第一段程序段，此时T0依旧为1,继续往下执行到第N段以后此时才会复位T0，第二种情况就产生了一个时间误差，假如是从N+1段开始的T0计时结束，此时定时器是开始停止计时的，它需要下一个周期重新走到第N段时候才会复位 重新计时，所以相对于系统时钟，定时器有个微小的时间停滞了。随着运行周期的累计，这个时间就会慢慢累加，同样在相同时间段，定时器启动的次数并没有执行那么多次，中间有短暂的暂停。另外还有一个情况就是定时器时间到是在程序执行到第N行时候这个概率也很小，这样的情况就是N行以前的程序没有变化（因为不可能倒过去执行），N行以后的是通过第N行运算的结果T0=0去执行，大致就是这个情况了。

2、验证如下，很多讲解是说这样自循环启动以后的T0无法接通，其实是错误的理解。是巧合没有接通。我在如下程序重复调用T0了25次，将定时器定时时间到大概率放到了定时器程序段的后面，故而产生了验证结果。

从上图可以看到，T0后的程序段完全得到了很大概率的执行了。

这个也解释了为啥定时器长时间定时循环累加比系统时钟循环累加会少的原因了。很大概率是累加小于系统时钟，所以长时间循环定时推系统时钟定时。定时器对计数要求存在明显误差了。听了很多学习视频对这个事都是模糊带过，只是希望初学者记住这个用法就行了。有点不负责任的授业。