关于定时器的问题

只看该作者 · 2010-8-11 22:49

定时器0初始化函数和中断处理如下：

void Init_timer0(uint8 x)
{
T0TC = 0;                //计时器初始值为0
T0PR = 0;                //不分频
T0MR0 = Fpclk / x;       //定时时间长度为 1/x 秒
T0MCR = 0x03;             //开MR0中断在比较后复位TC
T0TCR = 0x01;             //开启计时器
}

调用上面函数时X=100 即10MS一次的中断。

void __irq IRQ_TIMER0(void)
{

  txd_time_count0++;

  if(txd_time_count0 >= 6000)
  {
txd_time_count0 = 0;
U0THR = 'M';
  }


  T0IR = 0x01;                   //该位写入一可复位中断
  VICVectAddr = 0x00;

}

程序里除喂狗外没有其它地方关中断，也没有其它中断被启用。

按照程序来说，应该是每分钟向外发一次数据，可是从串口软件读到的数据如下：

可以看到，发送的数据每3、4分钟左右会有一个16MS的误差，如果把中断的处理时间和中断产生的时间的误差算在里面的话，那这个时间的误差应该是逐渐增加的才对，为什么会出现缩短的现象呢？

请问这个误差是怎样产生的？该如何避免？

PS:CPU用的是LPC2132  ,11.0592MHZ晶振

RX:4D  (08:35:23:372)
RX:4D  (08:36:23:372)
RX:4D  (08:37:23:372)
RX:4D  (08:38:23:372)
RX:4D  (08:39:23:356)
RX:4D  (08:40:23:356)
RX:4D  (08:41:23:356)
RX:4D  (08:42:23:340)
RX:4D  (08:43:23:340)
RX:4D  (08:44:23:340)
RX:4D  (08:45:23:340)
RX:4D  (08:46:23:325)
RX:4D  (08:47:23:325)
RX:4D  (08:48:23:326)
RX:4D  (08:49:23:310)
RX:4D  (08:50:23:310)
RX:4D  (08:51:23:309)
RX:4D  (08:52:23:309)
RX:4D  (08:53:23:293)
RX:4D  (08:54:23:293)
RX:4D  (08:55:23:292)
RX:4D  (08:56:23:276)
RX:4D  (08:57:23:276)
RX:4D  (08:58:23:276)
RX:4D  (08:59:23:416)
RX:4D  (09:00:23:259)
RX:4D  (09:01:23:259)
RX:4D  (09:02:23:258)
RX:4D  (09:03:23:242)
RX:4D  (09:04:23:242)
RX:4D  (09:05:23:242)
RX:4D  (09:06:23:241)
RX:4D  (09:07:23:225)
RX:4D  (09:08:23:225)
RX:4D  (09:09:23:224)
RX:4D  (09:10:23:208)
RX:4D  (09:11:23:208)
RX:4D  (09:12:23:208)
RX:4D  (09:13:23:207)
RX:4D  (09:14:23:191)
RX:4D  (09:15:23:191)
RX:4D  (09:16:23:190)
RX:4D  (09:17:23:174)
RX:4D  (09:18:23:174)
RX:4D  (09:19:23:176)
RX:4D  (09:20:23:177)
RX:4D  (09:21:23:162)
RX:4D  (09:22:23:163)
RX:4D  (09:23:23:164)
RX:4D  (09:24:23:149)
RX:4D  (09:25:23:149)
RX:4D  (09:26:23:149)
RX:4D  (09:27:23:149)
RX:4D  (09:28:23:133)
RX:4D  (09:29:23:133)
RX:4D  (09:30:23:133)
RX:4D  (09:31:23:117)
RX:4D  (09:32:23:117)
RX:4D  (09:33:23:117)
RX:4D  (09:34:23:117)
RX:4D  (09:35:23:101)
RX:4D  (09:36:23:100)
RX:4D  (09:37:23:099)
RX:4D  (09:38:23:083)
RX:4D  (09:39:23:082)
RX:4D  (09:40:23:082)
RX:4D  (09:41:23:081)
RX:4D  (09:42:23:064)
RX:4D  (09:43:23:064)
RX:4D  (09:44:23:063)
RX:4D  (09:45:23:046)
RX:4D  (09:46:23:046)
RX:4D  (09:47:23:046)
RX:4D  (09:48:23:045)
RX:4D  (09:49:23:029)
RX:4D  (09:50:23:029)
RX:4D  (09:51:23:028)
RX:4D  (09:52:23:012)
RX:4D  (09:53:23:012)
RX:4D  (09:54:23:012)
RX:4D  (09:55:23:011)
RX:4D  (09:56:22:995)
RX:4D  (09:57:22:995)
RX:4D  (09:58:22:995)
RX:4D  (09:59:22:979)
RX:4D  (10:00:22:978)
RX:4D  (10:01:22:978)
RX:4D  (10:02:22:977)
RX:4D  (10:03:22:961)
RX:4D  (10:04:22:961)
RX:4D  (10:05:22:961)
RX:4D  (10:06:22:945)
RX:4D  (10:07:22:944)
RX:4D  (10:08:22:944)
RX:4D  (10:09:22:943)
RX:4D  (10:10:22:927)
RX:4D  (10:11:22:927)
RX:4D  (10:12:22:927)
RX:4D  (10:13:22:911)
RX:4D  (10:14:22:910)
RX:4D  (10:15:22:910)
RX:4D  (10:16:22:910)
RX:4D  (10:17:22:894)
RX:4D  (10:18:22:893)
RX:4D  (10:19:22:893)
RX:4D  (10:20:22:877)
RX:4D  (10:21:22:876)
RX:4D  (10:22:22:876)
RX:4D  (10:23:22:876)
RX:4D  (10:24:22:860)
RX:4D  (10:25:22:859)
RX:4D  (10:26:22:859)
RX:4D  (10:27:22:842)
RX:4D  (10:28:22:842)
RX:4D  (10:29:22:841)
RX:4D  (10:30:22:840)
RX:4D  (10:31:22:824)
RX:4D  (10:32:22:823)
RX:4D  (10:33:22:822)
RX:4D  (10:34:22:806)
RX:4D  (10:35:22:805)
RX:4D  (10:36:22:804)
RX:4D  (10:37:22:804)
RX:4D  (10:38:22:788)
RX:4D  (10:39:22:787)
RX:4D  (10:40:22:787)
RX:4D  (10:41:22:771)
RX:4D  (10:42:22:771)
RX:4D  (10:43:22:770)
RX:4D  (10:44:22:770)
RX:4D  (10:45:22:754)
RX:4D  (10:46:22:754)
RX:4D  (10:47:22:753)
RX:4D  (10:48:22:737)
RX:4D  (10:49:22:737)
RX:4D  (10:50:22:736)
RX:4D  (10:51:22:736)
RX:4D  (10:52:22:720)
RX:4D  (10:53:22:720)
RX:4D  (10:54:22:719)
RX:4D  (10:55:22:750)
RX:4D  (10:56:22:703)
RX:4D  (10:57:22:702)
RX:4D  (10:58:22:702)
RX:4D  (10:59:22:686)
RX:4D  (11:00:22:686)
RX:4D  (11:01:22:687)
RX:4D  (11:02:22:689)
RX:4D  (11:03:22:691)
RX:4D  (11:04:22:693)
RX:4D  (11:05:22:695)
RX:4D  (11:06:22:680)
RX:4D  (11:07:22:680)
RX:4D  (11:08:22:681)
RX:4D  (11:09:22:665)

只看该作者 · 2010-8-11 22:49

还有，一个PCLK周期为1/11059200 秒的话，匹配值MR0=110592 ,如果不考虑晶振本身的误差的话。

这个10MS的中断其实是完全没有误差的是吧？？？？

只看该作者 · 2010-8-12 20:24

你是不是在ＰＣ机上用其它软件接收的数据？

确认下你的接收软件能准备计算出接收到数据的时间。从你发的数据来看，不像是定时器设置有问题，因为某些连续接收到的数据中，其接收时间是一样的。无论定时器设置的是多大时间间隔发数据，都不会产生几个数据发送的时间相等。

很可能的原因是，ＰＣ机串口接受到数据后，ＸＰ系统会对数据进行缓冲。接收程序的软件也不是在收到串口数据后，会立即打印显示。而是会尽量一次读多个，如果等待超时，才会将缓冲中已有的数据显示出来。这种起时时间会达到ms级的。

只看该作者 · 2010-8-14 00:11

本帖最后由 6019实验室于 2010-8-14 09:55 编辑

问题解决了没？

只看该作者 · 2010-8-14 00:24

本帖最后由米其林r 于 2010-8-14 09:57 编辑

我也遇到同样的问题，顶

只看该作者 · 2010-8-14 10:01

是在网上找的串口工具，能显示接收数据的时间的，我发送的数据只有4D，从程序里也可以看到，就是‘M’，前面的RX:和时间都是软件加上去的。

数据都是一分钟发一次的，没有连续发的情况。

我知道电脑串口也是基于16C550的规范，可能包含接收中断和超时中断，包括您说的XP系统的缓冲，这些应该只会让接收数据的周期延长，比如我一分钟发一次，但接收到的时间可能是1分钟10毫秒，但数据上来看，这个时间是每三四分钟会有一个缩短。虽然这个缩短不累积，但会让整体的发送时间前移。

怎么会有时间缩短的情况呢？

只看该作者 · 2010-8-14 10:15

我觉得你用串口发数据来检测定时器定时正确性这种方法是有问题的。你的测量结果不仅受定时器本身设置影响，而且也会受到串口收发过程、以及上位机接收数据的软件影响。所以，为了更好的测量，应该排除串口的不确定影响，不使用串口，而可以通过在ＩＯ输出方波，用逻辑分析仪测量时间的准确性。或者如果你用的KEIL，可以使用自带的软件信真器进行仿真，查看１０ＭＳ的定时是否精确。

只看该作者 · 2010-8-14 21:29

确实这个时间不会很准，115200的波特率，不考虑软件的延迟，也会有几毫秒的误差，我奇怪的就是，所有的影响，应该都是让时间周期延长，怎么会缩短呢？

KEIL仿真的结果是每次进中断的时间在逐渐加长，如下：

0.01005918

0.02006056

0.03005710

0.04005731

0.05005789

0.06005737

0.07005744

0.08005803

0.09005862

0.10005773

1.00007322

2.00008156

3.00009094

4.00010062

5.00010869

6.00011775

7.00012677

8.00013584

9.00014490

10.00015390

这个我也不大理解，按道理说，应该是一样的才对啊。

只看该作者 · 2010-8-14 21:51

既然上面的定时器测试没什么问题，那我觉得问题就出在上位机接受串口数据这一过程中。这种测量方面本来就是不准备的。

　　定时器定时仿真结果有偏差，可能的问题有：１、时钟频率没有计算正确；２、定时器没有配置正确。

　　你的输入参数x是多少，Fpclk又是多少？

只看该作者 · 2010-8-16 22:37

x=100

Fpclk=11059200

除过以后是整数，所以如果不考虑晶本身的偏差，也就是在仿真的情况下，这个时间应该是很准确的吧？

关于定时器的问题

相关下载

相关帖子