SMW22用于计时的实验

最近在smart200的论坛上看到一个用SMW22累加计时发现极大偏差的帖子，通过参与讨论终觉还是实践是检验真理的唯一标准。遗憾的是手头仅有老版本的200CPU（不支持BITIME，CITIME指令）实物可供实验，编制了如下图片的小程序，程序中有意通过改变一段程序的循环次数来让扫描周期发生振荡变化，实验结果在后面的图片中，累加SMW22计时的结果让人满意。在smart 200上相信只要把扫描周期控制在不低于1毫秒时能得到同样的结果。有条件的朋友不妨在smart 200也试一试。

佩服winter938老师对事认真的做法，学习了！

100个扫描周期，都是2.5，那SMW22到底会是显示多少？是有时显示2有时显示3，平均下来是2.5吗？

照你的实验，好像是这样，SMW22虽然只显示毫秒个位，但是仍在内部算的是绝对时间，就象Bitime。

是这样理解吗？

 SMW22的数值是最后的一个扫描周期时间，也就是上一个扫描周期时间，每个扫描周期都在更新，并且数值存在取整或者零头进1，不清楚；使用SMW22来累计时间肯定不是太准确。

938理解是不错，进位或者截取小数都可以，关键是内部绝对就是了。

不过。为何smw22不出现0毫秒？就这，是我对它的信任程度降低很多的原因。前一个周期进位了，下一个周期应该少了的。但是这样又不太符合最后扫描周期的名字。

很难说请。除非一个事情……扫描周期由系统保证最小要拖延到1毫秒。

zbhdm做的实验记录了SMW22和T32同时计时的前10次扫描的数据，我把这些数据放在了一张图片里，大家可以自行分析，后面三列数据扫描周期通过改变部分程序循环次数被有意改变了长度。4楼的疑问通过第一列数据可以得到一些解释。

第二列的VW102到VW108累计和VW208数据吻合出现了偏差1，这是可以理解的也完全可以接受。其它数据均完美一致。第一列的数据说明此时扫描周期是小于1毫秒的，但SMW22均表现为1毫秒，直接用它累加计时会出现计时错误，是错误不是误差。

学习，938老师分析的不错。

938，再怎么努力smw22也没有bitime好用。22是一个周期内不变的，Bitime是公共资源，硬件时间尺。任何子程序中断程序读取这个尺，都是实时值。可靠太多了。

SMW22是内部资源，不是提供给用户使用的资源。它和很多其它内部资源一样不向用户提供详细使用机制，也没有必要提供。用户对它的使用机制只能靠猜测，使用SMW22用于计时存在不可预知的结果。

累计时间有其它更方便更没有疑问的方法。

BITIME和CITIME是硬时间尺，但用户主程序中执行这两个指令都是以扫描周期为周期反复执行的，就像T32计时是毫秒级实时刷新的但主程序中周期性的去读取获得的数值和SMW22的却是一致的。在以扫描周期这种频度的读取追求所谓的毫秒级分辨率会失去意义。中断程序中去读取另当别论。记得我以前说过在主程序中使用T32之类的毫秒级定时器无法保证准确的启动和及时地读取状态（假如此时扫描周期达到了数毫秒），从而导致主程序中的T32失去了其毫秒级刷新的优势。所以T32应该在中断程序中启动，并启用其相应的中断。

由此想到200系统还有一个10毫秒分辨率的定时器，其刷新是在每个扫描周期开始刷新，累加SMW22计时和它相当吧，还勉强可以算个1毫秒的分辨率。

BITIM 开始间隔时间指令以及 CITIM计算间隔时间指令用来那些类似累计时间的场合那是再全美不过，SMW22用于计时没法与之相比。甚至在多数情况下，1mS定时器的使用都没有BITIM 、CITIM方便。

BITIM 和CITIM也是1mS分辨率的，并且可以多次调用，这就大大缓解了1mS的定时器资源的稀缺。

自从BITIM 和CITIM在200较高版本编程软件以及SMART编程软件中出现后，1mS的定时器的资源不再稀缺。

大大缓解了1ms的定时器资源。

对啊。我现在有些情况，自己有做库程序的，计时都不使用计时器了。

其实我想强调一点的是在主程序周期扫描执行的定时受困于这种周期循环毫秒级的定时其实始终存在接近扫描周期的误差，在这种情况下用SMW22累计定时效果也就差不多。其次就是实验证明了SMW22内部也是一个“绝对时间尺”，和T32，BITIM一样是一点不漏的在持续计时只是做不到随时刷新。

有一个情况看看t32怎么处理？

做一个固定周期脉冲的程序。比如100毫秒。

但是扫描周期有10 毫秒。那么以T32做主要计时工具的话有些什么方法做这个信号？

100毫秒产生一个上升缘。供扫描用。

计时到达那刻，未扫描到T32的程序，等扫描到了T32的时候，时间过去了一点点。然后置一个位。然后呢？

下面这个图片中的程序想模拟系统的BITIM指令，用的T32每30秒产生一个中断。没有上机实测。

CITIM指令也可以模拟，先调用MY_BITIM捕获当前时钟，再减去先前通过MY_BITIM捕获的时钟即可。

32位1ms定时区间足够长了。

一个循环时间长达49天，可识别的最长时间区间也有24天，几乎无敌。

思路不错，这是国内工程师的优势，但不能站在实用化，工程化的角度去解决问题，又是国内工程师的通病。T32的资源太少，不能满足程序多次调用的需求。

针对15楼最近有时间有机器特意实验了一下

这是主程序

这是SMB34定时121毫秒循环中断程序

这是T32定时30000毫秒中断

这是MYBITIM子程序，只有输出参数CLOCK，输出当前时钟

这是实验数据，可以发现D100-D196规律地记录了时钟间隔是121毫秒